debugging concepts

Overview

Reading static disassembly tells you what a program could do; a debugger lets you watch what it actually does as it runs. Debugging is one of the most powerful techniques in reverse engineering because it lets you pause a program, inspect its live state, and step through it one instruction at a time. This lesson explains the core debugging concepts: breakpoints, stepping, inspecting registers and memory, and watchpoints.

Learning objectives

• Explain what a debugger does and how it controls a running program.
• Describe breakpoints and the difference between stepping into and stepping over.
• Inspect registers and memory to understand program state.
• Explain what a watchpoint is and when it helps.

Core concept

A debugger is a tool that runs (or attaches to) a program and gives you control over its execution. Instead of the program running from start to finish invisibly, the debugger lets you stop it at chosen points, examine every register and memory location, change values, and resume or advance execution deliberately. This turns a static, hard-to-follow binary into something you can observe live. Debuggers such as those built around GDB (on Linux) are staples of CTF reversing and exploitation.

How it works

• Breakpoints — a breakpoint tells the debugger to pause execution when the program reaches a specific address or function. When the program hits it, control returns to you so you can inspect the current state before continuing. Breakpoints let you skip straight to the interesting part of a program rather than watching everything.
• Stepping — once paused, you advance execution in small, controlled amounts:
  • Step into — execute the next instruction (or line), and if it is a function call, descend into that function.
  • Step over — execute the next instruction, but if it is a call, run the whole called function and stop after it returns, staying at the current level.
  • Continue — resume normal execution until the next breakpoint or the program ends.
• Inspecting registers — while paused, you can read the CPU registers (like rax or the instruction pointer rip) to see exactly what values the program is working with at that moment. This is how you learn what a computed result or a comparison value really is.
• Inspecting memory — you can dump and read memory at any address: the contents of the stack, a buffer, a string, or a heap block. This reveals data the program is holding that is not visible in registers alone.
• Watchpoints — a watchpoint (sometimes called a data breakpoint) pauses the program when the value at a specific memory location changes (or is read), rather than when execution reaches a specific instruction. It answers the question "what code touches this variable?" by stopping you the moment the watched data is modified.

Practical example

You are solving an authorized reversing challenge where a program compares your input against a secret computed at run time. Statically, the secret is obscured, so you set a breakpoint on the comparison instruction. You run the program, it pauses at the breakpoint, and you inspect the register holding the expected value — revealing the secret the program computed. Alternatively, you set a watchpoint on the memory holding the secret; the debugger stops the instant that value is written, showing you exactly which code produced it. Either way, dynamic analysis exposed information that static reading alone made tedious to recover.

Cybersecurity relevance

Debugging is essential to reverse engineering, malware analysis, and exploit development in authorized settings. Static analysis and dynamic (debugger-based) analysis complement each other: static shows structure, dynamic shows real values and behavior, including things that are only computed at run time or deliberately obscured. Breakpoints and stepping let an analyst zero in on a decision point; inspecting registers and memory reveals secrets, keys, and buffer contents; watchpoints track how and when data changes. These same capabilities let defenders understand malware and let exploit developers observe memory state. Because analysis can involve untrusted or malicious binaries, it must always be done inside an isolated sandbox — the subject of the next lesson.

Common mistakes

• Confusing step-into with step-over and accidentally diving into (or skipping) library functions.
• Setting no breakpoints and trying to follow a fast-running program in real time.
• Reading a register before the relevant instruction has executed, getting a stale value.
• Debugging an untrusted binary outside an isolated environment, risking the host system.

Key takeaways

• A debugger lets you pause, inspect, and step through a running program to observe its real behavior.
• Breakpoints pause execution at a chosen location; step-into descends into calls while step-over runs them to completion.
• Inspecting registers and memory reveals the live values and data a program is working with.
• A watchpoint pauses when a specific memory value changes, helping you find what code touches a variable.

Check your understanding

• What is the difference between stepping into a function and stepping over it?
• How does a watchpoint differ from an ordinary breakpoint?