首先呢，我是一个小白，也不太懂太多的专业术语或者更加好的方法，所以以下文章用的方法也是小白都会想到的方法。如果有错误或者哪里有纰漏，也请大家理解。那我们就开始吧！{:1_924:}
Themida 3.0.4.0：
这个壳，在吾爱论坛上也有，点这里
。
加密方式是默认的：
加密选项.png (24.75 KB, 下载次数: 1)
下载附件
2021-1-5 15:38 上传
加密选项2.png (19.53 KB, 下载次数: 1)
下载附件
2021-1-5 15:38 上传
需要用到：
虚拟机 XP SP3 2002版 ，ollydbg ，LordPE , ImportREC , 一点点的小聪明 。 （亿点点的运气，这是我分析时需要的）
ps：XP系统调试这个壳真的贼爽，这个版本的Themida基本检测不到，直接在程序代码段设置内存访问运行两次就能到OEP。←亿点点的运气，不过这篇文章主要讲的也不是找OEP吧。:keai
分析：
先把要脱壳的程序运行起来，然后OD附加，分析主程序的代码段是否被更改：
对比1.png (37.31 KB, 下载次数: 0)
下载附件
2021-1-5 16:10 上传
我这里用了未加壳和程序和已经加壳的程序的代码进行分析，发现他并未对代码段进行更改。（这里和旧版的不同，旧版的是改了代码段的指令的，这里
。）而是对输入表中的API进行了重定向。接下来的事就简单了。在输入表中下写入断点。然后不就可以知道所有的API了吗？
思路是对的，但是实现起来却花了我不少时间，因为这个壳对在输入表的断点检测比较严格。（第一个难点）你必须要卡在它要开始填充输入表的前一刻再下写入断点。我这里试了许多办法，都不怎么行，最后盯上了旧版找OEP时需要用到的函数 ZwFreeVirtualMemory ，重载程序后下这个函数断点，但这次，我们看的并不是找OEP时看的EDI，而是
要盯住输入表
（对易语言来说，你把程序拖进OD，下面那个窗口就是他的输入表）的内容。当按了若干次F9后，
你可以注意到，输入表的内容发生了变化，从原来的乱码，变成了略有规律的代码
。但并不是重定向的地址。
从
：
变化1.png (19.61 KB, 下载次数: 1)
下载附件
2021-1-5 16:44 上传
变化成了
：
164447j6ykvdj6dgtdgktj.png (32.44 KB, 下载次数: 0)
下载附件
2021-2-4 14:02 上传
这个时候，就可以在输入表下写入断点了，但不能直接下内存写入断点，因为这里往后程序还会检测内存写入断点。但是过了硬件断点检测，所以只能下硬件写入断点，但硬件写入断点最多只能下16字节，那要下在哪呢？（这是第二个难点）
但其实这个很简单，
只要把程序运行起来，看看它哪些API地址没有被重定向，就是下那个地方的硬件写入断点
。运行起来可以发现：
寻找未重定向的API.png (11.23 KB, 下载次数: 1)
下载附件
2021-1-5 16:57 上传
可以得到输入表表头的API就没有进行重定向，我们就在这下硬件写入断点。F9后，就可以断在写入API指令的下一行。我们再在上一行下一个硬件执行断点，就是在写入API的那一行。然后F9一下。就到这里：（然后你多按几次F9你就可以自己发现规律了）
"
获取API.png (21.05 KB, 下载次数: 0)
下载附件
2021-1-5 17:10 上传
规律：
对无需重定向的API：
第一次 mov dword ptr ds:[ecx],eax（此时eax为API，ecx为备份地址）
....（花指令） + 隐藏API + 恢复API（放回EAX）
第二次 mov dword ptr ds:[ecx],eax（此时eax为API，ecx为填充输入表的位置）
....（花指令） + 获取下一个API地址，放到eax
返回 第一次
对需要重定向的API：
第一次 mov dword ptr ds:[ecx],eax （此时eax为API，ecx为备份地址）
....（花指令） + 隐藏API + 垃圾数据放入eax
第二次 mov dword ptr ds:[ecx],eax （此时eax为垃圾数据，ecx为壳段的某个地址）
....（花指令） + 获取下一个API地址，放到eax
返回 第一次
"
由规律可以轻易知道，对无需重定向的API，获得之后就直接填入输入表。对需要重定向的API，是先不需要填入输入表的，但重定向得到的地址也迟早需要填入输入表，这就是我们后面需要在输入表所在区段下内存写入断点的原因。（下内存写入断点后）当壳读取了API地址进行重定向之后，必定要向输入表填入重定向之后的地址，如图：
获取重定向地址.png (18.46 KB, 下载次数: 0)
下载附件
2021-1-5 19:21 上传
向输入表的481254位置写入重定向后的API地址 611955。（写入的指令有好几条，但指令都是“pop dword ptr ds:[ebx]”）这里很重要，写脚本要用到。
"
写脚本：由上面的规律可以知道，不管是需要重定向的API还是无需重定向的API他都需要先放到一个备份地址。而我们就要写一个脚本，将他需要重定向的API先读取出来。脚本如下：[Asm] 纯文本查看 复制代码//先手动运行到第一个需要重定向的API处（方法上面有提），再运行脚本。
var api //声明一个变量，用于存放API地址
var dizhi //声明一个变量，用于存放备份地址
mov dizhi,6111AA//备份地址
mov api,[dizhi] //先把第一个被重定向的API地址输出
jmp jlapi
re:
esto
cmp eip,788930 //判断是否停在我们下硬件执行段点
je pdapi //如果是就跳
ret
pdapi:
cmp ecx,6111AA //因为当ECX值就等于备份地址时，新获得的API还未被写入6111AA
je re
mov api,[dizhi]
jmp jlapi
jlapi:
wrta "C:\Documents and Settings\Administrator\桌面\ziji\tmd3API1.txt",api //将得到的api输出到一个记事本
jmp re
接下来，我们也要读取这些API本来需要填充到的地址（上面有提到重定向的顺序和填充IAT的顺序一致），脚本如下：[Asm] 纯文本查看 复制代码var ad //声明一个变量，存放api真正需要填充到的地址
mov ad,ebx //上面有说，地址就是ebx的地址。
wrta "C:\Documents and Settings\Administrator\桌面\ziji\tmd3APIdy.txt",ad //将api真正需要需要填充到的地址输出
//上面是先输出当前的
jl:
esto
mov ad,ebx //将下一个填充地址放入ad
wrta "C:\Documents and Settings\Administrator\桌面\ziji\tmd3APIdy.txt",ad //输出
jmp jl //重来！
当你两个脚本都运行完后，你会得到两个TXT，一个是全都是api地址。一个全都是api需要填充到的地址。我们将两个TXT的数据放进表格。可以发现，他们的个数是一样多的，这肯定是当然的啦！
部分.png (15.84 KB, 下载次数: 1)
下载附件
2021-1-5 20:13 上传
（看来被重定向的API有299个啊）接下来，我们就要写修复脚本了，我们巧妙地利用一下表格的功能，就能很快写出一个修复脚本啦！
修复脚本.png (16.25 KB, 下载次数: 1)
下载附件
2021-1-5 20:18 上传
有点投机取巧呢，哈哈。修复：先到达OEP，然后运行此脚本，刷刷刷！就好了。然后我们用LordPE 修复一下镜像，dump出来，然后用 ImportREC，填好OEP偏移后直接点自动搜索IAT,修复。
修复.png (40.15 KB, 下载次数: 0)
下载附件
2021-1-5 20:26 上传
看到这一排函数，是不是特别激动呢！{:1_927:}
可是，可别高兴太早了，这个时候。还是不能运行！（当初分析到这里的时候差点就吐了）我就直接把我分析的结果和 正确思路 直接和大家分享吧。回到得到全都是API地址的表格，我们利用表格将相同的地址给标记出来，终于发现问题出在哪里了。原来是有一些函数没有经过 上面提到的 mov dword ptr ds:[ecx],eax 所以也没放进备份地址。所以导致读取了两次一样的地址：
1.png (14.68 KB, 下载次数: 0)
下载附件
2021-1-5 20:38 上传
，
2.png (15.85 KB, 下载次数: 0)
下载附件
2021-1-5 20:38 上传
，
3.png (14.92 KB, 下载次数: 1)
下载附件
2021-1-5 20:38 上传
，
4.png (14.74 KB, 下载次数: 1)
下载附件
2021-1-5 20:38 上传
，
5.png (16.12 KB, 下载次数: 1)
下载附件
2021-1-5 20:38 上传
，
6.png (14.7 KB, 下载次数: 0)
下载附件
2021-1-5 20:38 上传
我姑且将这些没经过 mov dword ptr ds:[ecx],eax 的函数地址称为二次加密的入口地址。由上表我们也可以知道，这些二次重定向地址 它们本应该填充到的地址分别为：[Asm] 纯文本查看 复制代码4812B0
481268
481224
481190
481298
4812E4为了搞清楚这些二次重定向的API地址的真实地址到底是什么，我用了许多方法。你们可以在系统的DLL上下访问断点 然后改汇编指令 调用一下这些地址。看一下它到底调用了那些API（注意，此处要先让壳的代码先写出之后才行，因为重定向要进入壳代码。刚开始壳代码是空白）。。等等多种方法。不过一般工作量是真的大！如果有更好的方法能告诉我吗？我这里就直接把我多次分析的结论告诉你们。仅针对 VC程序（其他语言没有研究）。
被二次加密的API分别是：
1.ntdll.RtlSetLastWin32Error
2.ntdll.RtlSizeHeap
3.kernel32.ExitProcess
4.ntdll.RtlReAllocateHeap
5.ntdll.RtlGetLastWin32Error
6.ntdll.RtlUnwind
7.ntdll.RtlDeleteCriticalSection //这应该是仅针对控制台程序
总之，前6个函数必定会二次加密
这是我多次加壳后脱壳修复都会遇到的二次加密的API地址。
？什么？你问我怎么知道哪个是哪个？好家伙，上面不是提供了一种方法给你了吗？举个例子。
我想知道 4812B0 处真正的API地址是什么就直接改汇编指令，CALL他！
试试.png (15.22 KB, 下载次数: 0)
下载附件
2021-1-5 21:11 上传
然后我猜他是ntdll（因为大部分是ntdll）的，直接下内存访问断点
试试2.png (20.75 KB, 下载次数: 0)
下载附件
2021-1-5 21:11 上传
F9运行，就直接看EIP了：
试试3.png (25.7 KB, 下载次数: 1)
下载附件
2021-1-5 21:11 上传
但这种方法不是万能的，因为DLL的调用就像套娃一样，相互调用。如果都行得通，我们岂不是不就可以每一个函数都这么找吗？
所以这里也是有点运气成分在。还有，我这里改的是OEP的下一行，因为到了OEP，壳代码也肯定都恢复了。其实也不一定要在这里改，你在区段的Themida段下一个内存写入断点，当他写完所有的壳代码后，应该也可以直接CALL，不过这时候是 CALL 65437F ， 不是 CALL [4812B0] 。总之找个方法CALL它就行了。方法二：在上面的函数都下一个断点，然后再CALL重定向的地址，看看程序被断在哪，就可以知道哪个重定向地址对应哪个API。（这个方法应该更加好用）
最后：
费了九牛二虎之力，终于脱完了。也可以成功运行，试了一下，是可以跨平台的。
成功.png (44.46 KB, 下载次数: 0)
下载附件
2021-1-5 21:25 上传
（区段也要优化一下，不然程序太大了）
课件下载：
"
练习下载：
"
如果你觉得我这篇文章还行，请给我一个免费的
热心值
，求求了，这对我真的很重要！
