hexdump returning varying results

Chris_M · 03-20-2019, 01:57 AM

I have been playing with hex dump to look at binary files compiled with GCC, I am specifically looking at the structure of ELF files. I created a C program and compiled it and ran

Code:

hexdump temp

then ran

Code:

hexdump -C temp

where temp is the output from gcc.

In the attached images you can see the hex results are not the same for each run, temp was not recompiled in between each run of hexdump. Is anyone able to explain why I am getting different results?

allend · 03-20-2019, 02:24 AM

Welcome to the joys of Endianness and whether hexdump is reading bytes or words.

syg00 · 03-20-2019, 02:57 AM

Coming from big-endian, I find the x86 little endian format arcane beyond words.

berndbausch · 03-20-2019, 03:55 AM

Quote:

Originally Posted by Chris_M

Is anyone able to explain why I am getting different results?

Code:

$ hexdump /bin/bash | head -n1
0000000 457f 464c 0101 0001 0000 0000 0000 0000
$ hexdump -d /bin/bash|head -n1
0000000   17791   17996   00257   00001   00000   00000   00000   00000
$ hexdump -C /bin/bash | head
00000000  7f 45 4c 46 01 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|

Without options, hexdump outputs two-byte numbers. So, the first value is the number 0x457f, or decimal 17791.

However, byte 7f is located at position 0, byte 45 is located at position 1. This is so because Intel CPUs (and the ARM CPU in my tiny server, as I just confirmed) are little-endian: numbers are stored so that the lower bytes come first.

hexdump -C shows each byte as it is positioned: First 7f, then 45 and so on. This works for strings and, in general, one-byte values.

Quote:

Coming from big-endian, I find the x86 little endian format arcane beyond words.

Finally somebody who shares my pain. It was much more intuitive when UNIX ran on 68000 processors.

Chris_M · 03-20-2019, 03:30 PM

Thanks. Make sense now, just couldn't figure out what was happening