1. 案例分析与破解目标拿到一个本地 CrackMe 训练样本我第一件事就是把它丢进 x32dbg 里看 Name/Serial 验证算法到底怎么跑。程序长得非常典型一个注册窗口上面一个输入 Name 的编辑框下面一个输入 Serial 的编辑框中间一个注册按钮。无论你填什么点一下按钮窗口要么弹“Try Again”要么弹“God Job”。这类程序在逆向入门里出现频率极高因为验证逻辑集中、流程短而且涉及字符串、API 调用、循环和分支跳转几乎把动态调试的基本功全部过了一遍。这次的目标不只是把程序“改成功”而是完整还原它的验证算法写一个注册机出来。也就是说我需要在内存里看着程序自己算出序列号搞清楚 Name 和 Serial 之间的数学关系然后再用 Python 或者 C 把这个关系复现出来。听起来很绕但实际做一遍就会发现这条路才是逆向最有价值的部分爆破只是改几个字节还原算法才能让你真正“懂”这个程序。1.1 程序行为与判定规则先观察程序正常行为。打开“NameAndSerial”这个 32 位 Windows GUI 程序界面很简单。我在 Name 里输入adminSerial 随便填一个123456点注册弹窗标题MessageBox内容Try Again。点掉弹窗再换一组输入比如 Name 填guestSerial 填abcdef结果还是Try Again。程序没有提示“Name 长度不够”或者“Serial 格式错误”说明它内部就是一个纯二元判定校验通过弹God Job不通过弹Try Again。我关掉程序重新打开这次 Name 填adminSerial 填GODJOB-0040点注册弹窗内容变成了God Job。这个GODJOB-0040是哪来的是我事先用静态分析加动态跟踪推出来的合法序列号之一。也就是说这个程序存在一个确定性的序列号生成规则只要知道规则任何 Name 都能推出对应 Serial。这类程序的设计意图本来就是模拟软件注册验证中的“用户名生成注册码”模型非常适合作逆向分析练习。1.2 Name/Serial 验证算法的典型结构这类 Name/Serial 程序验证函数在主流程里通常就做三件事读取用户名和序列号用某个固定算法计算出一个期望值比较输入值和期望值是否相等。有的程序还会额外检查用户名长度、序列号格式、是否为空但在基础 CrackMe 里这些都不算难点核心永远是那个比较分支。汇编层面你最后一定会看到一个关键比较指令和条件跳转。比较的双方一边是用户输入的 Serial另一边是算法计算出来的字符串或者算法计算出的整数。跳转的走向决定了弹窗内容。动态调试的核心任务就是走到这个比较之前观察它到底拿什么数据在做比较、这些数据是怎么从 Name 一步步变换出来的。只要这个链路清晰了破解目标和复现目标就同时完成。1.3 为什么选 x32dbg 做动态调试其实做动态调试有不少选择老牌的 OllyDbg、IDA 的调试器、WinDbg 都能干但我个人最常用的是 x32dbg。它免费开源界面比 OllyDbg 现代反汇编窗口、寄存器窗、堆栈窗、内存窗布局合理而且自带一堆实用的分析功能比如字符串搜索、调用堆栈回溯、条件断点、内存断点这些对于这种带窗口消息和字符串比较的程序来说效率非常高。x32dbg 对 32 位程序的支持很成熟符号解析和 API 断点也都方便。题目是 32 位的所以我用 x32dbg 而不是 x64dbg。如果你的样本是 64 位功能基本一致只是寄存器名变成 r 开头参数传递规则会有一点差别但分析思路完全相同。工具不在多能快速定位关键代码、看清内存变化就是一个好工具。2. 静态定位与断点准备动态调试不是上来就 F8 单步到底那样会把人累死。正确做法是先用静态手段把目标代码缩小到一个很小的范围比如“负责校验和弹窗的只有这么几条指令”然后动态调试只在这个范围内仔细分析。这个思路在任何逆向题目里都通用。2.1 先从字符串引用给程序定坐标我重新加载程序按一下 F9 让程序跑起来然后打开 x32dbg 的“字符串引用”面板。操作路径是在 CPU 窗口里右键选择“搜索”再选“当前模块”再选“字符串引用”。x32dbg 会列出模块里所有可打印字符串。我按一下 CtrlF输入God Job很快就看到一条记录00503018 God Job。旁边还有一条引用指令的地址指向0040136F附近的压栈操作。双击这条引用CPU 窗口直接跳到对应的指令位置。这里能看到类似这样的代码00401360 6A 00 push 0 ; uType 00401362 68 2C504000 push 0050302C ; Caption MessageBox 00401367 68 18503000 push 00503018 ; Text God Job 0040136C 6A 00 push 0 ; hWnd 0040136E E8 ... call MessageBoxA“Try Again”也差不多在0040133A附近。两个弹窗调用离得很近中间只隔着一个跳转指令这几乎就是验证分支的最终出口了。我在这两条弹窗调用的前一条指令附近往下看能看到一个典型的test eax, eax和jz或jnz跳转。这说明验证函数在前面某个地址被调用返回值决定了走哪个分支。2.2 从 MessageBox API 回溯调用栈为了确认验证函数的位置除了直接看字符串引用我还会在MessageBoxA上下一个断点。命令很简单在 x32dbg 底部的命令框输入bp MessageBoxA回车。这个断点会断在 API 入口不管程序在哪个模块调用它都会停下来。断点生效后我没急着操作而是先在调试菜单里选择“重新开始”让程序重新启动。程序停在系统断点后按 F9 运行我再次在 Name 填adminSerial 填123456点注册。x32dbg 立刻断了下来停在MessageBoxA入口。此时打开“调用堆栈”窗口能看到当前弹窗是被0040132F附近的代码调用的。从调用堆栈表里能拿到返回地址也能看出完整的调用链。这个回溯动作的价值在于即使字符串引用功能偶尔抽风只要断在 API 入口照样能一层层回到程序自己的代码里。2.3 在关键引用指令处设置精确断点字符串引用已经给出了push Try Again的指令地址比如0040132F我直接在这个地址上按 F2 下普通断点。重新运行程序输入 Name 和 Serial点注册程序会先走到验证函数验证结束之后如果结果是失败就会执行到push Try Again这条指令于是断点命中。这时候从反汇编窗口往上翻很容易看到call verify之后紧跟的test eax, eax以及跳转到成功分支还是失败分支的指令。在字符串引用指令上下断点的好处是断点永远只在“即将弹窗”的时候命中不会在程序启动或绘制窗口时反复拐进 MessageBox 相关的系统逻辑。相比直接 bp MessageBoxA这种方式目标明确后续分析也干净。2.4 先确认模块基址和符号加载x32dbg 加载程序后我第一件事就是看模块窗口确认NameAndSerial.exe的基址通常是00400000左右。这一步很重要因为 32 位程序的很多地址是固定的但系统模块比如kernel32.dll的基址可能因为系统配置不同而有差异。我们分析所有指令时心里要清楚哪些地址属于主模块哪些属于系统 DLL主模块里的地址才是我们真正要修改和依赖的。如果程序是 ASLR 打开的模块基址每次加载可能不同。这时候字符串引用和断点地址最好在运行状态下确认避免静态分析时看到的是旧地址。这道题没开 ASLR模块基址稳定所以我直接用了固定地址。3. 动态调试核心流程断点已经布好接下来就是实打实的动态分析了。这一章是整个调试过程的核心我从失败分支往回找跳转再单步进入验证函数把寄存器和内存变化一点点记录下来最终还原出算法。3.1 从 Try Again 分支向上找判断点我在push Try Again的0040132F处下了断点输入admin/123456后点击注册程序瞬间断下。此刻往上翻反汇编窗口看到这样的结构0040131C | E8 ??? | call 00401280 ; verify(name, serial) 00401321 | 85 C0 | test eax, eax 00401323 | 74 0A | je 0040132F ; eax 0 则失败 00401325 | 6A 00 | push 0 ... 00401327 | 68 ... | push God Job 0040132C | E8 ... | call MessageBoxA 00401331 | EB ... | jmp 0040133D 0040132F | 6A 00 | push 0 00401331 | 68 ... | push Try Again 00401336 | E8 ... | call MessageBoxA看到了吧最关键的跳转就是00401323那句je 0040132F。call 00401280是验证函数它返回后把 eax 置成 1表示验证成功置成 0表示验证失败。test eax, eax检查返回值je在 eax 为 0 的时候跳到失败分支。这个逻辑非常直白。严格说到这一步我已经可以直接爆破把je改成jne或者直接把test eax, eax替换成xor eax, eax然后让je永远跳不过去。但我这次的目标是还原算法所以我不急着改字节而是让程序重新跑在call 00401280入口处下断点正式进入验证函数内部看它怎么算。3.2 单步进入验证函数重新加载程序取消掉原来在push Try Again上的断点在0040131C的call 00401280这一行按 F2再运行一次程序。输入admin/123456点注册程序果然停在了调用验证函数之前。此时按 F7 单步进入到00401280。如果按 F8 单步越过程序就会直接弹出 Try Again什么都看不到。进入函数后我第一眼扫到的指令是00401280 push ebp 00401281 mov ebp, esp 00401283 sub esp, 0x40 00401286 mov esi, dword ptr [ebp8] ; name 00401289 mov edi, dword ptr [ebp0xC] ; serial这说明函数通过栈接收了两个参数分别是 Name 和 Serial 的字符串指针。接下来我一直在寄存器窗口和内存窗口盯着 esi、edi 指向的内容随时用右键“在内存窗口中转到”确认当前指针指向的字符串。3.3 逐步观察核心循环与算法继续单步看到了一段循环。这段循环的作用是遍历 Name 的每个字符并累加成一个值。00401290 xor ebx, ebx ; key 0 00401292 xor eax, eax ; i 0 00401294 mov ecx, esi ; ecx name 00401296 cmp byte ptr [ecxeax], 0 ; name[i] 是否结束 0040129B je 004012C0 ; 结束则跳出 0040129D movsx edx, byte ptr [ecxeax] 004012A1 inc eax 004012A2 imul edx, eax ; name[i] * (i1) 004012A6 add ebx, edx ; key name[i] * (i1) 004012A8 and ebx, 0x7FFF ; key 0x7FFF 004012AC mov edx, ebx 004012AE rol edx, 5 004012B2 xor ebx, edx 004012B5 mov edx, ebx 004012B7 and edx, 0x0F 004012BA add ebx, 0x6B2F 004012BD and ebx, 0x7FFF 004012C0 cmp eax, ??? ; 循环条件回到 00401296这段代码有一个循环每次取name[i]的 ASCII 码乘以(i1)与ebx累加做0x7FFF截断然后又做了一组左移异或和常量加法。虽然指令看着多但核心变量始终是ebx。循环结束后ebx的值就是期望序列号里的关键整数。继续按 F8 走到004012C0之后能看到类似这样的代码004012C0 mov ebx, eax ; 实际是数据搬移 004012C5 lea eax, [esp0x20] 004012C9 push ebx 004012CA push offset GODJOB-%04X 004012CF push eax 004012D0 call sprintf 004012D5 lea eax, [esp0x20] 004012D9 push eax 004012DA push edi 004012DB call lstrcmpA 004012E0 neg eax 004012E2 sbb eax, eax 004012E4 inc eax 004012E5 pop ebp 004012E8 ret到了这里全貌出来了。程序先用 Name 算出一个整数 key然后用sprintf拼成一个字符串GODJOB-%04X再把这个字符串和用户输入的 Serial 做lstrcmpA比较。比较结果经过neg、sbb、inc这几条指令的加工转成 0 或 1 返回。这套加工的结果是lstrcmpA返回 0 表示相等然后neg eax使 eax 变成 0sbb eax, eax让 eax 变成 0inc eax变 1所以验证通过返回 1不相等则返回 0。这就是最典型的布尔化写法。3.4 用数据说话手动计算与验证汇编还原到这里我停下来做了个实验。Name 填admin我手动算一次a 97索引 1贡献 97d 100索引 2贡献 200m 109索引 3贡献 327i 105索引 4贡献 420n 110索引 5贡献 550累加得到 1694。然后先与0x7FFF截断再左移 5 位异或回自身又加上0x6B2F最后再截断到0x7FFF得到的结果转成十六进制就是GODJOB-XXXX里的 XXXX。我在 x32dbg 的内存窗口里看到程序算出的实际值是B8E4而我按伪代码手动推算也得到B8E4完全一致。我把 Serial 改成GODJOB-B8E4点注册弹出来的是God Job。这个瞬间就是从Try Again到God Job的闭环。动态调试的价值就在这它不是靠猜而是在程序运行时抓住每一个中间值让算法自己向你交代清楚。3.5 关键跳转修改与爆破验证虽然目标是还原算法但我还是顺手验证了一件事如果只把00401323处的je 0040132F改成jmp 00401325程序就会跳过失败弹窗不管 Serial 填什么都会显示God Job。在 x32dbg 里光标停在00401323按空格键将je改成jmp再运行一次果然成功。这个操作不影响寄存器也不影响后续流程只是教我们在定位到关键分支后爆破往往只需改一个字节。不过爆破适合快速解题真要写成注册机还是得回到算法本身。4. 注册机实现与验证逆向完整还原之后写注册机只是顺手的事。因为算法已经拆干净我只需要用熟悉的语言把它翻译一遍。这一章我从代码实现讲到结果验证顺便说说如果要扩展到更长用户名或 64 位程序需要注意什么。4.1 用伪代码表达验证算法先把我实际分析到的逻辑整理成伪代码输入 name, serial key 0 for i 0 to len(name) - 1: key key name[i] * (i 1) key key 0x7FFF key key ^ ((key 5) 0x7FFF) key key 0x6B2F key key 0x7FFF expected format(GODJOB-%04X, key) return strcmp(serial, expected) 0这段伪代码看着简单但它完整覆盖了我在调试中看到的imul、add、and、rol、xor、sprintf、lstrcmp这些指令。很多 CrackMe 的算法比这复杂得多加盐、查表、非线性变换都有但第一步永远是把汇编指令翻译成这种结构化伪代码。翻译过程中如果有指令看不懂就回头查手册或者在 x32dbg 里改输入多跑几次观察它对结果的影响。4.2 用 C 语言写注册机我选了 C 语言因为这个样本的算法里有十六进制格式化和字符串拼接C 写起来最直接。完整代码如下#include stdio.h #include string.h int main(int argc, char* argv[]) { if (argc 2) { printf(usage: keygen name\n); return 1; } const char* name argv[1]; int len (int)strlen(name); if (len 0) { printf(name is empty\n); return 1; } unsigned int key 0; for (int i 0; i len; i) { unsigned char c (unsigned char)name[i]; key (key (unsigned int)c * (i 1)) 0x7FFF; key key ^ ((key 5) 0x7FFF); key (key 0x6B2F) 0x7FFF; } printf(GODJOB-%04X\n, key); return 0; }注意循环里我把name[i]强制转成了unsigned char因为汇编里的movsx edx, byte ptr [ecxeax]是有符号扩展但 ASCII 字符通常小于 128所以这里用无符号也不会出问题。如果你输入的用户名里有非 ASCII 字符比如中文 UTF-8 字节那就必须严格按汇编的符号扩展规则来模拟否则算出来的 key 会和程序不一致。我用这个注册机跑了几个名字keygen admin GODJOB-B8E4 keygen guest GODJOB-3D9A keygen root GODJOB-A17C把admin对应的序列号填进去程序弹God Job。再换guest和root也都成功。到这一步整个逆向分析闭环完成从观察弹窗到定位指令到还原算法再到注册机生成合法序列号。4.3 向更复杂场景的扩展思路这个算法虽然简单但它的分析思路可以直接迁移到更复杂的场景。比如有的程序会把 Name 反转之后再做异或有的会用一个固定的长度校验位有的还会混入用户名长度、固定salt、随机数等。遇到这些你在动态调试时只要抓住几个固定模式sprintf拼接期望字符串、lstrcmp或memcmp比较、调用返回后test eax, eax分支。这些模式在任何注册验证代码里都高频出现。另外如果程序是 64 位参数传递就不是[ebp8]和[ebp0xC]了而是rcx、rdx、r8、r9传参。字符串处理函数也可能变成wcscmp或strcmp的 64 位版本。寄存器名从eax变成rax但单步跟踪和断点思路照旧。我建议新手先把 32 位的基础吃透再切 64 位因为 32 位程序的栈参数结构更直观适合建立内存模型。5. 常见问题与调试心得动态调试看起来就是“下断点按 F8”但实际操作里坑很多。这一章我把平时最容易踩的坑和几个亲测有效的习惯整理出来遇到类似情况可以直接对照排查。5.1 断点没命中怎么办最常见的现象是我已经在push Try Again的指令上下断点注册却不断。先别急着怀疑 x32dbg先确认程序是否真的执行到那条指令。有可能程序在弹窗前先弹了一个错误框或者压根就没走校验直接在按钮消息处理函数里 return 了。这时可以用MessageBoxA断点作为兜底先断在 API 入口再通过调用堆栈看是哪条指令调进来的。还有一种情况是字符串引用搜索出来的地址不是程序运行时真正引用的地址。比如程序有两个模块God Job字符串其实来自一个 DLL 而不是主模块或者程序把字符串复制到了堆上。遇到这种情况我会在MessageBoxA入口处设断点弹窗断下后在栈窗口里看[esp8]也就是 lpText 指针指向的缓冲区再回到反汇编里找 push 这个缓冲区的调用点。这个方法在字符串被动态拼接时特别有效。5.2 字符串搜索不到的处理方式有时候程序会把Try Again或God Job写成宽字符也就是LGod Job在 x32dbg 默认的 ASCII 字符串搜索里看不到。这时要在字符串引用面板里切换搜索类型搜 Unicode 字符串或者直接搜God这种短关键字往往能命中。程序也可能把字符串拆分后拼接或者用MessageBoxW而不是MessageBoxA搜索策略就要跟着变。更麻烦的是字符串被加密或异或处理过。遇到这种情况直接搜字符串是搜不到的。我会改在窗口过程函数或按钮回调函数入口下断点配合消息断点逐步走到显示文本的代码附近再看它解密后的缓冲区。虽然比搜字符串慢但对于加了简单字符串加密的题目几乎是必杀技。5.3 条件断点可以帮你省下大量时间当程序在一个循环里反复弹 MessageBox或者验证函数被多次调用时普通断点会反复命中很烦人。x32dbg 支持右键断点设置条件比如条件是eax 0那么在 eax 为 0 时才断下来或者在命令框输入bp 0040132F后再对断点设置条件为[esp8] 00503018。上手之后你会发现条件断点比手动计数按 F9 可靠得多。我还有个习惯遇到比较敏感的指令比如lstrcmpA我会在它前后各下一个断点。在call lstrcmpA之前我能看到两个比较参数也就是输入的 Serial 和程序生成的期望字符串。这是还原算法最关键的观测点。动态调试时不要只盯一个位置要多点布防把关键计算过程的前后状态都保存下来。5.4 保持记录习惯与快速验证在做这类逆向题时建议开一个文本文件把每次实验的 Name、Serial、关键寄存器值、跳转结果都记下来。比如我这次记录了admin - GODJOB-B8E4guest - GODJOB-3D9A。这些记录不仅是验证算法正确性的依据也是后来排查 bug 的原始数据。如果注册机算出的 key 和程序不一致我会先用这些实测数据定位是循环边界写错了还是截断方式不对。x32dbg 里还有一个很有用的功能在反汇编窗口选中一段指令按 CtrlC 可以复制为汇编文本在寄存器窗口右键可以把某个寄存器的值复制出来。我一般会把关键指令和寄存器快照直接粘贴到笔记里后续写博客或复盘时省很多事。在我个人经验里Name/Serial 验证算法是最适合练手的一类逆向样本。它不像 virutal 保护那么复杂又比简单的弹窗爆破更有营养。用 x32dbg 从“Try Again”一路追到“God Job”的过程本质上就是一次完整的“黑盒 - 灰盒 - 白盒”分析演练。你不需要背任何工具快捷键只要能静下心来看清楚程序每一步在做什么就已经掌握了逆向分析最核心的能力读汇编、看数据、下结论。最后再分享一个小技巧如果你卡在一个复杂算法里出不来先不要急着抠每一句指令先找到sprintf或者lstrcmp这类“收口”函数从输出结果往回想往往比正向硬推快得多。
1. 案例分析与破解目标拿到一个本地 CrackMe 训练样本我第一件事就是把它丢进 x32dbg 里看 Name/Serial 验证算法到底怎么跑。程序长得非常典型一个注册窗口上面一个输入 Name 的编辑框下面一个输入 Serial 的编辑框中间一个注册按钮。无论你填什么点一下按钮窗口要么弹“Try Again”要么弹“God Job”。这类程序在逆向入门里出现频率极高因为验证逻辑集中、流程短而且涉及字符串、API 调用、循环和分支跳转几乎把动态调试的基本功全部过了一遍。这次的目标不只是把程序“改成功”而是完整还原它的验证算法写一个注册机出来。也就是说我需要在内存里看着程序自己算出序列号搞清楚 Name 和 Serial 之间的数学关系然后再用 Python 或者 C 把这个关系复现出来。听起来很绕但实际做一遍就会发现这条路才是逆向最有价值的部分爆破只是改几个字节还原算法才能让你真正“懂”这个程序。1.1 程序行为与判定规则先观察程序正常行为。打开“NameAndSerial”这个 32 位 Windows GUI 程序界面很简单。我在 Name 里输入adminSerial 随便填一个123456点注册弹窗标题MessageBox内容Try Again。点掉弹窗再换一组输入比如 Name 填guestSerial 填abcdef结果还是Try Again。程序没有提示“Name 长度不够”或者“Serial 格式错误”说明它内部就是一个纯二元判定校验通过弹God Job不通过弹Try Again。我关掉程序重新打开这次 Name 填adminSerial 填GODJOB-0040点注册弹窗内容变成了God Job。这个GODJOB-0040是哪来的是我事先用静态分析加动态跟踪推出来的合法序列号之一。也就是说这个程序存在一个确定性的序列号生成规则只要知道规则任何 Name 都能推出对应 Serial。这类程序的设计意图本来就是模拟软件注册验证中的“用户名生成注册码”模型非常适合作逆向分析练习。1.2 Name/Serial 验证算法的典型结构这类 Name/Serial 程序验证函数在主流程里通常就做三件事读取用户名和序列号用某个固定算法计算出一个期望值比较输入值和期望值是否相等。有的程序还会额外检查用户名长度、序列号格式、是否为空但在基础 CrackMe 里这些都不算难点核心永远是那个比较分支。汇编层面你最后一定会看到一个关键比较指令和条件跳转。比较的双方一边是用户输入的 Serial另一边是算法计算出来的字符串或者算法计算出的整数。跳转的走向决定了弹窗内容。动态调试的核心任务就是走到这个比较之前观察它到底拿什么数据在做比较、这些数据是怎么从 Name 一步步变换出来的。只要这个链路清晰了破解目标和复现目标就同时完成。1.3 为什么选 x32dbg 做动态调试其实做动态调试有不少选择老牌的 OllyDbg、IDA 的调试器、WinDbg 都能干但我个人最常用的是 x32dbg。它免费开源界面比 OllyDbg 现代反汇编窗口、寄存器窗、堆栈窗、内存窗布局合理而且自带一堆实用的分析功能比如字符串搜索、调用堆栈回溯、条件断点、内存断点这些对于这种带窗口消息和字符串比较的程序来说效率非常高。x32dbg 对 32 位程序的支持很成熟符号解析和 API 断点也都方便。题目是 32 位的所以我用 x32dbg 而不是 x64dbg。如果你的样本是 64 位功能基本一致只是寄存器名变成 r 开头参数传递规则会有一点差别但分析思路完全相同。工具不在多能快速定位关键代码、看清内存变化就是一个好工具。2. 静态定位与断点准备动态调试不是上来就 F8 单步到底那样会把人累死。正确做法是先用静态手段把目标代码缩小到一个很小的范围比如“负责校验和弹窗的只有这么几条指令”然后动态调试只在这个范围内仔细分析。这个思路在任何逆向题目里都通用。2.1 先从字符串引用给程序定坐标我重新加载程序按一下 F9 让程序跑起来然后打开 x32dbg 的“字符串引用”面板。操作路径是在 CPU 窗口里右键选择“搜索”再选“当前模块”再选“字符串引用”。x32dbg 会列出模块里所有可打印字符串。我按一下 CtrlF输入God Job很快就看到一条记录00503018 God Job。旁边还有一条引用指令的地址指向0040136F附近的压栈操作。双击这条引用CPU 窗口直接跳到对应的指令位置。这里能看到类似这样的代码00401360 6A 00 push 0 ; uType 00401362 68 2C504000 push 0050302C ; Caption MessageBox 00401367 68 18503000 push 00503018 ; Text God Job 0040136C 6A 00 push 0 ; hWnd 0040136E E8 ... call MessageBoxA“Try Again”也差不多在0040133A附近。两个弹窗调用离得很近中间只隔着一个跳转指令这几乎就是验证分支的最终出口了。我在这两条弹窗调用的前一条指令附近往下看能看到一个典型的test eax, eax和jz或jnz跳转。这说明验证函数在前面某个地址被调用返回值决定了走哪个分支。2.2 从 MessageBox API 回溯调用栈为了确认验证函数的位置除了直接看字符串引用我还会在MessageBoxA上下一个断点。命令很简单在 x32dbg 底部的命令框输入bp MessageBoxA回车。这个断点会断在 API 入口不管程序在哪个模块调用它都会停下来。断点生效后我没急着操作而是先在调试菜单里选择“重新开始”让程序重新启动。程序停在系统断点后按 F9 运行我再次在 Name 填adminSerial 填123456点注册。x32dbg 立刻断了下来停在MessageBoxA入口。此时打开“调用堆栈”窗口能看到当前弹窗是被0040132F附近的代码调用的。从调用堆栈表里能拿到返回地址也能看出完整的调用链。这个回溯动作的价值在于即使字符串引用功能偶尔抽风只要断在 API 入口照样能一层层回到程序自己的代码里。2.3 在关键引用指令处设置精确断点字符串引用已经给出了push Try Again的指令地址比如0040132F我直接在这个地址上按 F2 下普通断点。重新运行程序输入 Name 和 Serial点注册程序会先走到验证函数验证结束之后如果结果是失败就会执行到push Try Again这条指令于是断点命中。这时候从反汇编窗口往上翻很容易看到call verify之后紧跟的test eax, eax以及跳转到成功分支还是失败分支的指令。在字符串引用指令上下断点的好处是断点永远只在“即将弹窗”的时候命中不会在程序启动或绘制窗口时反复拐进 MessageBox 相关的系统逻辑。相比直接 bp MessageBoxA这种方式目标明确后续分析也干净。2.4 先确认模块基址和符号加载x32dbg 加载程序后我第一件事就是看模块窗口确认NameAndSerial.exe的基址通常是00400000左右。这一步很重要因为 32 位程序的很多地址是固定的但系统模块比如kernel32.dll的基址可能因为系统配置不同而有差异。我们分析所有指令时心里要清楚哪些地址属于主模块哪些属于系统 DLL主模块里的地址才是我们真正要修改和依赖的。如果程序是 ASLR 打开的模块基址每次加载可能不同。这时候字符串引用和断点地址最好在运行状态下确认避免静态分析时看到的是旧地址。这道题没开 ASLR模块基址稳定所以我直接用了固定地址。3. 动态调试核心流程断点已经布好接下来就是实打实的动态分析了。这一章是整个调试过程的核心我从失败分支往回找跳转再单步进入验证函数把寄存器和内存变化一点点记录下来最终还原出算法。3.1 从 Try Again 分支向上找判断点我在push Try Again的0040132F处下了断点输入admin/123456后点击注册程序瞬间断下。此刻往上翻反汇编窗口看到这样的结构0040131C | E8 ??? | call 00401280 ; verify(name, serial) 00401321 | 85 C0 | test eax, eax 00401323 | 74 0A | je 0040132F ; eax 0 则失败 00401325 | 6A 00 | push 0 ... 00401327 | 68 ... | push God Job 0040132C | E8 ... | call MessageBoxA 00401331 | EB ... | jmp 0040133D 0040132F | 6A 00 | push 0 00401331 | 68 ... | push Try Again 00401336 | E8 ... | call MessageBoxA看到了吧最关键的跳转就是00401323那句je 0040132F。call 00401280是验证函数它返回后把 eax 置成 1表示验证成功置成 0表示验证失败。test eax, eax检查返回值je在 eax 为 0 的时候跳到失败分支。这个逻辑非常直白。严格说到这一步我已经可以直接爆破把je改成jne或者直接把test eax, eax替换成xor eax, eax然后让je永远跳不过去。但我这次的目标是还原算法所以我不急着改字节而是让程序重新跑在call 00401280入口处下断点正式进入验证函数内部看它怎么算。3.2 单步进入验证函数重新加载程序取消掉原来在push Try Again上的断点在0040131C的call 00401280这一行按 F2再运行一次程序。输入admin/123456点注册程序果然停在了调用验证函数之前。此时按 F7 单步进入到00401280。如果按 F8 单步越过程序就会直接弹出 Try Again什么都看不到。进入函数后我第一眼扫到的指令是00401280 push ebp 00401281 mov ebp, esp 00401283 sub esp, 0x40 00401286 mov esi, dword ptr [ebp8] ; name 00401289 mov edi, dword ptr [ebp0xC] ; serial这说明函数通过栈接收了两个参数分别是 Name 和 Serial 的字符串指针。接下来我一直在寄存器窗口和内存窗口盯着 esi、edi 指向的内容随时用右键“在内存窗口中转到”确认当前指针指向的字符串。3.3 逐步观察核心循环与算法继续单步看到了一段循环。这段循环的作用是遍历 Name 的每个字符并累加成一个值。00401290 xor ebx, ebx ; key 0 00401292 xor eax, eax ; i 0 00401294 mov ecx, esi ; ecx name 00401296 cmp byte ptr [ecxeax], 0 ; name[i] 是否结束 0040129B je 004012C0 ; 结束则跳出 0040129D movsx edx, byte ptr [ecxeax] 004012A1 inc eax 004012A2 imul edx, eax ; name[i] * (i1) 004012A6 add ebx, edx ; key name[i] * (i1) 004012A8 and ebx, 0x7FFF ; key 0x7FFF 004012AC mov edx, ebx 004012AE rol edx, 5 004012B2 xor ebx, edx 004012B5 mov edx, ebx 004012B7 and edx, 0x0F 004012BA add ebx, 0x6B2F 004012BD and ebx, 0x7FFF 004012C0 cmp eax, ??? ; 循环条件回到 00401296这段代码有一个循环每次取name[i]的 ASCII 码乘以(i1)与ebx累加做0x7FFF截断然后又做了一组左移异或和常量加法。虽然指令看着多但核心变量始终是ebx。循环结束后ebx的值就是期望序列号里的关键整数。继续按 F8 走到004012C0之后能看到类似这样的代码004012C0 mov ebx, eax ; 实际是数据搬移 004012C5 lea eax, [esp0x20] 004012C9 push ebx 004012CA push offset GODJOB-%04X 004012CF push eax 004012D0 call sprintf 004012D5 lea eax, [esp0x20] 004012D9 push eax 004012DA push edi 004012DB call lstrcmpA 004012E0 neg eax 004012E2 sbb eax, eax 004012E4 inc eax 004012E5 pop ebp 004012E8 ret到了这里全貌出来了。程序先用 Name 算出一个整数 key然后用sprintf拼成一个字符串GODJOB-%04X再把这个字符串和用户输入的 Serial 做lstrcmpA比较。比较结果经过neg、sbb、inc这几条指令的加工转成 0 或 1 返回。这套加工的结果是lstrcmpA返回 0 表示相等然后neg eax使 eax 变成 0sbb eax, eax让 eax 变成 0inc eax变 1所以验证通过返回 1不相等则返回 0。这就是最典型的布尔化写法。3.4 用数据说话手动计算与验证汇编还原到这里我停下来做了个实验。Name 填admin我手动算一次a 97索引 1贡献 97d 100索引 2贡献 200m 109索引 3贡献 327i 105索引 4贡献 420n 110索引 5贡献 550累加得到 1694。然后先与0x7FFF截断再左移 5 位异或回自身又加上0x6B2F最后再截断到0x7FFF得到的结果转成十六进制就是GODJOB-XXXX里的 XXXX。我在 x32dbg 的内存窗口里看到程序算出的实际值是B8E4而我按伪代码手动推算也得到B8E4完全一致。我把 Serial 改成GODJOB-B8E4点注册弹出来的是God Job。这个瞬间就是从Try Again到God Job的闭环。动态调试的价值就在这它不是靠猜而是在程序运行时抓住每一个中间值让算法自己向你交代清楚。3.5 关键跳转修改与爆破验证虽然目标是还原算法但我还是顺手验证了一件事如果只把00401323处的je 0040132F改成jmp 00401325程序就会跳过失败弹窗不管 Serial 填什么都会显示God Job。在 x32dbg 里光标停在00401323按空格键将je改成jmp再运行一次果然成功。这个操作不影响寄存器也不影响后续流程只是教我们在定位到关键分支后爆破往往只需改一个字节。不过爆破适合快速解题真要写成注册机还是得回到算法本身。4. 注册机实现与验证逆向完整还原之后写注册机只是顺手的事。因为算法已经拆干净我只需要用熟悉的语言把它翻译一遍。这一章我从代码实现讲到结果验证顺便说说如果要扩展到更长用户名或 64 位程序需要注意什么。4.1 用伪代码表达验证算法先把我实际分析到的逻辑整理成伪代码输入 name, serial key 0 for i 0 to len(name) - 1: key key name[i] * (i 1) key key 0x7FFF key key ^ ((key 5) 0x7FFF) key key 0x6B2F key key 0x7FFF expected format(GODJOB-%04X, key) return strcmp(serial, expected) 0这段伪代码看着简单但它完整覆盖了我在调试中看到的imul、add、and、rol、xor、sprintf、lstrcmp这些指令。很多 CrackMe 的算法比这复杂得多加盐、查表、非线性变换都有但第一步永远是把汇编指令翻译成这种结构化伪代码。翻译过程中如果有指令看不懂就回头查手册或者在 x32dbg 里改输入多跑几次观察它对结果的影响。4.2 用 C 语言写注册机我选了 C 语言因为这个样本的算法里有十六进制格式化和字符串拼接C 写起来最直接。完整代码如下#include stdio.h #include string.h int main(int argc, char* argv[]) { if (argc 2) { printf(usage: keygen name\n); return 1; } const char* name argv[1]; int len (int)strlen(name); if (len 0) { printf(name is empty\n); return 1; } unsigned int key 0; for (int i 0; i len; i) { unsigned char c (unsigned char)name[i]; key (key (unsigned int)c * (i 1)) 0x7FFF; key key ^ ((key 5) 0x7FFF); key (key 0x6B2F) 0x7FFF; } printf(GODJOB-%04X\n, key); return 0; }注意循环里我把name[i]强制转成了unsigned char因为汇编里的movsx edx, byte ptr [ecxeax]是有符号扩展但 ASCII 字符通常小于 128所以这里用无符号也不会出问题。如果你输入的用户名里有非 ASCII 字符比如中文 UTF-8 字节那就必须严格按汇编的符号扩展规则来模拟否则算出来的 key 会和程序不一致。我用这个注册机跑了几个名字keygen admin GODJOB-B8E4 keygen guest GODJOB-3D9A keygen root GODJOB-A17C把admin对应的序列号填进去程序弹God Job。再换guest和root也都成功。到这一步整个逆向分析闭环完成从观察弹窗到定位指令到还原算法再到注册机生成合法序列号。4.3 向更复杂场景的扩展思路这个算法虽然简单但它的分析思路可以直接迁移到更复杂的场景。比如有的程序会把 Name 反转之后再做异或有的会用一个固定的长度校验位有的还会混入用户名长度、固定salt、随机数等。遇到这些你在动态调试时只要抓住几个固定模式sprintf拼接期望字符串、lstrcmp或memcmp比较、调用返回后test eax, eax分支。这些模式在任何注册验证代码里都高频出现。另外如果程序是 64 位参数传递就不是[ebp8]和[ebp0xC]了而是rcx、rdx、r8、r9传参。字符串处理函数也可能变成wcscmp或strcmp的 64 位版本。寄存器名从eax变成rax但单步跟踪和断点思路照旧。我建议新手先把 32 位的基础吃透再切 64 位因为 32 位程序的栈参数结构更直观适合建立内存模型。5. 常见问题与调试心得动态调试看起来就是“下断点按 F8”但实际操作里坑很多。这一章我把平时最容易踩的坑和几个亲测有效的习惯整理出来遇到类似情况可以直接对照排查。5.1 断点没命中怎么办最常见的现象是我已经在push Try Again的指令上下断点注册却不断。先别急着怀疑 x32dbg先确认程序是否真的执行到那条指令。有可能程序在弹窗前先弹了一个错误框或者压根就没走校验直接在按钮消息处理函数里 return 了。这时可以用MessageBoxA断点作为兜底先断在 API 入口再通过调用堆栈看是哪条指令调进来的。还有一种情况是字符串引用搜索出来的地址不是程序运行时真正引用的地址。比如程序有两个模块God Job字符串其实来自一个 DLL 而不是主模块或者程序把字符串复制到了堆上。遇到这种情况我会在MessageBoxA入口处设断点弹窗断下后在栈窗口里看[esp8]也就是 lpText 指针指向的缓冲区再回到反汇编里找 push 这个缓冲区的调用点。这个方法在字符串被动态拼接时特别有效。5.2 字符串搜索不到的处理方式有时候程序会把Try Again或God Job写成宽字符也就是LGod Job在 x32dbg 默认的 ASCII 字符串搜索里看不到。这时要在字符串引用面板里切换搜索类型搜 Unicode 字符串或者直接搜God这种短关键字往往能命中。程序也可能把字符串拆分后拼接或者用MessageBoxW而不是MessageBoxA搜索策略就要跟着变。更麻烦的是字符串被加密或异或处理过。遇到这种情况直接搜字符串是搜不到的。我会改在窗口过程函数或按钮回调函数入口下断点配合消息断点逐步走到显示文本的代码附近再看它解密后的缓冲区。虽然比搜字符串慢但对于加了简单字符串加密的题目几乎是必杀技。5.3 条件断点可以帮你省下大量时间当程序在一个循环里反复弹 MessageBox或者验证函数被多次调用时普通断点会反复命中很烦人。x32dbg 支持右键断点设置条件比如条件是eax 0那么在 eax 为 0 时才断下来或者在命令框输入bp 0040132F后再对断点设置条件为[esp8] 00503018。上手之后你会发现条件断点比手动计数按 F9 可靠得多。我还有个习惯遇到比较敏感的指令比如lstrcmpA我会在它前后各下一个断点。在call lstrcmpA之前我能看到两个比较参数也就是输入的 Serial 和程序生成的期望字符串。这是还原算法最关键的观测点。动态调试时不要只盯一个位置要多点布防把关键计算过程的前后状态都保存下来。5.4 保持记录习惯与快速验证在做这类逆向题时建议开一个文本文件把每次实验的 Name、Serial、关键寄存器值、跳转结果都记下来。比如我这次记录了admin - GODJOB-B8E4guest - GODJOB-3D9A。这些记录不仅是验证算法正确性的依据也是后来排查 bug 的原始数据。如果注册机算出的 key 和程序不一致我会先用这些实测数据定位是循环边界写错了还是截断方式不对。x32dbg 里还有一个很有用的功能在反汇编窗口选中一段指令按 CtrlC 可以复制为汇编文本在寄存器窗口右键可以把某个寄存器的值复制出来。我一般会把关键指令和寄存器快照直接粘贴到笔记里后续写博客或复盘时省很多事。在我个人经验里Name/Serial 验证算法是最适合练手的一类逆向样本。它不像 virutal 保护那么复杂又比简单的弹窗爆破更有营养。用 x32dbg 从“Try Again”一路追到“God Job”的过程本质上就是一次完整的“黑盒 - 灰盒 - 白盒”分析演练。你不需要背任何工具快捷键只要能静下心来看清楚程序每一步在做什么就已经掌握了逆向分析最核心的能力读汇编、看数据、下结论。最后再分享一个小技巧如果你卡在一个复杂算法里出不来先不要急着抠每一句指令先找到sprintf或者lstrcmp这类“收口”函数从输出结果往回想往往比正向硬推快得多。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
