I am currently disassembling a test program I made to better understand how things work under the hood. I am using Cheat Engine, which has disassembly and debugging capabilities, similar to Ollydbg.
I noticed that there are inconsistencies in the endianness used to display data. Here is a picture:
If the data is being displayed in a fixed size container, such as registers, immediate instruction operands, or a stack item, then the data will be displayed in big-endian format.
If the data is displayed in a continuous container, such as the memory dump window in the bottom left, or in the machine code bytes dump under the "bytes" column at the top left, the same data will be displayed in little endian.
However, I am unsure if this is a feature of the display, or a feature of the ISA (data is converted in endianness when written to certain locations, or something).
Why am I seeing this?
CodePudding user response：
That's not intended to be "big endian", rather just a numeric value, written in normal place-value notation, printed without spaces. Like how 3 * 5 = 15, not 51 decimal.
The actual dump of machine-code bytes still uses the machine-code byte order, despite grouping together without spaces.
But the disassembly of course uses numeric values, just like you'd write in asm source for any assembler. There are no mainstream x86 assemblers that take numeric hex values in memory order rather than place-value order.
CodePudding user response：
Generally, hex digits glued together like 61616100 should be interpreted as a value, while separated ones like 00 61 61 61 as a byte sequence.
But your debugger has made a poor choice on representation of the immediate operands in instruction machine code bytes. It should either have separated the bytes (at least by a thin space if there's still a desire to group them), or shown them as a value.
The latter option is not unheard of. Agner Fog's objconv, for example, disassembles the instruction C7 04 24 00 61 61 61 (taken from the OP) as
C7. 04 24, 61616100 mov dword [esp], 1633771776
Note the 61616100 that's a value, rather than several bytes stuck together.
So, in conclusion, just get used to this (and only this) place having this peculiarity, or make a feature request for the authors of the debugger to add an option to show immediates as values instead of bytes glued together.