conditional breakpoints and events
An example of using conditional breakpoint (events)
Conditional statements are one of the essential parts of debuggers, and HyperDbg is not an exception.
These statements are handled in both command syntax, like you can specify a core or pid that triggers the event. Still, you can also use the script engine that gives you more flexibility to compare different arguments and, if necessary, call functions.
In this example, we want to put a conditional breakpoint on nt!ExAllocatePoolWithTag
only and only when it's called from nt!CmpAllocatePoolWithTag
function.
This example is only applicable to the debugger mode. Because pausing debugger is only available in this mode, however, you can write anything other than pausing debugger in the script in VMI mode.
Let's take a look at memory at nt!ExAllocatePoolWithTag
:
The assebly code for nt!CmpAllocatePoolWithTag
:
As you can see, nt!ExAllocatePoolWithTag
is called from fffff801`6325c5c4
in nt!CmpAllocatePoolWithTag
.
Based on x86 assembly, a call
instruction pushes the address of the next instruction to the stack so that the program can be continued later with the next instruction.
As the stack is down-to-up in computer science, if we dereference @rsp register and read 8-bytes from the stack, it's the pointer to the next instruction that the caller expects to be called after the call is finished (returned).
We know that the next instruction after the call instruction is fffff801`6325c5c9
which is equal to nt!CmpAllocatePoolWithTag+0x9
.
Now, we put an EPT hook on the target function nt!ExAllocatePoolWithTag
and check whether the caller is nt!CmpAllocatePoolWithTag+0x9
or not.
If the caller is what we expected, then we'll halt the debugger and get the control of the debuggee by using pause(); function.
All in all, the following script is the implementation of this logic.
You can see that the debugger will get the target system's control whenever it's called from nt!CmpAllocatePoolWithTag+0x4
.
Last updated