OSED and EXP-301: preparing for exploit development
OSED tests Windows user-mode exploit development. Build an EXP-301 workflow for WinDbg, DEP, ASLR, shellcode, debugging and reliable practice.
- AUTHOR
- Karol Rapacz / CEO of Breachroad · OSCP · PNPT
- PUBLISHED
- 22 June 2026
- READING TIME
- 10 min read
- TOPIC
- Careers and Certifications
OSED and EXP-301 focus on Windows user-mode exploit development. The course covers buffer overflows, custom exploits, DEP and ASLR bypass, shellcode, format strings and reverse engineering with WinDbg and IDA Pro. The current exam has three independent tasks and lasts 47 hours and 45 minutes.
This is not another network pentest. Candidates must understand process state and prove control of execution.
Prerequisites
Develop fluency in x86 registers, stacks, calling conventions, branch instructions and little-endian representation. Use Python to parse binary data, generate payloads and communicate with processes or services.
Work in WinDbg daily: breakpoints, exceptions, modules, memory and call stacks. Exploit development is iterative hypothesis testing.
Exploit workflow
- Reproduce a crash with controlled input.
- Find the offset and control boundary.
- Identify bad characters and protocol constraints.
- Inspect modules and mitigations.
- Build stable control-flow redirection.
- Add ROP or another bypass where required.
- Generate shellcode for the execution context.
- Test repeatedly and document assumptions.
Reliability matters. A payload working once in ten attempts requires timing, memory or environmental analysis.
DEP, ASLR and ROP
DEP separates data from executable code, while ASLR makes addresses unpredictable. Do not memorise one ROP chain. Learn to find gadgets, control registers, align stacks and invoke required APIs.
Document every chain element: address, instructions, effect and module dependency. This speeds debugging after a binary changes.
Exam preparation
Practise different task types in parallel but keep separate runbooks. Automate pattern generation, offset checks, address packing and log export. Do not automate reasoning about process state.
Write the report continuously: crash screenshot, registers, memory map, payload construction and final proof. After 48 hours, every detail cannot be reconstructed reliably from memory.
OSED suits vulnerability research and reverse engineering. Compare its role with OSEP and OSWE in the OSCE3 roadmap.
Analysing a crash step by step
Start with the smallest input that triggers the failure reliably. Confirm the exception type, register state and whether input controls the instruction pointer or another element relevant to execution flow. Calculate the exact offset with a unique pattern and verify it after restarting the process. A single accidental crash is not yet a stable exploit primitive.
Test bad characters for the specific input channel. A byte may be changed by a parser, copy routine or protocol encoding, so results from one exercise must not be copied blindly to another. Choose payload layout, an intermediate register and the control-transfer technique only after the buffer constraints are known.
DEP, ASLR and ROP-chain quality
ROP is not a contest to collect the most gadgets. A chain must prepare the required arguments, keep the stack consistent and hand off execution predictably. Describe each gadget by its register effects, stack-pointer change and side effects. Step through a small fragment in the debugger before adding the next one.
With ASLR, identify the origin of every address and verify the module properties in the target environment. With DEP, document exactly how memory permissions are changed or existing executable code is reused. This removes unexplained constants and makes the point of instability much easier to locate.
A repeatable workshop
Keep the network sender, payload generator and debugger notes separate. After every meaningful change, run a small regression set: does the process reach the same crash, is the offset still correct, did the buffer length alter the protocol, and are prohibited bytes absent? Automation should remove arithmetic mistakes without hiding data flow.
Once a week, reproduce an exercise from a clean virtual machine and write a short explanation of the root cause, exploit primitive and mitigation bypass. If you cannot explain the exploit without reading the finished script, the preparation remains too fragile.
Sources: OffSec EXP-301 FAQ, OSED Exam Guide.


