0

I have a hexdump of a Windows binary and identified the COFF header in this executable by looking at the COFF offset:

0000080: 4550 0000 014c 0003 6ec8 3add 0000 0000
0000090: 0000 0000 00e0 010f 010b 0301 2000 0000

We can further verify this is the file header because of its 4 byte signature: 'PE' followed by two NULL bytes. Clearly, the format appears to be expressed in little endian because if we were to write PE explicitly, we would have the hex 50 45.

If we look at the PE format specification and carry this observation though, the NumberOfSections field (offset 2 bytes from the end of the signature that are skipped for the Machine field), we determine there are 768 sections (03 00 in little endian). This contradicts the spec, stating that the Windows loader limits the number of sections to 96.

Furthermore, byte ordering in the Timestamp field (next 4 bytes) seems odd because only the permutation 3add 6ec8 produces a Unix timestamp that is in the past.

Is there a more explicitly defined byte ordering that I'm missing? Why do the byte orderings between the fields seem inconsistent?

James Taylor
  • 6,158
  • 8
  • 48
  • 74

1 Answers1

1

Your hexdump is using a misleading format. Try again with byte format (-c option)

In the dump you have, the output is already byte swapped. Things appear in the order

(byte1)(byte0) ' ' (byte3)(byte2) ' ' (byte5)(byte4) ' '

and so on.

The PE header is, as you mentioned

50 45

Hexdump's default display rules take these two bytes and interpret them as a 16-bit little endian integer, 0x4550, which is why the display is 4550

The number of sections is 3, (03 00 in the file). I don't know why you said 03 00 is 768 in little endian because that's just wrong. In this case, the 16-bit LE default format of hexdump actually worked because it is a 16-bit field, the decode of 0x0003 is correct.

The timestamp is displayed as 6ec8 3add but the actual bytes in the file are c8 6e dd 3a. Now the 32-bit field size and the 16-bit hexdump format mismatch, leading to your total confusion.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • Would that mean `0003` from the hexdump be actually expressed as `03 00`? If so, I think that's more linked sections than an executable can have. 3 seems much more reasonable, but I'm not sure. – James Taylor Feb 04 '18 at 18:45
  • 1
    The actual bytes that appear in the file, `03 00`, is little-endian for 3. Not 768. – Ben Voigt Feb 04 '18 at 18:47
  • @JamesTaylor: Your problem is that you're trying to swap what hexdump has already swapped, but not keeping track of the number of swaps. – Ben Voigt Feb 04 '18 at 18:48
  • Ah, makes sense. Thank you! – James Taylor Feb 04 '18 at 18:49