Design of !monitor

Design of !monitor command

The implementation of the !monitor command is derived from our Hypervisor From Scratch (Part 8).

Simulating Hardware Debug Registers Without Any Limitation

Have you ever used hardware debugger registers ?!

The debug registers allow researchers and programmers to selectively enable various debug conditions (read, write, execute) associated with a set of four debug addresses without any change in program instructions.

As you know, we can set up to 4 locations for these hardware registers, and it’s the worst limitation for these registers.

What if we have a structure (let's say _EPROCESS) and want to see what function in Windows Read or Write in this structure?

It’s not possible with current debug registers, but we use EPT to rescue!

Hidden Hooks Scenarios for Read/Write and Execute

HyperDbg unsets read or write or execute or all of them (based on how the user wants) in the entry corresponding to the address.

This means before the operating system or a kernel driver tries to read or write or execute, a VM-exit occurs, and an EPT Violation will notify us. In the EPT Violation handler, we log the address that tries to read or write or execute, then we find the entry in the EPT table and set all of the attributes (which means that any read or write, or execution to the page is allowed) and set an MTF flag.

VMM resumes, and one instruction executes, or in other words, read or write or execution is performed, then an MTF VM-exit occurs. In the MTF vm-exit handler, we unset the read and write and execution (or a custom combination of these attributes) again, so any future access to that page will cause an EPT Violation.

Note that all of the above scenarios happen to one core. Each core has a separate TLB and separate Monitor Trap Flag.