从CrackMe入门逆向工程：figugegl系列算法分析与注册机编写实战

1. 逆向分析项目概述与核心目标

最近在逆向分析的学习圈里，一个名为“figugegl”的系列程序（通常指代figugegl.1.exe和figugegl.2.exe）成了不少新手入门和进阶练习的热门目标。这其实是一个经典的CrackMe挑战，所谓CrackMe，就是程序员故意编写的一些小程序，目的是让逆向爱好者在不破坏程序功能的前提下，通过分析找到正确的注册码或绕过验证逻辑。figugegl系列以其清晰的逻辑、典型的保护手法和适中的难度，成为了理解Windows平台下软件逆向工程基础技能的绝佳“练手靶场”。我自己在带新人或者巩固基础时，也常常会拿它作为案例。

简单来说，这次逆向分析的核心目标非常明确：对于一个带有“Name”和“Serial”输入框的图形界面程序，我们需要搞清楚它的验证算法。也就是说，用户输入一个用户名（Name）后，程序内部究竟通过怎样的计算过程，生成一个与之匹配的正确序列号（Serial）。我们的任务就是像侦探一样，使用调试器、反汇编器等工具，深入程序内部，解读其机器指令，最终推导出这个算法，甚至写出一个能自动生成有效序列号的“注册机”。这个过程不仅考验对汇编语言的理解，更考验逻辑推理和耐心。下面，我就结合figugegl.1和2，把整个逆向分析的思路、工具使用和关键技巧拆解清楚。

2. 逆向分析环境准备与工具链解析

工欲善其事，必先利其器。逆向分析不是凭空想象，需要一套趁手的工具。对于像figugegl这样的32位Windows控制台或GUI程序，工具链的选择直接决定了分析效率。

2.1 核心调试器：OllyDbg (OD) 与 x64dbg

首先是调试器，这是逆向工程师的“主武器”。OllyDbg (OD)是一个传奇的、免费的32位调试器，以其强大的插件生态和直观的界面著称，非常适合分析figugegl这类程序。它的内存查看、汇编指令跟踪、断点设置功能都非常直观。不过，OD对64位程序支持不佳，且已停止维护。因此，许多人也转向了它的现代继任者——x64dbg。x64dbg原生支持32位和64位调试，界面更现代化，社区活跃，插件也在不断丰富。对于figugegl的分析，两者任选其一即可，操作逻辑大同小异。我个人更倾向于使用x64dbg，因为它集成了更多现代反编译引擎的视图，在分析复杂逻辑时更省力。

注意：从网络获取的任何可执行文件（包括CrackMe），务必在虚拟机或隔离的沙箱环境中运行和分析。这是安全红线，防止程序内嵌恶意代码。

2.2 静态分析利器：IDA Pro 与 Ghidra

调试器是动态跟踪，我们还需要静态分析工具来俯瞰代码全貌。IDA Pro是业界的黄金标准，它能将二进制文件反编译成更易读的伪C代码（Pseudocode），自动识别函数、数据结构，生成流程图，极大提升了分析效率。对于figugegl，用IDA可以快速定位到核心的验证函数，理解其整体逻辑框架。如果觉得IDA商业版昂贵，Ghidra是美国国家安全局（NSA）开源的一款强大逆向工具，同样具备反编译和高级静态分析能力，完全免费，是绝佳的替代品。在分析时，我通常会先用IDA或Ghidra进行静态反编译，理清大致的函数调用关系和关键逻辑点，然后再用调试器进行动态验证和细粒度跟踪。

2.3 辅助工具集

• 查壳工具：如Detect It Easy (DIE)或PEiD。第一步永远是检查程序是否被“加壳”保护。加壳相当于给程序穿了件“外套”，会干扰静态分析。幸运的是，figugegl系列通常是“裸奔”的（无壳或简单UPX壳），用这些工具可以快速确认。如果遇到UPX壳，直接用官方UPX工具-d参数就能脱壳。
• 字符串查找：这是逆向的经典突破口。在OD或x64dbg中都有“查找所有参考文本字符串”的功能。像figugegl这种教学程序，很可能存在明显的成功提示“Success”或失败提示“Wrong”等字符串，通过追踪对这些字符串的引用，能直接定位到验证逻辑的关键跳转点。
• 系统API监控：如API Monitor。程序获取用户输入（如GetDlgItemText）、进行消息比较等，都会调用Windows API。监控这些API的调用，可以帮助我们快速定位程序读取输入和进行比较的关键代码区域。

准备好这些工具后，我们的分析工作台就搭建完毕了。接下来，就是实战环节。

3. 对figugegl.1的逆向分析与算法推导

我们先从相对简单的figugegl.1入手。按照标准的逆向流程，一步步拆解。

3.1 初步运行与行为观察

首先运行figugegl.1.exe，你会看到一个典型的对话框，有“Name”和“Serial”两个输入框，以及一个“Check”按钮。这是最基础的验证界面。随意输入，比如Name: “test”， Serial: “123456”，点击Check。程序很可能没有任何提示（或者弹出错误提示）。这种“静默失败”或简单提示的行为，告诉我们验证逻辑就在按钮事件处理函数中，并且失败后的处理很直接。

3.2 字符串定位与关键代码区锁定

打开x64dbg，附加或直接载入figugegl.1.exe。程序中断在入口点后，我们首要任务就是寻找线索。在CPU视图中右键，选择“搜索” -> “所有模块” -> “字符串引用”。在出现的字符串列表中，我们很可能会发现诸如“Success”、“Wrong Serial”、“Try Again”或“Congratulations”之类的字符串。双击“Success”字符串，x64dbg会跳转到该字符串在代码中被引用的位置。通常，在其上下不远处，就会有判断逻辑和跳转指令（如jnz,je等）。

例如，你可能会看到类似如下的代码片段：

; 假设此处是计算得到的序列号与输入序列号的比较结果 cmp eax, ebx ; 比较两个值 jnz short label_fail ; 如果不相等，跳转到失败处理 ; 如果相等，继续执行成功流程 push offset str_Success ; 压入“Success”字符串地址 ... call [printf] ; 或 MessageBox等显示函数 ... label_fail: push offset str_Wrong ... call [printf]

找到这个关键比较点，就找到了逆向分析的“阵眼”。我们需要向上回溯代码，看eax和ebx中的值是如何来的。通常，一个是程序根据Name计算出的正确序列号（真码），另一个是我们输入的序列号（假码）。

3.3 动态调试与算法跟踪

在关键比较指令cmp或测试指令test所在行按F2设置断点。然后让程序运行起来（F9），在图形界面中输入Name和Serial，点击Check。程序会在断点处暂停。现在，我们可以查看寄存器和栈内存的内容。

核心任务：弄清楚正确的序列号是如何从Name生成的。这需要向上跟踪代码。

1. 回溯计算过程：从断点处开始，按Ctrl+F9（执行到返回）或一步步向上翻阅代码（在附近查看），寻找对Name字符串进行处理的循环或计算。常见的算法包括：
   • 简单运算：对Name的每个字符进行加减乘除、异或等操作。
   • 累加/累乘：将Name所有字符的ASCII码值相加或相乘，得到一个数值，可能再进行进制转换（如转成16进制字符串）。
   • 固定密钥参与：用一个内置的常量字符串或数组与Name进行运算。
2. 记录关键操作：在调试过程中，密切关注eax,ebx,ecx,edx这些通用寄存器，以及esi,edi（常作为源/目的地址指针）。使用x64dbg的“注释”功能，在重要的指令行标注其作用，比如“读取Name长度”、“开始字符循环”、“累加ASCII值”等。
3. 验证猜测：根据跟踪到的计算步骤，手动计算一次。例如，如果你发现程序将“test”每个字符的ASCII码（t=0x74, e=0x65, s=0x73, t=0x74）相加得到总和0x1C6，然后将其格式化为十进制“454”或十六进制“1C6”作为序列号，那么就在程序界面输入Name:“test”, Serial:“454”进行验证。

以figugegl.1为例，其算法很可能是一种经典的“求和-变换”模型。假设我们跟踪发现：

• 程序获取Name字符串长度。
• 循环遍历每个字符，将其ASCII值累加到一个寄存器（比如eax）中。
• 循环结束后，将累加和eax与一个固定数值（如0x5678）进行异或（XOR）操作。
• 再将结果与另一个固定数值（如0x1234）相加。
• 最后，将这个最终数值转换为十进制字符串，即为正确的Serial。

那么，算法伪代码就是：

int CalculateSerial(char *name) { int sum = 0; for (int i = 0; name[i] != '\0'; i++) { sum += (int)name[i]; // 累加ASCII值 } sum = sum ^ 0x5678; // 异或变换 sum = sum + 0x1234; // 加法变换 return sum; // 返回的整数即为序列号 }

3.4 编写注册机（KeyGen）

一旦算法清晰，编写注册机就水到渠成。你可以用任何熟悉的语言（Python、C、C#等）实现这个算法。例如，用Python实现上述算法：

def keygen(name): sum_val = 0 for ch in name: sum_val += ord(ch) sum_val ^= 0x5678 sum_val += 0x1234 return str(sum_val) if __name__ == "__main__": name = input("Enter Name: ") serial = keygen(name) print(f"Name: {name}\nSerial: {serial}")

将这个脚本编译或直接运行，就得到了一个能为任意Name生成有效Serial的注册机，标志着对figugegl.1的逆向分析成功完成。

4. 对figugegl.2的进阶挑战与差异分析

有了figugegl.1的经验，面对figugegl.2时，我们就有了方法论。通常，CrackMe的后续版本会增加难度，figugegl.2可能引入了更复杂的保护或算法。

4.1 初步对比与难点预判

首先同样运行程序，观察界面。可能界面类似，但验证逻辑必然更复杂。再次使用字符串查找法，可能会发现提示信息变了，或者字符串被隐藏了（例如，在运行时动态解密字符串），这增加了定位难度。如果静态字符串查找失效，我们需要换思路。

4.2 应对反调试与代码混淆

figugegl.2可能会引入简单的反调试技术，例如：

• IsDebuggerPresent API检测：调用这个API检查自身是否被调试器附加。在x64dbg中，可以通过修改ZF标志位（零标志）或直接nop掉这个调用指令来绕过。
• 时间差检测：通过rdtsc指令或GetTickCountAPI 检测代码段执行时间是否过长（因为单步调试会导致执行变慢）。应对方法是找到这些检测点并跳过，或者使用调试器插件隐藏调试器。
• 代码碎片化/花指令：在关键算法中插入大量无意义的跳转和指令，干扰反汇编器的线性分析。这需要耐心，在调试器中动态跟踪真实的执行流，忽略那些永远不会被执行到的“垃圾代码”。

4.3 复杂算法解析与注册机实现

figugegl.2的算法可能不再是简单的线性累加。它可能包含：

• 多重循环与嵌套计算：对Name的字符进行多轮处理，每一轮有不同的变换规则。
• 查表操作：使用预定义的置换表（S-Box）或常量数组，将字符值映射为另一个值。
• 非对称运算：例如，对奇数位和偶数位字符采用不同的处理方式。
• 引入随机种子：但CrackMe通常为确定性算法，种子可能来源于Name本身（如长度或首个字符）。

动态跟踪策略：

1. 从API切入：如果字符串查找不灵，可以从获取输入的函数入手。在x64dbg中对GetDlgItemTextA/W或GetWindowTextA/W设断点。当我们在界面点击Check后，程序会调用这些API读取输入框内容，断点触发后，我们就站在了处理用户输入的起点。
2. 数据断点：当我们知道输入的Serial存储在内存的某个地址后，可以对该地址设置“硬件访问断点”。这样，任何指令读取或比较这个内存区域时，调试器都会中断，能精准定位到使用该数据的代码位置。
3. 步步为营：从输入点开始，单步跟踪（F7/F8），结合寄存器和内存窗口，观察数据是如何被一步步加工的。画出示意图或做笔记，记录每个变换步骤。

假设我们通过跟踪，发现figugegl.2的算法如下：

1. 将Name字符串反转。
2. 对反转后的字符串，依次取每个字符的ASCII值。
3. 将ASCII值减去索引值（i）。
4. 将结果与一个硬编码的字节数组（密钥）进行循环异或。
5. 将最终得到的字节序列转换为十六进制字符串，作为Serial。

那么注册机代码就需要严格复现这个过程：

def keygen_v2(name): reversed_name = name[::-1] key = [0x12, 0x34, 0x56, 0x78] # 假设的密钥数组 result_bytes = [] for i, ch in enumerate(reversed_name): val = ord(ch) - i # 减去索引 val ^= key[i % len(key)] # 循环异或密钥 result_bytes.append(val & 0xFF) # 确保在字节范围内 # 转换为十六进制字符串，例如 “1A2B3C4D” serial = ''.join(f'{b:02X}' for b in result_bytes) return serial

5. 逆向分析中的通用技巧与深度思考

通过figugegl这两个案例，我们可以提炼出一些通用的逆向分析技巧和思维模式。

5.1 高效定位关键代码的套路

1. 字符串与API交叉定位：字符串查找是最快路径，失效则立即转向API断点。消息框API（MessageBoxA/W）、字符串比较API（lstrcmpA/W,strcmp）、对话框输入API是GUI程序的关键突破口。
2. 栈回溯分析：在关键函数内部，观察栈帧和返回地址，可以理解函数的调用层次，帮助理清程序模块结构。
3. 利用反编译器的图形视图：IDA或Ghidra的流程图视图能一眼看清函数的分支和循环结构，比纯汇编文本高效得多。先静态分析理清脉络，再动态调试验证细节。

5.2 算法识别与还原的心得

• 关注循环结构：loop指令、cmp/jxx组合形成的循环是处理字符串或数组的明显标志。循环计数器通常用ecx或一个局部变量。
• 识别数学运算：add（加）、sub（减）、xor（异或）、mul（乘）、div（除）是基本运算。shl/shr（左/右移位）也常用于乘除2的幂次方或位操作。
• 注意数据转换：eax可能被拆分为ax（低16位）再拆分为al（低8位）和ah（次低8位）来操作单个字节。cdq指令用于将eax符号扩展为edx:eax，为除法做准备。
• 记录与验证：每分析出一小段算法，最好立刻用计算器或写行小代码验证一下，确保理解正确。理解错误会像滚雪球一样导致后续分析全部偏离。

5.3 常见问题排查与避坑指南

即使按照流程，新手也常会遇到一些“坑”：

• 程序一启动就崩溃或退出：这很可能是触发了反调试。检查入口点附近是否有IsDebuggerPresent、CheckRemoteDebuggerPresent、NtQueryInformationProcess等调用。可以在x64dbg的插件中寻找反调试绕过插件，或手动修改关键跳转。
• 跟踪时“跟丢了”：在调用系统API（call dword ptr ds:[<API地址>]）后，需要用Ctrl+F9（执行到返回）快速步过，而不是傻傻地按F7跟进系统DLL内部。同样，对于明显的循环，可以在循环结束后设断点，然后F9运行，而不是单步迭代几十上百次。
• 算法复杂，逻辑理不清：不要试图一次性在脑子里还原全部算法。用纸笔或注释工具，画出数据流图：输入从哪里来，经过哪些函数或代码块，每个块做了什么变换，最终输出到哪里。将大问题分解为小问题。
• 注册机生成的码不对：这是最常遇到的问题。99%的原因是对算法的还原有细微错误。请仔细核对：
  • 字符编码处理对了吗？程序用的是ASCII还是宽字符（Unicode）？
  • 循环的起始和结束条件对吗？是i=0到len-1还是i=1到len？
  • 转换进制对了吗？结果是十进制、十六进制还是自定义进制？
  • 有没有考虑符号位？运算结果是当作有符号数还是无符号数处理的？
  • 最好的验证方法是：在调试器中，用你编写的注册机逻辑，手动计算一个中间值，与调试器中当时寄存器的值进行对比，从差异点反向排查。

逆向分析figugegl这样的CrackMe，远不止于得到一个注册码。它训练的是一种系统性的、逆向的工程思维——从模糊的现象出发，通过观察、假设、验证、推理，最终洞悉系统内部精确的运行机制。这种能力，在软件安全分析、漏洞研究、恶意代码检测、甚至理解复杂系统的工作原理上，都是无价之宝。每完成一个这样的练习，你对计算机如何执行代码、数据如何流动、逻辑如何组织的理解就会加深一层。