Enterprise Edition rlpack unpack by cqr2287
本帖最后由 cqr2287 于 2017-1-21 10:08 编辑Rlpac is a famous packers in Windows.
最近我研究了rl壳。所以来发个脱壳教程。
对于rlpack，比较简单。然而Enterprise Edition增加了保护措施。我们必须从新研究。。。
好了，载入od。直接运行，我们发现，他没有反调试。那么我们可以放心跟踪。
先看区段。
从40c0000一直属于rlpack。
00401000 > $57 push edi
00401001 .C7C7 72AFB4DF mov edi,0xDFB4AF72
00401007 .8D3D 5FBA581A lea edi,dword ptr ds:
0040100D .FFCF dec edi
0040100F .0facf7 f2 shrd edi,esi,0xf2
00401013 .0FBDFE bsr edi,esi
00401016 .F7C7 5CDC3027 test edi,0x2730DC5C
0040101C .0FBAF7 33 btr edi,0x33
00401020 .0FBBF7 btc edi,esi
00401023 .0FCF bswap edi
00401025 .BF 64A909DB mov edi,0xDB09A964
0040102A .85F6 test esi,esi
0040102C .81DF AC194648 sbb edi,0x484619AC
00401032 .F7DF neg edi
载入od我们就发现了许多异常。
我打算采用单步法。f8单步跟踪。
004011D0 .C7C7 F89C2006 mov edi,0x6209CF8
004011D6 .64:8bfe mov edi,esi
004011D9 .0FA3F7 bt edi,esi
004011DC .D1C7 rol edi,1
004011DE .85F6 test esi,esi
004011E0 .0fa4f7 e4 shld edi,esi,0xe4
004011E4 .0FCF bswap edi
004011E6 .0FBDFE bsr edi,esi
004011E9 .5F pop edi
004011EA .- E9 6BEF0000 jmp 13.0041015A
在区段底部，我们发现一个jmp直接调走了。我们跟踪。
0041015A 60 pushad
0041015B E8 00000000 call 13.00410160
00410160 83C4 04 add esp,0x4
00410163 8B6C24 FC mov ebp,dword ptr ss: ; 13.00410171
00410167 E8 80020000 call 13.004103EC
0041016C E8 69240000 call 13.004125DA
00410171 837C24 28 01 cmp dword ptr ss:,0x1
00410176 75 0C jnz short 13.00410184
00410178 8B4424 24 mov eax,dword ptr ss:
0041017C 8985 95450000 mov dword ptr ss:,eax ; kernel32.BaseThreadInitThunk
00410182 EB 0C jmp short 13.00410190
00410184 8B85 91450000 mov eax,dword ptr ss: ; 13.00400000
0041018A 8985 95450000 mov dword ptr ss:,eax ; kernel32.BaseThreadInitThunk
00410190 E8 0A0D0000 call 13.00410E9F
00410195 EB 03 jmp short 13.0041019A
00410197 24 00 and al,0x0
这里很像oep了。我们先下个断点做个标记。
继续f8.
我们在call ebx处发现了程序错误。
问题签名:
问题事件名称: APPCRASH
应用程序名: 13.exe
应用程序版本: 1.0.0.0
应用程序时间戳: 37d23b4a
故障模块名称: 13.exe
故障模块版本: 1.0.0.0
故障模块时间戳: 37d23b4a
异常代码: c0000005
没关系。我们直接f9，运行到刚才断下位置。
f8单步一次，我们可以发现符合esp定律。
我们刚才走出了区段。而在刚才rlpack区段，我们只发现了一些数学运算指令。
那么我们大胆推断，这里就是真正的数据区段
在这里下硬件执行没用。我们就f8跟踪。
慢点，注意堆栈。
0041025D FFB5 7A530000 push dword ptr ss:
00410263 56 push esi
00410264 FFD3 call ebx
此处丢失，做个断点记录。直接f9到这。
f7进call。
0041046C 60 pushad
0041046D 8B7424 24 mov esi,dword ptr ss:
00410471 8B7C24 28 mov edi,dword ptr ss: ; kernel32.BaseThreadInitThunk
00410475 FC cld
00410476 B2 80 mov dl,0x80
00410478 33DB xor ebx,ebx ; 13.0041046C
0041047A A4 movs byte ptr es:,byte ptr ds:
0041047B B3 02 mov bl,0x2
0041047D E8 6D000000 call 13.004104EF
00410482^ 73 F6 jnb short 13.0041047A
f8跟踪。
004104E0 95 xchg eax,ebp
004104E1 8BC5 mov eax,ebp
004104E3 B3 01 mov bl,0x1
004104E5 56 push esi
004104E6 8BF7 mov esi,edi
004104E8 2BF0 sub esi,eax
004104EA F3:A4 rep movs byte ptr es:,byte ptr ds:[>
我们在跟踪的过程中，就发现了错误。
我们不下断点，直接运行。
通过刚才在跟踪过程中的硬件执行，找到oep。
00401060 .68 0C354000 push 13.0040350C
00401065 ?E8 F0FFFFFF call 13.0040105A ;jmp 到 msvbvm50.ThunRTMain
0040106A ?0000 add byte ptr ds:,al
0040106C ?0000 add byte ptr ds:,al
0040106E ?0000 add byte ptr ds:,al
00401070 ?3000 xor byte ptr ds:,al
00401072 ?0000 add byte ptr ds:,al
00401074 ?3800 cmp byte ptr ds:,al
00401076 ?0000 add byte ptr ds:,al
00401078 ?0000 add byte ptr ds:,al
0040107A ?0000 add byte ptr ds:,al
0040107C .7B 91 jpo short 13.0040100F
0040107E ?F9 stc
0040107F .4c dec esp
00401080 ?B9 63D31192 mov ecx,0x9211D363
00401085 .^ 79 E1 jns short 13.00401068
00401087 ?1A19 sbb bl,byte ptr ds:
00401089 ?e4 72 in al,0x72
0040108B .3F aas
下一步就是修复iat了。
我们先不管，做个标记。。。。。。。。。
这里我们使用lordpe和importrec结合修复。
因为在od中dump会提示不是有效的win32程序。
怎么修复还用我说么？ 不会可以看我第17课。
错误还挺多。。
修复后即可搞定。。
楼下点评是正确的，但注意，我对图的解释是放在图下面的。这张图是没修复的。。。@xjun
最后说下，脱壳很考验逻辑能力的。我们要懂asm，并找到适当方法去寻找oep。论坛里好多人不善用od以外的工具，这样不好。要多方面去借住力量。
这也算我的感受吧。
谢谢大家。
感谢分享 大神叫我来顶帖~好吧，我啥也看不懂，过来支持支持~
@某中二绅士 召唤术！中二！！！ 高深莫测之感 前来支持一个~ 全是英文 看不懂 全是英文 看不懂 看不懂啊。。 谢谢楼主分享