How can I view the data at the address of the first operand in gdb?
cmp [ebp+eax], edi
I tried using:
print /d $ebp
print /d $eax
and manually adding the values to make the address, but was not sure what to do next, or if there was an easier way...
(gdb) help x
Examine memory: x/FMT ADDRESS.
ADDRESS is an expression for the memory address to examine.
FMT is a repeat count followed by a format letter and a size letter.
Format letters are o(octal), x(hex), d(decimal), u(unsigned decimal),
t(binary), f(float), a(address), i(instruction), c(char) and s(string).
Size letters are b(byte), h(halfword), w(word), g(giant, 8 bytes).
The specified number of objects of the specified size are printed
according to the format.
For your example:
x/d $ebp+$eax
Related
Basically im trying to get the last modified timestamp of a file without external libraries
OS: Windows
Code:
local cache_out = io.popen("dir /T:W %CD%\\data\\actions\\scripts\\cache.lua", "r")
local cache_data = cache_out:read("*a")
It prints:
My question is: How can start reading from 29/06/2021 to get the modified time which in this case is '04:45'? I know it can be done using string.find or string.gmatch but i have no clue how
Lua uses regex with its own classes for matching characters:
. -- all characters
%a -- letters
%c -- control characters
%d -- digits
%l -- lower case letters
%p -- punctuation characters
%s -- space characters
%u -- upper case letters
%w -- alphanumeric characters
%x -- hexadecimal digits
%z -- the character with representation 0.
To get the class of all characters except the group just use uppercase. For example, if you want to match any character except space (like tab and space) you would use %S.
To match multiple parts of a string you can use parenthesis in string.match() like so
local d, t, _ = string.match(cache_data, "(%d%d/%d%d/%d+)%s+(%d%d:%d%d)%s+([ap].m.)")
and just validate the data for anything other than nil.
For more detailed info I recommend reading this https://www.lua.org/pil/20.2.html
I'm trying to define custom characters on thermal printer NCR 7199.
I used ESC/POS command
ESC & y c1 c2 x d1...dn
and it works fine. But this command can change only characters in range 32-126, and those characters are latin letters and common symbols.
I'd prefer to replace characters with codes 8E-8F, for example, but cannot do it using this command.
Is it possible? Or is there any other ESC/POS command for user-defined characters?
UPD.
It seems like a firmware update can fix this problem. Firmware version on our printer is v99.21, and I saw this in release notes:
v99.25 "based on v99.24"
1. Allowed User-defined characters defined range from 20H to FFH in 7199 Emulation mode
Another user-defined character setting command for Kanji is for printers that support the MBCS character set, which is not what you want.
FS 2
Define user-defined Kanji characters
However, although it is unclear whether NCR 7199 supports it, ESC/POS has the ability to customize the font of the user-defined code page rather than the individual characters.
Please refer to the contents of the following pages.
GS ( E <Function 7>
Copy the user-defined page
GS ( E <Function 8>
Define the data (column format) for the character code page
GS ( E <Function 9>
Define the data (raster format) for the character code page
GS ( E <Function 10>
Delete the data for the character code page
Problem solved by updating firmware.
After updating "Main Firmware" to v99.27 (it seems that version must be greater or equal v99.25) and changing Emulation mode to "NCR 7199" I was finally able to define characters in all range 20-FF.
I need to be able to print Hebrew characters on my Epson TM-T20ii. I am trying to get my printer to switch to character code page 36(PC862) using
ESC t36
for some reason the printer is switching to code page 3 and then printing the number 6.
Is there a way to let the printer know that the 6 is part of my command?
If you know of a different workaround please comment below.
Thanks
You are making a mistake, you aren't meant to replace n with an actual number.
The proper syntax in your case would be ←t$
Explanation: the manual says "ESC t n", n referring to the page sheet, however you don't replace n with a number rather with the ASCII character n, so in your example 36 = $ because $ is the 36th character on the ASCII table.
I am very confused with the following gdb output. I am debugging a program that processes a text file. The first word in the file is "the" and the gdb output looks as follows:
"The":
(gdb) p *(char*)0x7fffffff9d30
$12 = 84 'T'
(gdb) p *(char*)0x7fffffff9d34
$13 = 104 'h'
(gdb) p *(char*)0x7fffffff9d38
$14 = 101 'e'
A character is one byte, so when I increase the address of 'T' by 8 bits I should find 'h' there. But the address of 'h' is only 4 bits farther. What am I missing here?
Didn't realize that these are Wchar_t (wide characters).
FWIW, in situations like this you might like to use the "x" command to dump memory. This avoids any possible confusion caused by types and operators.
While processing an EDI 210 X12 inbound file, receiving a following exception as EdiInvoice Service process failed: '', hexadecimal value 0x15, is an invalid character. Line 2, position 37.'. Because X12 Input file having a perpendicular in 106 position of ISA 16 element.
Can you please provide a solution to handle this symbol
It is not uncommon to define a segment separator like "|" is the X12 ISA segment (ISA16, character 106 of the ISA segment). Have a look at a related tutorial.
To my knowledge, characters with ASCII codes below 128 (hex 0x80) are allowed.
If your EdiInvoice service cannot handle partner-specific segment separators, you most likely have to contact the developer of your tool or the provider of your service first.
As suggested by eppye: If the sending partner can switch to an "easier" segment separator, this would also be an option, but there has to be a good reason for the partner to invest time and effort.
If the syntax of the EDI 210 X12 message conforms to the specification, the sending partner has no obligation to change anything.
No, neither CR nor CR+LF are allowed as Segment Terminator.
X12 is based on the idea of "graphical characters", to be independent of character encodings. CR is a non-printable character, not a graphical character.
The allowable chars in the basic char list are
"ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
!"&'()*+,-./:;?="
The extended character list is
"abcdefghijklmnopqrstuvwxyz%#[]_{}\|<>~^`#$"
Supporting the extended characters is a Trading Partner agreement item.
To be "X12 legal", a character from the basic set must be used. If the extended set is supported, a char from it may be used.
"X12 legal" is only as important as your trading partner thinks it is (or their software).
Using CR or CR+LF is not uncommon, even if frowned upon by purists.
Having a CR or CR+LF after each Segment Terminator is more common.
some companies indeed use non-printable character as segment terminator. AFAIK this is OK in ANSI X12. Sort of smart, as you are not allowed to use the segment terminator in your data, and data will (almost;-)) never contain hex 15. I have seen hex 07, carriage return etc..
possible solutions:
1. Contact the provider of the service, they should fix it.
2. Ask edi-partner if they can use other segment terminator.
3. pre-process the file and replace that character. Maybe not possible.
Not sure which EDI tool you're using, but another option is to define the element and segment terminators in your partner profile in your tool. I've done this in Sterling Integrator and know others support this as well.
In your case you need to confirm the trading partner of the below rule so that they may not get mistaken ISA16 with Segment Terminator or Suffix .
ISA16 (Sub Element separator)
Char
3a if the type is Hex
Limited to the values in the ASCII character set.
Segment terminator
~ if the type is Char
7e if the type is Hex.
empty
but if you do, you need to designate a suffix.This element is limited to the values in the ASCII character set.
Suffix
either None
CR (carriage return)
LF(line feed)
CRLF (carriage return/line feed).
Various combination for Segment Terminator and Suffix
Segment terminator
Segment terminator + carriage return
Segment terminator + line feed
Segment terminator + carriage return/line feed
Carriage return
Line feed
Carriage return/line feed