SSE寄存器泄漏大法ctf-tasks Fastcalc 系列挑战如何利用XMM绕过ASLR【免费下载链接】ctf-tasksAn archive of low-level CTF challenges developed over the years项目地址: https://gitcode.com/gh_mirrors/ct/ctf-tasksctf-tasks 是 Dragon Sector 战队开源的低层 CTFCapture The Flag挑战档案库收录了多年积累的 Windows/Linux 平台 pwn 与逆向题目。其中 Fastcalc 系列挑战以高速计算器为外壳隐藏着本篇文章的主角——SSE 寄存器泄漏漏洞攻击者利用 XMM 寄存器中的残留数据绕过 ASLR再配合栈溢出拼出 ROP 链最终拿到远程 shell。这篇面向新手的 SSE 寄存器泄漏入门分析将带你从漏洞原理一路走到完整利用链路理解寄存器残留这个冷门却致命的攻击面。Fastcalc 系列是什么ctf-tasks 里最烧脑的 Windows pwn 挑战 Fastcalc 是一道 32 位 Windows 计算器程序宣称能并发计算多个数学表达式如(12*3)/4。它的特别之处在于使用 SSE2 指令集做浮点运算只支持带 SSE2 的 CPU采用 Windows Fiber纤程机制模拟多线程在同一线程内切换多个计算任务静态链接且内部带有system调用为后续利用铺路。题目文件位于CONFidence CTF 2017/Teaser/Fastcalc/task/fastcalc.exe当年只有11/258 支队伍解出。而正赛版本的 Fastcalc-hardened 难度更高仅3/22 支队伍攻克。它被评为 500 分困难级挑战绝非浪得虚名。核心漏洞原理为什么 XMM 寄存器会变成泄漏通道 要理解 SSE 寄存器泄漏先要弄清两个关键机制。机制一Fiber 上下文切换只保存通用寄存器Windows Fiber 是轻量级的用户态调度单元切换时通常只保存/恢复通用寄存器EAX、EBX 等而XMM0–XMM7 这类 SSE 寄存器并不会被保存。Fastcalc 恰恰用 XMM 寄存器承载运算中间值于是一个纤程里 XMM 残留的数据可能被另一个纤程继承下来再通过计算结果泄露出去。机制二memcpy 的 SSE 优化分支会留下数据尾巴当memcpy的源地址和目标地址的低 16 位最低一个十六进制位恰好对齐时库函数会启用 SSE 优化路径——用 XMM6/XMM7 一次性搬运 16 字节数据。搬运结束后这些寄存器不会清零。此时 Fastcalc 的std::cout输出操作会把 XMM0–XMM5 归零却碰不到 XMM6/XMM7。于是memcpy 搬运过的内存片段比如一个合法的代码指针就安静地躺在 XMM6 里等待被偷走。关键细节为什么是 25% 概率memcpy 源地址与目标地址的 16 字节对齐关系由 ASLR 随机决定两者对齐一致的概率约为1/4。这意味着泄漏不是每次都成功但多试几次总能撞上——这正是漏洞利用概率化的典型玩法。实战教学如何用 XMM 寄存器泄漏绕过 ASLR ASLR地址空间布局随机化让每次运行的程序基址都不同常规打法必须先拿到一个地址才能推算基址。而 XMM 泄漏恰好提供了这条捷径。完整攻击流程见CONFidence CTF 2017/Teaser/Fastcalc/solution/exploit.py核心步骤如下✅构造泄漏表达式创建由 6 个组成的表达式。执行时 XMM0–XMM5 已被清零而 XMM6 里残留着 memcpy 泄漏的代码指针最后 6 个运算会把 XMM6 的值搬进 XMM0成为表达式结果。✅触发 memcpy 泄漏再创建一个由 256 个组成的表达式其 RPN 形式从栈拷贝到堆时触发 SSE 优化分支把代码指针留在 XMM6。✅提取泄漏值运行两个表达式把结果double 类型按位还原成 64 位整数取高 32 位即得到泄漏地址leaked_address struct.unpack(Q, struct.pack(d, result))[0] 32✅还原镜像基址将泄漏地址的低 16 位与已知偏移如0xC9EF、0x134C2比对匹配成功即可算出程序镜像基址IMAGE_BASE leaked - offset。✅构造 ROP 链利用基址计算system调用地址偏移0x3055和cmd.exe字符串地址偏移0x25380把两个地址打包成一个 double 浮点数作为表达式中的操作数。✅栈溢出 触发发送0×131 ROP浮点的超长表达式。131 个0恰好绕过栈保护 cookie只覆盖main的返回地址最后输入quit退出主循环ROP 链接管执行system(cmd.exe)随后输入type flag.txt即可拿到 flag。Fastcalc-hardened官方修复之后为何依然被打穿正赛版本针对 Teaser 的漏洞做了定向修复改动写在题目描述里还特意附上了当初导致异常输出的无辜输入见CONFidence CTF 2017/Main event/Fastcalc-hardened/task/bad_input.txt重排栈布局移除可被覆盖的std::string对象让旧的内存泄露手法失效Fiber 启动时清零 XMM0–XMM7堵死新建纤程继承脏寄存器这条路调整可控 double 的覆盖位置从覆盖 RETARG 改为覆盖 EBPRET使单靠爆破镜像基址不再可行。但出题人留了一手——XMM 寄存器在已经运行的纤程之间切换时依然不做保存/恢复。只要攻击者把两个纤程都先跑起来再借 memcpy 污染其中一个的 XMM6另一个纤程依旧能读出泄漏值。修复后的利用链路升级为创建×106表达式先运行 100 个让纤程被抢占挂起创建×256表达式触发 memcpy泄漏镜像基址对应偏移0x4b25换用×248再泄漏一次得到栈地址基址可跨连接复用栈地址必须同会话内泄漏构造双段 ROP第二段system(cmd.exe)放在栈上第一段用MOV ESP, EBP; POP EBP; RETN把栈指针 pivor 到第二段发送ROP浮点 ×258 pivot浮点quit后 ROP 链接管弹出 cmd.exe。完整的攻击脚本在CONFidence CTF 2017/Main event/Fastcalc-hardened/solution/exploit.py官方讲解见CONFidence CTF 2017/Main event/Fastcalc-hardened/solution/slides.pdf。两代 Fastcalc 攻击流程对比一览 对比项FastcalcTeaser 2017Fastcalc-hardened正赛 2017平台Windows x86Windows x86解出队伍11 / 2583 / 22需要泄漏的信息镜像基址镜像基址 栈地址触发泄漏的表达式×256×256基址/×248栈ROP 结构单段system(cmd.exe)双段先 pivot 栈再执行 system官方修复手段—清零 XMM、重排栈布局、改变覆盖位置修复是否生效—❌ XMM 切换泄漏依旧存在安全启示寄存器残留是常被忽视的信息泄漏面 ️Fastcalc 系列是教科书级的冷门攻击面教学案例它给开发者与安全研究者的启示非常直接上下文切换要彻底凡是切换执行流Fiber、协程、线程CPU 状态——尤其是 SSE/AVX 寄存器——都必须完整保存与恢复不能只盯通用寄存器清零要清到位只清零 XMM0–XMM5 而漏掉 XMM6/XMM7等于给攻击者留了后门泄漏与修复是猫鼠游戏即使修掉已知漏洞只要信息残留的根本成因还在攻防就会继续升级。如果你也想动手复现可以把整个挑战克隆到本地git clone https://gitcode.com/gh_mirrors/ct/ctf-tasks在CONFidence CTF 2017/目录下找到 Fastcalc 与 Fastcalc-hardened 两个子目录用题目附带的AppJailLauncher.exe把程序绑定到端口再运行 exploit 脚本亲眼见证 XMM 寄存器泄漏如何一步步瓦解 ASLR。理解了这个套路下次再见到多线程 向量寄存器的 pwn 题你就能第一时间想到寄存器里的旧数据也许就是打开系统大门的钥匙。【免费下载链接】ctf-tasksAn archive of low-level CTF challenges developed over the years项目地址: https://gitcode.com/gh_mirrors/ct/ctf-tasks创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考