GEF heap-analysis-helper：用 GDB 动态断点追踪 Glibc 堆生命周期，自动捕获 Double Free、UAF 与堆重叠

网络安全开发工具【免费下载链接】gefGEF (GDB Enhanced Features) - a modern experience for GDB with advanced debugging capabilities for exploit devs reverse engineers on Linux项目地址https://gitcode.com/gh_mirrors/gef/gef点击查看免费下载GEF 的heap-analysis-helper命令通过在malloc/calloc/realloc/free上安装内部分布式断点实时追踪每次堆块的分配与释放并基于会话内的“已分配/已释放”两个 chunk 列表自动拦截 NULL free、Double Free、Use-after-Free 与 Heap Overlap 四类 Glibc 堆不一致问题。阅读本文后你将掌握该命令的启用方式、全部配置项及其默认值、各类检测的底层实现原理软件观察点、重叠判定与 payload 提示以及如何将其降级为纯分配跟踪器并查询当前跟踪状态。功能定位与实验性声明官方文档对该功能的定位是追踪并分析 chunk 的分配与释放辅助定位 Glibc 堆不一致heap inconsistencies见 docs/commands/heap-analysis-helper.md。文档明确标注该特性仍处于开发中still under development, expect bugs and unstability可检测的问题清单为NULL freeUse-after-FreeDouble FreeHeap overlap这一实验性状态在源码中同样得到印证HeapAnalysisCommand 的do_invoke方法上叠加了experimental_feature装饰器运行时会先输出实验特性提示。同时也要注意文档给出的边界与 format-string-helper 类似它可能漏检复杂堆场景、也可能产生误报每条发现都必须人工二次确认。启用 helper一条命令背后的断点布局在活跃调试会话中直接运行heap-analysis-helper即可启用典型输出为gef➤ heap-analysis [] Tracking malloc() [] Tracking free() [] Disabling hardware watchpoints (this may increase the latency) [] Dynamic breakpoints correctly setup, GEF will break execution if a possible vulnerability is found. [] To disable, clear the malloc/free breakpoints (delete breakpoints) and restore hardware breakpoints (set can-use-hw-watchpoints 1)从源码 setup() 可以看到这条命令实际做了五件事跟踪分配在__libc_malloc与__libc_calloc上各挂一个TraceMallocBreakpoint输出为Tracking malloc() calloc()跟踪释放在__libc_free上挂TraceFreeBreakpoint跟踪重分配在__libc_realloc上挂TraceReallocBreakpoint文档示例输出未单独列出此项但源码中已包含禁用硬件观察点执行set can-use-hw-watchpoints 0因为 UAF 检测依赖软件 watchpoint硬件 watchpoint 数量有限且可能干扰代价是调试延迟升高源码中随后还会warn提示heap analysis slows down the execution noticeably注册退出清理钩子gef_on_exit_hook(self.clean)确保目标进程退出时自动拆除所有断点并恢复硬件观察点避免污染下一轮调试。文档还提到可以通过手动清除__GI___libc_free()/__GI___libc_malloc()上的断点来关闭分析从源码看这些是 glibc 内部符号对应的公开符号正是free/malloc的别名因此delete breakpoints或直接删除对应编号断点均可生效。需要说明的是上述断点目标函数名为 glibc 版本相关的内部符号在较新的 glibc 中形如__libc_malloc若目标库导出的符号名不同断点可能无法命中此时该功能会静默失效——这也是文档将其标记为实验特性的原因之一。配置项详解五类检查及其默认值文档中列出的开关可通过gef config单独启停完整形式为gef config heap-analysis-helper.key True|False。结合 HeapAnalysisCommand.init中注册的配置项实际生效的键名与默认值如下表配置键默认值触发条件源码判定位置heap-analysis-helper.check_free_nullFalsefree(NULL)被调用gef.py#L5077-L5086heap-analysis-helper.check_double_freeTrue释放的指针已在“已释放列表”中gef.py#L5088-L5097heap-analysis-helper.check_weird_freeTrue释放一个从未跟踪过的指针gef.py#L5106-L5113heap-analysis-helper.check_uafTrue已释放 chunk 上的观察点被命中gef.py#L5119-L5121heap-analysis-helper.check_heap_overlapTrue新分配地址落在任一在用 chunk 的地址区间内gef.py#L4967-L4995注意两点与文档的细微差异其一文档第一行写作check_null_free而__init__中实际注册的键名是check_free_null以源码为准其二文档列举时遗漏了check_heap_overlap但它与 Heap overlap 检测一一对应且默认开启。NULL free 与 Double FreeTraceFreeBreakpoint.stop()的逻辑是一条清晰的判定链gef.py#L5067-L5122取第一个参数addr打印Heap-Analysis - free(0x...)若addr为 0 且check_free_null开启打印 Attempting to free(NULL) at 0x... 并提示若 NULL 页可被分配可能导致代码执行随后返回True挂起执行若addr已存在于gef.session.heap_freed_chunks已释放列表且check_double_free开启则报告 Double free 并挂起。Double free 的拦截效果如下这里的关键状态是两个会话级列表heap_allocated_chunks在用 chunk与heap_freed_chunks已释放 chunk每一项均为(地址, 大小)元组。一次合法的free会把 chunk 从前者弹出并压入后者这正是后续所有判定重复释放、未知释放、重新分配命中已释放地址的事实基础。Use-after-Free软件观察点 白名单降噪UAF 是五类检查中实现最复杂的一种。流程分三步gef.py#L5119-L5177free()断点命中且check_uaf开启时额外挂一个TraceFreeRetBreakpointFinish 断点等待free返回free返回后对该地址创建UafWatchpoint——一个对内存读写的软件 watchpointBP_WATCHPOINT并登记到gef.session.heap_uaf_watchpoints若该 watchpoint 被命中stop()会先做误报过滤若当前帧函数名是_int_malloc、malloc_consolidate或__libc_callocglibc 自身在分配器内部会合法触碰已释放 chunk则静默返回False不告警否则打印Possible Use-after-Free in 可执行文件附上下触发指令的反汇编并挂起执行交由分析。[!] Heap-Analysis [!] Possible Use-after-Free in ./heap-uaf: pointer 0x5555555592a0 was freed, but is attempted to be used at 0x4011a6 0x4011a6 mov rax,QWORD PTR [rdx]值得强调的是正因为是软件 watchpoint它只能监控已释放且仍在跟踪窗口内的指针。如果该 chunk 被再次malloc出去TraceMallocRetBreakpoint.stop()会主动将其从 watchlist 中移除并wp.enabled Falsegef.py#L4954-L4963——即重新分配即视为合法这解释了为何文档提醒复杂堆场景可能漏检。Heap Overlap带利用 payload 提示的重叠检测重叠检测发生在分配侧而非释放侧。TraceMallocRetBreakpoint.stop()在拿到malloc/calloc的返回值loc后若check_heap_overlap开启会遍历所有在用 chunk通过GlibcChunk读取每个 chunk 的有效 size判断新地址是否落在[chunk_addr, chunk_addr size)区间内gef.py#L4967-L4995。命中时不仅报告新 chunk 覆盖了在用 chunk还直接给出可利用性信息Possible heap overlap detected Reason - new allocated chunk 0x555555559330 (of size 32) overlaps in-used chunk 0x5555555592a0 (of size 0x41) Writing 24 bytes from 0x5555555592a0 will reach chunk 0x555555559330 Payload example for chunk 0x5555555592a0 (to overwrite 0x555555559330 headers): data A*24 B*8 C*8其中 offset 按跳过本 chunk 的 prev_size/size 两个指针槽loc - chunk_addr - 2 * ptrsize计算负值视为误报丢弃。也就是说它不仅回答是否重叠还近似回答往旧 chunk 写多长能踩到新 chunk 的头部。纯跟踪模式关掉全部检查只留日志文档指出把上述所有检查项设为Falsehelper 就退化为一个只记录分配/释放的跟踪器检测到不一致时不再挂起仅在每次malloc/free时打印一行消息gef➤ gef config heap-analysis-helper.check_double_free False gef➤ gef config heap-analysis-helper.check_free_null False gef➤ gef config heap-analysis-helper.check_weird_free False gef➤ gef config heap-analysis-helper.check_uaf False对应纯跟踪模式的输出形如[] Heap-Analysis - malloc(16)0x5555555592a0 [] Heap-Analysis - calloc(32)0x5555555592d0 [] Heap-Analysis - realloc(0x5555555592a0, 48)0x5555555592d0 [] Heap-Analysis - free(0x5555555592d0)其中realloc(ptr, size)若返回地址与原地址相同显示绿色不同则显示红色便于快速发现 realloc 实际发生了搬迁。这种模式的典型用途是在无法预知漏洞类型的黑盒调试中先拿到完整的堆操作时序再人工比对。show子命令查看当前跟踪到的 chunk 快照运行heap-analysis-helper show可打印会话中跟踪到的全部 chunk无需等待任何异常触发。其背后是 dump_tracked_allocations()分两段输出Tracked as in-use chunks:逐行✗ malloc(16) 0x...来自heap_allocated_chunksTracked as free-ed chunks:逐行✓ free(32) 0x...来自heap_freed_chunks若某类为空则输出 No malloc() chunk tracked / No free() chunk tracked。这个子命令在利用分析中很有价值当目标程序发生堆破坏chunk 头被覆盖、free 链表被污染时show给出的GEF 视角的合法分配集与heap-chunks命令读到的内存中的实际 chunk 结构之间的差异本身就是定位堆损坏的关键线索。生命周期管理自动清理与手动关闭会话结束目标进程退出时clean() 钩子会自动删除 malloc/calloc/free/realloc 四个断点及残留的临时 Finish 断点对删除失败抛RuntimeError的情况静默容忍因为会话已结束、删除全部 UAF 观察点、清空三个会话列表并恢复set can-use-hw-watchpoints 1。若不退出进程而只想中途停用按启用输出中的提示执行delete breakpoints并手动恢复硬件观察点即可。验证路径与实践建议仓库自带一条完整的端到端验证链路可作为最小复现样例测试程序 tests/binaries/heap-analysis.c依次malloc(0x10)、calloc(0x20, 1)、realloc(p1, 0x30)、free(p2)测试用例 tests/commands/heap_analysis.py先断言无调试会话时执行命令会返回 inactive session 提示命令受only_if_gdb_running约束start后启用命令再continue并断言输出中依次出现malloc(16)、calloc(32)、realloc(., 48)与free(0x...)。最后汇总几条实践约束必须在活跃会话中运行do_invoke被only_if_gdb_running保护start或break main之后再启用显著拖慢执行速度每个堆调用都要经过内部断点命中 → 临时 Finish 断点取返回值 → 列表维护的流程UAF 开启时还有持续的软件 watchpoint 开销文档与源码warn提示都明确警告了这一点建议在需要时再启用断点目标依赖 glibc 符号__libc_malloc/__libc_free等内部符号在目标 glibc 中不可见时断点无法安装功能会静默降级发现必须人工确认实验特性 软件观察点的机制决定了误报与漏检并存尤其 UAF 白名单只覆盖了三个 glibc 内部函数其他合法触碰路径仍可能触发告警。配套阅读堆块静态分析可用 docs/commands/heap.md 中的heap-chunks等命令与heap-analysis-helper的动态跟踪互为补充——一个看内存里现在长什么样一个看程序做过哪些堆操作。赞分享网络安全开发工具【免费下载链接】gefGEF (GDB Enhanced Features) - a modern experience for GDB with advanced debugging capabilities for exploit devs reverse engineers on Linux项目地址https://gitcode.com/gh_mirrors/gef/gef点击查看免费下载相关推荐Pwndbg track-heap 命令详解GLibc 堆分配实时跟踪与 Use-After-Free 检测Pwndbg track heap 命令详解GLibc 堆分配实时跟踪与 Use After Free 检测 导读 track heap 是 Pwndbg 提逆向工程调试器应用安全开发工具基于 glibc 堆的 chunk 遍历与解析pwndbg heap 命令实战指南基于 glibc 堆的 chunk 遍历与解析pwndbg heap 命令实战指南 heap 是 pwndbg 中用于 迭代打印 glibc 堆上 mallo逆向工程调试器应用安全开发工具gstack /review 设计评审清单解析面向前端 diff 的 AI Slop 检测与 Fix-First 设计质量门禁gstack /review 设计评审清单解析面向前端 diff 的 AI Slop 检测与 Fix First 设计质量门禁 这篇指南以 review/de人工智能AI 技能浏览器控制AI 评测上一篇vmPing 免费多主机 ping 监控指南一眼看清几十台设备谁掉线了下一篇旧 Mac 装上新版系统OpenCore Legacy Patcher 实操指南2013-2017 机型创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考