-
-
Notifications
You must be signed in to change notification settings - Fork 131
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
Cannot reproduce the snapshot for HEVD fuzzer #134
Comments
Hey @mkubx, thanks for the detailed report! So I haven't had a chance to look at things in details, but here are a few ideas if you'd like to try to debug this yourself (I will take a look at it this week or this week-end):
Hope this helps for now! Cheers |
Hey @0vercl0k, thank you for your time and support. I still have no idea what's happening and I am curious to figure it out, here is what I got so far.
In my symbolized trace, I can see:
So looks like the fuzzer makes an invalid deref inside syscall. I used a new state in this output, but the error looks identical. |
Of course, no worries at all, thanks for giving the tool a shot :) Hehe what you described seems like an interesting investigation - it doesn't seem to look like anything I've seen which is exciting. I'm happy to take it from there to try to figure out what happens. Will try to have a look at this this weekend :) Cheers |
Thank you! Meanwhile I'll play with the different targets to see if there is any difference. I am not sure if I am not missing something stupid, since it was working for everyone else here. My setup is pretty ordinary, I just created a brand new VM in Hyper-V, then followed the instructions. Also, if you want me to upload the VM or something else, I am happy to assist you. |
I made it working, still not sure what went wrong. I used a different windows image (with Then I tried to take a dump twice, it had around 3.5GB (instead of the usual 1.5GB-1.8GB). I am happy that your fuzzer finally works (it's amazing and thanks for making it public), we can close the issue if you want. Thanks again for your help, I really appreciate it! |
Awesome, I'm glad to hear. I'll keep this issue open until I try to figure
out what happened if that's okay - there might be something interesting to
learn or maybe an opportunity to fix a bug / improve the tool :)
Don't hesitate to reach out if you encounter any other issues though!
Cheers
…On Fri, Sep 30, 2022 at 7:31 AM mkubx ***@***.***> wrote:
I made it working, still not sure what went wrong. I used a different
windows image (with Microsoft Windows [Version 10.0.19044.1288], instead
of the previous Microsoft Windows [Version 10.0.19044.2006]) and enabled generation
2
<https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/plan/should-i-create-a-generation-1-or-2-virtual-machine-in-hyper-v>
when I created a new VM. Other than this, everything was the same.
Then I tried to take a dump twice, it had around 3.5GB (instead of the
usual 1.5GB-1.8GB). I am happy that your fuzzer finally works (it's amazing
and thanks for making it public), we can close the issue if you want.
Thanks again for your help, I really appreciate it!
—
Reply to this email directly, view it on GitHub
<#134 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALIORPC7SXZJBVJVTVWGRTWA32SVANCNFSM6AAAAAAQXVDVSM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
All right, I had some time to check out this issue after work. The TL'DR is that it seems like HEVD's Here is the story of the longer version; maybe it's also useful for others that want to be able to debug issues they encounter w/ wtf. Put on your seat belt, let's go! First, I downloaded the provided
Okay, cool. One thing that is important to understand is that message is actually printed by
Okay so at this point, Windbg agrees w/ wtf which is good for wtf. The second logical step is to grab a RIP trace of the testcase to be able to follow what happens precisely, so let's do that:
The RIP trace is basically RIP addresses written into a file without any symbolization which is not super useful. To make it more useful, you need to symbolize it; to do that, I created symbolizer that does just that.
Now, you can open
As you can see, it seems an error was hit during symbolization of an address which is not expected. Because the symbolized file and the raw file are basically one address per line, it's easy to go to the same line number to see what's going on; here's what I found:
Okay makes sense. What probably happens is because Cool, so let's just update #ifdef WINDOWS
__declspec(safebuffers)
#endif
void BochscpuBackend_t::BeforeExecutionHook(
/*void *Context, */ uint32_t, void *Ins) {
// ...
fmt::print(TraceFile_, "{:#x}\n", Rip);
fflush(TraceFile_); Recompile, re-generate a trace, re-symbolize it and bingo we get a trace that doesn't stop abruptly now. Here is the end of the symbolized trace now:
Okay so the if (!g_Backend->SetBreakpoint("nt!DbgPrintEx", [](Backend_t *Backend) {
const Gva_t FormatPtr = Backend->GetArgGva(2);
const std::string &Format = Backend->VirtReadString(FormatPtr);
DebugPrint("DbgPrintEx: {}", Format);
Backend->SimulateReturnFromFunction(0);
})) {
DebugPrint("Failed to SetBreakpoint DbgPrintEx\n");
return false;
} What happens here is that the
Okay so we clearly see the call that will invoke
Okay so the pointer is actually pointing into the Anyways, we can also dig a bit deeper. If I looked at my own build of
That makes sense, the driver basically tells the user that they sent a busted code. It also sets an error code that we can also see in the code from the dump:
Cool, everything checks out! That class of issue is pretty annoying. It happens a LOT in user-mode and that's why I made lockmem. For kernel-mode I actually don't even know how to mimic that same behavior (Actually I've done some experiments on the fbl_kern branch but it hasn't pan out yet). Interestingly I haven't run into that issue on kernel yet - I wonder how much memory you had configured your VM with? I usually set mine at 4GB. In theory, you can also disable the Anyways, thanks again for the actionable report! Cheers |
Thank you very much for a detailed writeup! :) I was using 4GB and since on a new VM the issue reoccurred, I ended up by disabling the Is there the same issue with KVM? How can I take the snapshot on Linux? I know it's probably not supported yet, but what are the options? |
Interesting! Something that might be confusing is that every backend is meant to run Windows code; KVM included. Dumping / running / fuzzing Linux code is not supported. If you're really interested in that, there's been some work in #102 but it is experimental. I have personally not tried it out. Cheers |
I'll close this as the original issue was fixed! Cheers |
Hello. I followed the instructions here and installed W10 inside Hyper-V VM, 4GB RAM, 1 CPU. I also disabled KVA and used lockmem.exe when doing the memory dump (
!bdump
).Still, when I run the fuzzer (I modified only
ExGenRandom
to reflect my Windows version), I am getting the following errors:Here is the dump of my image.
I also did some sanity checks if the code was not swapped out, mentioned here #41, so for instance
KERNELBASE!DeviceIoControl
disassembles correctly. How can I debug this issue? I tried to create images 10-15 times with more or less the same result. Also, no problem to run the fuzzer with the snapshot you provided. Thanks.The text was updated successfully, but these errors were encountered: