|
 |
推荐文章 |
|
|
|
|
|
|
|
|
|
|
|
使用工具: SoftIce,LordPE,ImportREC,WinHex,Hiew
1. OEP快速寻找
设断点bpx GetStartupInfoA，程序中断返回
001B:00401DC3 50 PUSH EAX
001B:00401DC4 FF1504204000 CALL [KERNEL32!GetStartupInfoA] <== 通用断点函数
001B:00401DCA F645D001 TEST BYTE PTR [EBP-30],01
001B:00401DCE 7411 JZ 00401DE1
往前回溯
0008:00401CC0 55 PUSH EBP <== 原始OEP
0008:00401CC1 8BEC MOV EBP,ESP
0008:00401CC3 6AFF PUSH FF
0008:00401CC5 6830244000 PUSH 00402430
0008:00401CCA 68461E4000 PUSH 00401E46
0008:00401CCF 64A100000000 MOV EAX,FS:[00000000]
0008:00401CD5 50 PUSH EAX
0008:00401CD6 64892500000000 MOV FS:[00000000],ESP
0008:00401CDD 83EC68 SUB ESP,68
401CC0即为该crackme的原始OEP，可以直接运行程序，然后再用lordpe dump,修正OEP
2. 修复Import表
用LordPE, ImportREC轻松搞定。例行公事。
此时运行程序会产生错误，我们还有一些工作要继续完成
3. 修正代码
为了更快的知道出错位置，我在si中使用了faults on,这样每当出错，我就可以知道在何处出问题。
<1> 堆栈指针的修复:
以下是第一次截到的错误:
Break due to UnhandledException NTSTATUS=STATUS_ACCESS_VIOLATION
MSR LastExceptionFromIp=00401569 <== 这里引发的错误
MSR LastExceptionToIp=00147A60 <== 该位置访问权限错误
001B:00401564 68D4324000 PUSH 004032D4
001B:00401569 FF15C8324000 CALL [004032C8] <== Call引发的错误
001B:0040156F 8D4C2408 LEA ECX,[ESP+08]
001B:00401573 6A00 PUSH 00
该处call所执行的程序位于堆中(在si中可以执行query来查看,然而该堆于我们脱壳后的文件是无用的),然而我们dump下的代码里是没有的,以下这部分是call所执行的部分内容:
001B:00147A58 60 PUSHAD <== 由此判断后面的修改与寄存器无关？
001B:00147A59 E800000000 CALL 00147A5E
001B:00147A5E 5D POP EBP
001B:00147A5F 81ED0E5F1400 SUB EBP,00145F0E
001B:00147A65 8B442424 MOV EAX,[ESP+24]
001B:00147A69 8DB56D9E4000 LEA ESI,[EBP+00409E6D]
001B:00147A6F 8A18 MOV BL,[EAX]
001B:00147A71 881E MOV [ESI],BL
001B:00147A73 803800 CMP BYTE PTR [EAX],00
001B:00147A76 7404 JZ 00147A7C
001B:00147A78 46 INC ESI
上面代码截取的是原crackme执行的代码，此代码中很多花指令，不要被PUSHAD所蒙蔽，程序返回到40156F继续执行时,ESP的值已经被修改了。因而我用hiew修改了我dump下的程序，将401569处修改为:ADD ESP,4,其后用3条nop补足位数。至此再运行dump的程序，已经可以显示对话框了。147A58开始的代码段起的作用只是修改ESP。
<2> 代码段的修复
此时我们不输入字符，直接按下确定键，你会发现dump的程序再一次崩溃。我们要做的和上面的步骤一样，由dump的程序的出错位置，去运行原crackme，查看错误的位置和原因，以及原crackme再此做了一些什么手脚。
此时截到错误如下:
Break due to UnhandledException NTSTATUS=STATUS_ACCESS_VIOLATION
MSR LastExceptionFromIp=004016C4
MSR LastExceptionToIp=00142390
001B:004016C2 7549 JNZ 0040170D
001B:004016C4 FF15C4324000 CALL [004032C4] <== 错误有这里引发，我们直接F10过去，看什么变化
001B:004016CA EB08 JMP 004016D4
你看到了吗，后面紧跟的一段代码被修改了(还是F10好啊，我开始用F8跟进去那个才叫郁闷)!现在才是正常的代码。这时要做的就是用WinHex的内存编辑功能，dump下修改后的代码，然后覆盖掉我们所dump的文件中此位置的代码!这里简单的查找替换就可以完成了,这一部分是修正dump文件的最重要的环节.然后将4016C4处的call修改为6个nop语句。
继续往下跟踪，就在不远处 <下面的语句可是由上面的call动态生成的哦>:
001B:004016E6 FF15F4214000 CALL [USER32!SendMessageA]
001B:004016EC FF15C0324000 CALL [004032C0] <== 同样F10过去
001B:004016F2 EB08 JMP 004016FC
这里call的代码的作用想都想得到了，就是将上面修改后的代码再改回去，让你跟踪郁闷一点。要做的工作简单了，只需用nop取代，不让它改回去就OK了。
代码段的修复要重复很多遍，才能完全修正我们所dump的文件,其中401767那里的call要修复的代码很长。全部修复工作完成后，脱壳就完成了。碰巧的是，脱壳前后大小是一样的。 |
|
|
|
|
|
特别声明： 本站除部分特别声明禁止转载的专稿外的其他文章可以自由转载，但请务必注明出处和原始作者。文章版权归文章原始作者所有。对于被本站转载文章的个人和网站，我们表示深深的谢意。如果本站转载的文章有版权问题请联系编辑人员，我们尽快予以更正。 |
|
|
|
|
|
责任编辑： 原点 |
投稿作者： 本站收集 |
|
|
信息来源： 网络 |
录入时间： 2005-5-31 |
|
|
|
| |
|
设为首页
加入收藏
总编信箱
投稿或申请专栏请先 [登 陆]