• 标 题:Krypton 0.5加壳程序脱壳及输入表修复记
  • 作 者:lpyxt
  • 时 间:004-10-06,08:26
  • 链 接:http://bbs.pediy.com

Krypton 0.5加壳程序脱壳及输入表修复记

软件名称:swift的幻影V2.2注册机
使用工具:fly_od v1.10  peid v0.92  winhex v11.5 import v1.6 trw2000
调试环境:winme
软件简介:该软件为幻影v2.2的注册机,现在用的人不多了。
侦壳及OEP:PEID侦测知为Krypton 0.5 -> Yado/Lockless OEP为0a0a6
 记录人及时间: lpyxt 10-5-2004 22:40

此壳做的较好,尤其花指令令人头疼,刚接触稍不留意不是死机就是跟飞。值得一提的是loveboom的Krypton0.5 OEP Finder v1.0脱壳脚本,可以稳稳的停在入口处(40a0a6),可惜脚本语言我不会,有谁写一篇教程教教我等菜鸟吧。
用TRW2000无法调试。还是用od吧,它是脱壳利剑。

脱壳步骤:
od调入undbpe.exe隐藏od标志,忽视除内存异常外的其他异常。
f9
停在8003e1处
shift+f9
停在8093ec处
ctrl+G--40a0a6
f2
shift+f9
停在40a0a6处--oep
取消断点f2
用一脱壳软件dump之,用import修复输入表失败。脱壳后的程序不能运行?????!!!!
调入脱壳后的软件调试,发现所调用函数处非法。只有跟踪原程序了。。。。
退出所有程序,运行undbpe.exe
运行trw2000
bpx exitprocess
退出undbpe.exe
断在exitprocess处,在堆栈框中有40a378
u 40a378并向上找到40a372处的反汇编代码
40A372  call near[004230bc]=0070001f

0070001f add ds:[0070003a],7933b2ec
         mov eax,ds:[0070003a]  ;eax=0b5b406c+7933b2ec=848ef358
         sub ds:[0070003a],7933b2ec   ;还原[0070003a]处的值为0b5b406c
         jmp eax   ;eax=848ef358 exitprocess的入口处

原来从70001f开始的地方是解密输入表的。通过思考我认为应该是这样的,程序在某处将值1f007000(0070001F)写入到004230bc处,然后将函数(exitprocess)的地址值58f38e84(84f38e84)通过变换后写入0070003a处。然后将函数名字作加密处理。程序应该要用到getprocadess函数和loadlibrarya。还有关键地址4230bc和70003a应该是监视的重点。后面的跟踪证明分析正确。

od调入undbpe.exe
f9
断在8003e1处
在4230bc和70003a处下内存访问断点
下断点bpx loadlibraryA和bpx getprocdaess找到后在其后的花指令跳转处下断,不然程序会飞。
shift+f9然后f8或f7小心跟踪找到下面几处可疑地址。
809d9a popad ;eax=84f38e84
809dbb mov eax,dword ptr ss:[ebp+004117ba] ;eax=0070001f
去掉这行代码(以nop填充之),使之将函数地址值直接写入到4230bc处
809e06 mov dword ptr ds:[edi],eax  ;edi=004230bc
8095b4 nop
8095b5 nop 
8095b6 nop
8095b7 shl byte ptr ds:[ecx],cl ;破坏函数名称处 
8095b9 xor byte ptr ds:[ecx],al ;继续破坏函数名称

8095b4 xor ecx,ecx
       cmp ecx,0
       jmp 809625 ;去掉花指令直接跳转
清除所有断点,重新调入undbpe.exe
f9
断在8003e1处后,
ctrl+G--809dbb 填入90 90 90 90 90,
ctrl+G--8095b4 填入33 c9 83 f9 00 eb 6a,
ctrl+G--40a0a6  下断f2
shift+f9两次,程序断在入口点40a0a6
dump出程序,用impor修复输入表ok后退出
运行脱壳修复后的程序。。。。。?没反映
用od调入跟踪发现在41e8fe处的call near [00423434]死机....
用以上的方法分析此处应该是调用USER32.GetCursorPos修复输入表时根本没有user32.dll看来输入表还是有问题。用winhex调入dump_.exe找dll库文件名字首字符的地址列表如下:
文件首字地址        名字               输入表数组结构表中的地址
02A95C          KERNEL32.DLL           [029BEC]=5CA902
02B110          USER32.DLL             [029C00]=10B102
02B334          GDI32.DLL              [029C14]=34B302
02B34E          COMDIG32.DLL           [029C28]=4EB302
02B392          WINSPOOL.DLL           [029C3C]=92B302
02B3E2          APVAPI32.DLL           [029C50]=E2B302
02B3F0          SHELL.DLL                ×    ;以下是垃圾数据用来迷惑脱壳者
02B3FC          COMCTL32.DLL           [029C64]=FCB302
02B40A          OLEDLG.DLL             [029C78]=0AB402
02B560          OLE32.DLL              [029C8C]=60B502
02B56A          OLEPRO32.DLL           [029CA0]=6AB502
02B578          OLEAUT32.DLL           [029CB4]=78B502
将029BEC-0C(4字节一段此地址为第四段,前三段长度为3×4=12(0ch))=029BE0反向(e09b02)填入[pe,0,0]=88h+80h(PE文件头中输入表地址)处,将029c50+08h后填入20h字节的00作为输入表结构数组结束。
删除bb000处到文件结束的所有字节(import修复时新增的输入表).运行dump_.exe成功

后记:
这个壳还算"温柔"(准确地说应该是OD太强劲了),中间暗桩较多,但都被OD搞定了,跟踪过程中没有频繁的死机,只是花指令太花了搞的人头晕。输入表修复也是令人生畏的事,不过通过此次脱壳修复,使我对输入表的结构有了进一步的了解。另外脱壳后的程序在其他环境下没有测试。
附件中为脱壳前的文件