标题：Unpack SecuROM 4.x-5.x with FlyODBG v1.10
目标：秋之回忆：想君简体中文版
声明：纯粹为了速度和节省光驱
作者：无聊的菜鸟
时间：2005年11月20日        01：06

调试环境：WinXP、flyODBG、PEiD、LordPE、ImportREC、WinHex

SecuROM是Sony的产品，介绍就不用了吧，知道它是光盘保护系统就行了。

首先我们需要OEP，这个大家都知道的吧。

0186F5B2 OMOKIMI.<Modu>  55                    push ebp                <-OD停在了这里
0186F5B3                 8BEC                  mov ebp,esp
0186F5B5                 6A FF                 push -1
0186F5B7                 68 B8599401           push OMOKIMI.019459B8
0186F5BC                 68 90FA8601           push OMOKIMI.0186FA90
0186F5C1                 64:A1 00000000        mov eax,dword ptr fs:[0]
0186F5C7                 50                    push eax
0186F5C8                 64:8925 00000000      mov dword ptr fs:[0],esp
0186F5CF                 83EC 58               sub esp,58
0186F5D2                 53                    push ebx
0186F5D3                 56                    push esi
0186F5D4                 57                    push edi
0186F5D5                 8965 E8               mov dword ptr ss:[ebp-18],esp
0186F5D8                 FF15 10569601         call dword ptr ds:[<&kernel32.GetVersion>]       ; kernel32.GetVersion
0186F5DE                 33D2                  xor edx,edx

我们先来确认一件事情，游戏呢一般都使用VC++6.0写的，而VC++编译出来的程序都好一个把第一个调用的API写成GetVersion，所以呢，如果Sony没有像ASPr一样模拟API的入口的话，我们对这个API下断就一定能到很接近OEP的地方。

现在我们设置OD忽略一切异常（重要！），把FlyODBG的优先级调成低（重要！），He GetVersion，然后运行。
注意堆栈：
第一次：0012FF48   0186F5DE  返回到 OMOKIMI.0186F5DE 来自 kernel32.GetVersion

第二次：0012EF40   100068E8  返回到 CmdLineE.100068E8 来自 kernel32.GetVersion

第三次：0012F688   01816F9C  返回到 OMOKIMI.01816F9C 来自 kernel32.GetVersion

第四次：0012EF50   20002759  返回到 20002759 来自 kernel32.GetVersion

第五次：0012D4C4   01826A59  返回到 OMOKIMI.01826A59 来自 kernel32.GetVersion

第六次：0012F63C   004369E8  返回到 OMOKIMI.004369E8 来自 021B0000        <-这次就是了，因为返回值在第二个段中。

回去看看：
004369BC                 55                    push ebp
004369BD                 8BEC                  mov ebp,esp
004369BF                 6A FF                 push -1
004369C1                 68 D8E34300           push OMOKIMI.0043E3D8
004369C6                 68 98AB4300           push OMOKIMI.0043AB98
004369CB                 64:A1 00000000        mov eax,dword ptr fs:[0]
004369D1                 50                    push eax
004369D2                 64:8925 00000000      mov dword ptr fs:[0],esp
004369D9                 83EC 58               sub esp,58
004369DC                 53                    push ebx
004369DD                 56                    push esi
004369DE                 57                    push edi
004369DF                 8965 E8               mov dword ptr ss:[ebp-18],esp
004369E2                 FF15 084C8801         call dword ptr ds:[1884C08]
004369E8                 33D2                  xor edx,edx        <-返回这里

与上面对比一下，不用说了吧，传说中的OEP。我们先dump一份下来留着（dump.exe）。
不过我们注意一下返回的地方的前一行，似乎不是call dword ptr ds:[<&kernel32.GetVersion>]       ; kernel32.GetVersion
这就是SecuROM的保护了，间接API的调用。

下面我们将为了得到一个能够正确执行的文件而奋斗：

我们先来看看SecuROM都有些什么方法来保护。
1. 首先SecuROM没有加密API，只加密了它的调用，比SD好多了。。。。
2. 修改原始的Call []，使它指向壳中的位置，调用的时候经过一番运算得到应该用的API（比如GetVersion）的正确的存储位置（[43E144]）后跳去API那里执行。
3. 加密原始的Call []，使它变成Call XXXXXXXX的形式，调用的时候同上。虽然ASPr也喜欢干这种事情，但是Sony做得比较省事一点，在Call的前后加一些无伤大雅的单字节代码（这次我看见了0x27(daa),0x40(inc eax),0x90(nop),0xF5(cmc),0xF8(clc),0xF9(stc)）
4. 跳到API去执行的方式也不多。

在这里先说一下SecuROM的修复中最难的是避开他的时间检测，程序运行的时候，API调用得太快或是太慢，它都会丢个不正确的直让你的PatchCode直接异常去。。。
所以我在这里用另一种方法，先修复没有时间校检的调用，然后再Patch有时间校检的地方，让它一边运行一边修复。。。这样的话我们得到的文件就一定能运行。至于剩下多少代码要修复，那就看我们的运气了。。。

现在我们还在OEP处（还记得吧），我用OllyHelper插件分配了一段内存在0x02230000
主动修复代码（修复无时间检测的代码）：
60 9C B8 00 10 40 00 33 C9 66 8B 08 66 81 F9 FF 15 74 08 80 F9 E8 74 13 40 EB EC 8A 48 05 80 F9
01 75 F5 8B 48 02 8B 09 40 EB 08 8B 48 01 03 C8 83 C1 05 81 F9 00 20 82 01 72 DD 81 F9 00 30 82
01 77 D5 83 C0 05 50 FF E1 59 33 DB 66 8B 59 FA 66 81 FB FF 15 75 05 89 41 FC EB 2F 8A 19 80 FB
27 74 1A 80 FB 40 74 15 80 FB 90 74 10 80 FB F5 74 0B 80 FB F8 74 06 80 FB F9 74 01 49 83 E9 05
66 C7 01 FF 15 89 41 02 83 C1 06 8B C1 3D 80 DB 43 00 77 02 EB 83 9D 61 C3

02230000       60                pushad                           ; 保护一下现场
02230001       9C                pushfd
02230002       B8 00104000       mov eax,401000                   ; 代码基址
02230007       33C9              xor ecx,ecx
02230009       66:8B08           mov cx,word ptr ds:[eax]
0223000C       66:81F9 FF15      cmp cx,15FF                      ; 搜索Call []
02230011       74 08             je short 0223001B
02230013       80F9 E8           cmp cl,0E8                       ; 搜索 Call XXXXXXXX
02230016       74 13             je short 0223002B
02230018       40                inc eax                          ; 不是的话就继续找
02230019     ^ EB EC             jmp short 02230007
0223001B       8A48 05           mov cl,byte ptr ds:[eax+5]
0223001E       80F9 01           cmp cl,1                         ; 确定这个Call []真的是我们需要的，因为中还有一些很无辜的东西
02230021     ^ 75 F5             jnz short 02230018
02230023       8B48 02           mov ecx,dword ptr ds:[eax+2]     ; 取调用地址
02230026       8B09              mov ecx,dword ptr ds:[ecx]
02230028       40                inc eax
02230029       EB 08             jmp short 02230033
0223002B       8B48 01           mov ecx,dword ptr ds:[eax+1]
0223002E       03C8              add ecx,eax
02230030       83C1 05           add ecx,5
02230033       81F9 00208201     cmp ecx,1822000                  ; 确定这个Call是不检测时间的
02230039     ^ 72 DD             jb short 02230018
0223003B       81F9 00308201     cmp ecx,1823000
02230041     ^ 77 D5             ja short 02230018
02230043       83C0 05           add eax,5
02230046       50                push eax                         ; 构造Call的返回地址
02230047       FFE1              jmp ecx                          ; 去吧
02230049       59                pop ecx                          ; Patch返回处，获取Call的返回地址
0223004A       33DB              xor ebx,ebx
0223004C       66:8B59 FA        mov bx,word ptr ds:[ecx-6]       ; 准备区分Call []和Call
02230050       66:81FB FF15      cmp bx,15FF
02230055       75 05             jnz short 0223005C
02230057       8941 FC           mov dword ptr ds:[ecx-4],eax     ; Call []的话就直接写入地址
0223005A       EB 2F             jmp short 0223008B
0223005C       8A19              mov bl,byte ptr ds:[ecx]         ; 确定Call加密的垃圾代码是不是在调用后面
0223005E       80FB 27           cmp bl,27                        ; daa
02230061       74 1A             je short 0223007D
02230063       80FB 40           cmp bl,40                        ; inc eax
02230066       74 15             je short 0223007D
02230068       80FB 90           cmp bl,90                        ; nop
0223006B       74 10             je short 0223007D
0223006D       80FB F5           cmp bl,0F5                       ; cmc
02230070       74 0B             je short 0223007D
02230072       80FB F8           cmp bl,0F8                       ; clc
02230075       74 06             je short 0223007D
02230077       80FB F9           cmp bl,0F9                       ; stc
0223007A       74 01             je short 0223007D
0223007C       49                dec ecx
0223007D       83E9 05           sub ecx,5
02230080       66:C701 FF15      mov word ptr ds:[ecx],15FF       ; 构造Call []
02230085       8941 02           mov dword ptr ds:[ecx+2],eax
02230088       83C1 06           add ecx,6
0223008B       8BC1              mov eax,ecx
0223008D       3D 80DB4300       cmp eax,43DB80                   ; 手动找到的最后一个需要修复的地址
02230092       77 02             ja short 02230096
02230094     ^ EB 83             jmp short 02230019
02230096       9D                popfd                            ; 完成后恢复现场
02230097       61                popad
02230098       C3                retn                             ; 可以在这里下断,但不保证结果

解释一下最后一句，理论上来说修复之后是会停在那个retn的地方，但是不排除会像我一下直接退出。但是这是第一步已完成了，我们用LordPE把0x401000处长度为0x3D000的数据dump下来保存为dump.dmp。

需要Patch的调用过程（我们这里的Patch是为了直接得到API的正确的储存位置而不是API的地址）：

01822EC0:
01822F77       FF30               push dword ptr ds:[eax]        <-改为JMP 2230049
01822F79       C3                 retn

1822D00
01822DD4       8945 04            mov dword ptr ss:[ebp+4],eax        <-这里eax改为esi
。。。。
01822DE3       C3                 retn        <-这里改为pop eax；JMP 2230049

1822AF0
01822BA5       8B00               mov eax,dword ptr ds:[eax]        <-改为JMP 2230049

然后我们重新来到入口点（和我一样挂掉的朋友就重新忍受一下异常吧），再用OD载入备份dump.dmp，然后全部选中代码段，右击选择全部取消。这样我们刚刚的努力就有意义了。

被动修复代码（修复有时间接侧的调用）：
60 9C 8B 4C 24 24 33 D2 BA 00 E0 43 00 3B 02 74 05 83 C2 04 EB F7 33 DB 89 51 FC 9D 61 FF E0

02230000       60                pushad                           ; 保护一下现场
02230001       9C                pushfd
02230002       8B4C24 24         mov ecx,dword ptr ss:[esp+24]    ; 获取调用的返回地址
02230006       33D2              xor edx,edx
02230008       BA 00E04300       mov edx,43E000                   ; API的正确存储位置的起点
0223000D       3B02              cmp eax,dword ptr ds:[edx]       ; 确定API地址对应的储存位置
0223000F       74 05             je short 02230016
02230011       83C2 04           add edx,4
02230014     ^ EB F7             jmp short 0223000D
02230016       33DB              xor ebx,ebx
02230018       8951 FC           mov dword ptr ds:[ecx-4],edx     ; 由于现在只有Call [],所以就直接写地址
0223001B       9D                popfd                            ; 恢复现场
0223001C       61                popad
0223001D       FFE0              jmp eax                          ; 回去执行API

需要Patch的调用过程（我们这里Patch是为了得到API的地址，方便后面调用）：

017C74E9     - FFE0               jmp eax        <-我们需要返回修复的地方。改为JMP 2230000

现在我们就要经一切可能使用游戏的一切功能，不过还好，看过KID秋之回忆2代的代码心里很清楚游戏真正有用的代码不会多。

最后我们点退出游戏，OD就会直接挂住它，再用LordPE把0x401000处长度为0x3D000的数据再Dump一份存为dump1.dmp。
现在我们打开WinHex把dump1.dmp写入dump.exe的0x1000位置覆盖后面的数据。然后打开ImportREC填入OEP，IAT起始地址3E000，大小：0x29C，添加一个段修复一下就可以运行了。

现在我们的sony已经很无助了，因为我们现在已经可以正常的玩了，不过，谁知道什么时候会出问题呢？

Need Fpr Speed: Most Wanted(Black Edtion)要下完了，要是硬盘还够的话，那想君就要等上一段时间再来继续修了。

不过现在我们已经可以XX了，其他的暂时就不是那么重要了。

11月21日
无语，NFSMW居然是SD4.60。。。。。而且不知支持我的i855GME。。。。。。

我们还是继续修吧！

由于这次要修得比较少，所以我反而变得更懒了。

我们先搜索一个没修的，然后直接走到它的终点：
017C74E9     - FFE0               jmp eax        <-这里

我们把上面那个mov eax,[esi]直接nop掉，然后在这里写下Patch：
mov ecx,[esp]
mov [ecx-4],eax
retn

然后我们就可以回去了，搜一个，新建EIP，按一下F8。Call就被自己SMC了。然后下一个。。。。

最后，我们用LordPE把0x00401000的地方长度为0x3D000的数据dump下来了，用WinHex贴入我们最后那个文件的

0x1000处。
OK全部修完了。

不过，理论上来说不会有问题了，先是会不会和理想有差距那就只能走着瞧了。

如果哪位对那个时间检测很清楚的话，麻烦告诉小弟。谢谢观看。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！