Listen to this Post
Introduction:
After a seven-year hiatus, Corelan Consulting has reignited its legendary training series with a deep dive into Windows debugging fundamentals. The new tutorial, “Debugging – WinDBG & WinDBGX Fundamentals,” re-establishes a critical knowledge base for exploit developers, malware analysts, and reverse engineers, focusing on the practical runtime control necessary to dissect modern, hardened software. This resurgence highlights the enduring need for low-level debugging skills in an era where security controls like ASLR and DEP are standard.
Learning Objectives:
- Master the core workflows of WinDBG Classic and WinDBGX for process analysis and crash reproduction.
- Implement advanced breakpoint techniques, including conditional and logging breakpoints using `j` and `gc` commands.
- Utilize pseudo-registers and ASLR-resilient techniques to create reliable debugging sessions and exploit primitives.
You Should Know:
1. Establishing a Robust Debugging Environment
The foundation of effective debugging is a properly configured environment. Both WinDBG Classic and WinDBGX require accurate symbol paths to translate memory addresses into readable function names. Misconfigured symbols render stack traces and memory inspection nearly useless.
Step‑by‑step guide:
- Set the Symbol Path: In WinDBG, use the command `.sympath` to view or set the path. For Microsoft symbols, use the public store:
.sympath srvC:\Symbolshttps://msdl.microsoft.com/download/symbols
This caches symbols locally in `C:\Symbols` and downloads them on demand from Microsoft’s server.
- Load Symbols Explicitly: After setting the path, force a symbol load with
.reload:.reload /f
The `/f` flag forces a full load of all modules. For a specific module, use
.reload /f module.dll. - Verify Symbol Loading: Use `lm` (list modules) to confirm symbols are loaded:
lm
Look for the `pdb` (program database) signature next to the module name. Private symbols will show full path information, while public symbols will show a stripped version.
2. Mastering Process Control: Launching vs. Attaching
Understanding when to launch a new process versus attaching to an existing one is critical. Launching (windbg notepad.exe) gives you control from the entry point, ideal for analyzing initialization or exploits that trigger during startup. Attaching (windbg -pn notepad.exe or via File > Attach to Process) is used for analyzing a running application, a service, or a process that is already misbehaving.
Step‑by‑step guide:
- To launch a process: Open Command Prompt and navigate to your WinDBG installation. Run:
windbg -o C:\path\to\vulnerable.exe
The `-o` flag enables debugging of child processes.
- To attach to a running process by PID:
- Find the PID using Task Manager or `tasklist` command.
2. Execute: `windbg -p `
- Non‑invasive debugging: Use the `-pv` flag (
windbg -pv -p <PID>) to attach without actually suspending the target process. This is useful for inspecting a live system with minimal disruption.
3. Advanced Breakpoints: Conditional Execution and Logging
Standard breakpoints halt execution. For complex exploit development, you often need conditional stops or simple logging. WinDBG offers the `j` (execute if condition) command combined with `gc` (go from conditional breakpoint) to create powerful, non‑interrupting breakpoints.
Step‑by‑step guide:
- Set a Breakpoint: Set a breakpoint at a specific address or function.
bp kernel32!CreateFileA
- Convert to Conditional Breakpoint: Use the `j` command to evaluate a condition. For example, to break only when the `lpFileName` parameter points to “config.ini”:
bp kernel32!CreateFileA "j (poi(esp+4) == 0x12345678) ''; 'gc'"
Note: This syntax is a simplification. In practice, you’d dereference the string and compare it. A more robust method involves using `.printf` for logging.
- Implement Logging without Breaking: To simply log the call and continue:
bp kernel32!CreateFileA ".printf \"CreateFileA called with: %ma\n\", poi(esp+4); gc"
This prints the filename (using `%ma` to interpret the address as an ASCII string) and then automatically continues execution (
gc).
4. Memory Inspection and Pseudo-Registers
Memory inspection goes beyond `dd` (display dword). Pseudo-registers, like `$t0` through $t19, allow you to store and reuse addresses during a session. This is invaluable for ASLR-resilient techniques where you need to track dynamically allocated memory.
Step‑by‑step guide:
- Display Memory: Use `db` (bytes), `dw` (words), `dd` (dwords), and `dq` (qwords). To display Unicode strings, use
du.dd esp L4
This displays 4 dwords from the stack pointer.
- Assign a Pseudo‑Register: Store the value of a register for later use.
r $t0 = eax
- Use Pseudo‑Registers in Commands: Reference the stored value in other commands.
dd $t0 L8
- ASLR‑Resilient Breakpoint: Instead of hardcoding an address, break on a function call and capture a return address.
bp kernel32!VirtualAlloc "r $t1 = poi(esp); .echo VirtualAlloc called; gc"
Here, `poi(esp)` captures the return address, storing it in `$t1` for later analysis, regardless of where the function is loaded in memory.
5. Exploiting Session 0 Services with TTD
A comment from Robert Hawes highlights a critical technique for debugging services, which often run in Session 0 and are inaccessible to standard interactive debuggers. Using GFlags to launch a process with Time Travel Debugging (TTD) recording allows you to capture an execution trace that can later be analyzed in WinDBG, bypassing session restrictions.
Step‑by‑step guide:
- Set Up TTD Recording: Use GFlags to set the image flags for your target executable. In the command line:
gflags /i service.exe +ust
This enables user-mode stack trace. However, for TTD, you typically use the `ttd.exe` launcher directly.
- Launch with TTD: From an elevated command prompt, navigate to the WinDBG tools folder and run:
ttd.exe C:\path\to\service.exe
TTD will start the process and create a `.run` file with the trace.
- Load Trace into WinDBG: Once the service has performed the action you want to analyze, load the generated `.run` file:
windbgx.exe -load trace.run
This opens WinDBGX in TTD mode, allowing you to step backwards, set position breakpoints, and analyze the execution flow as if you had a full recording, effectively working around session 0 limitations.
6. Leveraging Mona.py for Exploit Development
While not covered in the initial post, the comment referencing `!mona writeexploit` underscores the importance of Corelan’s own Mona.py framework. This PyKD plugin automates many tedious tasks in WinDBG, such as finding ROP gadgets, creating pattern offsets, and generating exploit code.
Step‑by‑step guide:
- Load Mona: After installing the script in the WinDBG plugins folder, load it:
.load pykd.pyd !py mona
- Find a Safe SEH Chain: Use Mona to find a structured exception handler chain that isn’t corrupted.
!mona findmsp
This identifies the offset to the SEH chain based on a cyclic pattern.
- Generate Exploit Code: After identifying ROP gadgets and pivot points, use Mona to generate the exploit skeleton:
!mona writeexploit
This produces a Python or Ruby template with the correct offsets and buffer structure, drastically accelerating exploit development.
What Undercode Say:
- Resurgence of Low‑Level Skills: Corelan’s return signals a continued, critical need for deep systems knowledge. While tooling evolves, the ability to trace execution at the assembly level remains a non‑negotiable skill for advanced security roles.
- Practical Runtime Visibility: The emphasis on breakpoints and pseudo-registers highlights a shift from static analysis to dynamic, interactive debugging. Mastery of these commands enables engineers to not only find bugs but also craft reliable exploits against modern mitigations.
- Community-Driven Learning: The discussion around TTD for session 0 services illustrates how shared techniques from practitioners refine and expand the utility of core tools. This collaborative knowledge pool is essential for tackling complex, real-world targets like system services and privileged processes.
Prediction:
The revival of Corelan’s content will likely spur a renewed interest in manual exploit development training. As AI-generated code and automated fuzzing become more prevalent, the ability to perform nuanced, context-aware debugging will become a premium differentiator for security professionals. Expect to see a wave of new content focusing on integrating WinDBG’s TTD capabilities with modern kernel mitigations, further bridging the gap between legacy exploitation techniques and the security landscape of the late 2020s.
▶️ Related Video (88% Match):
https://www.youtube.com/watch?v=037Pw8btDiM
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Petervaneeckhoutte Debugging – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
