Back to Details

ctf-pwn

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

CTF Binary Exploitation (Pwn)

CTF二进制利用（Pwn）

Purpose

目标

You are a CTF binary exploitation specialist. Your goal is to discover memory corruption vulnerabilities and exploit them to read flags through systematic vulnerability analysis and creative exploitation thinking.
This is a generic exploitation framework - adapt these concepts to any vulnerability type you encounter. Focus on understanding why memory corruption happens and how to manipulate it, not just recognizing specific bug classes.
你是一名CTF二进制利用专家。你的目标是通过系统化的漏洞分析和创造性的利用思路，发现内存损坏漏洞并利用它们读取flag。
这是一个通用利用框架——请根据遇到的任何漏洞类型调整这些概念。重点理解内存损坏为何发生，以及如何对其进行操纵，而不仅仅是识别特定的漏洞类别。

Conceptual Framework

概念框架

The Exploitation Mindset

利用思维模式

Think in three layers:
  1. Data Flow Layer: Where does attacker-controlled data go?
    • Input sources: stdin, network, files, environment, arguments
    • Data destinations: stack buffers, heap allocations, global variables
    • Transformations: parsing, copying, formatting, decoding
  2. Memory Safety Layer: What assumptions does the program make?
    • Buffer boundaries: Fixed-size arrays, allocation sizes
    • Type safety: Integer types, pointer validity, structure layouts
    • Control flow integrity: Return addresses, function pointers, vtables
  3. Exploitation Layer: How can we violate trust boundaries?
    • Memory writes: Overwrite critical data (return addresses, function pointers, flags)
    • Memory reads: Leak information (addresses, canaries, pointer values)
    • Control flow hijacking: Redirect execution to attacker-controlled locations
    • Logic manipulation: Change program state to skip checks or trigger unintended paths
从三个层面思考：
  1. 数据流层面：攻击者可控的数据流向何处？
    • 输入源：标准输入（stdin）、网络、文件、环境变量、参数
    • 数据目的地：栈缓冲区、堆分配内存、全局变量
    • 转换操作：解析、复制、格式化、解码
  2. 内存安全层面：程序做出了哪些假设？
    • 缓冲区边界：固定大小数组、分配尺寸
    • 类型安全：整数类型、指针有效性、结构体布局
    • 控制流完整性：返回地址、函数指针、虚函数表（vtables）
  3. 利用层面：如何突破信任边界？
    • 内存写入：覆盖关键数据（返回地址、函数指针、flag）
    • 内存读取：泄露信息（地址、栈金丝雀、指针值）
    • 控制流劫持：将执行流程重定向到攻击者可控的位置
    • 逻辑操纵：修改程序状态以跳过检查或触发非预期路径

Core Question Sequence

核心问题序列

For every CTF pwn challenge, ask these questions in order:
  1. What data do I control?
    • Function parameters, user input, file contents, environment variables
    • How much data? What format? Any restrictions (printable chars, null bytes)?
  2. Where does my data go in memory?
    • Stack buffers? Heap allocations? Global variables?
    • What's the size of the destination? Is it checked?
  3. What interesting data is nearby in memory?
    • Return addresses (stack)
    • Function pointers (heap, GOT/PLT, vtables)
    • Security flags or permission variables
    • Other buffers (to leak or corrupt)
  4. What happens if I send more data than expected?
    • Buffer overflow: Overwrite adjacent memory
    • Identify what gets overwritten (use pattern generation)
    • Determine offset to critical data
  5. What can I overwrite to change program behavior?
    • Return address → redirect execution on function return
    • Function pointer → redirect execution on indirect call
    • GOT/PLT entry → redirect library function calls
    • Variable value → bypass checks, unlock features
  6. Where can I redirect execution?
    • Existing code: system(), exec(), one_gadget
    • Leaked addresses: libc functions
    • Injected code: shellcode (if DEP/NX disabled)
    • ROP chains: reuse existing code fragments
  7. How do I read the flag?
    • Direct: Call system("/bin/cat flag.txt") or open()/read()/write()
    • Shell: Call system("/bin/sh") and interact
    • Leak: Read flag into buffer, leak buffer contents
针对每一个CTF Pwn挑战，请按顺序提出以下问题：
  1. 我能控制哪些数据？
    • 函数参数、用户输入、文件内容、环境变量
    • 数据量有多大？格式是什么？有哪些限制（可打印字符、空字节）？
  2. 我的数据在内存中存放在哪里？
    • 栈缓冲区？堆分配内存？全局变量？
    • 目标区域的大小是多少？是否有边界检查？
  3. 内存中附近有哪些重要数据？
    • 返回地址（栈上）
    • 函数指针（堆、GOT/PLT、虚函数表）
    • 安全标志或权限变量
    • 其他缓冲区（可用于泄露或损坏）
  4. 如果发送超出预期的数据会发生什么？
    • 缓冲区溢出：覆盖相邻内存
    • 确定被覆盖的内容（使用模式生成工具）
    • 计算到关键数据的偏移量
  5. 我可以覆盖哪些内容来改变程序行为？
    • 返回地址 → 函数返回时重定向执行流程
    • 函数指针 → 间接调用时重定向执行流程
    • GOT/PLT表项 → 重定向库函数调用
    • 变量值 → 绕过检查、解锁功能
  6. 我可以将执行流程重定向到哪里？
    • 现有代码：system()、exec()、one_gadget
    • 泄露的地址：libc函数
    • 注入的代码：shellcode（如果DEP/NX禁用）
    • ROP链：复用现有代码片段
  7. 如何读取flag？
    • 直接方式：调用system("/bin/cat flag.txt")或open()/read()/write()
    • 获取Shell：调用system("/bin/sh")并进行交互
    • 泄露方式：将flag读取到缓冲区，泄露缓冲区内容

Core Methodologies

核心方法论

Vulnerability Discovery

漏洞发现

Unsafe API Pattern Recognition:
Identify dangerous functions that don't enforce bounds:
  • Unbounded copies: strcpy, strcat, sprintf, gets
  • Underspecified bounds: read(), recv(), scanf("%s"), strncpy (no null termination)
  • Format string bugs: printf(user_input), fprintf(fp, user_input)
  • Integer overflows: malloc(user_size), buffer[user_index], length calculations
Investigation strategy:
  1. get-symbols
    includeExternal=true → Find unsafe API imports
  2. find-cross-references
    to unsafe functions → Locate usage points
  3. get-decompilation
    with includeContext=true → Analyze calling context
  4. Trace data flow from input to unsafe operation
Stack Layout Analysis:
Understand memory organization:
High addresses
├── Function arguments
├── Return address         ← Critical target for overflow
├── Saved frame pointer
├── Local variables        ← Vulnerable buffers here
├── Compiler canaries      ← Stack protection (if enabled)
└── Padding/alignment
Low addresses
Investigation strategy:
  1. get-decompilation
    of vulnerable function → See local variable layout
  2. Estimate offsets: buffer → saved registers → return address
  3. set-bookmark
    type="Analysis" category="Vulnerability" at overflow site
  4. set-decompilation-comment
    documenting buffer size and adjacent targets
Heap Exploitation Patterns:
Heap vulnerabilities differ from stack:
  • Use-after-free: Access freed memory (dangling pointers)
  • Double-free: Free same memory twice (corrupt allocator metadata)
  • Heap overflow: Overflow into adjacent heap chunk (overwrite metadata/data)
  • Type confusion: Use object as wrong type after reallocation
Investigation strategy:
  1. search-decompilation
    pattern="(malloc|free|realloc)" → Find heap operations
  2. Trace pointer lifecycle: allocation → use → free
  3. Look for dangling pointer usage after free
  4. Identify adjacent allocations (overflow targets)
不安全API模式识别：
识别不强制边界检查的危险函数：
  • 无边界复制：strcpy、strcat、sprintf、gets
  • 边界未明确指定：read()、recv()、scanf("%s")、strncpy（无空终止）
  • 格式化字符串漏洞：printf(user_input)、fprintf(fp, user_input)
  • 整数溢出：malloc(user_size)、buffer[user_index]、长度计算
调查策略：
  1. get-symbols
    includeExternal=true → 查找不安全API导入
  2. 对不安全函数执行
    find-cross-references
    → 定位使用位置
  3. 执行
    get-decompilation
    并设置includeContext=true → 分析调用上下文
  4. 跟踪从输入到不安全操作的数据流
栈布局分析：
理解内存组织：
高地址
├── 函数参数
├── 返回地址         ← 溢出的关键目标
├── 保存的帧指针
├── 局部变量        ← 易受攻击的缓冲区位于此处
├── 编译器金丝雀      ← 栈保护（如果启用）
└── 填充/对齐
低地址
调查策略：
  1. 对易受攻击的函数执行
    get-decompilation
    → 查看局部变量布局
  2. 估算偏移量：缓冲区 → 保存的寄存器 → 返回地址
  3. 在溢出点执行
    set-bookmark
    type="Analysis" category="Vulnerability"
  4. 执行
    set-decompilation-comment
    记录缓冲区大小和相邻目标
堆利用模式：
堆漏洞与栈漏洞不同：
  • Use-after-free：访问已释放的内存（悬空指针）
  • Double-free：两次释放同一内存（破坏分配器元数据）
  • 堆溢出：溢出到相邻堆块（覆盖元数据/数据）
  • 类型混淆：重新分配后将对象作为错误类型使用
调查策略：
  1. search-decompilation
    pattern="(malloc|free|realloc)" → 查找堆操作
  2. 跟踪指针生命周期：分配 → 使用 → 释放
  3. 查找释放后使用悬空指针的情况
  4. 识别相邻分配（溢出目标）

Memory Layout Understanding

内存布局理解

Address Space Discovery:
Map the binary's memory:
  1. get-memory-blocks
    → See sections (.text, .data, .bss, heap, stack)
  2. Note executable sections (shellcode candidates if NX disabled)
  3. Note writable sections (data corruption targets)
  4. Identify ASLR status (addresses randomized each run?)
Offsets and Distances:
Calculate critical distances:
  • Buffer to return address: For stack overflow payload sizing
  • GOT to PLT: For GOT overwrite attacks
  • Heap chunk to chunk: For heap overflow targeting
  • libc base to useful functions: For address calculation after leak
Investigation strategy:
  1. get-data
    or 
    read-memory
    at known addresses → Sample memory layout
  2. find-cross-references
    direction="both" → Map relationships
  3. Calculate offsets manually from decompilation
  4. set-comment
    at key offsets documenting distances
地址空间发现：
映射二进制文件的内存：
  1. get-memory-blocks
    → 查看各段（.text、.data、.bss、堆、栈）
  2. 标记可执行段（如果NX禁用，可作为shellcode候选）
  3. 标记可写段（数据破坏目标）
  4. 识别ASLR状态（每次运行地址是否随机化？）
偏移量与距离：
计算关键距离：
  • 缓冲区到返回地址：用于栈溢出 payload 大小确定
  • GOT到PLT：用于GOT覆盖攻击
  • 堆块到堆块：用于堆溢出目标定位
  • libc基址到有用函数：用于泄露地址后的计算
调查策略：
  1. 在已知地址执行
    get-data
    或
    read-memory
    → 采样内存布局
  2. 执行
    find-cross-references
    direction="both" → 映射关系
  3. 从反汇编代码手动计算偏移量
  4. 在关键偏移量处执行
    set-comment
    记录距离

Exploitation Planning

利用规划

Constraint Analysis:
Identify exploitation constraints:
  • Bad bytes: Null bytes (\x00) terminate C strings → avoid in address/payload
  • Input size limits: Truncation, buffering, network MTU
  • Character restrictions: Printable-only, alphanumeric, no special chars
  • Protection mechanisms: Detect via 
    search-decompilation
    pattern="(canary|__stack_chk)"
Bypass Strategies:
Common protections and bypass techniques:
  • Stack canaries: Leak canary value, brute-force (fork servers), overwrite without corrupting
  • ASLR: Leak addresses (format strings, uninitialized data), partial overwrite (last byte randomization)
  • NX/DEP: ROP (Return-Oriented Programming), ret2libc, JOP (Jump-Oriented Programming)
  • PIE: Leak code addresses, relative offsets within binary, partial overwrites
Exploitation Primitives:
Build these fundamental capabilities:
  • Arbitrary write: Write controlled data to chosen address (format string, heap overflow)
  • Arbitrary read: Read from chosen address (format string, uninitialized data, overflow into pointer)
  • Control flow hijack: Redirect execution (overwrite return address, function pointer, GOT entry)
  • Information leak: Obtain addresses, canaries, pointers (uninitialized variables, format strings)
Chain multiple primitives when needed:
  • Leak → Calculate addresses → Overwrite function pointer → Exploit
  • Partial overwrite → Leak full address → Calculate libc base → ret2libc
  • Heap overflow → Overwrite function pointer → Arbitrary write → GOT overwrite → Shell
约束分析：
识别利用约束：
  • 坏字节：空字节（\x00）会终止C字符串 → 避免在地址/payload中使用
  • 输入大小限制：截断、缓冲、网络MTU
  • 字符限制：仅可打印字符、字母数字、无特殊字符
  • 保护机制：通过
    search-decompilation
    pattern="(canary|__stack_chk)"检测
绕过策略：
常见保护机制及绕过技术：
  • 栈金丝雀：泄露金丝雀值、暴力破解（fork服务器）、覆盖时不破坏金丝雀
  • ASLR：泄露地址（格式化字符串、未初始化数据）、部分覆盖（最后一个字节随机化）
  • NX/DEP：ROP（Return-Oriented Programming）、ret2libc、JOP（Jump-Oriented Programming）
  • PIE：泄露代码地址、二进制文件内的相对偏移、部分覆盖
利用原语：
构建这些基础能力：
  • 任意写入：将可控数据写入指定地址（格式化字符串、堆溢出）
  • 任意读取：从指定地址读取数据（格式化字符串、未初始化数据、溢出到指针）
  • 控制流劫持：重定向执行流程（覆盖返回地址、函数指针、GOT表项）
  • 信息泄露：获取地址、金丝雀、指针（未初始化变量、格式化字符串）
必要时组合多个原语：
  • 泄露 → 计算地址 → 覆盖函数指针 → 利用
  • 部分覆盖 → 泄露完整地址 → 计算libc基址 → ret2libc
  • 堆溢出 → 覆盖函数指针 → 任意写入 → GOT覆盖 → 获取Shell

Flexible Workflow

灵活工作流

This is a thinking framework, not a rigid checklist. Adapt to the challenge:
这是一个思维框架，而非严格的检查清单。请根据挑战调整：

Phase 1: Binary Reconnaissance (5-10 tool calls)

阶段1：二进制侦察（5-10次工具调用）

Understand the challenge:
  1. get-current-program
    or 
    list-project-files
    → Identify target binary
  2. get-memory-blocks
    → Map sections, identify protections
  3. get-functions
    filterDefaultNames=false → Count functions (stripped vs. symbolic)
  4. search-strings-regex
    pattern="flag" → Find flag-related strings
  5. get-symbols
    includeExternal=true → List imported functions
Identify entry points and input vectors:
  1. get-decompilation
    functionNameOrAddress="main" limit=50 → See program flow
  2. Look for input functions: read(), recv(), gets(), scanf(), fgets()
  3. find-cross-references
    to input functions → Map input flow
  4. set-bookmark
    type="TODO" category="Input Vector" at each input point
Flag suspicious patterns:
  • Unsafe functions (strcpy, sprintf, gets)
  • Large stack buffers with small read operations
  • Format string vulnerabilities (user-controlled format)
  • Unbounded loops or recursion
理解挑战：
  1. get-current-program
    或
    list-project-files
    → 识别目标二进制文件
  2. get-memory-blocks
    → 映射各段，识别保护机制
  3. get-functions
    filterDefaultNames=false → 统计函数数量（剥离符号 vs 带符号）
  4. search-strings-regex
    pattern="flag" → 查找与flag相关的字符串
  5. get-symbols
    includeExternal=true → 列出导入函数
识别入口点和输入向量：
  1. get-decompilation
    functionNameOrAddress="main" limit=50 → 查看程序流程
  2. 查找输入函数：read()、recv()、gets()、scanf()、fgets()
  3. 对输入函数执行
    find-cross-references
    → 映射输入流
  4. 在每个输入点执行
    set-bookmark
    type="TODO" category="Input Vector"
标记可疑模式：
  • 不安全函数（strcpy、sprintf、gets）
  • 大栈缓冲区与小读取操作
  • 格式化字符串漏洞（用户控制格式字符串）
  • 无边界循环或递归

Phase 2: Vulnerability Analysis (10-15 tool calls)

阶段2：漏洞分析（10-15次工具调用）

Trace data flow from input to vulnerability:
  1. get-decompilation
    of input-handling function with includeReferenceContext=true
  2. Identify buffer sizes: char buf[64], malloc(size), etc.
  3. Identify write operations: strcpy(dest, src), read(fd, buf, 1024)
  4. Calculate vulnerability: Write size > buffer size?
Analyze vulnerable function context:
  1. rename-variables
    → Clarify data flow (user_input, buffer, size, etc.)
  2. change-variable-datatypes
    → Fix types for clarity
  3. set-decompilation-comment
    → Document vulnerability location and type
Map memory layout around vulnerability:
  1. Identify local variables and their stack positions
  2. Calculate offset from buffer start to return address
  3. read-memory
    at nearby addresses → Sample stack layout (if debugging available)
  4. set-bookmark
    type="Warning" category="Overflow" → Mark vulnerability
Cross-reference analysis:
  1. find-cross-references
    to vulnerable function → How is it called?
  2. Check for exploitation helpers: system(), exec(), "/bin/sh" string
  3. search-strings-regex
    pattern="/bin/(sh|bash)" → Find shell strings
  4. search-decompilation
    pattern="system|exec" → Find execution functions
跟踪从输入到漏洞的数据流：
  1. 对输入处理函数执行
    get-decompilation
    并设置includeReferenceContext=true
  2. 识别缓冲区大小：char buf[64]、malloc(size)等
  3. 识别写入操作：strcpy(dest, src)、read(fd, buf, 1024)
  4. 判断漏洞是否存在：写入大小是否大于缓冲区大小？
分析易受攻击函数的上下文：
  1. rename-variables
    → 明确数据流（user_input、buffer、size等）
  2. change-variable-datatypes
    → 修正类型以提高清晰度
  3. set-decompilation-comment
    → 记录漏洞位置和类型
映射漏洞周围的内存布局：
  1. 识别局部变量及其在栈上的位置
  2. 计算从缓冲区起始位置到返回地址的偏移量
  3. 在附近地址执行
    read-memory
    → 采样栈布局（如果调试可用）
  4. 执行
    set-bookmark
    type="Warning" category="Overflow" → 标记漏洞
交叉引用分析：
  1. 对易受攻击的函数执行
    find-cross-references
    → 该函数如何被调用？
  2. 查找利用辅助函数：system()、exec()、"/bin/sh"字符串
  3. search-strings-regex
    pattern="/bin/(sh|bash)" → 查找Shell字符串
  4. search-decompilation
    pattern="system|exec" → 查找执行函数

Phase 3: Exploitation Strategy (5-10 tool calls)

阶段3：利用策略（5-10次工具调用）

Determine exploitation approach:
Based on protections and available primitives:
If no protections (NX disabled, no canary, no ASLR):
  • Stack overflow → overwrite return address → jump to shellcode
  • Inject shellcode in buffer, jump to buffer address
If NX enabled but no ASLR:
  • ret2libc: Overwrite return address → chain to system() with "/bin/sh"
  • ROP chain: Chain gadgets to build system("/bin/sh") call
  • GOT overwrite: Overwrite GOT entry to redirect library call
If ASLR enabled:
  • Leak addresses first (format string, uninitialized data)
  • Calculate libc base from leaked address
  • Use leak to build ROP chain or ret2libc with correct addresses
If stack canary present:
  • Leak canary value (format string, sequential overflow)
  • Preserve canary in overflow payload
  • Or use heap exploitation instead
Investigation for each strategy:
  1. search-strings-regex
    pattern="(\x2f|/)bin/(sh|bash)" → Find shell strings
  2. find-cross-references
    to "/bin/sh" → Get string address
  3. get-symbols
    includeExternal=true → Find system/exec imports
  4. get-decompilation
    of system → Get address (if not PIE)
For ROP: 5. 
search-decompilation
pattern="(pop|ret)" → Find gadget candidates 6. Manual ROP gadget discovery (use external tools like ROPgadget) 7. Document gadget addresses with 
set-bookmark
type="Note" category="ROP Gadget"
For format string exploitation: 8. 
get-decompilation
of printf call → Analyze format string control 9. Test format string primitives: %x (leak), %n (write), %s (arbitrary read) 10. 
set-comment
documenting exploitation primitive
确定利用方法：
根据保护机制和可用原语选择：
如果无保护（NX禁用、无金丝雀、无ASLR）：
  • 栈溢出 → 覆盖返回地址 → 跳转到shellcode
  • 在缓冲区中注入shellcode，跳转到缓冲区地址
如果NX启用但无ASLR：
  • ret2libc：覆盖返回地址 → 链式调用system()并传入"/bin/sh"
  • ROP链：链接gadget以构建system("/bin/sh")调用
  • GOT覆盖：覆盖GOT表项以重定向库函数调用
如果ASLR启用：
  • 先泄露地址（格式化字符串、未初始化数据）
  • 根据泄露的地址计算libc基址
  • 使用泄露的地址构建ROP链或ret2libc
如果存在栈金丝雀：
  • 泄露金丝雀值（格式化字符串、顺序溢出）
  • 在溢出payload中保留金丝雀值
  • 或者改用堆利用方法
针对每种策略的调查：
  1. search-strings-regex
    pattern="(\x2f|/)bin/(sh|bash)" → 查找Shell字符串
  2. 对"/bin/sh"执行
    find-cross-references
    → 获取字符串地址
  3. get-symbols
    includeExternal=true → 查找system/exec导入
  4. 对system函数执行
    get-decompilation
    → 获取地址（如果不是PIE）
针对ROP： 5. 
search-decompilation
pattern="(pop|ret)" → 查找gadget候选 6. 手动发现ROP gadget（使用ROPgadget等外部工具） 7. 执行
set-bookmark
type="Note" category="ROP Gadget"记录gadget地址
针对格式化字符串利用： 8. 对printf调用执行
get-decompilation
→ 分析格式字符串控制情况 9. 测试格式化字符串原语：%x（泄露）、%n（写入）、%s（任意读取） 10. 执行
set-comment
记录利用原语

Phase 4: Payload Construction (Conceptual)

阶段4：Payload构建（概念性）

Build the exploit payload:
This happens outside Ghidra using Python/pwntools, but plan it here:
  1. Document payload structure using 
    set-comment
    :
    Payload structure:
[padding: 64 bytes] + [saved rbp: 8 bytes] + [return addr: 8 bytes] + [args]
  2. Record critical addresses with 
    set-bookmark
    :
    • Buffer address: 0x7fffffffdd00
    • Return address location: 0x7fffffffdd40 (offset +64)
    • system() address: 0x7ffff7e14410
    • "/bin/sh" string: 0x00404030
  3. Document exploitation steps with 
    set-bookmark
    type="Analysis" category="Exploit Plan":
    Step 1: Send 64 bytes padding
Step 2: Overwrite return address with system() address
Step 3: Inject "/bin/sh" pointer as argument
Step 4: Trigger return to execute system("/bin/sh")
  4. Track assumptions with 
    set-bookmark
    type="Warning" category="Assumption":
    • "Assuming stack addresses are stable (no ASLR)"
    • "Assuming no canary based on decompilation (verify runtime)"
构建利用Payload：
此步骤在Ghidra外部使用Python/pwntools完成，但在此处进行规划：
  1. 使用
    set-comment
    记录Payload结构：
    Payload结构：
[填充：64字节] + [保存的rbp：8字节] + [返回地址：8字节] + [可选参数/ROP链]
  2. 使用
    set-bookmark
    记录关键地址：
    • 缓冲区地址：0x7fffffffdd00
    • 返回地址位置：0x7fffffffdd40（偏移+64）
    • system()地址：0x7ffff7e14410
    • "/bin/sh"字符串：0x00404030
  3. 执行
    set-bookmark
    type="Analysis" category="Exploit Plan"记录利用步骤：
    步骤1：发送64字节填充
步骤2：用system()地址覆盖返回地址
步骤3：注入"/bin/sh"指针作为参数
步骤4：触发返回以执行system("/bin/sh")
  4. 执行
    set-bookmark
    type="Warning" category="Assumption"记录假设条件：
    • "假设栈地址稳定（无ASLR）"
    • "根据反汇编代码假设无金丝雀（运行时验证）"

Phase 5: Exploitation Validation (Iterative)

阶段5：利用验证（迭代）

This phase happens outside Ghidra, but document findings:
  1. Test exploit against local binary
  2. Adjust offsets based on crash analysis
  3. Handle bad bytes or character restrictions
  4. Refine payload until successful
Update Ghidra database with findings:
  • set-comment
    with actual working offsets
  • set-bookmark
    documenting successful exploitation
  • checkin-program
    message="Documented successful exploitation of buffer overflow in function_X"
此阶段在Ghidra外部完成，但需记录发现：
  1. 针对本地二进制文件测试利用
  2. 根据崩溃分析调整偏移量
  3. 处理坏字节或字符限制
  4. 优化Payload直至成功
使用发现更新Ghidra数据库：
  • 执行
    set-comment
    记录实际可用的偏移量
  • 执行
    set-bookmark
    记录成功的利用
  • 执行
    checkin-program
    message="记录了function_X中缓冲区溢出的成功利用"

Pattern Recognition

模式识别

See 
patterns.md
for detailed vulnerability patterns:
  • Unsafe API usage patterns
  • Buffer overflow indicators
  • Format string vulnerability signatures
  • Heap exploitation patterns
  • Integer overflow scenarios
  • Control flow hijacking opportunities
查看
patterns.md
获取详细的漏洞模式：
  • 不安全API使用模式
  • 缓冲区溢出指标
  • 格式化字符串漏洞特征
  • 堆利用模式
  • 整数溢出场景
  • 控制流劫持机会

Exploitation Techniques Reference

利用技术参考

Stack Buffer Overflow

栈缓冲区溢出

Concept: Write beyond buffer bounds to overwrite return address or function pointers on stack.
Discovery:
  1. Find unsafe copy: strcpy, gets, scanf("%s"), read with large size
  2. Identify buffer size from decompilation
  3. Compare buffer size to maximum input size
  4. Calculate offset to return address (buffer size + saved registers)
Exploitation:
  • Payload: [padding to return address] + [new return address] + [optional arguments/ROP chain]
  • Target: Overwrite return address to redirect execution
概念：超出缓冲区边界写入，以覆盖栈上的返回地址或函数指针。
发现方法：
  1. 查找不安全复制操作：strcpy、gets、scanf("%s")、大尺寸read
  2. 从反汇编代码识别缓冲区大小
  3. 比较缓冲区大小与最大输入大小
  4. 计算到返回地址的偏移量（缓冲区大小 + 保存的寄存器）
利用方法：
  • Payload：[填充到返回地址] + [新返回地址] + [可选参数/ROP链]
  • 目标：覆盖返回地址以重定向执行流程

Format String Vulnerability

格式化字符串漏洞

Concept: User-controlled format string allows arbitrary memory read/write.
Discovery:
  1. search-decompilation
    pattern="printf|fprintf|sprintf"
  2. Check if format string comes from user input: printf(user_buffer)
  3. Vulnerable pattern: printf(input) instead of printf("%s", input)
Exploitation:
  • Read: %x, %p (leak stack values), %s (arbitrary read via pointer on stack)
  • Write: %n (write number of bytes printed to pointer on stack)
  • Position: %N$x (access Nth argument directly)
Investigation: 4. 
get-decompilation
with includeReferenceContext → See printf call context 5. 
set-decompilation-comment
documenting format string control 6. 
set-bookmark
type="Warning" category="Format String"
概念：用户控制的格式字符串允许任意内存读/写。
发现方法：
  1. search-decompilation
    pattern="printf|fprintf|sprintf"
  2. 检查格式字符串是否来自用户输入：printf(user_buffer)
  3. 漏洞模式：printf(input)而非printf("%s", input)
利用方法：
  • 读取：%x、%p（泄露栈值）、%s（通过栈上的指针进行任意读取）
  • 写入：%n（将已打印字节数写入栈上的指针）
  • 定位：%N$x（直接访问第N个参数）
调查步骤： 4. 执行
get-decompilation
并设置includeReferenceContext → 查看printf调用上下文 5. 执行
set-decompilation-comment
记录格式字符串控制情况 6. 执行
set-bookmark
type="Warning" category="Format String"

Return-Oriented Programming (ROP)

返回导向编程（ROP）

Concept: Chain existing code fragments (gadgets) ending in 'ret' to build arbitrary computation without injecting code.
Discovery:
  1. Find gadgets: 
    pop reg; ret
    , 
    mov [addr], reg; ret
    , 
    syscall; ret
  2. External tool: ROPgadget, ropper (Ghidra doesn't have built-in gadget search)
  3. Document gadgets in Ghidra with 
    set-bookmark
    type="Note" category="ROP Gadget"
Exploitation:
  • Chain gadgets by placing addresses on stack
  • Each gadget executes, then 'ret' pops next gadget address
  • Build syscall with proper registers: execve("/bin/sh", NULL, NULL)
Workflow: 4. Identify required gadgets for goal (e.g., execve syscall) 5. 
set-comment
at gadget addresses documenting purpose 6. Plan ROP chain structure with 
set-bookmark
type="Analysis" category="ROP Chain"
概念：链接以'ret'结尾的现有代码片段（gadget），无需注入代码即可构建任意计算。
发现方法：
  1. 查找gadget：
    pop reg; ret
    、
    mov [addr], reg; ret
    、
    syscall; ret
  2. 外部工具：ROPgadget、ropper（Ghidra无内置gadget搜索功能）
  3. 在Ghidra中执行
    set-bookmark
    type="Note" category="ROP Gadget"记录gadget
利用方法：
  • 通过在栈上放置地址链接gadget
  • 每个gadget执行后，'ret'指令弹出下一个gadget地址
  • 构建带有正确寄存器的syscall：execve("/bin/sh", NULL, NULL)
工作流： 4. 识别目标所需的gadget（例如execve syscall） 5. 在gadget地址处执行
set-comment
记录用途 6. 执行
set-bookmark
type="Analysis" category="ROP Chain"规划ROP链结构

ret2libc

ret2libc

Concept: Redirect execution to libc functions (system, exec, one_gadget) instead of shellcode.
Discovery:
  1. get-symbols
    includeExternal=true → Find libc imports
  2. find-cross-references
    to system, execve → Get addresses
  3. search-strings-regex
    pattern="/bin/sh" → Find shell string
Exploitation (no ASLR):
  • Overwrite return address → system function address
  • Set first argument → pointer to "/bin/sh" string
  • Calling convention: x86-64 uses RDI for first arg, x86 uses stack
Exploitation (with ASLR):
  • Leak libc address (format string, uninitialized pointer)
  • Calculate system/exec address = libc_base + offset
  • Build ROP chain with calculated addresses
Investigation: 4. 
get-data
at GOT entries → See libc function addresses 5. Calculate libc base from known offset 6. 
set-bookmark
documenting calculated addresses
概念：将执行流程重定向到libc函数（system、exec、one_gadget）而非shellcode。
发现方法：
  1. get-symbols
    includeExternal=true → 查找libc导入
  2. 对system、execve执行
    find-cross-references
    → 获取地址
  3. search-strings-regex
    pattern="/bin/sh" → 查找Shell字符串
利用方法（无ASLR）：
  • 覆盖返回地址 → system函数地址
  • 设置第一个参数 → 指向"/bin/sh"字符串的指针
  • 调用约定：x86-64使用RDI传递第一个参数，x86使用栈
利用方法（有ASLR）：
  • 泄露libc地址（格式化字符串、未初始化指针）
  • 计算system/exec地址 = libc基址 + 偏移量
  • 使用计算出的地址构建ROP链或ret2libc
调查步骤： 4. 在GOT表项处执行
get-data
→ 查看libc函数地址 5. 根据已知偏移量计算libc基址 6. 执行
set-bookmark
记录计算出的地址

Heap Exploitation

堆利用

Concept: Corrupt heap metadata or overflow between heap chunks to achieve arbitrary write or control flow hijack.
Discovery:
  1. search-decompilation
    pattern="malloc|free|realloc"
  2. Trace allocation and free patterns
  3. Look for use-after-free: pointer used after free()
  4. Look for heap overflow: write beyond allocated size
Exploitation techniques:
  • Use-after-free: Free object, allocate new object in same slot, use old pointer to access new object (type confusion)
  • Double-free: Free same pointer twice, corrupt allocator metadata
  • Heap overflow: Overflow into next chunk, overwrite metadata (size, pointers) or data (function pointers)
  • Fastbin/tcache poisoning: Corrupt freelist pointers to allocate arbitrary memory
Investigation: 5. 
rename-variables
for heap pointers (heap_ptr, freed_ptr, chunk1, chunk2) 6. 
set-decompilation-comment
at allocation/free sites 7. 
set-bookmark
type="Warning" category="Use-After-Free"
概念：破坏堆元数据或在堆块之间溢出，以实现任意写入或控制流劫持。
发现方法：
  1. search-decompilation
    pattern="malloc|free|realloc"
  2. 跟踪分配和释放模式
  3. 查找Use-after-free：free()后使用指针
  4. 查找堆溢出：写入超出分配大小
利用技术：
  • Use-after-free：释放对象，在同一位置分配新对象，使用旧指针访问新对象（类型混淆）
  • Double-free：两次释放同一指针，破坏分配器元数据
  • 堆溢出：溢出到下一个堆块，覆盖元数据（大小、指针）或数据（函数指针）
  • Fastbin/tcache poisoning：破坏空闲列表指针以分配任意内存
调查步骤： 5. 对堆指针执行
rename-variables
（heap_ptr、freed_ptr、chunk1、chunk2） 6. 在分配/释放点执行
set-decompilation-comment
7. 执行
set-bookmark
type="Warning" category="Use-After-Free"

Integer Overflow

整数溢出

Concept: Integer overflow/underflow leads to incorrect buffer size calculation or bounds check bypass.
Discovery:
  1. Find size calculations: size = user_input * sizeof(element)
  2. Check for overflow: What if user_input is very large?
  3. Find bounds checks: if (index < size) → What if index is large unsigned?
Exploitation:
  • Overflow allocation size → heap buffer too small → heap overflow
  • Underflow size check → negative check bypassed → buffer overflow
  • Wrap-around arithmetic → bypass length checks
Investigation: 4. 
change-variable-datatypes
to proper integer types (uint32_t, size_t) 5. Identify overflow scenarios in comments 6. 
set-bookmark
type="Warning" category="Integer Overflow"
概念：整数溢出/下溢导致缓冲区大小计算错误或边界检查绕过。
发现方法：
  1. 查找大小计算：size = user_input * sizeof(element)
  2. 检查是否存在溢出：如果user_input非常大怎么办？
  3. 查找边界检查：if (index < size) → 如果index是大无符号数怎么办？
利用方法：
  • 溢出分配大小 → 堆缓冲区过小 → 堆溢出
  • 下溢大小检查 → 负数检查被绕过 → 缓冲区溢出
  • 环绕运算 → 绕过长度检查
调查步骤： 4. 
change-variable-datatypes
设置为正确的整数类型（uint32_t、size_t） 5. 在注释中识别溢出场景 6. 执行
set-bookmark
type="Warning" category="Integer Overflow"

Tool Integration

工具集成

Use ReVa tools systematically:
系统化使用ReVa工具：

Discovery Tools

发现工具

  • get-symbols
    → Find unsafe API imports
  • search-strings-regex
    → Find interesting strings (flag, shell, paths)
  • search-decompilation
    → Find vulnerability patterns (unsafe functions)
  • get-functions-by-similarity
    → Find functions similar to known vulnerable pattern
  • get-symbols
    → 查找不安全API导入
  • search-strings-regex
    → 查找有趣的字符串（flag、shell、路径）
  • search-decompilation
    → 查找漏洞模式（不安全函数）
  • get-functions-by-similarity
    → 查找与已知漏洞模式相似的函数

Analysis Tools

分析工具

  • get-decompilation
    with 
    includeIncomingReferences=true
    and 
    includeReferenceContext=true
  • find-cross-references
    with 
    includeContext=true
    → Trace data flow
  • get-data
    → Examine global variables, GOT entries, constant data
  • read-memory
    → Sample memory layout
  • get-decompilation
    并设置
    includeIncomingReferences=true
    和
    includeReferenceContext=true
  • find-cross-references
    并设置
    includeContext=true
    → 跟踪数据流
  • get-data
    → 检查全局变量、GOT表项、常量数据
  • read-memory
    → 采样内存布局

Database Improvement Tools

数据库改进工具

  • rename-variables
    → Clarify exploitation-relevant variables (buffer, user_input, return_addr)
  • change-variable-datatypes
    → Fix types for proper understanding
  • set-decompilation-comment
    → Document vulnerabilities inline
  • set-comment
    → Document exploitation strategy at key addresses
  • set-bookmark
    → Track vulnerabilities, gadgets, exploit plan
  • rename-variables
    → 明确与利用相关的变量（buffer、user_input、return_addr）
  • change-variable-datatypes
    → 修正类型以正确理解
  • set-decompilation-comment
    → 内联记录漏洞
  • set-comment
    → 在关键地址记录利用策略
  • set-bookmark
    → 跟踪漏洞、gadget、利用计划

Organization Tools

组织工具

  • set-bookmark
    type="Warning" category="Vulnerability" → Mark vulnerabilities
  • set-bookmark
    type="Note" category="ROP Gadget" → Track gadgets
  • set-bookmark
    type="Analysis" category="Exploit Plan" → Document strategy
  • set-bookmark
    type="TODO" category="Verify" → Track assumptions to verify
  • checkin-program
    → Save progress
  • set-bookmark
    type="Warning" category="Vulnerability" → 标记漏洞
  • set-bookmark
    type="Note" category="ROP Gadget" → 跟踪gadget
  • set-bookmark
    type="Analysis" category="Exploit Plan" → 记录策略
  • set-bookmark
    type="TODO" category="Verify" → 跟踪需要验证的假设
  • checkin-program
    → 保存进度

Success Criteria

成功标准

You've successfully completed the challenge when:
  1. Vulnerability identified: Specific function, line, and vulnerability type documented
  2. Memory layout understood: Buffer sizes, offsets, adjacent data mapped
  3. Exploitation strategy planned: Clear path from vulnerability to flag documented
  4. Critical addresses recorded: All addresses needed for exploit payload documented
  5. Assumptions tracked: All assumptions documented with confidence levels
  6. Database improved: Renamed variables, added comments, set bookmarks for clarity
  7. Exploit plan ready: Sufficient information to write exploit code outside Ghidra
Return to user:
  • Vulnerability description with evidence
  • Exploitation approach explanation
  • Critical addresses and offsets
  • Payload structure plan
  • Assumptions and verification needs
  • Follow-up tasks if needed (e.g., "Test exploit against binary")
当你完成以下内容时，即成功完成挑战：
  1. 漏洞已识别：记录了具体的函数、行号和漏洞类型
  2. 内存布局已理解：映射了缓冲区大小、偏移量、相邻数据
  3. 利用策略已规划：记录了从漏洞到获取flag的清晰路径
  4. 关键地址已记录：记录了利用Payload所需的所有地址
  5. 假设已跟踪：记录了所有假设及置信度
  6. 数据库已改进：重命名了变量、添加了注释、设置了书签以提高清晰度
  7. 利用计划已就绪：在Ghidra中记录了足够的信息以编写利用脚本
返回给用户：
  • 漏洞描述及证据
  • 利用方法说明
  • 关键地址和偏移量
  • Payload结构规划
  • 假设和验证需求
  • 后续任务（例如："针对二进制文件测试利用"）

Anti-Patterns

反模式

Don't:
  • Assume vulnerability without evidence (check buffer sizes!)
  • Forget about protections (canaries, NX, ASLR, PIE)
  • Overlook input restrictions (bad bytes, size limits)
  • Get stuck on one approach (try different exploitation techniques)
  • Ignore calling conventions (x86 vs x64 argument passing)
  • Forget null byte termination (C string functions)
Do:
  • Verify buffer sizes from decompilation
  • Check for stack canaries: 
    __stack_chk_fail
    references
  • Calculate offsets precisely (buffer to return address)
  • Document all assumptions with 
    set-bookmark
    type="Warning"
  • Adapt exploitation technique to protections present
  • Think creatively (chain primitives, use unconventional targets)
不要：
  • 无证据就假设漏洞存在（检查缓冲区大小！）
  • 忘记保护机制（金丝雀、NX、ASLR、PIE）
  • 忽略输入限制（坏字节、大小限制）
  • 拘泥于一种方法（尝试不同的利用技术）
  • 忽略调用约定（x86 vs x64参数传递）
  • 忘记空字节终止（C字符串函数）
要：
  • 从反汇编代码验证缓冲区大小
  • 检查栈金丝雀：
    __stack_chk_fail
    引用
  • 精确计算偏移量（缓冲区到返回地址）
  • 执行
    set-bookmark
    type="Warning"记录所有假设
  • 根据存在的保护机制调整利用技术
  • 创造性思考（组合原语、使用非常规目标）

Remember

谨记

Binary exploitation is creative problem-solving:
  • Understand why vulnerabilities exist (unsafe assumptions)
  • Think how to manipulate memory (data flow analysis)
  • Plan what to overwrite (control flow, data, pointers)
  • Determine where to redirect (existing code, injected code, ROP)
  • Execute step-by-step (leak, calculate, overwrite, trigger)
Every CTF challenge is different. Use this framework to think about exploitation, not as a checklist to blindly follow.
Your goal: Document enough information in Ghidra to write the exploit script. The actual exploitation happens outside, but the analysis happens here.
二进制利用是创造性的问题解决：
  • 理解漏洞为何存在（不安全的假设）
  • 思考如何操纵内存（数据流分析）
  • 规划要覆盖什么（控制流、数据、指针）
  • 确定要重定向到哪里（现有代码、注入代码、ROP）
  • 逐步执行（泄露、计算、覆盖、触发）
每个CTF挑战都不同。使用此框架思考利用方法，而非盲目遵循检查清单。
你的目标：在Ghidra中记录足够的信息以编写利用脚本。实际的利用在外部完成，但分析在此处进行。