Cyber Security Academy · Lesson

Reversing and Pwn Basics

Intro to reverse engineering and binary exploitation.

Reversing and Pwn Basics is a free Cyber Security Academy lesson on CoddyKit — lesson 3 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Cyber Security Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Reversing and Pwn at a Glance

Two closely related CTF categories deal with compiled programs:

Reverse engineering (rev) — you analyze a binary to understand what it does, often to recover a password check or hidden logic that prints the flag.
Pwn (binary exploitation) — you find a memory-safety bug in a running binary and exploit it to hijack execution, frequently to spawn a shell on a remote service holding the flag.

Rev is about understanding; pwn is about breaking. Both require comfort with low-level concepts.

First Look at a Binary

Never open a binary blind in a disassembler. Triage it first with quick command-line tools to learn its type, architecture, and any obvious strings.

# Identify file type and architecture
file ./challenge

# Pull human-readable strings (flags are sometimes left in plaintext)
strings ./challenge

# Check which security mitigations are enabled
checksec --file=./challenge

Static vs Dynamic Analysis

You analyze binaries two complementary ways:

Static analysis — read the code without running it, using a disassembler or decompiler such as Ghidra or a disassembler view. You see the full control flow but must infer runtime values.
Dynamic analysis — run the program under a debugger such as GDB and watch real values in registers and memory. You see exactly what happens but only along the path you execute.

Skilled players switch between them: read statically to form a theory, confirm dynamically by stepping through.

Reading Disassembly

To reverse, you read assembly. You do not need to write it fluently, but you must recognize patterns:

cmp / test followed by a jump (je, jne) is a comparison and branch - often the password check.
call invokes a function; the arguments were placed in registers or on the stack just before.
mov moves data between registers, memory, and constants.

When you find a cmp against your input followed by a branch to a success message, you have found the check. Now recover or bypass the expected value.

Decompilers Speed You Up

Modern decompilers turn assembly back into approximate C, which is far faster to read than raw instructions. A decompiled password check might look like this:

// Decompiler output (approximate)
if (strcmp(user_input, "s3cr3t_p4ss") == 0) {
    puts("Correct! Here is your flag:");
    print_flag();
} else {
    puts("Wrong.");
}

How Memory Corruption Begins

Pwn challenges exploit programs that read input into a fixed buffer without checking its length. The stack stores local variables and the saved return address that tells the CPU where to go when a function finishes.

If input overflows a local buffer, it can overwrite that saved return address. Whoever controls the return address controls where execution goes next.

// Vulnerable: no bound on how much is read into buf
void vuln() {
    char buf[64];
    gets(buf);   // reads until newline, ignores buf size
}

The Classic Stack Buffer Overflow

The simplest pwn is overwriting the return address to jump to a function the program never intended to call - a hidden win() that prints the flag.

The steps:

Find the exact offset from the start of the buffer to the return address (a cyclic pattern tool gives this quickly).
Find the address of the target function.
Send padding up to the offset, then overwrite the return address with the target.

# Build the input with a Python exploit library
from pwn import *

p = process('./challenge')
offset = 72                 # bytes to reach the return address
win_addr = 0x401176        # address of the win() function
p.sendline(b'A' * offset + p64(win_addr))
p.interactive()

Modern Mitigations

Real binaries enable defenses that block naive overflows. You must recognize them with checksec:

Stack canaries — a secret value placed before the return address; if it changes, the program aborts. You must leak it first.
NX (No-eXecute) — the stack is non-executable, so you cannot run shellcode placed there.
ASLR / PIE — addresses are randomized each run, so you need an address leak before you can aim.
RELRO — protects the global offset table from overwrites.

Each mitigation pushes you toward more advanced techniques.

Return-Oriented Programming (ROP)

When NX stops you from running your own code, Return-Oriented Programming reuses code already in the binary.

You chain together short instruction sequences called gadgets, each ending in ret, to perform actions piece by piece - for example, loading a register and calling a library function to spawn a shell. You build the chain on the stack so each ret jumps to the next gadget.

ROP is the bridge from beginner overflows to real-world exploitation, where attacker code is rarely executable directly.

Format String Bugs

Another classic pwn primitive is the format string vulnerability, where user input is passed directly as the format argument to a print function.

// Vulnerable: user controls the format string
printf(user_input);          // dangerous

// Safe: user input is data, not format
printf("%s", user_input);    // correct

Why Defenders Learn This

You learn to exploit memory bugs precisely so you can prevent them. The defensive takeaways are concrete:

Never use unbounded input functions like gets or strcpy; use length-checked equivalents.
Keep mitigations on: canaries, NX, full ASLR/PIE, and full RELRO by default.
Prefer memory-safe languages where the threat model allows it.
Treat any user-controlled value reaching a format string or a buffer copy as a serious finding in code review.

Quick Check

Test your understanding of reversing and pwn basics.

Recap

You now have a map of reversing and pwn:

Triage every binary with file, strings, and checksec before deep analysis.
Combine static (disassembler/decompiler) and dynamic (debugger) analysis to understand logic.
Pwn starts with the stack buffer overflow overwriting a return address; mitigations (canaries, NX, ASLR/PIE, RELRO) raise the bar.
ROP defeats NX by reusing existing gadgets; format string bugs arise from untrusted format arguments.
Every technique doubles as a defensive lesson for writing and reviewing safer code.

Next, you build a toolkit and learn to write up your solutions.

Frequently asked questions

Is the “Reversing and Pwn Basics” lesson free?

Yes — the full text of “Reversing and Pwn Basics” is free to read here on the web, and the Cyber Security Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Cyber Security Academy course, upgrade to CoddyKit PRO.

What will I learn in “Reversing and Pwn Basics”?

Intro to reverse engineering and binary exploitation. You practise Cyber Security Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Cyber Security Academy?

No prior experience is required. Cyber Security Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 3 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Reversing and Pwn Basics” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Cyber Security Academy lesson?

Yes. Every Cyber Security Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

← Back to Cyber Security Academy