1. 漏洞利用中的栈帧调整艺术
在二进制漏洞利用领域，one_gadget作为一种高效的getshell方式，常常成为攻击者的首选武器。但实际应用中我们经常会遇到一个尴尬的局面 - 明明找到了可用的one_gadget地址，执行时却因为寄存器状态不满足条件而功亏一篑。最近我在研究glibc堆利用时，发现realloc函数可以成为调整栈帧的神奇工具，下面就来详细剖析这个技术点。
2. realloc函数的双重特性
2.1 内存调整的标准行为
realloc作为C标准库中的内存调整函数，其基础功能众所周知：当需要扩大内存块时，它会在原内存块后扩展空间（如果后续空间足够），或寻找新空间并迁移数据；当需要缩小内存块时，它会截断多余部分。但很多人忽略了它在执行这些操作时的调用栈变化特性。
2.2 隐藏的栈帧操作特性
realloc的特殊之处在于它的执行路径会经过多个内部函数调用：
code复制realloc -> _int_realloc -> 可能触发sysmalloc/memmove等
这个调用链会在栈上留下多层返回地址，而我们可以通过精心构造的size参数来控制调用深度。比如当请求调整的大小超过mmap阈值时，就会触发更长的调用路径。
3. one_gadget的条件约束分析
3.1 典型约束条件示例
以glibc 2.27的one_gadget为例，常见的约束条件包括：
code复制1. [rsp+0x70] == NULL
2. rcx == NULL
3. [[rsp+0x50]] == NULL || [rax] == NULL
在实际漏洞利用中，直接跳转到one_gadget地址时，这些条件往往很难同时满足，特别是涉及多层指针解引用的条件。
3.2 寄存器状态的连锁影响
栈帧布局会直接影响函数调用时的寄存器状态：
- 调用前的栈push操作会影响rsp相对位置
- 函数prologue会改变rbp的值
- 调用链长度会影响返回地址在栈中的位置
4. realloc调整栈帧的实战技巧
4.1 基础利用框架构造
假设我们已经控制程序执行流，典型的ropchain结构如下：
code复制pop_rdi_ret -> /bin/sh
pop_rsi_ret -> 0
pop_rdx_ret -> 0
realloc_plt -> one_gadget
但这样直接调用往往无法满足条件，需要在realloc和one_gadget之间做文章。
4.2 关键参数调整策略
通过控制realloc的参数可以精确操控栈帧：
python复制# 调整前size：影响是否走_int_realloc路径
realloc_size = 0x20000 # 确保触发mmap路径
# 调整后size：控制内部调用深度
new_size = 0x21000 if need_more_stack else 0x1000
4.3 栈帧偏移计算实践
假设我们需要满足[rsp+0x40] == NULL的条件：
- 首先在gdb中断在realloc入口，记录当前rsp值
- 单步执行到one_gadget位置，观察rsp变化
- 计算目标偏移与实际的差值Δ
- 通过调整realloc参数增加Δ/8次栈push操作
5. 高级技巧与实战案例
5.1 多阶段栈调整技术
在复杂场景下可能需要多次调整：
python复制# 第一阶段：基础调整
rop.raw(realloc_plt)
rop.raw(pop_rdi)
rop.raw(init_size)
# 第二阶段：精细调整
rop.raw(realloc+0x10) # 跳过部分prologue
rop.raw(adjust_size)
5.2 结合其他函数的混合利用
有时需要配合其他函数使用：
code复制malloc_usable_size -> 泄露当前堆块信息
realloc -> 调整栈帧
free -> 制造特定内存状态
6. 常见问题与调试技巧
6.1 典型错误排查表
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 段错误 | 栈未对齐 | 在ropchain中插入ret指令 |
| 条件不满足 | 偏移计算错误 | 使用gdb的telescope命令观察栈 |
| 执行流混乱 | realloc参数无效 | 确保size参数符合arena约束 |
6.2 gdb调试命令备忘
bash复制# 观察栈布局
telescope $rsp 20
# 跟踪调用链
bt 20
# 检查寄存器状态
info registers
# 设置条件断点
b *one_gadget if $rcx == 0
7. 防护方案与对抗措施
7.1 防御方检测特征
- 异常的realloc调用序列
- 连续的size参数突变
- 返回地址指向非常规区域
7.2 绕过思路进阶
- 使用realloc_hook等合法跳板
- 结合IO_FILE结构体进行伪装
- 利用tcache机制制造合法调用假象
在实际漏洞利用中，我发现最稳定的方式是分阶段验证：先在gdb中逐步调整参数找到理想的栈偏移量，然后编写ropchain时保留10%的调整余量。有一次在CTF比赛中，我通过realloc+0x30的偏移调用，配合精心构造的size参数，成功让原本不满足条件的one_gadget生效，这种精确控制的感觉确实令人着迷。