Strange Value in EXE header!

Question

I've seen a strange value placed in EXE header

00000000 :4D 5A 90 00 03 00 00 00 - 04 00 00 00 FF FF 00 00
00000010 :B8 00 00 00 00 00 00 00 - 40 00 00 00 00 00 00 00
00000020 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00000030 :00 00 00 00 00 00 00 00 - 00 00 00 00 A8 00 00 00

00000030 :00 00 00 00 00 00 00 00 - 00 00 00 00 A8 00 00 00 <-

I don't know what is A8 doing there but if I replace it with zeros My program doesn't execute.

In one word:What is that??

EDIT:

Could you give me also link to the full MS DOS header ?

Answer 1

DWORD at offset 0x3c is the offset of the new EXE header, aka IMAGE_NT_HEADERS. So if you change the value there, the PE loader cannot find the new EXE header.

Answer 2

The first part of a PE is the MSDOS stub; at 0x3C (where your "A8" is) there's the offset to the PE file signature. If you zero it, the loader won't be able to find the PE signature, and will refuse to load it (or load it as just an MS-DOS executable, I didn't try). For more information, see the PE format specifications.

Answer 3

I suspect that it is the offset to the new PE header, the first 30 odd bytes are the MS-DOS header, that offset into the file where 'A8' resides in corresponds to the field in the structure _IMAGE_DOS_HEADER called LONG e_lfanew; // File address of new exe header; It is that value 'A8' would be part of the new IMAGE_NT_HEADER which contains this information

• DWORD Signature;
• _IMAGE_FILE_HEADER FileHeader;
• _IMAGE_OPTIONAL_HEADER OptionalHeader;

The very first two bytes are the original MS-DOS header into the executable as shown by this constant: WORD IMAGE_DOS_SIGNATURE = 0x5A4D; // MZ; The IMAGE_NT_HEADER has this signature to identify that it is an executable for NT platforms DWORD IMAGE_NT_SIGNATURE = 0x00004550; // PE00;

You will find all this information in a header file called pe.h.

What happened there is you wiped out the value 'A8', the loader could not find the IMAGE_NT_HEADER and hence failed.

Hope this helps, Best regards, Tom.