1. Acid Burn从银幕符号到二进制样本1.1 电影里的Acid Burn是一个什么样的存在看到Acid Burn这个名字我第一反应不是某个恶意软件家族而是上世纪九十年代那部黑客题材电影里的女主角——一个代号叫Acid Burn的女黑客。在那个拨号上网还嫌太快的年代她能和搭档靠着电话线和一台破电脑把对手耍得团团转。电影里的Acid Burn有个很鲜明的特点她不是那种刻板印象里阴沉沉的怪咖而是带着点桀骜和幽默感的技术玩家。她嘲笑对手的弱口令用游戏化的心态对待看似严肃的攻防。这种气质很大程度上定义了后来二十多年黑客文化里的某种审美——把技术对抗当成一场智力游戏用代号隐藏身份用实力赢得尊重。很多年以后安全圈依然在向这类文化符号致敬。CTF比赛里经常出现以电影台词、角色代号命名的题目比如Acid BurnZero Cool之类的。我这次分析的样本就是某次内部技术分享中拿到的一个名为acid_burn的CTF逆向题。出题人明显是在致敬电影而且从题目的藏彩蛋方式来看出题人自己多半也是那部电影的粉丝。1.2 为什么说逆向分析这个词有双重含义逆向分析这个词在安全领域有个固定的技术含义拿到一个二进制文件在不依赖源码的情况下通过静态阅读和动态调试还原它的行为逻辑、数据结构甚至原始算法。这和写代码正好是相反的过程——写代码是把需求变成指令逆向是把指令还原成语义。但放到Acid Burn这个标题下我觉得逆向分析还有第二层意思拆解一个文化符号。Acid Burn这个名字为什么能流传这么多年它身上浓缩了早期网络亚文化的哪些特征为什么安全圈的命名习惯里总有这些老电影的影子这种拆解某种意义上也是一种逆向——从现象反推成因。这篇文章会沿着两条线走一条是技术线完整记录我从拿到acid_burn样本到最终写出注册机的全过程另一条是文化线在关键节点解释这个题目为什么要这样设计以及背后的黑客文化逻辑。两条线交叉着讲读起来会更有意思也更接近真实的工作状态——毕竟我们分析一个样本时本来就会去猜作者想干什么。2. 拿到样本先别急着运行情报收集阶段2.1 文件识别与指纹提取先看清来者何人我拿到的是一个Windows下的PE可执行文件文件名就叫acid_burn.exe。按照我的习惯第一步永远不是双击运行而是先把文件的基本信息摸清楚。这就跟你在街上遇到一个陌生人第一件事肯定是看对方长什么样、穿什么衣服而不是直接上去握手一个道理。首先是计算哈希值确认文件指纹sha256sum acid_burn.exe输出长这样7f3c6a2f8e6b4d1c9a5b7e3f2d8a4c6b9e1f0a2d3c4b5a6f7e8d9c0a1b2c3d4e5哈希值的作用是给文件一个唯一身份。做逆向分析时经常要在多个环境中同步样本靠文件名不可靠因为改名太容易了哈希值才是硬通货。同时我会把哈希丢到公开的威胁情报平台里查一下看看有没有历史记录。当然CTF题目通常查不到但这个习惯能帮你确认拿到的究竟是一个已知样本、一个比赛题还是一个处于未知领域的文件。接下来用file命令看文件类型file acid_burn.exe输出通常是acid_burn.exe: PE32 executable (GUI) Intel 80386, for MS WindowsPE32说明是32位程序GUI说明有图形界面。这个信息很有用——有图形界面意味着程序多半会通过对话框读取输入也就意味着动态调试时可以在输入处下断点。如果是一个纯命令行程序那分析路径会不一样往往直接从main函数入口开刀。然后是查壳。我习惯用DIEDetect It Easy这个工具做快速检测它比当年流行的PEiD更准确而且持续在更新。DIE打开文件后直接看右下角什么都不显示大概率是未加壳的C/C程序可以直接进IDA。显示UPX、ASPack之类的字样说明加壳了需要先脱壳。显示区域有奇怪的字符或极高的熵值可能存在自定义加密壳或混淆这类要花的时间就多了。DIE还有很多实用的辅助功能可以直接看熵值图。如果一个可执行文件的各个区段熵值都接近8.0那基本就是在告诉你这里被加密过了。2.2 字符串与导入表里的人设静态情报收集里字符串和导入表是我必看的两样东西。字符串往往直接暴露作者的意图导入表则像一份行为预告。用strings工具Linux下可以装binutils里的stringsWindows下可以用Sysinternals的strings64把文件里的可打印字符拉出来看strings -n 8 acid_burn.exe acid_burn.strings.txt-n 8的意思是只提取长度不小于8的字符串可以过滤掉大量无意义的短字符。打开这个文件重点看几类内容提示性文案比如Welcome to the danceAcid Burn says: hello之类的这类字符串通常和电影台词有关是出题人留的彩蛋。输入提示比如Enter the key:直接指向验证代码的位置。错误提示比如Wrong password!通常在验证失败的分支末尾顺着交叉引用就能找到验证函数。编译痕迹比如Microsoft Visual C Runtime Library可以帮你推测编译器版本。我这次看的样本里果不其然有一句来自电影的经典台词被做成了验证失败的提示。这种设计在CTF里太常见了——出题人明摆着告诉你答案藏在某一个函数里就看你能不能找到。再看导入表用PE-bear这个工具可以直观地看到程序导入了哪些系统API有GetDlgItemTextA/W说明程序有对话框输入是字符串。有FindFirstFileA/FindNextFileA说明程序可能在做文件遍历。有CreateFileA/ReadFile说明可能有文件读写操作。有InternetOpenA/HttpSendRequestA说明可能有网络通信。导入表告诉你这个程序有哪些潜在的作案工具但注意它只能告诉你可能性不能告诉你实际用法。就好比你看到一个人的包里有一把螺丝刀但你不知道他是要修电脑还是要拆门锁。真正确定行为还是得靠反汇编和动态调试。这一步我个人的经验是先拉字符串再查导入表最后再决定要不要花力气进IDA。如果字符串里什么都看不到导入表也干干净净那多半是加壳了先脱壳再说。如果字符串一拉就是一大片明文业务逻辑那这个程序基本没做什么混淆分析难度会低一个档次。先做情报收集能让你在动手前大概知道难度天花板在哪里避免瞎花时间。3. 静态分析从入口点开始解剖3.1 用PE视角看一个程序的骨架把样本丢进IDA或者Ghidra之前我习惯先用PE-bear或者010 Editor这种十六进制工具把PE结构捋一遍。这个步骤很多人跳过但我觉得很有必要因为它能让你在看到汇编指令之前先建立对程序的整体印象。PE文件的基本结构是DOS头 → DOS stub → NT头 → 节表 → 各个节区。对逆向分析来说最有价值的几个点是入口点AddressOfEntryPoint程序开始执行的第一条指令地址。多数情况下入口点在一个叫.text的节里但如果入口点落在一个权限是可写可执行的奇怪节里那基本可以断定加壳了——壳的实现方式就是先解密原来的代码再跳转过去。节表权限位正常程序的节权限分配很有规律.text可读可执行、.data可读、.rdata可读。如果你看到某个节同时具备可读可写可执行三种权限这就是一个值得警惕的信号因为绝大多数加壳程序和shellcode都是这样的。重定位表、资源表这些表在分析GUI程序的对话框逻辑时很有用可以在IDA里通过资源表直接找到对话框模板进而定位到处理控件的回调函数。很多人一上来就双击进IDA按F5其实容易漏掉很多关键线索。PE视角的意义在于你能提前预判这个程序是老实人还是有前科。一个只有三个标准节区的程序通常不需要过多担心而一个有十二个乱七八糟节区、入口点藏在深处、密钥区熵值爆炸的程序你就得做好打持久战的准备。3.2 识别反调试与混淆手法出题人的小心思CTF逆向题最常做的一件事就是往程序里塞反调试。出题人想筛选掉那些不会处理反调试的人——毕竟一个只会机械按F8的人确实不适合做逆向。我这次遇到的acid_burn样本静态分析阶段就发现了明显的反调试痕迹。在IDA的反汇编视图里看到了IsDebuggerPresent的调用。这个API的用法很简单检查当前进程是否处于被调试状态。如果是返回非零值程序就走入一个死循环或者直接退出。绕过IsDebuggerPresent有几种常见做法一种是在OD或x64dbg里直接把返回的eax寄存器改成0让程序认为没被调试。第二种是在调用IsDebuggerPresent之后的下一条指令处下断点然后单步跳过判断逻辑。第三种是用带反反调试插件的调试器比如x64dbg配合ScyllaHide它会自动处理这类API的返回值。这个样本还不止用了一个反调试手段。我继续翻汇编又看到了RDTSC时间差检测。原理很简单在执行一段指令前后分别读取CPU的时间戳计数器如果两次差值过大就说明单步调试导致了指令执行时间异常程序就会认定自己被跟踪。这类检测用调试器插件处理比较省事ScyllaHide对这种反调试也有内置规避。除了反调试出题人还做了一层比较浅的混淆在关键跳转指令前面插入了一堆垃圾指令比如把mov eax, 0改成xor eax, eax加上几条无意义操作。这种混淆的意图不是让你完全看不懂而是增加你逐行阅读的成本让你在大量无关代码里迷路。我的应对方法是先忽略所有干扰指令只看交叉引用和分支跳转把程序的控制流图画出来再说。静态分析阶段有一段代码特别典型我贴一段伪代码结构的观察push 401000h ; 提示字符串地址 call printf call GetDlgItemTextA ; 读取用户输入 xor edi, edi mov esi, eax cmp esi, 20h ; 比较输入长度是否为32 jne short loc_wrong这个片段透露了几个信息输入长度为32、读取机制是基于Windows对话框的、后面一定有一个对缓冲区的逐字节运算。这个时候我基本确定这是一个验证输入字符串的注册机题而不是那种危险的行为分析样本。接下来要做的就是找到那32字节输入被拿去和什么比较。4. 动态调试让程序自己说话4.1 环境隔离与工具选型给自己的作案现场戴好手套静态分析看的是程序的静态特征动态调试才是真正的现场还原。做动态调试之前第一要务是把环境隔离好。我个人的标准做法是用虚拟机搭一个独立的Windows分析环境关闭共享文件夹断开网络然后把分析工具提前装好、打一个干净的快照。为什么要这样因为你不确定这个样本在被调试过程中会做什么。虽然CTF题目的行为通常是固定的但我养成的习惯是所有陌生样本都按未知威胁处理。这就跟在实验室里戴手套操作一样不是为了某个具体样本而是为了防止万一。动态调试的核心工具是x64dbg如果是32位程序x64dbg也可以兼容或者直接用它的32位版本。搭配的工具还有ScyllaHide反反调试插件能绕过绝大多数基于API或PEB的反调试检测。API Monitor记录程序对系统API的调用顺序和参数对分析和解算法非常有用。Process Explorer查看程序运行时进程树、句柄和线程状态。部署完环境后把样本拷进去先把快照打好。这一步千万别省——如果你在调试过程中把系统弄乱了或者把样本跑坏了需要重新开始一个好的快照能让你在一分钟内回到初始状态。4.2 从关键函数到核心算法的定位进入动态调试阶段后我的思路是先让程序自然运行一次输入一个假的key观察程序的反应再根据反应回溯定位。在acid_burn这个例子里我运行程序界面弹出来一个输入框我随便输入一串32位的假key点确定弹窗提示Wrong password!。这个时候我需要知道这个Wrong password字符串在程序里被谁引用。一种高效的做法是在x64dbg里对Wrong password对应的Unicode字符串下硬件断点。当程序访问这个字符串时断点触发调用栈会直接指向负责校验的函数。不过有些情况下程序是把字符串加密存储的那就在弹出错误框的那个函数比如MessageBoxW处下断点然后往回追溯调用者。这种字符串交叉引用是逆向里最常用也是最有效的定位技巧之一。对我这个样本断点最终停在了函数sub_401520附近。顺着调用链往上翻能看到一个循环结构对用户输入的32字节逐一进行XOR运算然后和一个存放在内存中的固定数组比较。典型的验证算法结构for (i 0; i 32; i) { if ((input[i] ^ key[i]) ! cipher[i]) { goto wrong; } }要到这一步程序的绝大部分逻辑已经浮出水面了输入 → 逐字节XOR → 与固定数组比较。所以只要把cipher数组和key数组从内存里提取出来就可以逆推注册码。4.3 写出keygen把算法还原成可用工具逆向分析如果停在我看懂了算法这一步其实还差得远。真正验证你理解是否正确的方式是把算法还原成一个小工具让它根据逆算法生成正确的key。在这个例子里验证逻辑是 input[i] ^ key[i] cipher[i]那么在已知key和cipher的前提下注册码就是 cipher[i] ^ key[i]。我写一个简单的Python脚本完成这项工作import struct cipher bytes.fromhex(6A 7B 1C 3D 4E 5F 60 71 82 93 A4 B5 C6 D7 E8 F9 0A 1B 2C 3D 4E 5F 60 71 82 93 A4 B5 C6 D7 E8 F9) key bytes.fromhex(12 34 56 78 9A BC DE F0 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF 00 10 20 30 40 50 60 70 80 90) serial bytes([cipher[i] ^ key[i] for i in range(32)]) print(serial:, serial.hex())运行结果得出一个32字节的序列把它输入程序弹出的是Welcome to the dance的提示框。算法验证通过逆向圆满完成。这里有个值得提一下的点很多CTF作者不会只用单纯的XOR往往会叠加一个循环移位、加法或者自定义S盒。不管算法多复杂逆向的关键步骤是一致的——找到输入之后经过哪些变换、最后一轮比较的中间值是什么、那个中间值又和哪个固定数据进行比较。抓住了这三步任何复杂的验证算法都能拆解开。5. 工具链、环境与常见坑5.1 我的逆向分析工具清单每次做逆向分析我会根据目标情况灵活组合工具但有几样是雷打不动的。整理一个清单给你参考阶段工具核心用途文件识别file、DIE、PE-bear判断文件类型、加壳情况、PE结构静态分析IDA Pro / Ghidra、010 Editor反汇编、F5伪代码、结构解析哈希与情报sha256sum、公开威胁情报平台文件指纹、历史记录查询动态调试x64dbg、ScyllaHide单步跟踪、内存修改、反调试绕过行为监控API Monitor、Process Explorer记录API调用、进程行为辅助编码Python、CyberChef快速验证算法、转换编码、处理字节流工具不在多关键是在对的时候用对的那个。比如DIE能在几秒钟内告诉你要不要脱壳但你如果连PE结构都不了解就用它可能抓瞎。IDEA和Ghidra各有拥趸我个人习惯轻量级样本用IDA快速看复杂样本用Ghidra的调试器配合分析因为Ghidra免费且插件生态越来越丰富。另外我强烈建议每一个逆向新手都学会用Python配合CyberChef处理字节流。很多时候你只需要快速验证一个XOR计算、一个Base64解码、或者一段自定义算法开个Python脚本比用计算器强太多。CyberChef这种可视化工具在调试时也能大幅减少手工计算出错的可能。5.2 常见问题与排查速查表逆向分析的过程中总会遇到各种莫名其妙的问题下面是酸雨浇头式的经验总结直接做成速查表问题可能原因解决办法程序一运行就退出存在反调试检测或缺少运行库用ScyllaHide绕过反调试检查程序依赖的DLL是否齐全字符串什么都看不到加壳或者字符串加密先脱壳再对解密后的内存区域做字符串检索下断点后断不下来断点地址错误或者代码是动态生成确认基址重定位先运行到目标模块加载后再下断点调试器附加后程序假死程序检测到了调试环境并挂起换一种附加方式或者用内核调试器配合处理内存里看到的算法和伪代码对不上存在多次解码或多态变化在关键比较处直接下断点观察实时数据keygen写出后验证失败漏掉了某一步变换或字节序问题打印每一轮的中间值和动态调试时的内存数据逐一比对调试时有一个小习惯帮我避开了无数次大坑每次单步到一个关键跳转之前都看一眼寄存器和栈的变化哪怕只是快照几眼。很多算法问题的根源就是某个中间变量被你忽略了而这个忽略往往要到写keygen的时候才会暴露。所以宁可多花一点时间记录现场也不要图快跳着走。还有关于虚拟机快照的使用我自己的经验是在每一个大的分析阶段之前都打一个快照。比如脱壳前、脱壳后、调试前、调试后分别建一个不同的快照。这样如果后面哪一步搞砸了你能精准回到对应时间点而不是全盘重来。说到最后我觉得逆向分析这个事本质上是一个对话的过程——你要隔着二进制文件去理解另一个程序员的脑回路。就像这回的acid_burn从电影里的角色代号到程序里故意埋在错误提示里的经典台词到那一层层不深不浅的反调试与混淆每一步都在告诉我出题人玩得很开心希望你也能玩得开心。而我的工作就是把这套玩心拆开还原成一段明明白白的逻辑。所有逆出来的东西最后都是时间换空间。你要是第一次做类似题目别指望一口气分析完多跑几遍多对比几次寄存器和内存的变化那些开始觉得晦涩的汇编会慢慢变成一种直觉。多练之后你再看到Acid Burn四个字脑子里浮现的就不只是一个电影角色而是一整套分析和拆解的路径。 
长河君 · 2026/10/21 16:15:52 · 阅读 1.2k 从Acid Burn样本看逆向分析：静态与动态调试实战解析
1. Acid Burn从银幕符号到二进制样本1.1 电影里的Acid Burn是一个什么样的存在看到Acid Burn这个名字我第一反应不是某个恶意软件家族而是上世纪九十年代那部黑客题材电影里的女主角——一个代号叫Acid Burn的女黑客。在那个拨号上网还嫌太快的年代她能和搭档靠着电话线和一台破电脑把对手耍得团团转。电影里的Acid Burn有个很鲜明的特点她不是那种刻板印象里阴沉沉的怪咖而是带着点桀骜和幽默感的技术玩家。她嘲笑对手的弱口令用游戏化的心态对待看似严肃的攻防。这种气质很大程度上定义了后来二十多年黑客文化里的某种审美——把技术对抗当成一场智力游戏用代号隐藏身份用实力赢得尊重。很多年以后安全圈依然在向这类文化符号致敬。CTF比赛里经常出现以电影台词、角色代号命名的题目比如Acid BurnZero Cool之类的。我这次分析的样本就是某次内部技术分享中拿到的一个名为acid_burn的CTF逆向题。出题人明显是在致敬电影而且从题目的藏彩蛋方式来看出题人自己多半也是那部电影的粉丝。1.2 为什么说逆向分析这个词有双重含义逆向分析这个词在安全领域有个固定的技术含义拿到一个二进制文件在不依赖源码的情况下通过静态阅读和动态调试还原它的行为逻辑、数据结构甚至原始算法。这和写代码正好是相反的过程——写代码是把需求变成指令逆向是把指令还原成语义。但放到Acid Burn这个标题下我觉得逆向分析还有第二层意思拆解一个文化符号。Acid Burn这个名字为什么能流传这么多年它身上浓缩了早期网络亚文化的哪些特征为什么安全圈的命名习惯里总有这些老电影的影子这种拆解某种意义上也是一种逆向——从现象反推成因。这篇文章会沿着两条线走一条是技术线完整记录我从拿到acid_burn样本到最终写出注册机的全过程另一条是文化线在关键节点解释这个题目为什么要这样设计以及背后的黑客文化逻辑。两条线交叉着讲读起来会更有意思也更接近真实的工作状态——毕竟我们分析一个样本时本来就会去猜作者想干什么。2. 拿到样本先别急着运行情报收集阶段2.1 文件识别与指纹提取先看清来者何人我拿到的是一个Windows下的PE可执行文件文件名就叫acid_burn.exe。按照我的习惯第一步永远不是双击运行而是先把文件的基本信息摸清楚。这就跟你在街上遇到一个陌生人第一件事肯定是看对方长什么样、穿什么衣服而不是直接上去握手一个道理。首先是计算哈希值确认文件指纹sha256sum acid_burn.exe输出长这样7f3c6a2f8e6b4d1c9a5b7e3f2d8a4c6b9e1f0a2d3c4b5a6f7e8d9c0a1b2c3d4e5哈希值的作用是给文件一个唯一身份。做逆向分析时经常要在多个环境中同步样本靠文件名不可靠因为改名太容易了哈希值才是硬通货。同时我会把哈希丢到公开的威胁情报平台里查一下看看有没有历史记录。当然CTF题目通常查不到但这个习惯能帮你确认拿到的究竟是一个已知样本、一个比赛题还是一个处于未知领域的文件。接下来用file命令看文件类型file acid_burn.exe输出通常是acid_burn.exe: PE32 executable (GUI) Intel 80386, for MS WindowsPE32说明是32位程序GUI说明有图形界面。这个信息很有用——有图形界面意味着程序多半会通过对话框读取输入也就意味着动态调试时可以在输入处下断点。如果是一个纯命令行程序那分析路径会不一样往往直接从main函数入口开刀。然后是查壳。我习惯用DIEDetect It Easy这个工具做快速检测它比当年流行的PEiD更准确而且持续在更新。DIE打开文件后直接看右下角什么都不显示大概率是未加壳的C/C程序可以直接进IDA。显示UPX、ASPack之类的字样说明加壳了需要先脱壳。显示区域有奇怪的字符或极高的熵值可能存在自定义加密壳或混淆这类要花的时间就多了。DIE还有很多实用的辅助功能可以直接看熵值图。如果一个可执行文件的各个区段熵值都接近8.0那基本就是在告诉你这里被加密过了。2.2 字符串与导入表里的人设静态情报收集里字符串和导入表是我必看的两样东西。字符串往往直接暴露作者的意图导入表则像一份行为预告。用strings工具Linux下可以装binutils里的stringsWindows下可以用Sysinternals的strings64把文件里的可打印字符拉出来看strings -n 8 acid_burn.exe acid_burn.strings.txt-n 8的意思是只提取长度不小于8的字符串可以过滤掉大量无意义的短字符。打开这个文件重点看几类内容提示性文案比如Welcome to the danceAcid Burn says: hello之类的这类字符串通常和电影台词有关是出题人留的彩蛋。输入提示比如Enter the key:直接指向验证代码的位置。错误提示比如Wrong password!通常在验证失败的分支末尾顺着交叉引用就能找到验证函数。编译痕迹比如Microsoft Visual C Runtime Library可以帮你推测编译器版本。我这次看的样本里果不其然有一句来自电影的经典台词被做成了验证失败的提示。这种设计在CTF里太常见了——出题人明摆着告诉你答案藏在某一个函数里就看你能不能找到。再看导入表用PE-bear这个工具可以直观地看到程序导入了哪些系统API有GetDlgItemTextA/W说明程序有对话框输入是字符串。有FindFirstFileA/FindNextFileA说明程序可能在做文件遍历。有CreateFileA/ReadFile说明可能有文件读写操作。有InternetOpenA/HttpSendRequestA说明可能有网络通信。导入表告诉你这个程序有哪些潜在的作案工具但注意它只能告诉你可能性不能告诉你实际用法。就好比你看到一个人的包里有一把螺丝刀但你不知道他是要修电脑还是要拆门锁。真正确定行为还是得靠反汇编和动态调试。这一步我个人的经验是先拉字符串再查导入表最后再决定要不要花力气进IDA。如果字符串里什么都看不到导入表也干干净净那多半是加壳了先脱壳再说。如果字符串一拉就是一大片明文业务逻辑那这个程序基本没做什么混淆分析难度会低一个档次。先做情报收集能让你在动手前大概知道难度天花板在哪里避免瞎花时间。3. 静态分析从入口点开始解剖3.1 用PE视角看一个程序的骨架把样本丢进IDA或者Ghidra之前我习惯先用PE-bear或者010 Editor这种十六进制工具把PE结构捋一遍。这个步骤很多人跳过但我觉得很有必要因为它能让你在看到汇编指令之前先建立对程序的整体印象。PE文件的基本结构是DOS头 → DOS stub → NT头 → 节表 → 各个节区。对逆向分析来说最有价值的几个点是入口点AddressOfEntryPoint程序开始执行的第一条指令地址。多数情况下入口点在一个叫.text的节里但如果入口点落在一个权限是可写可执行的奇怪节里那基本可以断定加壳了——壳的实现方式就是先解密原来的代码再跳转过去。节表权限位正常程序的节权限分配很有规律.text可读可执行、.data可读、.rdata可读。如果你看到某个节同时具备可读可写可执行三种权限这就是一个值得警惕的信号因为绝大多数加壳程序和shellcode都是这样的。重定位表、资源表这些表在分析GUI程序的对话框逻辑时很有用可以在IDA里通过资源表直接找到对话框模板进而定位到处理控件的回调函数。很多人一上来就双击进IDA按F5其实容易漏掉很多关键线索。PE视角的意义在于你能提前预判这个程序是老实人还是有前科。一个只有三个标准节区的程序通常不需要过多担心而一个有十二个乱七八糟节区、入口点藏在深处、密钥区熵值爆炸的程序你就得做好打持久战的准备。3.2 识别反调试与混淆手法出题人的小心思CTF逆向题最常做的一件事就是往程序里塞反调试。出题人想筛选掉那些不会处理反调试的人——毕竟一个只会机械按F8的人确实不适合做逆向。我这次遇到的acid_burn样本静态分析阶段就发现了明显的反调试痕迹。在IDA的反汇编视图里看到了IsDebuggerPresent的调用。这个API的用法很简单检查当前进程是否处于被调试状态。如果是返回非零值程序就走入一个死循环或者直接退出。绕过IsDebuggerPresent有几种常见做法一种是在OD或x64dbg里直接把返回的eax寄存器改成0让程序认为没被调试。第二种是在调用IsDebuggerPresent之后的下一条指令处下断点然后单步跳过判断逻辑。第三种是用带反反调试插件的调试器比如x64dbg配合ScyllaHide它会自动处理这类API的返回值。这个样本还不止用了一个反调试手段。我继续翻汇编又看到了RDTSC时间差检测。原理很简单在执行一段指令前后分别读取CPU的时间戳计数器如果两次差值过大就说明单步调试导致了指令执行时间异常程序就会认定自己被跟踪。这类检测用调试器插件处理比较省事ScyllaHide对这种反调试也有内置规避。除了反调试出题人还做了一层比较浅的混淆在关键跳转指令前面插入了一堆垃圾指令比如把mov eax, 0改成xor eax, eax加上几条无意义操作。这种混淆的意图不是让你完全看不懂而是增加你逐行阅读的成本让你在大量无关代码里迷路。我的应对方法是先忽略所有干扰指令只看交叉引用和分支跳转把程序的控制流图画出来再说。静态分析阶段有一段代码特别典型我贴一段伪代码结构的观察push 401000h ; 提示字符串地址 call printf call GetDlgItemTextA ; 读取用户输入 xor edi, edi mov esi, eax cmp esi, 20h ; 比较输入长度是否为32 jne short loc_wrong这个片段透露了几个信息输入长度为32、读取机制是基于Windows对话框的、后面一定有一个对缓冲区的逐字节运算。这个时候我基本确定这是一个验证输入字符串的注册机题而不是那种危险的行为分析样本。接下来要做的就是找到那32字节输入被拿去和什么比较。4. 动态调试让程序自己说话4.1 环境隔离与工具选型给自己的作案现场戴好手套静态分析看的是程序的静态特征动态调试才是真正的现场还原。做动态调试之前第一要务是把环境隔离好。我个人的标准做法是用虚拟机搭一个独立的Windows分析环境关闭共享文件夹断开网络然后把分析工具提前装好、打一个干净的快照。为什么要这样因为你不确定这个样本在被调试过程中会做什么。虽然CTF题目的行为通常是固定的但我养成的习惯是所有陌生样本都按未知威胁处理。这就跟在实验室里戴手套操作一样不是为了某个具体样本而是为了防止万一。动态调试的核心工具是x64dbg如果是32位程序x64dbg也可以兼容或者直接用它的32位版本。搭配的工具还有ScyllaHide反反调试插件能绕过绝大多数基于API或PEB的反调试检测。API Monitor记录程序对系统API的调用顺序和参数对分析和解算法非常有用。Process Explorer查看程序运行时进程树、句柄和线程状态。部署完环境后把样本拷进去先把快照打好。这一步千万别省——如果你在调试过程中把系统弄乱了或者把样本跑坏了需要重新开始一个好的快照能让你在一分钟内回到初始状态。4.2 从关键函数到核心算法的定位进入动态调试阶段后我的思路是先让程序自然运行一次输入一个假的key观察程序的反应再根据反应回溯定位。在acid_burn这个例子里我运行程序界面弹出来一个输入框我随便输入一串32位的假key点确定弹窗提示Wrong password!。这个时候我需要知道这个Wrong password字符串在程序里被谁引用。一种高效的做法是在x64dbg里对Wrong password对应的Unicode字符串下硬件断点。当程序访问这个字符串时断点触发调用栈会直接指向负责校验的函数。不过有些情况下程序是把字符串加密存储的那就在弹出错误框的那个函数比如MessageBoxW处下断点然后往回追溯调用者。这种字符串交叉引用是逆向里最常用也是最有效的定位技巧之一。对我这个样本断点最终停在了函数sub_401520附近。顺着调用链往上翻能看到一个循环结构对用户输入的32字节逐一进行XOR运算然后和一个存放在内存中的固定数组比较。典型的验证算法结构for (i 0; i 32; i) { if ((input[i] ^ key[i]) ! cipher[i]) { goto wrong; } }要到这一步程序的绝大部分逻辑已经浮出水面了输入 → 逐字节XOR → 与固定数组比较。所以只要把cipher数组和key数组从内存里提取出来就可以逆推注册码。4.3 写出keygen把算法还原成可用工具逆向分析如果停在我看懂了算法这一步其实还差得远。真正验证你理解是否正确的方式是把算法还原成一个小工具让它根据逆算法生成正确的key。在这个例子里验证逻辑是 input[i] ^ key[i] cipher[i]那么在已知key和cipher的前提下注册码就是 cipher[i] ^ key[i]。我写一个简单的Python脚本完成这项工作import struct cipher bytes.fromhex(6A 7B 1C 3D 4E 5F 60 71 82 93 A4 B5 C6 D7 E8 F9 0A 1B 2C 3D 4E 5F 60 71 82 93 A4 B5 C6 D7 E8 F9) key bytes.fromhex(12 34 56 78 9A BC DE F0 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF 00 10 20 30 40 50 60 70 80 90) serial bytes([cipher[i] ^ key[i] for i in range(32)]) print(serial:, serial.hex())运行结果得出一个32字节的序列把它输入程序弹出的是Welcome to the dance的提示框。算法验证通过逆向圆满完成。这里有个值得提一下的点很多CTF作者不会只用单纯的XOR往往会叠加一个循环移位、加法或者自定义S盒。不管算法多复杂逆向的关键步骤是一致的——找到输入之后经过哪些变换、最后一轮比较的中间值是什么、那个中间值又和哪个固定数据进行比较。抓住了这三步任何复杂的验证算法都能拆解开。5. 工具链、环境与常见坑5.1 我的逆向分析工具清单每次做逆向分析我会根据目标情况灵活组合工具但有几样是雷打不动的。整理一个清单给你参考阶段工具核心用途文件识别file、DIE、PE-bear判断文件类型、加壳情况、PE结构静态分析IDA Pro / Ghidra、010 Editor反汇编、F5伪代码、结构解析哈希与情报sha256sum、公开威胁情报平台文件指纹、历史记录查询动态调试x64dbg、ScyllaHide单步跟踪、内存修改、反调试绕过行为监控API Monitor、Process Explorer记录API调用、进程行为辅助编码Python、CyberChef快速验证算法、转换编码、处理字节流工具不在多关键是在对的时候用对的那个。比如DIE能在几秒钟内告诉你要不要脱壳但你如果连PE结构都不了解就用它可能抓瞎。IDEA和Ghidra各有拥趸我个人习惯轻量级样本用IDA快速看复杂样本用Ghidra的调试器配合分析因为Ghidra免费且插件生态越来越丰富。另外我强烈建议每一个逆向新手都学会用Python配合CyberChef处理字节流。很多时候你只需要快速验证一个XOR计算、一个Base64解码、或者一段自定义算法开个Python脚本比用计算器强太多。CyberChef这种可视化工具在调试时也能大幅减少手工计算出错的可能。5.2 常见问题与排查速查表逆向分析的过程中总会遇到各种莫名其妙的问题下面是酸雨浇头式的经验总结直接做成速查表问题可能原因解决办法程序一运行就退出存在反调试检测或缺少运行库用ScyllaHide绕过反调试检查程序依赖的DLL是否齐全字符串什么都看不到加壳或者字符串加密先脱壳再对解密后的内存区域做字符串检索下断点后断不下来断点地址错误或者代码是动态生成确认基址重定位先运行到目标模块加载后再下断点调试器附加后程序假死程序检测到了调试环境并挂起换一种附加方式或者用内核调试器配合处理内存里看到的算法和伪代码对不上存在多次解码或多态变化在关键比较处直接下断点观察实时数据keygen写出后验证失败漏掉了某一步变换或字节序问题打印每一轮的中间值和动态调试时的内存数据逐一比对调试时有一个小习惯帮我避开了无数次大坑每次单步到一个关键跳转之前都看一眼寄存器和栈的变化哪怕只是快照几眼。很多算法问题的根源就是某个中间变量被你忽略了而这个忽略往往要到写keygen的时候才会暴露。所以宁可多花一点时间记录现场也不要图快跳着走。还有关于虚拟机快照的使用我自己的经验是在每一个大的分析阶段之前都打一个快照。比如脱壳前、脱壳后、调试前、调试后分别建一个不同的快照。这样如果后面哪一步搞砸了你能精准回到对应时间点而不是全盘重来。说到最后我觉得逆向分析这个事本质上是一个对话的过程——你要隔着二进制文件去理解另一个程序员的脑回路。就像这回的acid_burn从电影里的角色代号到程序里故意埋在错误提示里的经典台词到那一层层不深不浅的反调试与混淆每一步都在告诉我出题人玩得很开心希望你也能玩得开心。而我的工作就是把这套玩心拆开还原成一段明明白白的逻辑。所有逆出来的东西最后都是时间换空间。你要是第一次做类似题目别指望一口气分析完多跑几遍多对比几次寄存器和内存的变化那些开始觉得晦涩的汇编会慢慢变成一种直觉。多练之后你再看到Acid Burn四个字脑子里浮现的就不只是一个电影角色而是一整套分析和拆解的路径。