Dr Sly's Technical Ramblings

DOS exe header

A good description of the DOS exe header can be found at http://www.delorie.com/djgpp/doc/exe/

Finding the start of the program data:

The word at offset 0x08 tells us the size of the MZ header (0x1c or 28 paragraphs). Thus the start of program data will be offset 0x1c0 or 448 bytes (28 x 16) from the start of the file. Indeed we can find a copyright message at this location.

Finding the program entry point:

The words at offsets 0x14 and 0x16 give us the offset and (relative) segment of the program entry point respectively. To find the entry point in the program, add the (relative) segment (0x20) paragraphs, or 0x200 bytes, to the start of program data, then add the initial value of the IP register (zero in our case). We should find the program entry point at offset 0x3c0.

Calculating the program size:

The words at offsets 0x02 and 0x04 tell us the program is 12 full 512 byte blocks, plus 336 bytes in the final block. This gives a program size of (12 * 512) + 336 = 6,480 bytes. Adding this to the start offset (0x1c0) gives the program end at offset 0x1b10 (or 6928 decimal). Jumping to that location in the file, we find a bunch of zeroes, but there is something interesting at 0x1b50, that could be a windows PE header. We'll look at it in more detail later.

Relocation table

The word at offset 0x18 tells us the start of the relocation table, in our case 0x40. The word at offset 0x06 tells us the number of relocation entries (93). Each relocation entry is four bytes and consists of a 16 bit offset followed by a 16 bit segment. For each entry, the loader adds the start segment address to the word value pointed to by the segment:offset pair.

Calculate the start segment address:

We know the start of the program data (based on the word at offset 0x08) is at offset 0x1c0 from the start of the file. To find out where it was loaded into memory we can subtract the word at offset 0x16 (0x20) from the initial value in the CS register (0x020D). This gives a start segment address value of 0x01ED, representing the location the program was loaded into memory.

Let's examine the first two relocation entries:

0000:003C

0000:0040

Adding the offsets to the start of the program data, we find the file contains zeroes at offsets 0x1fc and 0x200. Comparing the memory view of the corresponding location in the loaded file (01ED:003C and 01ED:0040), we can confirm the zeroes have been altered to 0x01ED.

In fact, it appears that the bytes starting at 0x003C to 0x004F consist of five segment:offset pairs, all pointing to locations within the starting segment.

Let's look at another, non-trivial example, near the program entry point:

Look closely at the instruction at 020D:0002:

9A 02 00 7C 02    call 027C:0002

Compared with the original bytes in the source file:

9A 02 00 8F 00

Note the value 0x008F at address 020D:0005 has 0x1ED added to it, as expected to become 0x027C as part of the call instruction. Let's find the relocation entry corresponding to this address.

Look at offset 0x0054 from the beginning of the file:

0020:0005

Remember, our file was loaded into segment 0x01ED. Adding 0x0020 to the segment gives us 0x020D (the initial value of the CS register), and the 0x0005 offset leaves us the adjusted value in our call instruction!

Now we understand how the relocation table works, take a close look at the value of the relocation segments. We've already seen the five instances from 0x0000, and there's a few instances from 0x0020 and 0x0027, but the majority are from segment 0x008F. This gives us an idea about the structure of the executable code in the file.

Using the information we've discovered, we can map out the file structure.