Add support for loading raw VMWare snapshots #202
Conversation
A debugger won't work for vmware dumps, so just warn in that case and continue on. Additionally, there's some sort of discrepancy with cpu state between dumps from hyper-v and from vmware. Ignoring these didn't result in anything horrible, so warn on it but continue.
|
Woot that's awesome! As I have mentioned in private messages, give me some time to try to figure out what's the best way to do this that is shippable 🫡 Cheers |
|
Hello, any updates with vmware snapshot fuzzer? |
|
@xinali I can't really ship that code in this current state, I'm sorry. The correct way would be to rearchitect wtf to allow loading an address space with different ways but I am not really planning to implement that in this project. I am tinkering with maybe rewriting wtf where I would be able to solve the most annoying issues (and not building it for Windows only would be one of them). For a one off though, this PR is useful for people to see how they could make it work for their use-cases; I'm also happy to assist you if you're running into issues. Cheers |
3 participants
These patches simply add support for loading VMWare snapshots which are raw, linear, RAM dumps.
The change in the kdump parsers is simple, if the initial parsing fails, it opportunistically tries to load the file as a raw dump, else it continues into parsing different usual kdumps types.
The second part of the patch has to do with actually loading these where I had to relax a few warnings or errors, as there's no point in trying to enable a debugger on raw memory dumps.
To build the project with support for loading these VMWare dumps, there's a new
build-release-vmware-support.batscript that enables the flags that relax the warnings.I'll have a macOS/fuzzer target and an example workflow in a separate repository.