Debuggers: Stepping Through Someone Else's Code

In Level 0 you stepped through a program with a friendly visualizer and learned that this is called tracing. A debugger is the industrial version of that visualizer, and it is the single most important tool in dynamic reverse engineering. The same program that pauses your code so you can fix a bug pauses an attacker's target so they can understand it.

Three controls, total visibility

A debugger gives an attacker three simple powers, and together they are enough to take a program apart.

• Breakpoints: mark a line, and execution freezes the instant it reaches that line, no matter how the program got there.
• Stepping: from a frozen point, advance exactly one line at a time, so the whole path is walked at human speed.
• Watches: at every pause, inspect the live value of any variable, including values the code worked hard to compute or decode.

Picture pressing pause on a film at the exact frame you care about, then advancing one frame at a time while a caption shows what every character is thinking. You are no longer guessing at the plot from the poster. You are watching it unfold as slowly as you like, with the internal state written out for you. That is what a debugger does to a program.

The reason this defeats static tricks is that a debugger operates on the running program, not the file. Obfuscation rearranges and disguises the static text, but at the moment a breakpoint fires, the debugger shows the true value in that variable right then, however tangled the code that produced it. A decoded string, a computed key, a resolved endpoint: each one is plainly readable in a watch window the instant the program has produced it, because to use a value the program must first materialize it.

Set a breakpoint, watch the state

The stepper below is a small debugger. Set your attention on a line, advance one step at a time, and read the variables table, which is your watch window. Watch a value get assembled across several steps, then sit there in the open, exactly as it would in a real debugger the moment after the program computes it.

Notice the shape of what just happened. The final value did not exist in the file as text; it was built up across several steps. Yet at the moment it finished being built, it sat in the variables table in plain view. No obfuscation of the static code could change that, because the value has to exist to be used, and the debugger reads it exactly when it exists.

Why anti-debugging is a speed bump, not a wall

Programs can try to detect a debugger and refuse to run, and these anti-debugging checks are a real nuisance to an attacker. But they are checks made by code the attacker can read and patch, so a determined reverser finds the check, disables it, and continues. Anti-debugging raises the cost of the first attack on a build; it does not remove the debugger's fundamental power, which is to read runtime state once execution is allowed to proceed.

Prove the runtime-visibility point to yourself. The challenge below assembles a value across a loop, the same way real code assembles a decoded string or a derived key. Reading the code, the final value is not obvious. Step it, or just run it, and the debugger's view settles it immediately. Your task is to make the assembled value come out to a specific target, which forces you to reason about the runtime state a debugger would simply show you.

A debugger turns a locked box into a glass one. Breakpoints stop execution where the attacker chooses, stepping walks the real path, and watches expose every value the moment it exists. Static obfuscation does not survive contact with it, because a running program has to materialize the values it uses, and the debugger reads them precisely then. Anti-debugging slows the first attempt; it does not repeal that fact.

Frequently asked questions