Cannot reproduce HEVD because of OpenDumpFile(state\mem.dmp) failed with hr=-0x7ff8ffa9 or nt!ExGenRandom's code has changed

[GanbaruTobi]

Hello, I am trying to reproduce the HEVD-Setup. I am running two up to date Systems (Win11 10.0.22631, x64) as host and target. The Debugger is WinDBG 1.2308.2002.0

When I write the snapshot i get the following message:

85% written. 5 sec remaining. 90% written. 3 sec remaining. 95% written. 1 sec remaining. Wrote 4.0 GB in 37 sec. The average transfer rate was 110.6 MB/s. Wrote 4578 pages of 0xdeadfeed into this dump file for memory that could not be read successfully by the kernel memory manager. The kernel memory manager can not read pages that have a held page lock, are on the failed memory page list, or which have been hot removed from the system. Dump successfully writte

If I go on to bochscpu it will continue with the second error

❯ C:\Users\gbaru\wtf\target\bin-win64.RelWithDebInfo\wtf.exe run --name hevd --state state --backend=bochscpu --input .\inputs\ --limit 10000000 Initializing the debugger instance.. (this takes a bit of time) OpenDumpFile(state\mem.dmp) failed with hr=-0x7ff8ffa9

I tried switching the target system with a Windows 10. I did not have the first error, but the second error stayed the same.

I did see that the same error was given in https://github.com/0vercl0k/wtf/issues/101 but it stated that its probably resolved in https://github.com/0vercl0k/wtf/issues/101#issuecomment-1868337583.

I tried switch to the historic windbg, I had the first error but the second changed.

Initializing the debugger instance.. (this takes a bit of time) Setting debug register status to zero. Setting debug register status to zero. It seems that nt!ExGenRandom's code has changed, update the offset! Could not initialize target fuzzer.

Now I am confused, because I thought for Windows host I don't need symbols-store.json? I thought thats for Linux? Windbg also sees the symbols.

So i cannot get rid of this third error, even after placing a symbol-store.json in the state directory. Any help is appreciated!

[0vercl0k]

All right let's unpack all of this - but before this, just wanted to thank you for taking the time to write a detailed bug report :)

So the first thing that looks bizarre is this - are you using Hyper-V? I've heard about people struggling to get a dump with VMWare. I've personally only tested the tool with Hyper-V and you shouldn't see that output:

Wrote 4578 pages of 0xdeadfeed into this dump file for memory that could not be
read successfully by the kernel memory manager. The kernel memory manager can
not read pages that have a held page lock, are on the failed memory page list,
or which have been hot removed from the system.
Dump successfully written

Then let's look at the second thing. The below error means that the dbgeng.dll APIs are failing to grab to open your dump file and not because of kdmp-parser not knowing how to parse your dump.

❯ C:\Users\gbaru\wtf\target\bin-win64.RelWithDebInfo\wtf.exe run --name hevd --state state --backend=bochscpu --input .\inputs\ --limit 10000000
Initializing the debugger instance.. (this takes a bit of time)
OpenDumpFile(state\mem.dmp) failed with hr=-0x7ff8ffa9

This happens if you grabbed the dump with the new WinDbg. Basically, wtf tries to find the right dbgeng.dll (see https://github.com/0vercl0k/wtf/blob/main/src/wtf/debugger.h#L139) on your filesystem and it grabs it off the Windows SDK paths. I actually don't know how to find the path of the new WinDbg installation, and then it seems that you need to be admin to copy off files from that directory? Anyways, this is annoying but if you do it manually it should work. Run the WinDbg you used to grab the dump file, go to the directory where this WinDbg is, and copy the dbghelp.dll, symsrv.dll, dbgeng.dll, dbgcore.dll DLLs and paste them in the directory where wtf.exe is. I've filed #196 as this is something other users have hit and I'd love to fix it.

Now, the third thing.

Initializing the debugger instance.. (this takes a bit of time)
Setting debug register status to zero.
Setting debug register status to zero.
It seems that nt!ExGenRandom's code has changed, update the offset!
Could not initialize target fuzzer.

This basically means that the fuzzer module doesn't know where it should patch nt!ExGenRandom; it was written for a specific version and expects to find a certain instruction at a certain offset and if it's not the case it bails out. It doesn't try to be smart and find the equivalent or anything. You can see that code here: https://github.com/0vercl0k/wtf/blob/main/src/wtf/fuzzer_hevd.cc#L93.

Your understanding is right, on Windows you do not need the symbol-store.json file - it is generated on Windows but it isn't used, so modifying it won't change anything. The fact that the fuzzer tells you It seems that nt!ExGenRandom's code has changed, update the offset! it means that it has been able to load the dbgeng.dll API because and that it was able to find the base address of nt!ExGenRandom which means your setup is working perfectly: your dump is loaded and your symbols work.

I hope this helps!

Cheers

[GanbaruTobi]

Hey @0vercl0k,

thank you so much for the detailed answer.

So the first thing that looks bizarre is this - are you using Hyper-V? <-> yes, I am running Hyper-V.

I also have VMWare installed, I don't know if that could cause a problem here, but I guess not. Anyway it is a VM running in Hyper-V with Hyper-V-Manager.

I will test 2. and 3. later and will report.

You helped me a lot! Thank you

[GanbaruTobi]

After doing the changes of 2. it worked and also the 3. error disappeared... So its looking fine now:

[0vercl0k]

Woot, awesome!