Thread by @HyperDbg

Here are 11 reasons why we should use #HyperDbg, the differences between HyperDbg and #WinDbg, and how HyperDbg will change our debugging/reversing journey.

A thread (24 tweets) 🧵:

1. !epthook/!epthook2: a.k.a hidden hooks, HyperDbg implements classic EPT hook (!epthook) combined with old detour methods (!epthook2). It's super fast and invisible! By looking at the memory, neither the operating system nor the application ever understands that /

there is a hook.

docs.hyperdbg.org/commands/exten…
docs.hyperdbg.org/commands/exten…
docs.hyperdbg.org/using-hyperdbg…

2. !monitor: HyperDbg simulates hardware debug registers but this time without any limitation in size and transparent from the operating system.
Imagine you can get notified about /

all reads or writes or reads/writes to a structure in the memory (without size limitation), so you can find all the functions related to the particular structure.

docs.hyperdbg.org/commands/exten…
docs.hyperdbg.org/using-hyperdbg…

3. !syscall/!sysret: Have you ever tried to hook /

all system calls? It's super hard. Modifying SSDT is not a good solution, and hooking KiSystemCall64 is complicated especially after the #meltdown patch.

You can hook all of the system calls using HyperDbg. It also offers a way of hooking SYSRET instruction, which means /

that you will be notified in the case of any system calls and log the parameters, and before it returns to user mode, you are notified again so that you can view/modify the results of those system calls.

docs.hyperdbg.org/commands/exten…
docs.hyperdbg.org/commands/exten…
docs.hyperdbg.org/using-hyperdbg… /

4. HyperDbg is hidden by its nature. Most of the ant-debugging/anti-reversing methods won't detect it. HyperDbg didn't use any API or any operating system mechanism to debug a process or the operating system itself, so even Windows doesn't have any idea that it's being debugged /

thus, you can use HyperDbg as a transparent and hidden debugger, sure it has its visible footprints, but in the future versions, we try to remove these side effects as much as possible to hide the debugger from complex anti-debugging methods.

docs.hyperdbg.org/using-hyperdbg… /

docs.hyperdbg.org/tips-and-trick…
docs.hyperdbg.org/using-hyperdbg…
docs.hyperdbg.org/commands/exten…

5. Instrumentation step-in: Have you ever tried to debug instructions from user-mode to kernel-mode or from kernel-mode to user-mode. Of course, it has its challenges, but by using HyperDbg, you can /

simply step through the instructions from user mode to kernel mode. HyperDbg guarantees that no other processes or instructions in other cores are executed while you're stepping through the instructions. For instance, you can directly debug SYSCALLs and go from user mode /

to kernel-mode dispatching routines and step instructions until you return to the user mode (SYSRET).

docs.hyperdbg.org/commands/debug…

6. A tremendously faster script engine: HyperDbg's script engine has a different design than WinDbg's scripts. Based on its design, /

every check is performed on the kernel side (vmx-root mode), and in contrast with WinDbg, nothing is passed to the debugger. Based on our experiment (which is available in our academic paper), Windbg checks 6,941 conditions, while HyperDbg checks 23,214,792 at the same time. /

It is ~3300 times faster! You can put conditional breakpoints on hundreds of functions with high execution rates and still use your system normally.

preprints.org/manuscript/202…
docs.hyperdbg.org/commands/scrip…
docs.hyperdbg.org/commands/scrip… /

7. I/O Debugging: Using the !ioin and the !ioout commands, you'll be notified whenever any Port Mapped I/O (PMIO) is used. You can also debug Memory Mapped I/O (MMIO) devices using the !monitor command. Using the script engine, /

you can change the input/output of the devices.

docs.hyperdbg.org/commands/exten…
docs.hyperdbg.org/commands/exten…

8. !msrread, !msrwrite, !tsc, !pmc, !cpuid: In HyperDbg, many many VT-x features are exported to the user mode to be used by the debugger. You can use !msrread and !msrwrite to /

monitor each execution of RDMSR and WRMSR in Windows to detect rootkit or analyze how a special feature works possibly. !pmc and !tsc are used for debugging applications that leverage RDPMC and RDTSC/RDTSCP instructions. You can also detect/modify /

each execution of the CPUID instruction by using the !cpuid command.

docs.hyperdbg.org/commands/exten…
docs.hyperdbg.org/commands/exten…
docs.hyperdbg.org/commands/exten…
docs.hyperdbg.org/commands/exten…
docs.hyperdbg.org/using-hyperdbg… /

9. !exception, !interrupt: !exception is another feature to monitor the exceptions ( IDT < 32 ), including page-faults and other processor exceptions for debugging and performance reasons. /

If you want to watch external device interrupts (32<IDT<256), you can also use the !interrupt command!

docs.hyperdbg.org/commands/exten…
docs.hyperdbg.org/commands/exten…
docs.hyperdbg.org/using-hyperdbg… /

10. HyperDbg is not a classic debugger, which means that we are not limited to just breaking to the debugger to get a command like #windbg. We have three types of actions when something happens. First, we pause the debugger and wait for a /

command (precisely like all classic debuggers).

Another one is the script. When you want to get the log from the system state (general-purpose registers or memory contents) when an event is triggered, or if you want to check conditions or change the system state, HyperDbg /

doesn't break to the debugger for these purposes and runs the scripts directly in the debugger and accumulates the logs. When it's safe, it sends the records to the debugger to show them to the user. The last one that makes the HyperDbg super flexible is the ability to execute /

custom assembly code in the target debuggee (without returning to the debugger).

docs.hyperdbg.org/using-hyperdbg…
docs.hyperdbg.org/using-hyperdbg…

11. HyperDbg is based on innovative methods and is actively under development. Soon we will have more magical commands, especially new commands /

with the assistance of Intel Processor Trace (PT) for future versions. If you think you can help, you're more than welcome to join HyperDbg developers to bring new magical commands to the HyperDbg.

github.com/HyperDbg/Hyper…