Hex Output - Byte Order

Here is the byte order reversed, for example the last data word is aa55 and in the byte by byte output above 55 aa...

The intel computer is called a "Little Endian" computer vs "Big Endian" (PowerPC was "Big Endian"). I know that does not mean much to you, but I'll try to explain.

In a Little Endian computer, the address of any numeric value is the "Least Significant Byte" (LSB) for that number. So if you have a 16 bit number (eg. 0xAA55), the address of that number (eg. 0x076E) points to the Least Significant Byte, which in this case would be 0x55. The 16 bit number's address +1 (eg. 0x076F) will point to the "Most Significant Byte" (MSB), which in this case is 0xAA.

If this were a 32 bit number, such as the value at 0x0720, then the LSB would be 0x09, the next significant byte would be 0x2F, the next would be 0x05, and finally the MSB would be 0xFE. Reading this as a 32 bit value it would look like 0xFE052F09.

All that this really means is that when the intel computer loads data from memory into a working register, it will place the LSB in the lowest 8 bits of the register (bits 0-7), then next byte in the register's 8-15 bits, etc... The computer can load values into the working registers in 1 byte units, 2 byte units, 4 byte units, and the 64-bit intel chips can also load 8 bytes at a time. And in all cases the address of the numeric value points to the Least Significant byte.

A "Big Endian" computer always points to the Most Significant Byte of any numeric value. From a hex dump output point of view this makes sense to your brain, but the computer hardware doesn't really care, and as a programmer, I find there are some benefits to Little Endian.

Digital Equipment Corporation was also a Little Endian computer manufacture, and they had a hex dump format where the address was on the right and you read the dump lines right to left. This allowed the individual bytes to also be grouped into 16, 32, and 64 bit words without any special reformatting.

For example:

hexdump -C tmp.tmp

00000000 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e 20 |The quick brown |

00000010 66 6f 78 20 6a 75 6d 70 73 20 6f 76 65 72 20 74 |fox jumps over t|

00000020 68 65 20 6c 61 7a 79 20 64 6f 67 2e 0a |he lazy dog..|

0000002d

myhexdump tmp.tmp # my own version of DEC's hexdump utility:

20 6e 77 6f 72 62 20 6b 63 69 75 71 20 65 68 54 0 |The quick brown |

74 20 72 65 76 6f 20 73 70 6d 75 6a 20 78 6f 66 10 |fox jumps over t|

0a 2e 67 6f 64 20 79 7a 61 6c 20 65 68 20 |he lazy dog..|

You read the later Right to Left. It takes a little getting used to, but when dealing with Little Endian computers it is extremely useful.

x1/x2 means size bytes per integer. So basically you are looking at integers of 2 bytes, that would make sense to use this filter if you were looking at dumps representing 16 bits integers, but this filter is not helpful for you if what you want to see is the content of the file without interpretation. This is not specific the the Mac by the way, you will see this on any system.

I think you are just seeing the endianness of the different stored data sizes. See this article or Intel's whitepaper.

The MBR is always little-endian; that's how it was defined, irrespective of the host endianness.

You're dumping using octal and hexadecimal using the od tool, and od places the octal offset addresses along the left column, and hexadecimal in the data area organized for low-to-high addresses from left-to-right.

The last line of data is 760 to 777, which is appropriate for a 512-byte disk sector used by an MBR.

The last two addresses are thus 776 and 777, and aa55 is appropriate there. This when viewing address 776 as a little-endian word; the low byte is 776, the high byte 777.

Consider using xxd or the GUI-based (free) Hex Fiend tool, or some other tool that might provide you a better view than od does. For this task, using the fdisk tool (carefully!) or any of the various software packages available to format the MBR and the GPT structures would be more typical than using od or xxd. On Mac OS X, the MBR is usually a protective MBR, and the interesting stuff is over in the GPT. Also see Amit Singh's available tools at his Mac OS X Internals book web site.

Here is an article on and a small hunk of C code that looks at endianness, and which might provide you with a different way of looking at this stuff.