破解UltraEdit（Ver20.00.0.1040），无限试用

因为是第一次破解较大型的商业软件，所以有必要记录一下，另外UE的价格也实在太贵了。。。

第零步：准备

　　准备好破解常用软件。我常用的工具有IDA（用于静态分析）、Ollydbg（动态调试）、PEiD（用于查看可执行文件是否加壳）、W32Dasm（在一个网上教学视频中看到的软件，用于静态搜索软件中的字符串资源）、CheatEngine（多用于游戏作弊，这里用来动态搜索进程中的字符串）。

　　先对Uedit32.exe这个可执行文件进行初探，PEiD发现它没有加壳，这也不出意料，这种软件肯定是不屑于加壳的。

　　其次，需要了解一下UE的注册/激活机制：默认安装后软件处于未注册/激活状态，此时可以试用30天，试用到期后，会弹出提示，必须注册才可以使用；未到期时也可以点击“帮助”->“注册”，此时看到的是UE的在线激活对话框（如下图所示），填入许可证ID和密码点击“激活”按钮后将向UE的server发起HTTP交互，没有正确的许可证ID和密码时当然是不能被server check通过的。

　　还有另一种激活方式--脱机激活，需要在禁用网卡的情况下点击上面的“激活”按钮才会出现：

　　点击“脱机激活”，在对话框中填入“许可证”、“密码”、“验证码1”、“验证码2”后，点击“激活”按钮，会弹出失败信息：

　　注意这个错误提示信息“您输入的代码无效。您需要...”，本文所陈述的破解方式就从这个字符串开始。

第一步，找到访问出错提示的指令和函数。

　　首先尝试静态查找。使用W32dasm，查找字符串“您输入的代码无效。您需要...”，没找到。

　　由此猜测UE的提示信息可能使用动态加载的方式，在UE启动时从某个文件中读取到内存中。据此尝试使用CheatEngine附加后查找，查找成功:

继续使用CheatEngine找出是什么访问了这个地址，找到这样几个指令：

我们只应该关注UE模块内的指令，因此这里要关注上图中第一条指令。

尝试对这条指令下断点，发现程序被不停地断下，可以猜测UE可能存在一个线程在不停地执行该处指令，另外观察到每次断下后堆栈都不相同，由此可见该处的指令可能位于一个底层函数内部，因此需要使用条件断点，当寄存器EDI的值等于05A27B80时断下。这时发现不会被反复断下了，并且再次尝试激活时断到了这条指令。

然后需要开始一个痛苦的步骤：需要找到按下“激活”按钮时所调用的函数。注意查看上图右下的调用栈，由内向外依次尝试对各个call下断点（非条件断点），每加一个断点，尝试让UE运行，看是不是只是在点击“激活”按钮时才被断下，如果不是，删除断点，继续在上一级函数下断点。尝试几次后，找到了一个call：0099B170。

第二步，分析判断验证码/注册码匹配的关键指令逻辑。

　　关掉CheatEngine，使用IDA对UE可执行文件进行反汇编，并找到函数0099B170。由于文件较大，反汇编可能需要很久才能ready。

　　分析反汇编，发现下面指令是在判断用户是否输入了许可证：

cmp     dword ptr [eax-0Ch], 0
jnz     loc_99B2F9

　　并且后续所调用的这一段逻辑与输入了许可证但验证错误的情况下都会被执行：

.text:0099B8FF loc_99B8FF:                             ; CODE XREF: sub_99B170+783j
.text:0099B8FF                 mov     edx, [eax]
.text:0099B901                 mov     ecx, eax
.text:0099B903                 mov     eax, [edx+0Ch]
.text:0099B906                 call    eax
.text:0099B908                 lea     edi, [eax+10h]
.text:0099B90B                 mov     [ebp+var_68], edi
.text:0099B90E                 push    6D6Fh           ; unsigned int
.text:0099B913                 mov     byte ptr [ebp+var_4], 18h
.text:0099B917                 call    ?AfxFindStringResourceHandle@@YGPAUHINSTANCE__@@I@Z ; AfxFindStringResourceHandle(uint)
.text:0099B91C                 test    eax, eax
.text:0099B91E                 jz      short loc_99B931
.text:0099B920                 push    6D6Fh           ; lpWideCharStr
.text:0099B925                 push    eax             ; hModule
.text:0099B926                 lea     ecx, [ebp+var_80]
.text:0099B929                 call    sub_4098F0
.text:0099B92E                 mov     ebx, [ebp+var_80]
.text:0099B931
.text:0099B931 loc_99B931:                             ; CODE XREF: sub_99B170+7AEj
.text:0099B931                 push    6D70h           ; unsigned int
.text:0099B936                 call    ?AfxFindStringResourceHandle@@YGPAUHINSTANCE__@@I@Z ; AfxFindStringResourceHandle(uint)
.text:0099B93B                 test    eax, eax
.text:0099B93D                 jz      short loc_99B950
.text:0099B93F                 push    6D70h           ; lpWideCharStr
.text:0099B944                 push    eax             ; hModule
.text:0099B945                 lea     ecx, [ebp+var_68]

由此猜测UE的验证可能类似这样的逻辑：

...
ret = check(/*各种用户的输入*/)
str_id = get_str_by_ret(ret);
show_str(str_id)
...

另外有幸看到前面有一段这样的指令：

.text:0099B1C4                 push    0               ; bEnable
.text:0099B1C6                 mov     ecx, eax
.text:0099B1C8                 call    ?EnableWindow@CWnd@@QAEHH@Z ; CWnd::EnableWindow(int)
.text:0099B1CD

使用ollydbg尝试修改.text:0099B1C4为push 1，发现激活按钮不再变灰，因此，猜测判断注册码匹配与否的逻辑在上述两段指令中间。

继续分析ida的反汇编结果，发现中间有两处调用atoi：

.text:0099B337                 push    ebx             ; char *
.text:0099B338                 mov     byte ptr [ebp+var_4], 4
.text:0099B33C                 call    _atoi
.text:0099B341                 add     esp, 4
.text:0099B344                 push    eax
.text:0099B345                 call    sub_CCDA26
.text:0099B34A                 mov     edi, eax
.text:0099B34C                 mov     eax, [ebp+var_6C]
.text:0099B34F                 push    0C6h
.text:0099B354                 push    eax             ; char *
.text:0099B355                 call    _atoi
.text:0099B35A                 add     esp, 4

ollydbg断到这两个地方，发现他们的入参分别的UE的验证码1和验证码2的字符串，可见，判断注册码匹配与否的逻辑在这两个atoi后面。

继续分析ida的反汇编结果，发现在两个atoi后面有一个这样的指令：

.text:0099B363                 lea     ecx, [edi-13h]
.text:0099B366                 cmp     ecx, 0Dh        ; switch 14 cases
.text:0099B369                 ja      loc_99B8B8      ; jumptable 0099B376 default case

感谢ida帮我们分析出这是一个switch case分支，猜测后面就是前面索要找的get_str_by_ret。

第三步，破解。

ollydbg尝试修改执行cmp     ecx, 0Dh前的ecx，最有可能正确的就是0，尝试改为0，继续运行，看到了弹出对话框，还可以试用30天。ollydbg脱离UE进程，停止调试，关闭UE，重新打开，没有再弹出试用到期的提示，破解成功。

总结

其实最后一步破解时，算是运气比较好的，比较容易地找到了判断逻辑，如果尝试失败了，可能要继续找到真正的check函数了。

网上其实有很多破解补丁可以下载，甚至有破解版的UE（但这个20.00.0.1040版本的没找到），正如刚开始所说的，本文的意义在于记录分享而非炫耀。

可以进一步延伸：

1、我想UE的剩余试用时间应该是写在注册表或者是某个文件中，如果可以找到的话，就有可能把试用时间改为无限长；

2、可以挑战一下在线注册，完全不同的思路呢；

3、就本文的思路，还差一个破解补丁，在cmp     ecx, 0Dh之前修改一下ecx的值，这个也应该比较容易，后续有时间再搞。