pll621 crackme脱壳

pll621 crackme脱壳 作者：unknown 更新时间： 2005-05-31 使用工具: 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要修复的代码很长。全部修复工作完成后，脱壳就完成了。碰巧的是，脱壳前后大小是一样的。