EmuDbg

EmuDbg is a lightweight, high-speed Emulator + Debugger designed for reverse engineering Windows executables.

---

✨ How It Works

• Run any .exe in debug mode
• Disassemble instructions using Zydis
• Directly emulate assembly instructions
• Skip Windows API calls via debugger stepping without emulating syscalls
• Much faster than traditional emulators that simulate the entire OS environment
• Ideal for reverse engineering, malware analysis, and low-level research

---

⚡ Why EmuDbg?

Unlike heavy full-system emulators, EmuDbg focuses on fast instruction emulation.
Windows API functions are skipped through debugger stepping, allowing seamless execution flow without the need for syscall emulation or complex kernel hooks.

---

🚀 Getting Started

1. Clone the repository

   git clone --recurse-submodules https://github.com/mojtabafalleh/emudbg
   cd emudbg
   cmake -B build

2. Or download the latest prebuilt emudbg.exe from the Releases page

3. Configure runtime modes (optional):

   You can customize EmuDbg’s behavior by editing the cpu.hpp file.
   There are three main flags controlling logging and CPU mode:

   //------------------------------------------
   // LOG analyze 
   #define analyze_ENABLED 1
   
   // LOG everything
   #define LOG_ENABLED 0
   
   // Test with real CPU
   #define DB_ENABLED 0
   
   //stealth 
   #define Stealth_Mode_ENABLED 1
   
   //emulate everything in dll user mode 
   #define FUll_user_MODE 1
   
   //Multithread_the_MultiThread
   #define Multithread_the_MultiThread 0
   
   // Enable automatic patching of hardware checks (not working yet )
   #define AUTO_PATCH_HW 0
   //------------------------------------------

   Setting all flags to 0 will run the emulator in pure emulation mode without extra logging or real CPU testing.

---

🛠 Usage

emudbg.exe <exe_path> [-m target.dll] [-b software|hardware|noexec]

📌 Arguments

Argument	Required	Description
<exe_path>	✅	Path to the target executable you want to debug
-m <target.dll>	❌	Wait for a specific DLL to load before setting breakpoints
-b <type>	❌	Breakpoint type: software (default) or hardware or noexec
-r <rva>	❌	Set a breakpoint at a Relative Virtual Address (RVA) inside the target module. Note: Cannot be used together with -b noexec
-watch_section <sections>	❌	Monitor execution in specific sections. Can list section names or use all to watch all sections.

what is noexec breakpoint?

noexec removes execution permission from memory regions where code is about to run, so that it triggers an access violation and acts like a breakpoint. It's very useful because it can be used without requiring full user mode. It provides almost the best performance among all types of breakpoints. but doesn’t work with RVA.

📌 Note on -watch_section:

When using the -watch_section option, emudbg will log the sections being executed or accessed. For example, it will record transitions like from which section to which section the code jumps. Examples:

emudbg program.exe -m game.dll -watch_section .text .vm
emudbg program.exe -watch_section all

💡 Examples

🔸 Run with software breakpoints on process entry point and TLS callbacks

emudbg.exe C:\Samples\MyApp.exe -b software

🔸 Wait for a specific DLL to load, then set hardware breakpoints

emudbg.exe C:\Samples\MyApp.exe -m target.dll -b hardware

🔸 Default usage with no flags (uses software breakpoints)

emudbg.exe C:\Samples\MyApp.exe

🔹 Set a breakpoint at a specific RVA in the main executable

emudbg.exe C:\Samples\MyApp.exe -r 0xFAB43

🔹 Set a hardware breakpoint at a specific RVA inside a specific module

emudbg.exe C:\Games\MyGame.exe -m target.dll -r 0x12A400 -b hardware

🔹🔹 noexec doesn’t work with RVA

emudbg.exe C:\Games\MyGame.exe -m target.dll  -b noexec