标题: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全部修完了。
不过,理论上来说不会有问题了,先是会不会和理想有差距那就只能走着瞧了。
如果哪位对那个时间检测很清楚的话,麻烦告诉小弟。谢谢观看。