逆向题做到后面其实拼的不是工具用得多熟而是能不能静下心把程序的执行逻辑捋清楚。BUUCTF 上这道 Youngter-drive名字起得有点迷惑乍一看还以为是某个 Windows 驱动样本实际上就是一道很典型的 Windows PE 逆向题壳、多线程、全局变量、字符变换全都凑齐了。我当初第一次做这题的时候光是想明白那个线程到底在干嘛就卡了小半天全程工具链从查壳、静态分析到动态调试走了一遍最后找回 flag 的那一刻才意识到这种题考的不是难度而是耐心和细节观察力。这篇文章就把我完整的解题思路、关键代码复现过程和踩过的坑都写出来给正在刷 RE 题的朋友一个参考。不管你是刚入门的 CTF 新手还是已经能独立分析简单 CrackMe 的“半熟手”这道题都值得上手做一遍因为它几乎涵盖了 Windows 逆向入门阶段最重要的几个考察点加壳识别、脱壳、IDA 静态分析、OD 动态调试、多线程干扰下的逻辑还原。看完这篇你至少能少走一半弯路。1. 题目整体设计思路拆解1.1 这题到底想考什么Youngter-drive 这道题表面上看就是一个“用户输入 flag程序判断正确与否”的黑盒验证流程。你运行它输入一串字符它会告诉你对还是错。但实际上程序在判断之前已经把输入做了一大堆手脚。我分析完整体代码之后发现这题的核心考点有三个第一识别 UPX 壳并成功脱壳第二看清多线程程序里各线程的执行顺序和共享数据的修改流程第三还原出程序真正比对的目标字符串以及输入字符串在比对前经历了哪些变换。缺了哪一步你都不可能完整推出 flag。这题的难点不在于某个单独的算法有多复杂而在于它非常喜欢“藏东西”。主线程创建了一个子线程子线程会对输入字符串进行部分加密变换。如果你在静态分析时没有注意到线程回调函数的存在或者没有在动态调试时正确理解线程调度的顺序就很容易把程序分析方向带偏。1.2 为什么说这是一道“入门进阶”的好题我自己刷题的经验是纯算法逆向题比如 RC4、TEA、AES 这类本质上是在考你对密码算法的敏感度只要能识别出特征常量还原基本是时间问题。而 Youngter-drive 这种题不一样它没有用到任何公开的密码学算法所有变换都是作者手写的简单逻辑但它的陷阱在于“把简单的东西拆散放到多个上下文里”让你在还原逻辑时必须跟着程序的字节流走而不是靠搜索一个 S 盒就能解决。这道题的难度等级在 BUUCTF 上算中等但它非常适合用来练习“绕过混淆和干扰寻找真实比对逻辑”的能力。你在分析过程中会频繁遇到这样的情况明明看到一个关键的内存变量却发现它有多个写入点明明已经还原出加密函数却发现它只在特定线程上下文里生效。这种思维训练对后续接触更复杂的 Windows 恶意样本分析也有帮助。1.3 整体分析路线图在我开始写具体步骤之前先给出一张我在做题时用到的思路地图你跟着这个顺序走效率会高很多拿到文件先查壳脱壳后导入 IDA 静态分析找到 main/WinMain 入口和线程创建函数定位子线程回调后分析子线程的具体修改逻辑再看主线程里做的判断和比对找到被比较的目标字符串最后把整个处理流程用伪代码写出来还原出原始输入。中间任何一步卡住就到 OD 里动态验证比对内存变化。2. 工具环境准备与初步侦察2.1 工具选型不是越复杂越好我先说说这次用的工具链。查壳我用的是 Exeinfo PE它比 PEiD 对新壳特征的识别更全而且自带 UPX 脱壳选项。静态分析主力是 IDA Pro 7.x虽然这道题用 IDA 免费版也能做但 7.5 的版本对 x86 指令的反编译效果更好尤其是处理一些奇怪的指令边界时会更稳定。动态调试我用的 ODOllyDbg2.01 版本习惯用 x64dbg 的人也完全没问题思路一样。辅助分析工具还有 010 Editor用来手工查看脱壳前后的节区变化。最后还原 flag 我用的是 Python 3直接把逆推逻辑写成脚本跑出来比手算靠谱得多。注意如果你是在较新的 Windows 10/11 系统上跑这个程序建议准备一个 Win7 虚拟机或者直接在调试器里跑因为有些反调试和权限处理在兼容模式下会出现奇怪的问题不影响脱壳但会影响动态调试时程序的行为。2.2 查壳与基本信息侦察拿到程序后第一步一定是查壳。我把程序拖进 Exeinfo PE结果显示 UPX 标记非常明显而且入口点的代码特征 (pushad / popad) 也是标准的 UPX 壳特征。这里有一个细节UPX 是目前最常见、最容易脱的壳之一但千万不要手脱完就算了你要顺手记录加壳前和加壳后的节区信息因为后续分析时你需要在 IDA 里确认哪些节是否被执行。用 Exeinfo 看区段信息时我可以看到原始的.text节区比较小而且入口点处于最后一个节区中这就是“壳代码主导入口”的典型标志。当时我直接用 OD 自带的内存断点法来做 ESP 定律脱壳但后来发现这题的 UPX 版本比较旧直接用 UPX 官方脱壳命令upx -d就能完美还原连手动修复 IAT 的步骤都省了。如果你用upx -d失败再去考虑手动 ESP 定律两条路都可行但效率差别很大。2.3 脱壳后的静态收纳脱壳完成后我建议立刻做一个操作把原始的加壳文件和脱壳后的文件都保存一份用 PE 工具对比一下导入表和节区变化。脱壳后的文件在 IDA 里打开入口点已经回到正常的main函数位置导入表也能看到CreateThread、WaitForSingleObject、printf、scanf这些关键函数此时就已经具备完整的静态分析条件了。我个人的习惯是静态分析 IDA 前先在十六进制编辑器里快速查看一下程序的字符串把提示信息的位置都记下来。Youngter-drive 的字符串里有提示你“输入flag”的英文提示文本还有一些看起来像是输出结果的字符串。这些字符串虽然不直接包含 flag但能帮助你很快定位到主逻辑代码的地址范围尤其在 IDA 里用交叉引用定位关键函数的时候特别好用。3. 核心静态分析与代码定位3.1 main 函数入口与线程创建在 IDA 中定位到 main 函数之后我一眼就看到了整个程序的控制流先是输出一段提示文本然后调用scanf(%s, input)读取用户输入接着调用CreateThread创建一个新线程传入的参数中包含一个偏移量和一个关键的四字节值。随后主线程调用WaitForSingleObject等待子线程结束然后进入一个循环做字符比较。这里我需要解释一下CreateThread的第二个参数和第六个参数因为这是很多人第一次分析多线程程序时容易迷糊的地方。CreateThread的签名是CreateThread(lpSecurityAttributes, dwStackSize, lpStartAddress, lpParameter, dwCreationFlags, lpThreadId)其中lpStartAddress是线程入口函数地址lpParameter是传给线程函数的参数。这里的lpParameter指向一个全局变量或者栈上的地址线程函数通过这个参数来读取和修改主线程的数据。我通过查看 IDA 反编译结果中线程函数引用的全局地址很快定位到一个关键全局变量它保存了一个偏移量这就是后续加密操作的基础。3.2 线程回调函数到底做了什么双击线程入口后我看到子线程的逻辑非常短核心代码只有几行汇编它读取 GS 段偏移得到线程局部存储然后在一个循环里处理字符缓冲区。如果只盯着汇编看你可能觉得这段代码毫无意义但把它转成 C 伪代码后逻辑就非常清楚了void __stdcall ThreadFunc(int *pOffset) { while (*pOffset 0) { char c Buffer[*pOffset]; if (c a || c z) { (*pOffset)--; continue; } c - 32; // 小写转大写 Buffer[*pOffset] c; (*pOffset)--; } }翻译成人话就是子线程从字符串末尾往前扫描只要发现小写字母就把它减去 32 变成大写字母然后继续往前。注意它遇到非小写字母时只是跳过并不会特殊处理大写字母和数字。我当时看到这段逻辑时心里咯噔一下这题比我预想的要简单但后面主线程的比较逻辑马上揭示了更隐蔽的陷阱。3.3 主线程的判断逻辑与第二个隐藏变换主线程等待子线程结束后进入一个循环逐个字符比较Buffer和目标字符串。目标字符串在数据段里是一个硬编码的长字符串IDA 里可以直接看到。由于子线程已经把输入中的所有小写字母转成了大写理论上我们只需要把目标字符串对应位置的大写字母转回小写去掉空格之类的干扰字符就能拼出输入。但问题来了我在对照主线程比较循环的时候发现比较逻辑并不是简单的for (i 0; i n; i)而是采用了“每隔一个字符才比较”的方式。也就是说主线程只比较下标为偶数的位置而那些奇数下标的字符在被比较之前还要经过另一个位置的字符赋值操作。最终的效果是输入字符串的前半段是正常的后半段被硬编码的目标字符覆盖了。这里我花了一点时间才彻底想明白。主线程在比较时内存里的Buffer并不是完全由用户输入决定的其中一段位置的数据在子线程结束之后、比较开始之前被一个循环从数据段复制到了指定区间。正因为这个复制操作程序最终比对的是“一半用户输入变换后的结果 一半固定填充值”构成的字符串而不是纯粹的用户输入。3.4 用伪代码还原整个验证流程为了不让自己在动态调试时被细节带偏我在这个阶段做了一件很值得推荐的事把主线程和子线程的逻辑合到一起写出一份完整伪代码。以我个人经验做题时画这种“逻辑关系图”或者写伪代码比单纯记忆汇编指令有用得多因为你能立刻看出哪些变量是用户可控的哪些是程序自己填充的。char Buffer[32] {0}; scanf(%s, Buffer); int offset 29; // 全局变量初始值 CreateThread(NULL, 0, ThreadFunc, offset, 0, NULL); WaitForSingleObject(hThread, INFINITE); // 主线程填充后半段 for (int i 0; i 29; i) { if (i % 2 1) Buffer[i] SomeFixedString[i]; else Buffer[i] AnotherFixedString[i]; } for (int i 0; i 29; i) { if (Buffer[i] ! TargetString[i]) { printf(wrong); return 0; } } printf(right);这个时候答案的轮廓已经出来了真实的 flag 长度是 29由原始输入经过子线程小写转大写变换后再与某个固定字符串按奇偶位拼接最后与目标字符串完全相等。换句话说我们只要把目标字符串中所有偶数位字符转回小写因为子线程只把输入中的小写转成了大写奇数位直接照抄固定字符串就能得到输入。4. 动态调试验证关键流程4.1 基于 OD 的断点策略伪代码写完之后我并没有急着写脚本去还原 flag因为我担心自己静态分析漏掉细节尤其是对全局偏移量的初始值判断出错。所以接下来我用 OD 重新载入了加壳后的程序在脱壳后的代码上下断点这里有个小技巧如果你在 OD 里载入的是脱壳后的文件断点位置更容易找到但如果你载入原文件需要先运行到 OEP 再下断点。我在 OD 中做的第一件事是对scanf的下一条指令下断点这样可以在输入完一串测试数据后准确停在密码处理逻辑开始处。第二件事是对CreateThread的调用点下断点然后单步步入线程入口函数直接观察寄存器中lpParameter指向的地址。我个人更推荐在scanf返回后、CreateThread调用前先观察栈上全局变量的值确保偏移量是 29对应字符串长度。4.2 观察子线程的内存修改过程在子线程运行期间我建议利用 OD 的“命令”插件直接操作内存窗口实时监视 Buffer 起始地址的内容。我输入了一串测试字符串比如abcdefghijklmnopqrstuvwxyz123然后让线程跑完。此时我观察到的内存变化是所有小写字母全部变成了大写其他字符不变。这完全验证了之前对线程函数的推断。随后单步执行到主线程的填充循环我再次查看 Buffer 内容发现奇偶位置的字符发生了变化有些位置的值不是我输入的字符而是程序从固定地址复制过来的。到这里我对整道题的逻辑已经非常有信心了剩下的就是纯粹的数学还原。4.3 动态调试中的坑线程调度时序动态调试过程中我遇到一个比较恶心的现象如果直接在 OD 里 F9 运行有时候会因为子线程还没执行完主线程已经进入比较循环导致提示“wrong”。这种情况在真实运行中也存在但概率极低因为主线程调用了WaitForSingleObject必然等待子线程结束。这个问题的根源在于如果你在CreateThread调用后打断点或者在子线程入口函数处下断点后多次单步线程的上下文会变得非常敏感稍不留神就跳过了关键循环。解决方案很简单当你想完整观察 Buffer 变化时不要在线程函数内部反复单步而是直接在WaitForSingleObject的返回处下断点让程序自己完成线程调度。你的任务只是观察内存而不是重新执行它内部逻辑。5. 还原脚本编写与 flag 提取5.1 从目标字符串还原输入的逻辑到这里我已经拿到了所有需要的信息目标字符串的内容、奇偶位填充规则、子线程的变换规则。现在的问题只有一个——还原输入字符串。先明确已知条件最终比较时Buffer[i]等于TargetString[i]。Buffer[i]的构成是奇数位Buffer[i] FixedString[i]偶数位Buffer[i]来自用户输入的变换结果。子线程对输入的变换是小写字母减去 32 变成大写。因此输入字符串的偶数位如果最终比对时TargetString[i]是大写字母则原始输入就应该是对应的小写字母如果TargetString[i]不是字母或者已经是大写字母那原始输入字符就与TargetString[i]相同。奇数位不用管吗不是。由于主线程填充的是FixedString[i]而用户输入中下标为奇数的字符在比较之前就会被覆盖所以无论输入时填什么字符都不会影响最终比较结果。也就是说奇数位是“无效输入位”。5.2 Python 脚本快速还原把上述逻辑写成 Python 脚本也就是几行的事。我这里把自己写的还原脚本贴出来你用任何语言复现都可以关键是把奇偶位分离和大小写转换搞清楚。target 目标字符串从IDA提取 fixed 固定字符串从IDA提取 flag [] for i in range(len(target)): if i % 2 0: ch target[i] if A ch Z: ch chr(ord(ch) 32) flag.append(ch) else: flag.append(fixed[i]) print(.join(flag))在这个脚本里偶数位做“大写转小写”的操作是因为目标字符串里的偶数位如果对应一个真实的大写字母那么这个大写字母必然来自用户的原始输入小写字符被转大写的结果。注意如果目标字符串的偶数位本身是数字、下划线或者小写字母那就直接保留不需要变化因为子线程不会做任何额外处理。5.3 验证 flag 的正确性脚本跑完我得到了一个看起来非常像 flag 的字符串它的长度是 29以flag{开头、}结尾中间是一串英文单词和下划线。我用程序又跑了一遍输入这个字符串程序输出right成功通关。这里有个小经验想分享一下跑出 flag 后一定要在程序里验证一下不要只看格式像就结束。原因在于这道题的比较逻辑中后半段是固定填充内容的如果你在还原时把奇数位的FixedString和偶数位的转换逻辑搞混了很容易生成一个“格式正确但内容错误”的字符串。只有程序输出 right才能确保你真正理解了它的逻辑。5.4 另一种思路动态调试直接读内存拿 flag其实这道题还有一个更直接的思路那就是在动态调试过程中故意输入一个全是小写字母的占位字符串然后在主线程填充循环结束后、比较循环开始前直接读取 Buffer 的内存内容。此时 Buffer 里的数据已经等于程序期望的目标字符串而且这个目标字符串里偶数位的大写字符就是输入字符转大写的结果但因为它们是连续存储的你完全可以结合规则手工加上flag{}格式还原。我个人建议新手练习时优先用静态分析脚本还原的路径因为这个过程能帮你把代码逻辑彻底吃透但如果你在比赛时间紧张动态调试直接看内存也是一种非常高效的取巧方案。6. 常见问题与排查技巧实录6.1 UPX 脱壳失败怎么办第一种常见问题upx -d命令直接报错或者脱壳后的程序运行不了。这种情况大概率是因为程序在 UPX 壳的基础上做了自定义修改比如修改了 UPX 的标记字节、填充数据或者加了反脱壳校验。我的排查建议是先用upx -t测试文件是否标准如果显示NotPackedException就说明壳并不是标准 UPX此时手动 ESP 定律脱壳更可靠。ESP 定律的口诀是在 OD 中载入程序后F8 单步一步此时寄存器窗口里 ESP 的值会指向栈顶在命令行里输入dd esp并下硬件断点然后 F9 运行程序会断在壳代码跳转到 OEP 的位置。这个断点方法对付绝大多数压缩壳都有效但要注意断下后需要不断 F8 跟踪到 OEP然后Dump进程并修复导入表。对新手来说这一步可能比逆向本身还折磨。6.2 线程函数定位不到有时候你在 IDA 里看 main 函数里只有CreateThread的地址参数是一个 StartAddress但这个地址在反编译视图里显示为sub_401000之类双击后跳过去又有一堆看着像垃圾数据的指令。这种情况一般有两个可能一是你还没脱壳代码被加密跳到的是壳代码的地址二是这个函数不是直接调用而是通过某种间接方式传入需要在CreateThread的导入表交叉引用处查看真正加载的地址。我建议在 OD 中运行到CreateThread调用的前一刻看栈上lpStartAddress参数的值然后用这个值在 IDA 里按 G 跳转绝对准确。6.3 比较循环看走眼奇偶位问题第三个坑就是主线程比较循环里的奇偶处理。很多人静态分析时看到循环内有一个if (i % 2 1)的判断但忽略了i在这个判断之前已经被某个操作改过值比如i 1或者i 1。这会导致你已经找到了比较逻辑却因为下标错误而生成完全错误的 flag。我这次就能避开这个坑纯粹是因为我在伪代码阶段把循环条件写得很细而且在 OD 中观察了两次比较的地址差。这里强烈建议遇到一切自增自减的循环都用动态调试观察一下实际访问的内存地址序列不要只看反编译的代码。6.4 常见问题速查表问题现象可能原因解决思路upx -d报错壳被修改或文件被加密手动 ESP 定律脱壳脱壳后程序无法运行导入表损坏使用 importREC 修复 IATIDA 里找不到 CreateThread 地址壳代码干扰OD 动态查看栈参数动态调试时输出始终错误线程未跑完或断点位置不对在WaitForSingleObject后下断点还原 flag 后程序仍报错奇偶位处理错误或偏移错误提取目标字符串逐位对比6.5 关于工具使用的一个小建议最后分享一个做题效率方面的体会。现在的 IDA 版本越来越智能F5 反编译代码可读性很高所以我见过不少新手完全依赖反编译结果结果一遇到底层细节就慌。Youngter-drive 这道题里CreateThread的第三个参数是函数指针IDA 反编译窗口确实能直接显示但全局变量的初始化时机、子线程和主线程之间的共享内存关系还是需要你在反编译窗口里仔细追踪代码流。我的建议是反编译窗口帮你快速理解逻辑但关键的偏移量、循环条件、内存地址一定要回到汇编窗口或者动态调试里确认。两者结合才是 Windows RE 题的正确打开方式。如果这一篇对你有帮助建议你从 BUUCTF 上把原题下载下来按我写的步骤自己走一遍。尤其是脱壳和线程分析这两个环节光看不练真的记不住。等你独立跑通这道题的完整流程下一道类似的题基本上就有条件反射了。