ASLR开着怎么打Exploitarium相对delta覆盖策略的数学原理【免费下载链接】exploitariumA single archive of public exploit PoCs and vulnerability research writeups. At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if handed out lulz. Please do not abuse these. I do this so to allure people into the field, and Ive always found this is the most efficient way.项目地址: https://gitcode.com/GitHub_Trending/ex/exploitarium一句话导读当ASLR 始终开启、程序又拒绝任何信息泄露时传统先读一个地址、再算出精确偏移的思路就会彻底卡死。本文拆解 Exploitarium 仓库里 objdump-dlx-calc-poc 模块所用的相对 delta 覆盖策略——它不追求一次算准而是提前预判出所有可能命中的6 个固定偏移量按页对齐的低 32 位 libc 基址分桶累加把单次命中率顶到100%。一、先看懂这道题到底难在哪 这个 PoC 要做的是把一个被破坏的FILE对象里、指向_IO_2_1_stderr_偏移0x2044e0的 libc 指针改写成指向system偏移0x58750。难点在于libc 的基址每次启动都不同ASLR而且你拿不到这个基址。你只能盲猜一个固定偏移量加上去。听起来只要算好一个 delta 就完事了对吧可惜数学说不行。libc 低 12 位源指针 P 的 4 字节内存顺序目标指针 S 的 4 字节内存顺序关键差异0x0000e0 44 20 0050 87 05 00S 的第 3 字节 050x8000e0 c4 20 0050 07 06 00S 的第 3 字节 06注意两行里源指针 P 的第 3、4 字节完全一样都是20 00但目标 S 的第 3 字节却不一样05vs06而这个差别是由源指针的第 2 字节44vsc4决定的。而 payload 能用的 32 位大端重定位加法进位只会从高位往低位流动——它根本无法让输出的第 3 字节去依赖输入的第 2 字节。依赖方向反了所以不存在一个对所有基址都成立的固定 delta。这就是策略要绕过去的数学障碍。完整论证见 docs/aslr-bypass-analysis.md。二、相对 delta 是怎么算出来的 既然大端加法方向不对那就换个思路与其找一个万能 delta不如给每一种实际会出现的基址各算一个 delta。核心公式只有三行取自 tools/aslr_delta_coverage.pysrc 大端视角( 低32位(base 0x2044e0) ) # 重定位看到的原始值 dst 大端视角( 低32位(base 0x58750) ) # 我们想要的结果 delta (dst - src) mod 2^32为什么是大端视角因为 x86 内存里存的是小端字节而 DLX 后端把这个 4 字节字段当作大端数来加——于是加法实际上是在字节翻转后的值上进行的。把这件事想清楚是整个策略的地基。这里base是页对齐的libc 以 4096 字节为边界随机所以不同 base 只会落进有限的几种进位模式。一旦某个 base 确定对应的 delta 就唯一确定。关键洞察来了遍历全部 2²⁰ 个页对齐位置delta_for_base(base)只会吐出 6 个不同的值。也就是说猜 delta这个看似无限大的问题其实只有 6 种答案。三、6 个 delta 如何拼出 100% 覆盖 ✅把这 6 个 delta 按各覆盖多少个页对齐位置列出来就是下面这张覆盖表由 tools/aslr_delta_coverage.py 复现固定 delta命中页数单份覆盖累加覆盖0x7042e500703 48867.09%67.09%0x6f42e600235 52022.46%89.55%0x7043e4ff82 6207.88%97.43%0x6f43e5ff26 5202.53%99.96%0x7043e5ff3240.031%99.99%0x6f43e6ff1040.0099%100.00%总页数 703 488 235 520 82 620 26 520 324 104 1 048 576 2²⁰正好是低 32 位里所有页对齐位置的数量。这张表揭示了策略的精髓6 个 delta 恰好对全部 2²⁰ 个可能基址做了一个无重叠、无遗漏的划分。不管你这次启动落到哪一个页都必然落进某一行——所以把 6 份 payload 全带上libc 低 32 位这一环就必然命中。这就是相对 delta 覆盖策略名字的由来用覆盖代替算准。⚠️ 注意这张表只覆盖了libc 低 32 位这一环。堆/libio 的内存布局off_io、off_sec、rbase等偏移仍可能因构建不同而不同——所以才要再叠一层多套 profile见下节。四、为什么不用先泄露、再计算的两段式 新手常会想那我第一次先读出一个地址泄露 libc 基址第二次再用精确 delta 不就行了这条路在本触发器上被堵死了重定位副作用只对第一个文件生效本地 GDB 实测objdump -W -r file1 file2下会改写.debug_info的 DWARF 重定位副作用只作用于第一个对象第二个文件打印出的是未改动的符号名s0、s1……。FIFO 缓冲也被挡住未修改的objdump里display_file()会先调get_file_size()而它会在bfd_openr()之前就拒绝非普通文件没法用管道在线喂入第二个 payload。所以动态泄露 → 精确计算走不通作者干脆选择了静态穷举 覆盖的路线。这也是本文标题相对 delta要表达的核心取舍。五、落地72 个 payload 和重试循环怎么跑 理论讲完看它怎么变成能跑的东西3 套内存 profileorig/wsl2404/gnu2461应对不同构建下的堆布局每套 profile 再乘以2 个 flag 字节 × 2 个 buf_delta × 6 个 system_delta合计3 × 2 × 2 × 6 72 个 payload全部躺在 payloads/ 目录每个都附带一份.notes说明它对应哪个布局、哪个 delta。生成逻辑在 generate_objdump_dlx_calc_poc.py把 6 个 delta 作为候选列表直接写死进循环。运行器 run_dlx_calc_poc.sh 做的事很朴素一轮轮地把 72 个 payload 喂给objdump -g谁触发了calc_hit.log里的CALC_HELPER_RAN就收工。因为 6 个 delta 已经保证了必然有一个能对上 libc 低 32 位所以通常第一轮就中HIT try1 payloadpayloads/dlx_calc_aslr_gnu2461_f06_b702fff00_s7042e500.bin CALC_HELPER_RAN 2026-06-25T11:19:07Z对同一构建连跑 10 次结果10/10 全中——这正是覆盖策略带来的确定性收益不靠运气只靠把可能空间全堵满。六、关键文件导航 文件作用docs/aslr-bypass-analysis.md完整数学论证为什么单 delta 不成立、6 份如何覆盖 100%tools/aslr_delta_coverage.py复现6 个 delta / 2²⁰ 页的覆盖表tools/search_pointer_transform.py用 Z3 反证固定重定位序列为何推不出万能变换generate_objdump_dlx_calc_poc.py生成 72 个 payload3 profile × 2×2×6 组合run_dlx_calc_poc.sh重试循环 runner命中即停payloads/成品 payload 与逐条.notes说明README.md模块总览与手动复现步骤一句话总结ASLR 开着、又漏不出地址时别死磕算准一个偏移把可能空间离散化、全枚举、累加覆盖用 6 份静态 delta 堵满 libc 低 32 位再用 3 套 profile 堵满堆布局——确定性就从覆盖里长出来了。⚖️免责声明本文仅为漏洞研究的技术解读。仓库内容属于善意公开披露请仅用于学习与防御研究切勿用于任何恶意用途。【免费下载链接】exploitariumA single archive of public exploit PoCs and vulnerability research writeups. At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if handed out lulz. Please do not abuse these. I do this so to allure people into the field, and Ive always found this is the most efficient way.项目地址: https://gitcode.com/GitHub_Trending/ex/exploitarium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考