0vercl0k / wtf

Unlike other parts, I wonder why there is this line here.

Line 154 in 67beeb4

if (g_Dbg.GetModuleBase("verifier") > 0) {

This line is here to make sure that the `verifier` module is present in the address space before setting a breakpoint on a function that lives in that module; does this make sense? Cheers

…

On Tue, Sep 20, 2022 at 1:06 AM Donghyun Lee ***@***.***> wrote: Unlike other parts, I wonder why there is this line here. https://github.com/0vercl0k/wtf/blob/67beeb4ef0297253177397f8505265ac12cd55eb/src/wtf/crash_detection_umode.cc#L154 — Reply to this email directly, view it on GitHub <#130>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALIORMUHVLSOVMEWBPNA7DV7FWAHANCNFSM6AAAAAAQQZY7F4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

Why doesn't the other part(hal!~~, nt!~~, ntdll!~~) need that line to set the breakpoint?

I think verifier module only loaded when specific feature( e.g. +hpa ) enabled, but ntoskrnl or ntdll module are always loaded in normal circumstance.

Therefore, checking existence of those module is not essential unlike verifier or any others.

Aha, got it.
In bochscpu, the GetModuleBase() did not throw an error, but in kvm, the following error occurs and fuzzing stops.
Is this intended?

$ sudo ../../src/build/wtf fuzz --name abc --backend kvm --limit 1000000000
The debugger instance is loaded with 16 items
Parsing coverage/xxx.cov..
Parsing coverage/yyy.cov..
Applied 1367271 code coverage breakpoints
Setting debug register status to zero.
Setting debug register status to zero.
Resolved breakpoint 0x5b96b5a7 at GPA 0x515355a7 aka HVA 0x5602b70a25a7
Resolved breakpoint 0x7ffd49aed110 at GPA 0x10240c110 aka HVA 0x5602ba610110
Resolved breakpoint 0x7ffd49aed6d0 at GPA 0x10240c6d0 aka HVA 0x5602ba6106d0
Resolved breakpoint 0x7ffd49aed9d0 at GPA 0x10240c9d0 aka HVA 0x5602ba6109d0
Resolved breakpoint 0xfffff8035c488a00 at GPA 0x2e88a00 aka HVA 0x5602ba612a00
Resolved breakpoint 0xfffff8035c3fbc40 at GPA 0x2dfbc40 aka HVA 0x5602ba614c40
Resolved breakpoint 0xfffff8035c3ea3b0 at GPA 0x2dea3b0 aka HVA 0x5602ba6163b0
Resolved breakpoint 0xfffff8035c065f70 at GPA 0x2a65f70 aka HVA 0x5602ba618f70
Resolved breakpoint 0xfffff8035c409d50 at GPA 0x2e09d50 aka HVA 0x5602ba61ad50
Resolved breakpoint 0xfffff8035c40a980 at GPA 0x2e0a980 aka HVA 0x5602ba61c980
Could not set a breakpoint at hal!HalpPerfInterrupt.
Failed to set breakpoint on HalpPerfInterrupt, but ignoring..
Resolved breakpoint 0xfffff8035c3118c0 at GPA 0x2d118c0 aka HVA 0x5602ba61e8c0
Resolved breakpoint 0xfffff8035c1ff950 at GPA 0x2bff950 aka HVA 0x5602ba620950
Resolved breakpoint 0x7ffd49aa1210 at GPA 0x102511210 aka HVA 0x5602ba622210
Resolved breakpoint 0xfffff8035c208d00 at GPA 0x2c08d00 aka HVA 0x5602ba624d00
verifier could not be found in the symbol store  ----------------------------->  !

Note: I used SetupUsermodeCrashDetectionHooks()

If you see this message it means that you made changes that lead to a new symbol store entry not being added into the symbol.json file. To fix this, run the harness on Windows because that's the only way I can use the dbg APIs to resolve symbolic names. Then, take the new file and move it to your linux environment.

Cheers

Thanks!:)

If you see this message it means that you made changes that lead to a new symbol store entry not being added into the symbol.json file. To fix this, run the harness on Windows because that's the only way I can use the dbg APIs to resolve symbolic names. Then, take the new file and move it to your linux environment. Cheers

…

On Wed, Sep 21, 2022 at 12:04 AM Donghyun Lee ***@***.***> wrote: Aha, got it. In bochscpu, the GetModuleBase() did not throw an error, but in kvm, the following error occurs. Is this intended? $ sudo ../../src/build/wtf fuzz --name abc --backend kvm --limit 1000000000 The debugger instance is loaded with 16 items Parsing coverage/xxx.cov.. Parsing coverage/yyy.cov.. Applied 1367271 code coverage breakpoints Setting debug register status to zero. Setting debug register status to zero. Resolved breakpoint 0x5b96b5a7 at GPA 0x515355a7 aka HVA 0x5602b70a25a7 Resolved breakpoint 0x7ffd49aed110 at GPA 0x10240c110 aka HVA 0x5602ba610110 Resolved breakpoint 0x7ffd49aed6d0 at GPA 0x10240c6d0 aka HVA 0x5602ba6106d0 Resolved breakpoint 0x7ffd49aed9d0 at GPA 0x10240c9d0 aka HVA 0x5602ba6109d0 Resolved breakpoint 0xfffff8035c488a00 at GPA 0x2e88a00 aka HVA 0x5602ba612a00 Resolved breakpoint 0xfffff8035c3fbc40 at GPA 0x2dfbc40 aka HVA 0x5602ba614c40 Resolved breakpoint 0xfffff8035c3ea3b0 at GPA 0x2dea3b0 aka HVA 0x5602ba6163b0 Resolved breakpoint 0xfffff8035c065f70 at GPA 0x2a65f70 aka HVA 0x5602ba618f70 Resolved breakpoint 0xfffff8035c409d50 at GPA 0x2e09d50 aka HVA 0x5602ba61ad50 Resolved breakpoint 0xfffff8035c40a980 at GPA 0x2e0a980 aka HVA 0x5602ba61c980 Could not set a breakpoint at hal!HalpPerfInterrupt. Failed to set breakpoint on HalpPerfInterrupt, but ignoring.. Resolved breakpoint 0xfffff8035c3118c0 at GPA 0x2d118c0 aka HVA 0x5602ba61e8c0 Resolved breakpoint 0xfffff8035c1ff950 at GPA 0x2bff950 aka HVA 0x5602ba620950 Resolved breakpoint 0x7ffd49aa1210 at GPA 0x102511210 aka HVA 0x5602ba622210 Resolved breakpoint 0xfffff8035c208d00 at GPA 0x2c08d00 aka HVA 0x5602ba624d00 verifier could not be found in the symbol store -----------------------------> ! — Reply to this email directly, view it on GitHub <#130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALIOROJJAFMYMIYLZQ4JYDV7KXOHANCNFSM6AAAAAAQQZY7F4> . You are receiving this because you commented.Message ID: ***@***.***>

Checking `g_Dbg.GetModuleBase("verifier") > 0`