-
-
[原创]UltraEdit 中文版背后的故事
-
发表于: 2010-4-25 13:11
-
自己先搞了一下 然后又看了一下网上的爆破方法
先说一下网络上流传的爆破方法： OD载入后 Ctrl+S 搜索 PUSH 6E6D 这个是弹出过期的资源对话框的ID值
我们通过启动时判断是否注册来定位程序的验证点。用工具eXeScope 查看 ueres.dll
这个方法很快 我用的是另一种方法 点程序关于的时候 根据对话框文字内容不同 在内存下硬件读取断点来定位
最终效果都是相同的 定位到算法CALL的关键跳：
Cr（1032版）：
00806282 /EB 02 JMP SHORT Uedit32.00806286 ; 修改为JMP
00806284 |. |8AC3 MOV AL,BL
如果只是这样的话 是不是很爽的 我查看了一下老外的版本 发现也是这样搞的
0046333B E8 A078FFFF CALL Uedit32.0045ABE0
00463340 8B2D 201CB500 MOV EBP,DWORD PTR DS:[<&USER32.SendMessa>; user32.SendMessageA
00463346 83C4 14 ADD ESP,14
00463349 84C0 TEST AL,AL
0046334B 0F84 1D030000 JE Uedit32.0046366E ; 16.0.0.1038 就是把这里NOP掉就OK了
00463351 391D E478D900 CMP DWORD PTR DS:[D978E4],EBX
00463357 0F85 11030000 JNZ Uedit32.0046366E
0046335D 395C24 14 CMP DWORD PTR SS:[ESP+14],EBX
00463361 74 28 JE SHORT Uedit32.0046338B
00463363 8B4C24 24 MOV ECX,DWORD PTR SS:[ESP+24]
00463367 8B5424 28 MOV EDX,DWORD PTR SS:[ESP+28]
0046336B 83EC 10 SUB ESP,10
0046336E 8BC4 MOV EAX,ESP
00463370 8908 MOV DWORD PTR DS:[EAX],ECX
00463372 8B4C24 3C MOV ECX,DWORD PTR SS:[ESP+3C]
00463376 8950 04 MOV DWORD PTR DS:[EAX+4],EDX
00463379 8B5424 40 MOV EDX,DWORD PTR SS:[ESP+40]
0046337D 8948 08 MOV DWORD PTR DS:[EAX+8],ECX
00463380 8950 0C MOV DWORD PTR DS:[EAX+C],EDX
00463383 E8 680CFFFF CALL Uedit32.00453FF0 ; 该CALL中调用 6E6D 资源
而中文版则不然，英文版程序大小为 9.66M 而中文版大小为12M
英文版下载链接（1038版）：：79dK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6i4g2D9N6s2u0S2k6h3c8A6N6q4)9J5k6h3y4G2L8g2)9J5c8X3k6A6L8r3g2K6i4K6u0r3N6h3g2Q4y4h3k6W2L8X3N6D9K9i4y4Z5i4K6u0W2P5X3W2H3
中文版下载链接（1032版）：：f3eK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6i4g2D9N6s2u0S2k6h3c8A6N6q4)9J5k6h3y4G2L8g2)9J5c8X3k6A6L8r3g2K6i4K6u0r3N6h3g2Q4y4h3k6U0K9r3W2F1k6i4y4W2i4K6u0W2P5X3W2H3
那多出来的代码是什么呢 ？ 通过调试得中文版的UE做了很多BT的事情，OD调试的时候首先是无法下INT3断点的。程序在启动时会效检代码段数据是否被修改过，所以我们下 BP ReadProcessMemory 函数或者对我们下INT3断点的数据下内存读写断点（我喜欢后者）。然后还没有结束，程序会用效检数值解密代码并将数据填充到代码段某几段数据，说的俗点就是SMC解码代码段的几段数据。
我调试的是1032的版本，笔记比较乱，我详细说思路和方法，所以简单贴上关键点，对于读取代码段数据进行效检部分的代码就不贴了，留给有心人去自己调试吧，这里只贴出程序SMC填写那三段数据的函数：
00C21D7F 8B4D 08 MOV ECX,DWORD PTR SS:[EBP+8]
00C21D82 51 PUSH ECX ; ECX 是长度
00C21D83 8B55 C8 MOV EDX,DWORD PTR SS:[EBP-38]
00C21D86 52 PUSH EDX ; EDX 是源代码段
00C21D87 8B45 0C MOV EAX,DWORD PTR SS:[EBP+C]
00C21D8A 50 PUSH EAX ; EAX 是要目的代码段
00C21D8B E8 6040DFFF CALL Uedit32_.00A15DF0 ; 该CALL实现SMC写入
这样一共SMC动态填充程序的三段数据。问题就来了：该函数的第二个参数（EDX的源数据）是如何解密的来的呢？ 这里有兴趣的朋友可以继续内存断点来分析。我是这样想的，如果是动态效检的结果再去计算得到的源数据，而调用的函数都是同一个，与其处理效检值，不若直接把这个COPY函数NOP掉，手动把正确的代码Patch回去，然后把这个函数NOP掉好了。这个是破解壳的时候对付SMC的常见手法哈。还好啦，就三段，不然会死人啦 ……
程序跑起来之后基本上就没啥了，但是BT的UE又开始效检，又把我们自己Patch进去的三段代码给乱码写回去，真够猥琐的。于是乎把那里也咔嚓掉。看来UE对中文用户特别关照了，这3M真不白给哈。有兴趣的朋友可以一起分析一下UE中文版本的效检。就到这吧，有有时间再来灌水 ~~
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
学习下。。。
|
|
|
没缘分呀
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
