So I have started reverse engineering an old LE executable. So to get a better understanding of the format. I started by writing a parser for this format. Using the following resources I have made quite some progress.



But now I'm encountering what seems like a fault in the format description when parsing the Fixup Record Table, as it is called by the vexillium.org link.

When parsing this particular binaries Fixup Record Table, there seems to be 2 bytes extra in each entry. So I was wondering if there is something wrong with my understanding of the format or if the format description is incomplete.

PS. I am aware that I should use the Fixup Page Table to extract the fixups that correspond with each page, and I do this in the code, but it is not relevant for the issue I'm having. Except for the fact that there are indeed Fixup Record Table entries according to the Fixup Page Table.

In the binary on the offset of the Fixup Record Table are the following bytes.

07 00 AB 09 02 54 85 07 00 DB 0A 02 40 85 07 00
D2 0A 02 40 85 07 00 AF 0A 02 40 85 07 00 66 0A
02 80 85 07 00 4D 0B 02 83 18 07 00 E3 0B 02 80
85 07 00 FA 0C 02 83 18 07 10 92 0C 01 AC 0F 01
00 07 00 5F 0C 02 83 18 07 00 73 0D 02 8C 00 07
10 53 0E 01 B4 0E 01 00 07 10 F6 0D 01 B4 0E 01
00 07 00 F5 0E 02 8C 00 07 10 A6 0E 01 AC 0F 01
00 07 10 9F 0E 01 30 0F 01 00 07 10 89 0F 02 FA

So if we look at the format description of the Fixup Record Table on Vexillium.org I would parse this as follows.

Reloc_addres_type is 0x07 Reloc_type is 0x00

Because Reloc_addres_type bit 5 is not set we are parsing "non list" entries

Relocation offset should always be parsed and is 0x09AB

Because Reloc_type = 0, the lowest 2 bits are '0', thus this is an internal fixup.

So we parse a Target segment number of one byte, this is 0x02

We should be done now and parse the next entry. But if we look at the structure of the binary, we can see 2 bytes after the current byte is another 0x07 entry. And if we were to continue parsing it would will fail within 2 parse operation because of the lower 2 bits of the reloc_type both becoming '1' and there is no format description for this type as it is labeled OSFIXUP???.

Here is some sample output from my parser. It stops after the 2nd entry because the 3rd entry encouters the reloc type with that ends in '11'

reloc_addres_type: 7
reloc_type: 0
    offset: 09ab
        segment_number: 2

reloc_addres_type: 84
reloc_type: 133
    offset: 0007
        imported_module_name_index: 219
        ordinal_value: 10
        abs_add_value:  16386
        extra: --
  • assuming that the word is an offset into a table, have you checked what's there in each table, to see if one of them makes sense? It's likely that the docs are missing that reference, and everyone copied blindly. Jun 26, 2016 at 15:43

2 Answers 2


The additional 16 bits is the target offset (TRGOFF in the textfiles doc).

I recommend you to check your parser against Hex-Rays' Extensive File Dumper.


So I started looking for extra sources on the LE format after the suggestions to cross-validate my parser with hex-rays one, It turns out there is an extra field in the InternalFixup type of fixups called target offset, it can however either be 16-bits or 32-bits depending on the "32-bit target offset" flag. which is the 4th bit (starting at 0=LSB) in the second byte of the entry

Source: LX format and more specifically figure 2 of that paper

Note that as far as I understand LE and LX are the same format but LE has mixed 16 and 32 bit instructions while LX only has 32 bit instructions.

Note that this description also describes the '11' case talked about in my question which refers to an 'InternalEntry'.

EDIT: When reading over the textfiles explanation again, it seems to convey the same ideas as the new source I found, although the way textfiles presented it felt weird and I couldn't wrap my head around it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.