New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows kernel type libraries #2913
Comments
I think this is solved through the upstream source issue microsoft/wdkmetadata#1 |
Yes that's the easiest solution. There are other more difficult solutions. |
Sad to see this won't be in 3.2? Considering it's relevancy, this is a much needed feature and I feel a lot of people would appreciate and are waiting on it! |
I 100% agree with this, and we're very sorry it's not going to make the 3.2 release. There were two ways we could have solved this issue:
This issue is still a high priority for us and we'll be focusing a bunch of type libraries in the next release. |
Upstream WDK metadata has been published https://github.com/microsoft/wdkmetadata |
Yup already have my eye on it. This ticket is currently slated as high priority for the up coming release. |
FWIW Since the fantastic new header import GUI I've had great success importing the SDK/DDK from official (MS) and unofficial (ProcessHacker NT Headers) sources. Something like: IMO this approach is way better than typelibs because it allows us to control through the macros the DDI version we wanna use. Only downside I have currently is the (crazy) long analysis time, but it's a one-time thing (2-time actually, once on load, once after importing the headers but still). So great work on this to the team, I finally don't need IDA any longer for my own project (and am pushing at work to make the switch) ❤️ 🥷 |
You might also consider using "analysis hold" to not do that initial analysis and only let the full analysis continue after you've imported the type lib. That might actually improve the overall time for that workflow? Just use open with options and select analysis hold. |
Adding to this that the header import currently has issues with padding. For example, running the command by hugsy above results in the definition of the It also says the first field |
Looking at the header I have (wdm.h from 10.0.19041.0), I think those offsets are actually correct. Vergillus has it at that offset too, so I think the parser is accurate. Best guess is that the other structures inside the union have alignment 8 (they start with pointers), so the whole union gets aligned to 8 bytes. And unless this specific member has special casing, I'm inclined to believe it is correct as-parsed. Other best guess is that you were expecting x86 (not x64) alignment, in which case there is no padding and it is at 0x4. If you want x86 parsing of the header, you can swap |
You're right. Actually appears the UI threw me off. This is how its shown in HLIL UI: This is how its shown in disassembly: Somehow, the disassembly is much clearer in what is being accessed ( In fact, I read HLIL as saying The only way I can read Am I reading this wrong? Note: For display purposes I change the
|
My guess is a lot of the confusion comes from the lack of union type support (see #1013), which is a known limitation that, while we have plans to address eventually, has proven significantly more difficult than first expected. You can probably cheat around this lacking by splitting up the giant union type and using each of the individual sub-members within, but it is not a clean solution and is certainly not as smooth as it should be. As for your assumption, it's probably giving you the offset from the start of the inner union, and just having difficulty looking up the name of which member specifically that pertains to ( |
Ah also correct, it is 0x10 from the start of it. The union support thing is an interesting note, since it appears the disassembly has no problems resolving the correct name Otherwise yes, I imagine the eventual union support work would cover this. Just wanted to note the information is actually there already and displayed in other views. |
That's not too surprising, given that each level of IL has a different way of rendering member access lookups (MLIL and HLIL actually use references to the type directly, vs LLIL and disasm which don't know about types and just annotate guesses by offset). You may get good mileage out of having a disasm pane open at the same time if it is able to resolve in a way that you can use. |
Added in 3.6.4708 |
What is the feature you'd like to have?
Typelibs for Windows kernel mode libraries
Additional Information:
Having type information for common kernel mode libraries, such as:
ntoskrnl.exe
hal.dll
ndis.sys
would make it easier to analyze drivers that link to these components.
The text was updated successfully, but these errors were encountered: