Safengine Shielden v2.40 IAT修复及脚本编写(x64dbg)

前言

首先感谢 L4nce 前辈写的“  浅谈 Safengine 系列脱壳  ”，给了我很大帮助，让我开始入门脱加密壳。

L4nce 的这篇文章已经算是“巨人的肩膀”了，但我觉得仍有一些东西可以细写。由于是自己第一次研究脱壳写脚本，没有人指点，错误纰漏处还请指正包涵。

我的奇妙之旅

到这里，我就假设大家已经看完 L4nce 的文章了。接下来我想谈一些他文章中没有写到或者写全的东西，以及一些我的“奇妙旅途”。

关于研究脱壳写脚本，我是先从简单程序（只有几个 API 调用的汇编程序）入手，分析调用 iat 的代码有什么特征和功能，然后写个简易脚本，测试脱壳成功了。再用相对复杂程序（易语言静态编译程序）测试脚本并完善修改。

这个方法在我看来或许比较耗时，但可以逐步解决难关，避免在莫名其妙的问题上“卡关”。

再来谈谈 SE 的 IAT 加密。。。刚开始按照 L4nce 的思路写脚本，最后测试脱壳什么的都成功了。。。直到我√上了“使用散列API函数名称”再测试脱壳，就失效了。

分析看了一下，不再走获得API地址的 add edi,eax 这条路了。这样就只能另辟蹊径获得 API 地址

这逼的我重新分析两种情况下 call sedata_section 的流程，以图寻找共同点和突破点。

一般来说，为了程序的速度，壳对原程序的 iat 调用的加密不会多厉害，最多是在第一次跑的时候跑的久一点，之后调用都是马上取得目标地址，调用 API 或者对寄存器赋值API地址。这一点，我认为不仅适用于 se ，也适用于其他加密壳，照着这个想法找下去，总能找到希望。

最终我找到了一个点： push xxxxxx

se在虚拟机中获取到目标(API)地址后会将其修改成push 目标地址

由此我修改了脚本流程：

1.找 call sedata_section

2.步进跟踪找 push xxxxxx 和 cmp dword ptr ss:[esp+0x4],0

3.对 push 的立即数下硬件写入断点，以此来获得目标（ API ）地址

4.判断调用IAT的类型，做出修复

在第4点上， L4nce 说了大部分情况，但有些特殊情况没有细说了。我在此把相关情况列一下：

常见：

1.call dword ptr [iat]

2.jmp dword ptr [iat]

3.mov reg,dword ptr [iat]

call reg

少见：

4.call @ jmp dword ptr [iat]

jmp dword ptr [iat]

第4种情况的 call ，在加壳的时候有时候会加密，有时候不会（但其调用的  jmp dword ptr [iat] 是一定会加密的）。既然这样，就一律按加密的情况来考虑。

判断调用IAT的类型

在L4nce方法的基础上，我做了一些较大的变动。方法如下：

1.分别对 call sedata_section+5和 call sedata_section+6 这两处可能的返回地址下单字节断点（ int3 ）

2.判断获取到的目标（ API ）地址所处地址是否大于壳区段，以此判断是否是 Mov_Reg 类型或者其他 IAT 调用类型

其他 IAT 调用类型

（ shadow 已破）

3.1如果是 Mov_Reg类型，直接 run ，停在返回地址后，依次判断哪个寄存器参与了调用。

3.2如果是其他 IAT 调用的类型，先对其 API 地址下硬件执行断点再 r un ，此时 EIP 停在 API 领空，判断 [esp] 是否与  call sedata_section+5 或者 call sedata_section+6 相等，或者都不相等。

4.1 如果与 call sedata_section+6 相等，则是 call dword ptr [iat]

4.2 如果与 call sedata_section+5 相等，则是

call @ jmp dword ptr [iat]

 jmp dword ptr [iat] 中的 call

4.3 如果都不相等，则是 jmp dword ptr [iat]

至此， IAT 的调用类型就判断完了，然后按照各自情况修复就可以了，可以直接参考脚本。

（特殊 API 如 CreateThread 不会填充 push xxxxxx ，手动修复即可）

写脚本的奇妙旅途

写 x64dbg 脚本，还真是发生了不少“奇妙事件”。有些解决了，有些只能回避掉。

1. 单步步入（ sti ）无效：

在把 EIP 设置到 call 上后，第一次 sti 有一定几率停在原地不动

2. 跑脚本时奇奇怪怪的异常崩溃：

也是把 EIP 设置到 call 上后，步进追踪可能崩溃，可能出现异常访问（偏偏手动单步执行脚本就不会出现，换个系统也有可能不会再出现）。遇到这种情况，只能把地址加入 ignore 表，到时候手动修复。所幸这都是少数，一般就3个左右

3. 跑脚本跑得 x64dbg 崩溃：

这个还好，跑脚本前把 GUI 更新关闭，堆栈更新关闭，日志更新关闭即可。出现特殊情况了，再解开 GUI 更新，分析情况。

4.  call 压入错误返回地址

这个是最奇妙的。把 EIP 设置到 call 上后，第一次步进,，有几率出现压入错误的返回地址的现象！只能重新把 EIP 设置在 call 上，把之前的返回地址清0，再步进跟踪一次，就不会再出现了。

尾声

L4nce 在他的文中写到还有“被抽取的代码”，不过我脱壳时都没遇见到，不知道什么情况。

脱壳时建议选择 win7 环境（ xp 貌似用不了 x64dbg ）， win10 下脱出来的易语言静态编译程序 （其他语言程序没问题） ，在其他平台运行不了。只有 win7 脱下来的正常运行在其他平台（暂时只测试了 xp，win7，win10 ）

脚本我写了比较多的注释，放上来供大家参考。至于特殊情况的判断和修复，相信对有心学习的人来说不是难事，对伸手党倒是难事。

- End -

看雪ID： Lixinist        

https://bbs.pediy.com/thread-251066.htm

本文由看雪论坛  Lixinist    原创

转载请注明来自看雪社区

热门图书推荐

戳   立即购买！

公众号ID：ikanxue

官方微博：看雪安全

商务合作：wsc@kanxue.com

↙ 点击下方“阅读原文”，查看更多干货