Type library for LDR_DATA_TABLE shuld be updated to differentiate the 3 linked lists

[utkonos]

Version and Platform (required):

• Binary Ninja Version: 4.2.6455
• OS: macOS
• OS Version: 15.3.2
• CPU Architecture: x64

Bug Description:
The LDR_DATA_TABLE_ENTRY offsets shown in binja are misaligned and incorrect compared to in the binary in a debugger.

Steps To Reproduce:

1. Open the binary (provided below)
2. Navigate to 0x401757
3. Change to Graph View (this was shellcode before converting to a PE, so graph view is just easier to understand).
4. Compare _LDR_DATA_TABLE_ENTRY::InLoadOrderLinks.Flink and _LDR_DATA_TABLE_ENTRY::SizeOfImage to what this loop shows in a debugger. For some reason, this switches from InInitializationOrderModuleList (correct) to InLoadOrderLinks

Expected Behavior:
This loop iterates through the InInitializationOrderModuleList and therefore at 0x40174a, the struct member should be the pointer to the Buffer element of the BaseDllName UNICODE_STRING

Screenshots/Video Recording:
View in binja:

Here is the _PEB_LDR_DATA::InInitializationOrderModuleList.Flink in the debugger selected with the cursor.

Here is the BaseDllName with the Length MaximumLength and Buffer selected with the cursor:

Binary:
Reference phrase: "brave wizard glows boldly"

[xusheng6]

The reason is that the code is walking the list of modules in the load order, which is the 3rd doubly-linked list in LDR. So in the screenshot below, Flink actually does not pointer to the InLoadOrderLinks field in _LDR_DATA_TABLE_ENTRY. Instead it points to InInitializationOrderModuleList in it:

Adding the 0x10 in the offset will exactly fix the issue. I believe this can be fixed by the use of offset pointers (https://docs.binary.ninja/guide/types/attributes.html#offset-pointers), but I made a few attempts and did not figure out how to do it

[xusheng6]

Besides from the potential manual fix using offset pointers, I believe this can also be fixed by tweaking the type library, i.e., separating the three linked list into three different types, and use offset pointers on them properly. Though it will take us a while before we get there

[utkonos]

Yes, after reading the documentation for offset pointers, this feature is precisely for fixing the problem shown here in the second and third linked list in the _LDR_DATA_TABLE_ENTRY struct.

[BlasterXiao]

In my analysis, I often encounter operations related to doubly linked lists, and the position of the LIST_ENTRY member within a node is not always at offset +0x00. Therefore, in such cases, we need to manually adjust the offset in order to correctly read the code. This is very helpful for analyzing structures and doubly linked lists, so I hope this bug can be fixed.