📚 课程目录第4章程序执行控制

4、程序执行控制：单步执行（stepi/nexti）、跳过函数、运行到指定位置、反向调试（record/reverse）基础

程序执行控制是GDB调试漏洞与逆向分析的核心操作能力。在分析二进制程序时，仅仅设置断点并查看寄存器远远不够——你需要精确控制CPU的每一条指令执行，观察程序状态如何随指令流变化，并在崩溃点或关键比较指令处回溯执行历史。本章将系统讲解GDB中四类最核心的执行控制手段：单步执行（stepi/nexti）、跳过函数（finish/until）、运行到指定位置（tbreak/rbreak/until address）以及反向调试（record/reverse）。这些技术组合使用，能够帮助你在不修改程序行为的前提下，完整还原漏洞触发路径、绕过反调试逻辑、定位缓冲区溢出的精确偏移量。

上图展示了GDB执行控制技术的整体框架。在漏洞分析实战中，这四类操作并非孤立使用，而是根据分析阶段动态组合：先通过record开启执行记录，再使用stepi逐指令追踪关键路径，遇到不需要深入分析的函数时用finish快速跳过，最后用reverse-continue回溯到崩溃点之前的状态。下面我们将逐一深入讲解每种技术的原理、操作方法和实战技巧。

4.1 单步执行：stepi与nexti的精确控制

4.1.1 核心原理

stepi（step instruction）和nexti（next instruction）是GDB中最底层的执行控制指令。两者的本质区别在于对待函数调用的方式：stepi会进入被调用的函数内部，逐条执行函数体内的指令；而nexti则将整个函数调用视为一条指令，直接执行完函数并停在返回地址处。在汇编层面，nexti遇到call指令时会自动在该函数返回点设置临时断点，执行完整个函数后暂停。

对于漏洞分析而言，stepi的价值在于能够精确观察每一条指令执行前后寄存器、内存和栈的变化。例如，在分析栈溢出漏洞时，你需要逐条执行mov、push、call等指令，观察ESP/RSP如何变化、返回地址何时被覆盖。nexti则适用于快速跳过那些与分析目标无关的函数调用，比如printf、strlen等库函数，避免陷入大量无关指令中。

4.1.2 操作方法与判断流程

# 基本用法
(gdb) stepi              # 执行当前指令，进入函数调用
(gdb) stepi 5            # 连续执行5条指令
(gdb) nexti              # 执行当前指令，跳过函数调用
(gdb) nexti 3            # 连续执行3条指令（跳过函数）

# 结合寄存器查看
(gdb) stepi
(gdb) info registers rip rsp rbp   # 查看指令指针、栈指针、基址指针
(gdb) x/5i $rip          # 查看当前指令附近的反汇编代码
(gdb) x/10gx $rsp        # 查看栈顶10个8字节内容

判断何时使用stepi还是nexti，可以参考以下流程：



确认当前指令类型：使用x/1i $rip查看即将执行的指令。如果是call指令，需要判断目标函数是否与分析目标相关。
分析函数相关性：如果目标函数是strcpy、memcpy等可能触发漏洞的函数，必须使用stepi进入内部观察；如果是printf等格式化输出函数，通常使用nexti跳过。
观察关键状态变化：每次单步后，检查RIP是否指向预期位置，RSP是否发生异常偏移，栈上数据是否被非预期修改。

4.1.3 实战案例：定位栈溢出精确偏移
假设你在分析一个存在栈溢出漏洞的CTF题目，程序使用strcpy将用户输入复制到局部缓冲区。你的目标是确定覆盖返回地址所需的精确字节数。
# 设置断点在strcpy调用处
(gdb) break *0x4011a5
(gdb) run < input.txt

# 此时停在call strcpy指令前
(gdb) x/3i $rip
=> 0x4011a5 <main+45>: call 0x401030 <strcpy@plt>
   0x4011aa <main+50>: mov  eax,0x0
   0x4011af <main+55>: leave

# 查看缓冲区地址和栈布局
(gdb) info registers rdi rsi
rdi = 0x7fffffffe1a0   # 目标缓冲区地址
rsi = 0x7fffffffe2b0   # 源字符串地址

# 使用stepi进入strcpy内部
(gdb) stepi
(gdb) x/5i $rip
=> 0x7ffff7e6a3a0 <__strcpy_sse2>: movdqu xmm0,XMMWORD PTR [rsi]
   0x7ffff7e6a3a4 <__strcpy_sse2+4>: movups XMMWORD PTR [rdi],xmm0
   ...

# 连续单步观察写入过程
(gdb) stepi 20
(gdb) x/8gx 0x7fffffffe1a0   # 查看缓冲区内容
0x7fffffffe1a0: 0x4141414141414141  0x4141414141414141
0x7fffffffe1b0: 0x4141414141414141  0x4141414141414141
0x7fffffffe1c0: 0x4141414141414141  0x4141414141414141
0x7fffffffe1d0: 0x4141414141414141  0x4141414141414141

# 继续单步直到返回地址被覆盖
(gdb) stepi 30
(gdb) x/2gx 0x7fffffffe1d8   # 返回地址位置
0x7fffffffe1d8: 0x4141414141414141  0x00000000004011aa
通过逐指令观察，你发现缓冲区起始地址为0x7fffffffe1a0，返回地址位于0x7fffffffe1d8，两者相差0x38（56字节）。因此，构造payload时前56字节填充任意数据，第57-64字节覆盖返回地址。这个精确偏移量完全依赖stepi的逐指令观察能力。

经验提醒：在单步执行时，建议同时开启display/1i $rip和display/2gx $rsp，让GDB在每次暂停时自动显示当前指令和栈顶内容，避免频繁手动输入查看命令。

4.2 跳过函数：finish与until的高效导航
4.2.1 核心原理
finish命令用于执行当前函数直到返回，然后暂停在调用者的下一条指令处。其底层实现是：GDB在当前函数的返回地址处设置一个临时断点，恢复程序执行，当程序执行到该断点时自动移除断点并暂停。until命令则有两种用法：不带参数时，执行到当前函数中下一个源码行（或汇编指令）；带地址参数时，执行到指定地址处暂停。
在漏洞分析中，finish特别适合以下场景：你已经通过stepi进入了某个函数内部，但发现该函数逻辑复杂且与漏洞触发无关，此时使用finish快速退出，回到调用者上下文继续分析。until则适合跳过循环或重复代码段，例如在分析for循环时，你可以使用until *0x401200直接跳到循环结束后的指令。
4.2.2 操作流程与对比


命令 行为 适用场景 注意事项


finish 执行到当前函数返回 快速退出无关函数 如果函数永不返回（如exit），会一直执行
until（无参数） 执行到当前函数下一行 跳过循环体 在汇编模式下可能行为不同
until *addr 执行到指定地址 跳过已知代码段 地址必须在当前可执行范围内
advance *addr 执行到指定地址（类似until） 跨函数跳转 与until功能重叠，但更灵活


4.2.3 实战场景：绕过反调试时间校验
假设目标程序包含以下反调试逻辑：调用ptrace(PTRACE_TRACEME)检测是否被调试，然后调用sleep(3)进行时间校验。你希望在分析时跳过这些干扰。
# 断点在ptrace调用处
(gdb) break *0x401150
(gdb) run

# 当前停在ptrace调用前
(gdb) x/2i $rip
=> 0x401150 <main+20>: call 0x401030 <ptrace@plt>
   0x401155 <main+25>: test eax,eax

# 使用nexti跳过ptrace（不进入内部）
(gdb) nexti
(gdb) x/1i $rip
=> 0x401155 <main+25>: test eax,eax

# 查看返回值，如果eax=0说明ptrace成功（未被调试）
(gdb) info registers eax
eax = 0x0

# 继续执行到sleep调用处
(gdb) until *0x401170
(gdb) x/1i $rip
=> 0x401170 <main+45>: call 0x401040 <sleep@plt>

# 使用finish跳过sleep函数（不等待3秒）
(gdb) finish
Run till exit from #0  0x00007ffff7e6a3a0 in sleep ()
0x0000000000401175 in main ()
(gdb) x/1i $rip
=> 0x401175 <main+50>: mov eax,0x0
通过nexti跳过ptrace、finish跳过sleep，你成功绕过了反调试逻辑，且没有等待任何延迟时间。这种组合操作在分析带时间校验的恶意软件时非常实用。

风险提示：使用finish时，如果当前函数内部存在无限循环或永不返回的路径（如while(1)），程序会一直执行下去。建议在finish前先设置一个备用断点，或者使用Ctrl+C中断执行。

4.3 运行到指定位置：tbreak与rbreak的精准定位
4.3.1 核心原理
tbreak（temporary breakpoint）设置一次性断点，断点命中后自动删除。rbreak（regular expression breakpoint）则根据正则表达式匹配函数名批量设置断点。这两种命令在漏洞分析中各有妙用：tbreak适合临时在某个地址暂停一次，比如在ret指令处设置临时断点观察返回地址是否被篡改；rbreak适合在分析大型程序时，对所有可能涉及内存操作的函数（如strcpy、memcpy、sprintf）统一设置断点。
4.3.2 操作示例
# 临时断点：在main函数的ret指令处暂停一次
(gdb) disassemble main
...
   0x00000000004011af <+55>: leave
   0x00000000004011b0 <+56>: ret
(gdb) tbreak *0x4011b0
Temporary breakpoint 1 at 0x4011b0
(gdb) continue
Continuing.
Temporary breakpoint 1, 0x00000000004011b0 in main ()

# 正则断点：对所有str*函数设置断点
(gdb) rbreak ^str
Breakpoint 2 at 0x7ffff7e6a3a0: file strcpy.c, line 30.
Breakpoint 3 at 0x7ffff7e6a4b0: file strlen.c, line 25.
Breakpoint 4 at 0x7ffff7e6a5c0: file strcmp.c, line 40.
(gdb) info breakpoints
Num Type           Disp Enb Address            What
2   breakpoint     keep y   0x7ffff7e6a3a0    strcpy
3   breakpoint     keep y   0x7ffff7e6a4b0    strlen
4   breakpoint     keep y   0x7ffff7e6a5c0    strcmp
4.3.3 实战案例：定位格式化字符串漏洞的写入点
在分析格式化字符串漏洞时，你需要找到printf被调用的位置，并观察格式化字符串参数是否可控。使用rbreak可以快速捕获所有printf调用。
# 对所有printf相关函数设置断点
(gdb) rbreak printf
Breakpoint 5 at 0x401040: printf@plt.
Breakpoint 6 at 0x7ffff7e6a3a0: printf.c:30.

# 继续执行，第一次命中printf@plt
(gdb) continue
Continuing.
Breakpoint 5, 0x0000000000401040 in printf@plt ()

# 查看参数：rdi是格式化字符串，rsi是第一个可变参数
(gdb) x/s $rdi
0x7fffffffe1a0: "Hello %s, your number is %d\n"
(gdb) x/s $rsi
0x7fffffffe2b0: "World"

# 继续执行，第二次命中printf.c中的实际实现
(gdb) continue
Continuing.
Breakpoint 6, printf (format=0x7fffffffe1a0 "Hello %s, your number is %d\n") at printf.c:30
(gdb) stepi
(gdb) x/5i $rip
=> 0x7ffff7e6a3a0 <printf+0>: sub rsp,0xd8
   0x7ffff7e6a3a7 <printf+7>: mov QWORD PTR [rsp+0x28],rdi
   ...
通过rbreak批量设置断点，你快速定位了所有printf调用点，并确认了格式化字符串参数完全可控，为后续构造格式化字符串攻击payload奠定了基础。
4.4 反向调试：record/reverse的时空回溯
4.4.1 核心原理
反向调试（Reverse Debugging）是GDB 7.0引入的划时代功能。通过record命令，GDB会记录程序执行的每一条指令及其对内存、寄存器的影响。之后可以使用reverse-step、reverse-next、reverse-continue等命令反向执行程序，回到之前的任意状态。其底层实现基于执行追踪（Execution Tracing），GDB在软件层面模拟了CPU的执行过程，记录每条指令的副作用。
在漏洞分析中，反向调试的价值无可替代：当程序崩溃时，你可以直接reverse-continue回到崩溃前的最后一条指令，观察是哪次内存访问导致了段错误；当发现某个寄存器值异常时，可以反向单步追踪该值是在哪条指令被修改的。
4.4.2 操作流程与限制
# 开启执行记录
(gdb) record full
(gdb) continue
Program received signal SIGSEGV, Segmentation fault.
0x00000000004011b0 in main ()

# 反向执行到崩溃前的指令
(gdb) reverse-stepi
0x00000000004011af in main ()
(gdb) x/1i $rip
=> 0x4011af <main+55>: leave

# 反向继续执行到最近的函数调用
(gdb) reverse-continue
Breakpoint 1, 0x00000000004011a5 in main ()
(gdb) x/3i $rip
=> 0x4011a5 <main+45>: call 0x401030 <strcpy@plt>
   0x4011aa <main+50>: mov eax,0x0
   0x4011af <main+55>: leave
反向调试的主要限制包括：

性能开销：记录执行轨迹会显著降低程序运行速度（通常慢10-100倍），不适合长时间运行的程序。
内存消耗：每条指令的记录都需要存储空间，大型程序可能消耗数GB内存。
不支持所有指令：某些系统调用、信号处理、多线程操作可能无法完全记录。

4.4.3 实战案例：崩溃现场完整还原
假设你在分析一个网络服务程序，它接收客户端输入后进行处理，但某个特定输入导致程序崩溃。你需要找到崩溃的根本原因。
# 启动程序并开启记录
(gdb) record full
(gdb) run < malicious_input.txt

# 程序崩溃
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7e6a3a0 in __memcpy_avx_unaligned () from /lib64/libc.so.6

# 查看崩溃时的寄存器状态
(gdb) info registers rdi rsi rdx
rdi = 0x7fffffffe1a0    # 目标地址
rsi = 0x4141414141414141 # 源地址（已被覆盖）
rdx = 0xffffffffffffffff # 复制长度（异常）

# 反向单步，找到rdx被修改的位置
(gdb) reverse-stepi 10
(gdb) x/5i $rip
=> 0x4011c0 <process_data+80>: mov edx,DWORD PTR [rbp-0x4]
   0x4011c3 <process_data+83>: mov rsi,QWORD PTR [rbp-0x10]
   0x4011c7 <process_data+87>: mov rdi,QWORD PTR [rbp-0x18]
   0x4011cb <process_data+91>: call 0x401030 <memcpy@plt>

# 查看rbp-0x4处的值
(gdb) x/wx $rbp-0x4
0x7fffffffe1cc: 0xffffffff

# 反向继续，找到这个值被写入的位置
(gdb) reverse-continue
(gdb) x/3i $rip
=> 0x401190 <process_data+30>: mov DWORD PTR [rbp-0x4],eax
   0x401193 <process_data+33>: cmp eax,0x100
   0x401196 <process_data+36>: jle 0x4011a0

# 查看eax的来源
(gdb) info registers eax
eax = 0xffffffff

# 继续反向追踪eax
(gdb) reverse-stepi 5
(gdb) x/2i $rip
=> 0x401180 <process_data+20>: mov eax,DWORD PTR [rbp-0x8]
   0x401183 <process_data+23>: sub eax,0x100

# 查看rbp-0x8处的值
(gdb) x/wx $rbp-0x8
0x7fffffffe1c8: 0x000000ff
通过反向调试，你完整还原了崩溃链条：rbp-0x8处存储的输入长度值0xff（255）减去0x100（256）后得到0xffffffff（-1），这个负数被当作memcpy的长度参数，导致复制了海量数据，最终访问非法地址崩溃。这个分析过程完全依赖reverse-stepi和reverse-continue的时空回溯能力。

核心要点总结：

stepi用于逐指令精确追踪，nexti用于跳过函数调用，两者结合可控制分析粒度。
finish快速退出当前函数，until跳过循环或跳转到指定地址，提高分析效率。
tbreak设置一次性断点，rbreak批量匹配函数名，适合快速定位关键调用点。
record/reverse提供执行历史回放能力，是崩溃现场还原和异常值溯源的利器。
反向调试有性能开销，建议在关键路径上开启，而非全程记录。


4.5 常见误区与复盘


误区 后果 正确做法


全程使用stepi而不使用nexti 陷入库函数内部，分析效率极低 先判断函数相关性，无关函数用nexti跳过
在record开启前就运行程序 无法回溯到运行开始时的状态 在run之前执行record full
依赖finish跳过所有函数 如果函数内部有断点，finish会先触发内部断点 使用finish前检查函数内是否有断点
忽略until的地址参数 无法精确跳过特定代码段 使用until *addr精确控制跳转目标
反向调试时忘记关闭记录 内存持续增长，程序越来越慢 分析完成后使用record stop关闭记录


在实际漏洞分析项目中，建议建立标准化的执行控制流程：首先使用rbreak对关键函数设置断点，快速定位分析目标；然后使用stepi进入关键函数内部逐指令分析；遇到无关代码使用finish或until跳过；在崩溃点附近开启record进行反向回溯。这种组合策略能够最大化分析效率，同时保证对关键路径的完全掌控。
        
            ← 上一章
            📖 返回目录
            下一章 →
        
        可可资料掘金营 · 点击在线试看（想要更多资料，咨询可可微信keke90988）

误区	后果	正确做法
全程使用`stepi`而不使用`nexti`	陷入库函数内部，分析效率极低	先判断函数相关性，无关函数用`nexti`跳过
在`record`开启前就运行程序	无法回溯到运行开始时的状态	在`run`之前执行`record full`
依赖`finish`跳过所有函数	如果函数内部有断点，`finish`会先触发内部断点	使用`finish`前检查函数内是否有断点
忽略`until`的地址参数	无法精确跳过特定代码段	使用`until *addr`精确控制跳转目标
反向调试时忘记关闭记录	内存持续增长，程序越来越慢	分析完成后使用`record stop`关闭记录

命令	行为	适用场景	注意事项
`finish`	执行到当前函数返回	快速退出无关函数	如果函数永不返回（如`exit`），会一直执行
`until`（无参数）	执行到当前函数下一行	跳过循环体	在汇编模式下可能行为不同
`until *addr`	执行到指定地址	跳过已知代码段	地址必须在当前可执行范围内
`advance *addr`	执行到指定地址（类似until）	跨函数跳转	与until功能重叠，但更灵活