Windows Type Improvements/Hints

[leechristensen]

Creating this to brainstorm potential ways Ghidra's Windows type generation/assignment could be potentially improved for Windows binaries.

Extrinsic Sources of Type Information

Data sources outside of the binary that could be used to enrich Windows binary reversing:

1. Built-in Windows data type databases lack support for different/newer SDK versions and does not include the WDK. There is an included script that shows how to generate GDTs for newer SDKs, but it does not cover the entire Windows SDK. Based on my experience extending it to fully cover the Windows SDK, the C parser can be problematic due to parser bugs or mixed C/C++ usage in files (since the parser does not support C++). In addition, even if there is type information, Ghidra does not auto-assign SDK names to constants. For example, Win32 error codes, information classes (tokens, process, system), and access control rights in security descriptor ACEs (e.g., services, processes), and GUIDs).
   • A potential solution to address these is to leverage Microsoft's SDK/WDK metadata projects to derive type information (Binary Ninja takes a similar approach, fwiw):
     • https://github.com/microsoft/win32metadata/
     • https://github.com/microsoft/wdkmetadata/
2. Nt* API definitions. The phnt project that the SystemInformer project is a great source for these.
3. COM type library files (.TLB files). These could also be intrinsic to the binary if embedded as a resource.
4. The _o_ variants of the CRT functions. e.g. _o_memcpy_s

Intrinsic Sources of Information

Other potential intrinsic sources of type information that could be used:

• WPP and Tracelogging metadata, particularly how the WPP_SF_ symbols detail the number+types of the parameters.
• Parsing RPC interface information embedded inside of Windows binaries a la NtObjectManager. Example of doing so using NtObjectManager.