Skip to main content

Command Palette

Search for a command to run...

Part 0: Building a Windows Exploit Development Lab with WinDbg (32-bit

An isolated Windows 10 VM + the 32-bit Debugging Tools for Windows — the prerequisite for the whole OSED journey

Updated
Part 0: Building a Windows Exploit Development Lab with WinDbg (32-bit

TL;DR — Build an isolated Windows 10 (1809-era) VM from a legal source (Microsoft Evaluation Center / official ISO). Snapshot it. In the isolated VM only, disable Windows Update and Microsoft Defender so the build stays stable and your PoCs don't get quarantined. Install the 32-bit Debugging Tools for Windows (WinDbg) from the SDK installer, set a symbol path, save a workspace, verify by attaching to a 32-bit app, then snapshot the clean lab.

Exploit development means deliberately crashing programs and running PoC code — that belongs in an isolated VM, never your host. This post sets up the environment for the rest of the OSED journey. It's "Part 0" because everything else depends on it.


Why a Dedicated, Isolated VM

  • Isolation — crashes/shellcode/PoCs stay sandboxed.

  • Snapshots — instant rollback to a clean state.

  • Reproducibility — a fixed build keeps addresses/behavior consistent.

Rule: after setup, keep the VM off the internet and your LAN (host-only/internal networking). We're weakening its security on purpose.


Getting Windows the Right Way

You want a Windows 10 (1809-era) VM (period-accurate for EXP-301). Source it legally:

  • Microsoft Evaluation Center (free, time-limited ISOs)

  • Microsoft's free pre-built test VMs

  • Avoid unofficial mirrors for anything you publish or rely on — legitimate sources avoid licensing issues and tampering.

  • I personally downloaded from the link.

Download the Windows 10 required version


What You'll Install

  • A hypervisor: VMware, VirtualBox, or Hyper-V.

  • Debugging Tools for Windows (WinDbg) — the 32-bit (x86) package, via the Windows SDK installer (select only "Debugging Tools for Windows"). Official MSI: "X86 Debuggers And Tools-x86" from download.microsoft.com.

  • I downloaded the debugging tool from the link below.

Download Windows Debugging Tool


Hands-On Lab

  1. Create the VM — ~2 vCPU / 4 GB RAM / 60 GB disk; host-only/internal network.

  2. Install Windows 10 (1809) from a legal source; local account. Snapshot → clean-install.

  3. Disable Windows Update (isolated lab only)services.msc → Windows Update → Disabled + Stop.

  4. Disable Microsoft Defender (isolated lab only) — Windows Security → turn off Real-time protection; permanent via gpedit.msc → ... → Microsoft Defender Antivirus → Turn off → Enabled.

  5. Install WinDbg (x86) — run the SDK MSI, select only "Debugging Tools for Windows".

  6. Configure symbolsSRV*C:\symbols*https://msdl.microsoft.com/download/symbols.

  7. Save a workspace — Command + Disassembly views → File → Save Workspace.

  8. Verify — attach to a 32-bit app, run r.

  9. Snapshot → lab-ready .


Safety Recap

  • Disposable, isolated VM — no personal data, no real logins, no internet/LAN after setup.

  • Disabling Update + Defender is acceptable only in a sandboxed, snapshotted VM. Never on a host/production system.

  • Snapshot before and after configuration.


Conclusion

You now have an isolated Windows 10 (1809) VM, Update + Defender off (isolated VM only), the 32-bit WinDbg installed with symbols + a saved workspace, and a clean lab-ready snapshot. Next: Part 1 — x86 architecture (program memory, the stack, and CPU registers).


Part of my OSED (EXP-301) journey. Not affiliated with or endorsed by any organization; reflects my own study using public tools. Obtain Windows legally and only disable security controls inside an isolated lab VM.

Exploit Dev Journey

Part 1 of 2

A structured, hands-on path through Windows exploit development — from building an isolated WinDbg lab, through x86 architecture and debugger fundamentals, toward memory corruption and exploitation techniques. Each post is a lab-style walkthrough with real assembly, WinDbg commands, and practical steps. Aimed at intermediate security practitioners (OSCP-level and up).

Up next

Part 1: x86 Architecture for Exploit Developers — Program Memory, the Stack, and CPU Registers

The foundation behind every buffer overflow — memory layout, the stack, calling conventions, and the registers that matter

More from this blog

E

Exploit Dev Journey

2 posts

Hands-on notes from learning Windows exploit development — x86 architecture, WinDbg debugging, memory corruption, and beyond. Written for intermediate security practitioners (OSCP-level and up) who want clear, lab-style walkthroughs with real assembly, debugger commands, and isolated VM setups. Part of a structured series from lab setup to exploitation techniques. Personal study blog — original tutorials using public resources, not course material reproduction.