每年吾爱破解论坛的解题领红包活动都是逆向爱好者练手的好时候。尤其是Windows初级题一般就是一个32位小exe打开以后一个输入框、一个验证按钮任务非常明确找出那个内置口令。很多人觉得逆向门槛高看到汇编就慌但实际上初级题考的不是对抗而是基本功——查壳、定位关键函数、下断、读比较逻辑。这篇文章就按我实际解题的顺序来写把从拿到压缩包到最终提交口令的每一步都拆开聊同时也把每一步“为什么这么做”讲清楚。如果你正打算入坑Windows逆向或者已经看过一些教程但没完整跑通过一道题这篇文章应该能让你少走不少弯路。我不打算把最终口令直接甩在开头因为那会把解题过程变成抄答案按流程走到最后你会自己看到那串字符串从内存里冒出来那个瞬间比任何教程都管用。1. 开搞之前先把题目底细摸清楚1.1 这类题到底在考什么拿到压缩包解压之后往往只有一个exe没有说明文件。活动帖里一般就写着“找出内置口令”几个字剩下全靠自己摸索。Windows初级题考的东西非常聚焦第一你能不能快速定位到程序处理输入的那段代码第二你能不能把它的验证逻辑读明白。它不会像高级题那样铺满各种混淆、多段壳、反调试对抗撑死套一个UPX或者用一个IsDebuggerPresent吓唬一下新人。之所以叫初级题是因为它的重点不是让你和设计者斗法而是让你把工具链和基本思路彻底走通。换个角度看这题就是一道开卷的填空题。程序内部一定有一处地方把用户输入和正确口令做比较我们要做的无非是找到那个比较点看看跟它比较的“另一半”到底长什么样。难的不是结果而是过程。很多新手为什么卡住因为一上来就埋头读汇编从入口点开始逐条跟跟到后面完全不知道自己在哪。正确的做法是先静态分析定位再用动态调试验证带着目的去翻代码。1.2 工具清单真正用得上的就这四样我见过不少新手一上来就装全家桶OllyDbg、x64dbg、IDA、Ghidra、WinDbg、Cheat Engine全塞进来结果光选工具就犹豫半天真正打开程序的时候反而不知道该用哪个。实际做一道初级题下面这四样就完全够用工具主要用途什么时候用DIEDetect It Easy查壳、识别编译器和打包器拿到文件后第一时间做体检IDA Pro静态分析、F5反编译看伪代码定位关键函数和验证逻辑x64dbg动态调试、下断点、观察内存确认静态分析结论并追踪口令PE-bear / CFF Explorer查看PE结构、节区、导入表需要确认入口点或导入函数时先解释一下为什么不是OllyDbg而是x64dbg。OllyDbg在Win7时代是主力但放到现在的Windows 10/11上兼容性问题不少而且本身已经多年没更新。x64dbg还在活跃维护32位程序也能调试界面和操作逻辑跟OllyDbg一脉相承新手直接上手x64dbg更稳妥。至于虚拟机我强烈建议准备一个。一方面是为了隔离论坛出的题基本安全无害但长期搞逆向的人应该养成“陌生程序先在虚拟机里跑”的习惯另一方面是方便恢复现场调试时改坏文件、写错跳转都是家常便饭一个干净快照能让你原地满血复活。系统方面Win10 x64就够用再装好常用的VC运行库x86/x64版本大部分题都不会有环境问题。2. 静态分析先行让程序自己把线索亮出来2.1 查壳与文件体检别一上来就上调试器拿到exe的第一件事不是双击运行而是先拖进DIE看一眼。DIE会直接告诉你这个文件有没有壳、是什么编译器生成的、入口点有什么特征。如果显示“UPX”之类的打包器说明程序加壳了得先脱壳再分析如果显示“Microsoft Visual C”或者“MinGW”大概率是无壳的普通程序可以直接进IDA。脱UPX壳最快的办法是命令行直接执行upx -d简单粗暴大多数情况下一次就能成功。如果脱不了再用ESP定律手动脱在x64dbg里打开程序停在入口点后下断点单步到ESP寄存器第一次发生变化的位置沿ESP地址下硬件访问断点让程序自己跑起来到解码完成后的代码段再断下最后dump修复PE文件。这个过程说起来有点绕但初级题基本用不到upx -d解不掉的壳很少。为什么要先查壳因为带壳文件的代码段是压缩过的IDA打开后看不到正常的函数逻辑字符串搜索也搜不到F5更是会直接失败。等于你要在一间上了锁的房间里找东西先把锁拆了里面才能看清。2.2 字符串和导入表是两把现成的钥匙脱壳之后把文件拖进IDA按ShiftF12打开字符串窗口你会看到一大堆可读文本。绝大多数初级题的作者为了方便新手都会在字符串里留下明显的提示比如“请输入口令”“验证”“口令错误”“恭喜你”之类。看到这些就别客气双击其中一个字符串选中后按CtrlX查看交叉引用IDA会直接带你去引用这个字符串的那条汇编指令。那个位置就是消息弹窗或者比较逻辑的所在顺着往上翻几行基本就能找到按钮点击事件的处理代码。导入表同样重要。在IDA左侧函数列表里扫一眼如果看到GetDlgItemTextA或GetWindowTextA说明程序会把输入框的内容读到一个缓冲区里看到lstrcmpA或strcmp说明它很可能直接把两个字符串作比较看到MessageBoxA说明弹窗逻辑就在附近。这几个API就是天然的坐标锚点可以帮你在茫茫汇编里快速建立坐标系。这里有个生活化类比字符串是程序外壳上贴的标签导入函数是这个程序对外打开的窗口。你把一个exe当黑盒看的时候不可能一上来就把整个代码从头读完但顺着标签和窗口走往往能几秒钟就摸到核心位置。逆向新手最怕面对一大片汇编没人带路但只要你找到“它从哪个函数取输入、用哪个函数做比较、通过哪个函数给结果”骨架就出来了。2.3 在IDA里定位窗口过程锁定按钮点击逻辑这类Windows界面程序绝大多数走的是DialogBoxParam DialogProc模板。从IDA的Exports窗口找到Start入口顺着WinMain往下找很快就能遇到DialogProc找不到的话也别慌直接用字符串交叉引用跳过去找到“恭喜你”或“口令错误”那条字符串的引用位置后一路往上滚通常也能撞进对话框过程函数。DialogProc里做的事情其实很固定我按实际调试中看到的典型结构简化成下面这段伪代码方便你理解F5之后应该找什么INT_PTR CALLBACK DialogProc(HWND hDlg, UINT msg, WPARAM wParam, LPARAM lParam) { switch (msg) { case WM_COMMAND: if (LOWORD(wParam) IDC_BTN_CHECK) { char input[64] {0}; GetDlgItemTextA(hDlg, IDC_EDIT_INPUT, input, 64); if (check_serial(input)) { MessageBoxA(hDlg, 恭喜你口令正确, 提示, MB_OK); } else { MessageBoxA(hDlg, 口令错误再接再厉, 提示, MB_OK); } } break; } return FALSE; }点按钮后程序做的事情只有三件调用GetDlgItemTextA把输入框内容读到一个缓冲区把缓冲区指针交给check_serial函数根据它的返回值决定弹哪个窗口。所以重点研究对象是这个check_serial函数在IDA里双击它然后F5看反编译结果。实际题目里check_serial可能被编译器内联也可能被优化成一大段逐字节比较的汇编指令但万变不离其宗它一定会访问一个“参考口令”的内存地址然后把参考数据和用户输入做对比。你只需要找到那个参考口令的地址后面动态调试就有了明确目标。3. 动态调试补刀跟着程序的脑子走一遍3.1 x64dbg与IDA的双屏组合打法静态分析只能告诉你程序大概干了什么但口令到底是不是明文放在数据段里、比较之前有没有做变换这些必须通过动态调试确认。我的习惯是屏幕左半边开IDA看伪代码右半边开x64dbg看汇编、寄存器和内存两边对照着走。先在IDA里找到check_serial函数的地址比如是0x4012A0。然后到x64dbg里按CtrlG输入这个地址直接跳到对应位置。大多数论坛题为了方便调试都不会开ASLR加载基址就是0x400000和IDA里的地址完全一致。如果遇到随机基址的情况x64dbg的模块加载地址会变成别的值比如0x6A0000这时按偏移换算就行目标地址 实际加载基址 (IDA地址 - 0x400000)。另外提醒一句动手调试之前先给虚拟机打一个快照。这一步太容易被忽略一旦你在调试中patch错了跳转、改坏了指令或者程序死活跑不起来了没有快照的话只能从头再来非常打击积极性。3.2 断点到底下在哪三种选位思路新手最容易犯的错误是把断点下在MessageBoxA上。这样当然也能断下来但程序已经完成口令比较了你只看到了结果没看到过程等于学生抄了答案却不会做题。断点应该下在“比较发生之前”我一般有三种选位思路第一种是API断点。在x64dbg命令栏输入bp GetDlgItemTextA然后按F9运行。程序只要读输入框内容就会停在API入口处这时你可以从栈窗口看到缓冲区地址输入的内容就在缓冲区里。第二种是字符串交叉引用的指令断点。先在IDA里找到“恭喜你”字符串的交叉引用记下那附近某条指令的地址比如调用MessageBoxA之前的一个test指令再到x64dbg里CtrlG过去F2下断。这种方式可以停在判断结果即将生效的瞬间适合观察返回值和跳转方向。第三种是对参考口令内存地址下硬件访问断点。静态分析已经定位到check_serial访问的那个内存地址就在x64dbg里选中这一小块内存右键设置硬件访问断点。这样程序一碰这块数据就停非常适合字符串被加密或数据被动态解密的情况。3.3 输入一个错误口令观察比较发生时发生了什么实际操作一遍流程是这样的用x64dbg打开exe先bp GetDlgItemTextA按F9运行。程序界面出来之后在输入框敲一个“123456”点验证按钮调试器立刻停在GetDlgItemTextA入口。这时候看栈窗口能看到三个关键参数对话框句柄、目标缓冲区地址、缓冲区长度。在x64dbg的地址栏里输入缓冲区地址就能在内存窗口看到ASCII形式的“123456”。按F8单步走出API继续按F8走几步你会看到程序把你的输入缓冲区地址传给check_serial然后进入一堆比较指令。重点关注三类指令cmp、lstrcmpA调用、rep cmpsb。当程序在某条cmp或lstrcmpA处比较时另一个操作数指向的内存区域里很可能就是正确口令或者它的某种变换形态。最理想的情况是明文比较内存窗口直接显示一溜可读字符串那答案基本到手。这种情况下我建议先不要急着跑按住Ctrl的同时往上翻几行汇编看清楚它是什么时候把这个地址放进寄存器、从哪里加载的这样就算后面活动帖复盘你也能讲清楚来龙去脉。3.4 一个小技巧用patch验证判断点找对了没有如果程序在比较之后有个jz或jnz跳转新手可以试着改一下跳转条件把jz改成jnz或者直接nop掉跳转指令强制程序走“成功”分支。如果弹出了“恭喜你”说明你找的这个判断点就是核心验证逻辑如果没弹说明后面可能还有第二道校验得回到静态分析继续查。不过我要强调patch只是用来验证判断工具和辅助理解的不要靠patch蒙混过关。设计者既然做了这个题往往会把正确口令本身设计成下一步流程的钥匙或者加了内存自校验改动指令反而直接触发异常。真正该做的是老老实实把算法还原出来拿到原始口令这样才算真正学会。4. 把比较算法还原出来口令就藏在里面4.1 Windows初级题最常见的三种比较方式动态调试过程中你会看到构造各异的具体实现但归纳下来Windows初级题里最常出现的比较方式就这几种比较方式特征应对思路明文直接比较数据段一眼能看到ASCII字符串记录即可无脑拿分简单变换后比较内存里的参考数据是乱码但每个字节有统一规律抄下字节序列写脚本异或/加减/倒序还原多步运算比较有循环对输入的每一位逐次处理单步跟循环找出数学关系或查表逻辑明文比较就不多说了遇到就能直接收工。简单变换比较是初级题的主力题型最常见的是固定异或xor、单字节加减、顺序反转、大小写切换或者组合起来用。关键特征是乱码的每个字节和原始ASCII之间有确定的关系只要看两三个字节就能推出来。多步运算比较就比较讲究了程序会对口令每一位做处理比如按位置加索引、查一个S盒表或者用一个简单的校验公式。4.2 用脚本把口令算出来比人肉翻字节快十倍比赛时我习惯在实机开一个Python把内存窗口看到的参考数据抄出来写脚本一把梭。x64dbg的命令行也能做简单计算但复杂变换还是脚本看得清楚。下面这个脚本结构就是最常用的异或还原模板具体数据只是演示用的例子不是题目的实际答案# 从内存窗口看到的参考数据十六进制格式抄出来粘进去 data bytes.fromhex(5C 6F 5A 6B 3C 3D) key 0x33 flag .join(chr(b ^ key) for b in data) print(f还原结果: {flag})如果程序比较前做了倒序就先执行data data[::-1]如果是加减变换就把b ^ key改成(b - key) 0xFF如果每个字节和位置有关就再加一个索引参与运算。绝大多数初级题绕不开异或、加减、倒序、查表这四板斧你把模板准备好到时候套参数就行。为什么一定要到这个步骤因为很多题虽然会做变换但变换算法往往简单一两行脚本就能解出。如果现场一位一位地人工算既容易算错又浪费时间。逆向比赛拼到最后读算法和写脚本的速度决定了你的效率。哪怕只是解一个固定异或脚本也比手算可靠。4.3 拿到口令之后怎么验证并提交还原出口令后回到程序界面输入并点验证看到“恭喜你”弹窗基本就通关了。然后把口令按照活动帖要求的格式提交到指定地方通常是在版块里回帖或者私信版主按规则领取红包和评分。但到这里还没完我建议多花五分钟再回IDA里看一遍check_serial确认这个函数里到底有多少个校验点。论坛活动里经常有人拿着正确口令通过验证但复盘时讲不清原理这类人下一次拿到新题还是不会做。真正吃透一道题的标准是你能不能在没有任何笔记的情况下用大白话讲出“它在哪里取输入怎么处理和什么比较跳转条件是什么”。如果讲得出来这一题才算彻底消化。5. 实操中注定要踩的坑问题排查速查表5.1 断点断不下来或乱跳先查反调试和模块加载我见过很多人在这一步卡半天明明下了bp GetDlgItemTextA程序就是不停。第一个可能的原因是反调试个别题会调用IsDebuggerPresent或者直接检查PEB里的BeingDebugged标志检测到调试器就改变执行流程。解决方法是在x64dbg里装个HideDebugger插件一键隐藏调试器或者在静态分析阶段就看到这个API直接把它patch成xor eax, eax; ret让检测失效。第二个原因是断点下错了模块有些程序的核心逻辑被放在动态申请的内存里普通指令断点会因为模块未加载而不生效。这种情况要先在VirtualAlloc下断点等它申请到内存并返回地址后再转到那段内存上下断。5.2 字符串窗口全是乱码八成是壳或运行时解密如果没有脱壳就去找字符串看到的是压缩或加密后的垃圾数据等于隔着毛玻璃找东西。先回DIE确认壳类型能upx -d就直接脱。脱壳后还是乱码说明字符串不是静态存放的而是程序启动后才解密。这时不要盯着静态字符串窗口死磕回到动态调试在GetDlgItemTextA、lstrcmpA这些函数上下断等解密逻辑执行完再去内存窗口里看真实缓冲区内容。很多时候你会在某个解密函数返回后看到内存里突然出现一溜干净ASCII那才是口令本体。5.3 patch完程序闪退可能踩了自校验有些题目为了防作弊会对自身文件或内存做完整性校验。你刚改完跳转程序在下一次读文件或执行到校验点时检查到异常直接弹框退出。解决办法是尽量使用内存patch而不是保存修改后的文件并且在patch之前给虚拟机做快照。更根本的做法还是回到算法还原这条正路上patch只是验证性的辅助手段不要在patch上寄托太多。5.4 环境兼容性和虚拟机里的那些小毛病论坛题的运行环境大多是Windows但不同版本的系统行为会有细微差别。Win10 x64跑2024年左右出的题基本没问题Win11偶尔会因为缺少VC运行库或者SmartScreen拦截而跑不起来装一遍常用VC运行库能解决大部分问题。DPI缩放导致界面模糊很常见不影响调试杀毒软件把x64dbg当威胁拦截也常见加白名单解决或者干脆在虚拟机里关掉实时防护。这里总结一份速查表遇到问题优先按这个顺序排查现象可能原因优先排查方法断点频繁乱跳或不命中反调试干扰、断点模块错误先开HideDebugger插件改下API断点找不到关键字符串加壳、字符串运行时解密DIE查壳并脱壳动态下断电查看内存程序运行就闪退自校验、缺少运行库恢复快照安装VC运行库避免修改文件内存里显示的参考数据是乱码口令被变换后再比较抄字节序列写脚本还原别指望直接看明文6. 写给刚入坑的新手这道题教会我的几件事第一件事别怕汇编。初级题的代码再怎么绕最终都绕回读输入、做比较、弹消息这三件事。遇到看不懂的地方就问自己两个问题它现在把值送到哪了下一步要拿这个值跟谁比想清楚这两点八成代码都能读明白。第二件事工具不追新流程要固定。我到现在依然是IDA加x64dbg这套老组合真正让我提速的从来不是某个炫酷插件而是固定流程查壳、看字符串、定位窗口过程、API断点、单步跟比较、写脚本还原。这套流程形成肌肉记忆之后拿到的任何一个未知Windows程序都能快速理出骨架。第三件事也是解题后最重要的一件事亲手把这道题的验证逻辑讲一遍或写下来。不用写得很正式几张草图也可以。只要你脱离了跟着教程一步步走的被动状态能独立说出为什么在那个地址下断、为什么是这个变换这一题才算真正吃透。最后留一个实用小技巧调试前把x64dbg的Log窗口打开它会记录每次断点命中时的模块和地址。碰到“明明下了断却不命中”这种玄学问题先看Log窗口里有没有模块加载记录。很多所谓灵异现象其实都白纸黑字写在日志里只是你没看而已。