Handle short MZ files

[msbit]

As per:

https://reverseengineering.stackexchange.com/questions/12993/how-to-quickly-distinguish-pe-dll-dos-mz-files-based-on-magic-numbers#answer-14031

check whether the value for e_lfanew is within the file, as old MZ files may use that location for something else, creating an invalid offset

[msbit]

This came up with the attached file, as it has 0x00000100 (65536) at offset 0x3c, which is beyond the size of the file (6506 bytes) causing a segfault when attempting to read the PE header.

main.zip

[tkchia]

Hello @msbit, hello @zfigura,

According to an old Developer Note from Microsoft (see https://jeffpar.github.io/kbarchive/kb/065/Q65122/ and elsewhere), the PE/NE header offset field is only valid if the MZ relocation table offset (e_lfarlc) is exactly 0x40:

The word at offset 18h in the old-style .EXE header contains the relative byte offset to the stub program's relocation table. If this offset is 40h, then the double word at offset 3Ch is assumed to be the relative byte offset from the beginning of the file to the beginning of the segmented executable header.

However, I realize not all new-style executables follow this — e.g. some UEFI modules blank out all the MZ header fields except the MZ magic and e_lfanew.

Perhaps a useful preliminary check, might be to see if e_lfarlc is exactly 0x40, or is a bogus value (< 0x1c).

Thank you!