Start a new process
Starting a process from entrypoint
Starting to debug a user-mode process from the start entrypoint of the module is one of the essential tasks that debuggers can do, and HyperDbg is no exception.
HyperDbg won't use any Windows API for intercepting and pausing threads, and everything is done at the hypervisor level.
The user-mode debugger is still in the beta version and not stable. We decided to exclude it from this release and release it in future versions. If you want to test the user-mode debugger in VMI Mode, you should build HyperDbg with special instructions. Please follow the instruction here.
In contrast with the kernel debugger, the user debugger is still very basic and needs a lot of tests and improvements. We highly recommend not to run the user debugger in your bare metal system. Instead, run it on a supported virtual machine to won't end up with a Blue Screen of Death (BSOD) in your primary device. Please keep reporting the issues to improve the user debugger.
HyperDbg> .start path c:\Windows\system32\notepad.exe
You can also specify the parameters of the target executable.
HyperDbg> .start path c:\Windows\system32\notepad.exe c:\myfolder\myfile.txt
HyperDbg will run the process and put a breakpoint on the entrypoint of the process. Once the process reaches the entrypoint (loading module is finished), the debugger is paused again and gives the control back to the user or kernel debugger.
Starting an EXE and running until entrypoint
If you're using a kernel debugger, everything (including the operating system) is halted, and you can debug the process normally.
If you're using the user debugger, the thread is paused and waits for the commands from the debugger.
Continue the target process
Note that pausing the target thread is only possible in user debugger, not kernel debugger. Also, you should keep interacting with the process to force the process to run its codes in user-mode so HyperDbg will intercept more threads.
Pausing the target process
Detaching from the process