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
data:
offset: 09ab
data:
segment_number: 2
reloc_addres_type: 84
reloc_type: 133
data:
offset: 0007
data:
imported_module_name_index: 219
ordinal_value: 10
abs_add_value: 16386
extra: --