不知道rafael在幹什麼，3.0的殼完全是倒退。。。
3.0的TM/WL沒有混淆iat call，還把API代碼抽取給刪了。API出現的特徵代碼也不見得加強了多少
修iat最難的就是
1.定位API出現的時機
2.識別並還原iat call
這裏第2難點由於3.0沒有混淆iat call，所以不存在。想學習的請看這篇文章及其腳本（用x64dbg單步走腳本看，別瞪代碼）SE_IAT修復
來說說第一點
說第一點之前，我還是想先給出我的思考。
iat call的流程是：
iat call>>進入混淆後的殼代碼>>取出要調用的API地址>>調用API
這裏我們要關注的就是 取出要調用的API地址。
殼代碼必然會在某一個時機將API地址取出來，並放在寄存器或者棧（甚至是堆）中
而我們要做的就是定位到這個時機。
老方法都是用代碼特徵碼，根據API地址出現的時機，將周圍的代碼作爲特徵碼。當腳本檢測到這片代碼時，便停下來取API地址。
但是這個方法存在一個問題：
代碼各種不同的混淆，取API地址的代碼特徵碼千變萬化，怎麼辦
當時我想到這個問題時，我不禁在想：
我是怎麼知道API地址出現了？
仔細一想，可不就是x64dbg的註釋信息告訴我了嗎？那麼說明x64dbg是自帶API識別功能的。
可惜我查過所有腳本命令後，發現沒有這個識別API的命令。無奈向Mr.mrexodia提問
Mr.mrexodia半月後就提供了一個API：
mod.isexport()
參數爲寄存器或者內存地址。
如果是API地址，則返回1，否則返回0
例如要判斷eax/rax是否爲API地址：
mod.isexport(cax)==1
至此，大麻煩已經解決了。
只要一直步進跟蹤iat call，並用這個命令做爲判斷條件即可找出API地址了，而不用再定位代碼的特徵碼。
ticnd (mod.isexport(cax)==1),0x100：
步進跟蹤0x100步，當cax爲API地址時停下
這裏放一個Themida/WinLicense3.0 IAT修復腳本(x64)
僅供學習參考，不保證伸手黨能直接用
腳本鏈接