Add low stub offset kernel detection

[Danking555]

Summary

This PR introduces a Low-Stub based method as an additional approach to kernel offset discovery in Volatility.
When available, this method resolves the kernel offset in ~3 seconds, a significant improvement compared to the ~90 seconds required by the current KDBG scan for large memory dumps (e.g., 32GB).
If the Low Stub method fails (e.g., for Hyper-V .vmem files), Volatility gracefully falls back to the existing KDBG scan.

Motivation

The KDBG scan is computationally intensive, particularly for large memory dumps, and can delay forensic investigations and incident response.
By leveraging the Low Stub, which contains the DTB and kernel base address hint, the kernel offset can be determined far more efficiently, improving overall runtime for all plugins dependent on this step.

Testing

This hybrid approach was tested on:

• Physical memory dumps from Windows 11
• Edge cases where the Low Stub is unavailable, with successful fallback to the KDBG scan (e.g., VMs memory)

References

• Memprocfs: Inspired the Low Stub based approach to kernel offset discovery.
• Alex Ionescu: Recon 2017 Talk on the Low Stub (starting at 43:36).

Special thanks to Ulf Frisk and Alex Ionescu for their pioneering research, which informed and inspired this contribution.

Acknowledgment

Thank you for maintaining Volatility as an indispensable tool in the forensic community. I hope this contribution enhances its usability and performance. I welcome any feedback or suggestions for further improvement.

[ikelos]

Thanks very much, this looks really interesting! Have you managed to test it against older systems (x86, PAE, etc)? My concern is that it has a lot of hard coded hex bytes which may not be applicable to all x86-based architectures or memory layouts so I'd want to be careful about that. It would also be good to get a few more comments (although I appreciate the continue comments explaining which bit the guard statements were looking for)...

Could you please also apply ruff (which just wants the unnecessary struct import removing) and black to format the file appropriately please? Having it pass all the tests will give us a bit of confidence that it's working as intended...

[Danking555]

Thanks for your feedback! I'm checking and working on everything you mentioned.

[Danking555]

Hi @ikelos, I've addressed your feedback and made the following updates:

• Removed unnecessary struct import.
• Added the LowStubLayout class to centralize all relevant constants of the _PROCESSOR_START_BLOCK structure for better organization and maintainability.
• Added documentation for the LowStubLayout class and method_low_stub_offset.
• Updated the guard statement to address the concern about reservation bits.
• Added a new guard check statement that compares the previously detected page table offset stored in vlayer._initial_entry with the value of cr3 which can be deferred from the structure for additional validation. Let me know if you'd prefer it removed or adjusted.
• Confirmed the method works on three physical machines.
• After verifying functionality, applied ruff and black for code cleanup and formatting.

Please let me know if there's anything else you'd like me to refine or modify!

[ikelos]

Thanks very much for clearing all those up! It's looking really good now. Rather than a separate class in the middle of the code, would it be possible to move the constants and their comments to the constants.windows module please? All of our other windows constants live there so it just keeps things in a single place to find them all. I guess move the docstring as an enlarged comment just before the section where you include those constants. Then it looks like it's good to go in! 5:D

[Danking555]

I've moved the constants into constants.windows, added the docstring comment, and ran ruff and black again.
Let me know what you think-thanks!

[ikelos]

Yep, very happy with that, thanks! 5:D I'll merge it as soon as the tests finish...