[目录]
[0x01].简介
[0x02].隐形解密技术
2.1.为什么要使用隐形解密
2.2.隐形解密的前提条件
2.3.基于API的隐形解密器结构
2.4.隐藏IAT
[0x03].反AVs启发式检测技术
3.1.anti-Heuristic
3.2.获得"safe api"
3.3."碎片化"解密器
[0x04].反AVs特征检测技术
4.1.解密器多态处理
4.2."规则化"的多态引擎(Kpasm)
4.3.继续强化
[0x05].Win32/Leon的检测与分析
5.1.代码段扫描
5.2.动态代码分析
5.3.静态代码分析
[0x06].其他
[0x01].简介
Win32/Leon（by kaze）病毒中首次使用了对病毒解密器进行非传统多态方式的伪装技术,这是一种的新的反启发式检测的方式,也就是基于API的隐形解密,以此来做到强于EPO的效果，
目前看,能对该病毒感染后的文件完全检测的AVs产品还很少，下面将对该技术进行分析,同时给出可行的检测方案。
[0x02].隐形解密技术
2.1.为什么要使用隐形解密
众所周之，加密、多态病毒是逃避特征检测的最好方案（木马加壳一类不属于我们讨论的技术范畴）,但无论是加密病毒还是多态病毒,如果aver在不考虑进
行完全修复而仅是最大限度的检测病毒的情况下,最有效的检测位置就是解密器的那部分代码（sanboxes除外）,所以解密器是vxer和aver的必争之地,进而vxer
针对该位置进行混淆,早期代表性的病毒有whale,MtE,hps,Vulcano...和由此产生的大量的polymorphism引擎。
所以，此后的一段时间polymorphism偏向于复杂化,以难以让AVs检测为目的，同时尽量让代码变换得难以理解。 但有一点要注意的就是，一个多态引擎无论写的多好，
一旦aver有了针对它的检测方案，那么再使用这个引擎进行伪装就是很危险的了。Win32/Leon采用逆向思维的方式来考虑这个问题,让病毒程序的入口代码--解密器
（仅指加密、多态类病毒）尽量做到普通化，大众化，像普通应用程序一样平淡无奇，迫使AVs仿真器退出检测，这也就是隐形解密技术的产生原因。
2.2.隐形解密的前提条件
win32/Leon使用隐形技术的两个前提假设条件是:
1)当前的AVs仿真器都不仿真APIs，至少不会仿真所有的APIs.
2)如果仿真器分析的代码看起来像普通的应用程序，并且再去调用那些没有被AVs仿真的APIs，那么仿真器很有可能会取消检测.
这两个假设有些牵强，但作为桌面防毒产品，不大可能花费非常多的时间用于仿真方面的检测，所以这样的假设是有实现可能的.
常见的病毒解密器要编写的复杂和难以让仿真器执行，Win32/Leon要建立一个看起来像普通程序的代码,是一个”无害的代码块“，仅使用普通的APIs调用，不使用xor等
常见的解密方式及特殊的opcode，因为很少有病毒利用APIs作为解密器，更多都是使用垃圾指令来填充。同时Win32/Leon 还考虑了，当仿真器退出后，基于API序列的检测还
会继续扫描，进而继续隐藏API序列。
2.3.基于API的隐形解密器结构
可以完全的肯定，利用现有的APIs能完成解密器的设计的工作，关键是选择哪些APIs，Win32/Leon使用了标准的Microsoft CryptoAPI系列API，因为这很方便也是现成
加解密的方案，同样还可以选择其它的APIs，这就需要耐心一点的寻找，kaze推荐的有BitBlt，因为BitBlt的最后一个参数dwRop，提供多种逻辑操作手段，比如
BOOL BitBlt(
HDC hdcDest, // handle to destination DC
int nXDest, // x-coord of destination upper-left corner
int nYDest, // y-coord of destination upper-left corner
int nWidth, // width of destination rectangle
int nHeight, // height of destination rectangle
HDC hdcSrc, // handle to source DC
int nXSrc, // x-coordinate of source upper-left corner
int nYSrc, // y-coordinate of source upper-left corner
DWORD dwRop // raster operation code
);
dwRop 可选择
PATINVERT 会执行一个xor操作
MERGECOPY 会执行一个AND操作
而且这些指令的执行是在GPU上，而不是CPU上，算是个很好的anti-emultor。有关图形图像的APIs，会有很多的数据逻辑操，这些都可以成为备选目标。Win32/Leon使用如下
方式：
csp dd ?
hash dd ?
key db 48 dup (?)
hkey dd ?
call CryptAcquireContext, offset csp,0,0,PROV_RSA_FULL,CRYPT_VERIFY_CONTEXT
call CryptCreateHash, csp,CALG_MD5,0,0,offset hash
call CryptHashData, hash, offset key,4,0
call CryptDeriveKey, csp,CALG_RC4,hash,48,offset hkey
call CryptDecrypt, hkey,0,1,0,start_of_virus,size_of_virus,start_of_virus
这样就可以利用cr4对称密钥算法来解密病毒体，同样Win32/Leon也内置了一个xor方案的解密，但很少用。Win32/Leon中主要是利用CryptoAPI系列构建解密器。
2.4.隐藏IAT
首先修改宿主程序的IAT：
1）扩展最后一个节，分配一个空白数据空间，拷贝宿主程序的IAT到这里。
2）添加一个IID(image import descriptor)项到宿主程序，也就是解密时用到的APIs函数，CryptoAPI系类函数都在advapi32.dll中导出，所以无论宿主程序是否导入了
advapi32.dll，都要新添加一个IID目录项，有两个DLL同名的IID项是不影响PE程序执行的。
3）给上面添加的IID中FirstThunk和OriginalFirstThunk，填入适当RVA,使其指向解密时能用用到的函数名称，CryptAcquireContext","CryptCreateHash", "CryptCreateHash"...
这时再调用这些APIs解密时，就和普通的应用程序没有区别了，因为通常的病毒程序的做法是自己搜索这些API的地址。但由于添加的IID过于明显，为了防止AVs的特征检测，
Win32/Leon使用了两个小技巧。
* 对 OriginalFirstThunk和 FirstThunk 指向的函数名称随机存放。
* 考虑到，如果在advapi32.dll中仅导入CryptoAPI系列函数，那么启发式检测就可以轻松的发现这个异常，所以在导入函数时，在随机的导入一些其他的函数。
一个修改后的宿主IAT将会是如下方式：
感染前：
PE Header-----.
|
V
+-------------------------------------------------+
.---|----------------< IAT rva |
| |_________________________________________________|
| | section... |
| |-------------------------------------------------|
| | |
.---|-->IAT |
| | .-------> "Sleep" |
| | |-------> "ExitProcess" |
| | |------... |
| | | |
| |->Kernel32.dll(FirstThunk) |
| | |
| |->user32.dll(FirstThunk) |
| |... | |
| |--------> ... |
| |--------> "DrawRect" |
| .--------> "GetDC" |
+_________________________________________________+
| |
| section n |
+-------------------------------------------------+
感染后：
PE Header-------.
|
V
+-------------------------------------------------+
.---|--------------< IAT rva |
| |_________________________________________________|
| | section... |
| |-------------------------------------------------|
| | |
| | ori IAT |
| | .-------> "Sleep" |
| | |-------> "ExitProcess" |
| | |------... |
| | | |
| | .------>|->Kernel32.dll(FirstThunk) |
| | | | |
| | .------>|->user32.dll(FirstThunk) |
| | | |... | |
| | .---. |--------> ... |
| | | |--------> "DrawRect" |
| | | .--------> "GetDC" |
| +_____|___________________________________________+
| | | |
| | | section n |
| | | |
.---|-->new IAT >------------. |
| | |
| V |
| advapi32.dll(FirstThunk) |
| | |
| "random api 1"<-----|--->"CryptDeriveKey" |
| | |
| "random api n"<-----|--->"CryptDecrypt" |
| |
|-------------------------------------------------+
| virus body |
+-------------------------------------------------+
这样一个解密器基本需求就建立起来了，它可以像普通应用程序那样解密virus body，并且对IAT中的函数进行patch，可以躲过一般的静态扫描，但这样还远远不够，Win32/Leon
还在继续伪装解密器。
[0x03].反AVs检测技术
3.1.anti-Heuristic
由于在程序执行过程中，解密器的调用API的序列固定，所以Win32/Leon 尝试随机的插入一些API调用放到解密器的代码之中，这里kaze提出了一个“safe api”的概念，但这里
的“safe api”不是MS概念中的安全API，而是指“可随机构造API函数的输入参数值，然后调用它，除了返回错误码外，不影响程序运行的API”.例如 CloseHandle这个函数，我这样调用
call random ; eax 存放随机值0 ~ 2^32-1
mov ecx,eax
puhs ecx
call CloseHandle; eax 中会存入一个返回值（错误码）
可以99.9999%的肯定，这样的语句加入程序中，除了得到一个错误码外，不会影响任何事情，所以kaze的想法就是在解密器的代码中，随机的位置，插入随机的这样的“safe api”，这是
Win32/Leon对抗启发式检测的主要思路。
3.2.获得safe api
1)选择我们的要找的api所以在模块，比如kernel32.dll user32.dll advapi32.dll gdi32.dll 中导出的函数
2)对于每一个api，我们并不知道它有多少个参数，所以在堆栈中压入20个参数，看有多少个dword被pop出来，这个数字就是函数的参数。
3)调用api多次，并且每次随机选择不同的参数进行调用
4)如果没有异常抛出，也没有崩溃，那么这个api就是一个safe api
kaze 编写了一个工具，自动的跑出了这些结果，在os（winxp sp1 sp2 / win2k) 中取这些结果api的交集。下面列出一部分这样的safe api。
kernel32.dll
参数个数：名称
1 ; AddAtomA
1 ; AddAtomW
3 ; AddConsoleAliasA
3 ; AddConsoleAliasW
0 ; AllocConsole
3 ; AllocateUserPhysicalPages
0 ; AreFileApisANSI
2 ; AssignProcessToJobObject
1 ; CloseHandle
0 ; CloseProfileUserMapping
1 ; CmdBatNotification
...
ws2_32.dll
参数个数：名称
0 ; WSACancelBlockingCall
0 ; WSACleanup
1 ; WSACloseEvent
7 ; WSAConnect
0 ; WSACreateEvent
3 ; WSADuplicateSocketA
3 ; WSADuplicateSocketW
2 ; WSAEnumNameSpaceProvidersA
....
user32.dll
参数个数：名称
2 ; ActivateKeyboardLayout
4 ; AlignRects
1 ; AllowSetForegroundWindow
3 ; AnimateWindow
0 ; AnyPopup
1 ; ArrangeIconicWindows
3 ; AttachThreadInput
0 ; DestroyCaret
1 ; DestroyCursor
1 ; DestroyIcon
1 ; DestroyMenu
...
以上这些api在win2k和winxp下进行调用基本都是安全的，但在vista下如果传入错误参数，会有5~10%的函数抛出异常，因为Win32/Leon主要是xp/2000平台，在这方面也就没有继续
筛选。
3.3."碎片化"解密器
为了获得更好的混淆效果，Win32/Leon将解密器分成若个chunk代码块，每一个chunk块包含一个API的调用，这些块随机的写入宿主程序的不同位置，首块位于宿主程序的EOP处，
宿主程序被改写的这些代码或数据保存在virusbody中，在virus退出时，重新写回宿主程序，然后再jump到宿主程序入口OEP，继续执行宿主程序。当然选择这些位置时要格外的小心，
避免宿主程序被破坏，还包括重要的PE结构也不能破坏（IAT, EAT, ressources, tls ...），感染后的一个文件可能情况如下：
PE header -----------.
|
V
+-------------------------------------------------+
| EOP-----|------.
|_________________________________________________| |
| section 1(code) | |
| +-------+ +------+<--------|------.
| |api #2 |<----------------- |api #1| |
| +-------+ +------+ OEP<===|======\
|--------|----------------------------------------| |
| | section 1(code/data/reloc...) | |
| | | |
| .---------------------->+-------+ | |
| +--------+ |api #3 | | |
.----|----|api #n |<--------------. +-------+ | |
| | +--------+ | | | |jmp OEP
| | \------/ | |
| | | |
| |-------------------------------------------------| |
| | section n | |
| |-------------------------------------------------| |
| | | |
| | +-------+ +-------+ +-------+ +--------+ | |
| | |save #1| |save #2| |save #3| |save #n | | |
| | +-------+ +-------+ +-------+ +--------+ | |
| | | |
.--->| virus body |======/
+-------------------------------------------------+
为了防止启发式检测，chunk块之间的调用要加入混淆，假设AVs不知道一个API调用的参数个数(基于不会仿真所有api的假设)，那么在执行chunk #k块向chunk #k+1块调用时，
将采用如下的方式：
chunk #k ---> CloseHandle 带1个参数
chunk #k+1 ---> lstrcmp 带2个参数
chunk #k chunk #k+1
+-------------------------------------+ .---->+-------------------------------+
| | | | |
| push fake_address1 | | | push fake_address1 |
| push fake_address2 | | | push fake_address2 |
| | | | push fake_address3 |
| * push chunk#k+1_address * -----|-------. |* push chunk#k+2_address *... |
| | | |
| push random() | | push random() |
| call CloseHandle() | | push random() |
| ret | | call lstrcmp() |
+-------------------------------------+ | ret |
+-------------------------------+
这样，因为AVs在chunk #k中不知道参数的个数，导致无法分析出chunk #k+1情况下的函数调用（当然这些对具有完备的sandbox功能的AVs是无效的，对付的是中等品质的仿真器）,基
于以上的种种处理，Win32/Leon将具备一定anti-emultor功能。但对抗AVs特征检测方面还比较薄弱，针对这一点，主要使用多态方式。
[0x04].反AVs特征检测技术
4.1.解密器多态处理
对抗特征检测最有效的方式就是对解密器进行多态伪装，但Win32/Leon多态的目的不同于以往病毒的多态引擎，因为要求代码多态后也要使解密器看起来像普通的应用程序调用，
Win32/Leon没有使用标准的多态引擎，因为那会使代码看起来怪怪的，还会有些少见的opcode出现，这些对于高级别AVs仿真器很有可能会报毒”suspicious“。kaze在多态方面使用规则化
的多态引擎思路。
4.2.”规则化“的多态引擎（Kpasm）
kpasm是一个更像编译器的工具，只不过它按照规则产生一个多态代码的工具。而它的规则编写则更像是高级语言，有点像C语言,执行过程如下:
.-------.
rule_kpasm.txt------>| kpasm | ----------->poly_kpasm.asm----.
.-------. |---> virus.exe
virus.asm----.
产生的混淆代码可能如下：
mov reg,data <== > mov reg,0 , add reg,data
规则会列出这样的一组描述，而引擎针对的处理则是个复杂的产生过程，比如会使用随机寄存器，jumps，loops，mem read ，mem wirte 等操作手段操作。
因为规则就是对产生指令的描述，所以同样要避免产生僻指令，及过多的使用stc ，clc 这样的指令。Win32/Leon 使用的规则如下:
*标准操作: mov, add, sub, lea, cmp, jmp, push, pop, etc.
*API 调用: junk api
*jumps : 产生Predicate
*junk ：少量的junk loops
Win32/Leon 使用的多态并不多，而且也只是为了对付特征检测而加入的。但要保证的是，当产生两个类似的解密器时,要产生完全不同的代码，当然这需要一个平衡，多态过多
容易引起仿真器的报警，太少则无法绕过特征检测。
kpasm 的规则语法也很简介，依据自己的思路就可以产生任意一个等效指令，部分规则描述如下:
//----------------------- **** mov regx,xxx **** --------------------------------//
mov_reg_cst(reg:registre,cst:entier)
{
1: {
mov_reg_cst(reg,cst-[freemem0]); // 等效 mov reg,cst-[mem] ; add reg,[mem]
junk();
add_reg_mem(reg,freemem0);
}
1: {
mov_reg_cst(reg,cst+[freemem0]); // 等效 mov reg,cst+[mem]; sub reg,[mem]
junk();
sub_reg_mem(reg,freemem0);
}
1: {
mov_reg_mem(reg,freemem0); // 等效 mov reg,[mem]; add reg,cst-[mem]
junk();
add_reg_cst(reg,cst-[freemem0]);
}
1: {
mov_reg_mem(reg,freemem0); // 等效 mov reg,[mem] ; sub reg,[mem]-cst
junk();
sub_reg_cst(reg,[freemem0]-cst);
}
1: {
mov_reg_cst(reg,cst-1); // 等效 mov reg，cst-1 ; inc reg
junk();
inc_reg(reg);
}
4: DEFAUT // 不经过任何变换
{
write8(0xB8|reg);
write32(cst);
}
}
//------------------------ **** cmp [xxx],yyy ****--------------------------------//
cmp_mem_cst(mem:adresse,cst:entier)
{
1: {
mov_reg_mem(freereg0,mem); // 等效 mov tmp_Reg , mem ; cmp tmp_reg , cst
cmp_reg_cst(freereg0,cst);
}
4: DEFAUT { // 不经过任何变换
write16(0x3D81);
write32(mem);
write32(cst);
}
}
// ---------------------------------------------------------------------------------//
其余的规则于此类似不再赘述，Win32/Leon的一部分多态的代码如下：
6A EC push -14
FF35 18880001 push dword ptr ds:[1008818]
8BD8 mov ebx,eax
FF68 94 jmp far fword ptr ds:[eax-6C]
14 00 adc al,0
01BE 40B13801 add dword ptr ds:[esi+138B140]
8B0D 2F280301 mov ecx,dword ptr ds:[103282F]
2BF1 sub esi,ecx
43 inc ebx
B8 D2110301 mov eax,KAZENO~1.010311D2
8998 CD150000 mov dword ptr ds:[eax+15CD],eb
8935 AB270301 mov dword ptr ds:[10327AB],esi
FF35 AB270301 push dword ptr ds:[10327AB]
68 00008000 push 800000
FF35 1B280301 push dword ptr ds:[103281B]
A1 8B270301 mov eax,dword ptr ds:[103278B]
05 8DB2F7FF add eax,FFF7B28D
BF 351B0301 mov edi,KAZENO~1.01031B35
8BB7 520D0000 mov esi,dword ptr ds:[edi+D52]
A3 2F270301 mov dword ptr ds:[103272F],eax
对函数调用的一个混淆如下：
68 2F600001 push KAZENO~1.0100602F -------------> stack中压入下一个chunk块的地址
FF35 EB270301 push dword ptr ds:[10327EB] @1
C705 2B270301 653594>mov dword ptr ds:[103272B],5E943565
BB FF38AD3E mov ebx,3EAD38FF
BD 86AFDCE6 mov ebp,E6DCAF86
FF35 2B270301 push dword ptr ds:[103272B] @2
FF35 03280301 push dword ptr ds:[1032803] @3
68 E1F5FE63 push 63FEF5E1 @4
BD 87280301 mov ebp,KAZENO~1.01032887
8B5D 08 mov ebx,dword ptr ss:[ebp+8]
41 inc ecx
891D 9B270301 mov dword ptr ds:[103279B],ebx
FF35 9B270301 push dword ptr ds:[103279B] @5
FF35 F3270301 push dword ptr ds:[10327F3] @6
FF15 04110001 call dword ptr ds:[<&KERNEL32.CompareStringW>]
8B3D 0F280301 mov edi,dword ptr ds:[103280F]
C3 retn
可以看到在一个函数的参数之间，有随机的寄存器，内存读写，而且整体代码看起来是合法的调用，参数都是随机产生的，所以感染一个宿主程序两次，即便是同样的调用
CompareStringW的代码块，也很难出现连续3个字节以上相同的特征，所以重复的几率是微乎其微的。
4.3.继续强化
通过重定位方式可以继续对解密器的代码进行混淆，当然，这样要求宿主程序也要有.reloc节，或者再新添加一个.reloc节，一般来说有.reloc节的PE文件占整体的~5%。这一技术
最早描述在29a#5 tcp写的Encryptation through relocs 中，Win32/Leon中思路和那篇类似，也就是利用重定位节中的数据再次对病毒代码进行解密,而这个解密是windows帮我们做
的，在此不再赘述。
通过以上种种对抗方式使得Win32/Leon是一个难于检测的感染式病毒，能对其准确报出病毒名称的也只有avp,a-squared,Sophos等...。kaze在将病毒发给AVs三周后，sophos 能对
感染后的文件保持在~80%的检出率，而其他的都低于20%。6个月后，sophos达到~95%，avp ~15%，sophos利用的是解密器的若干个有效的特征码，所以针对Win32/Leon产生的特征码文件
也很大。其他AVs检出率不高，有可能是传播不广的原因。
[0x05].检测分析
首先我们知道，对于隐形解密技术，一定要加入一个IID到宿主程序，这样有可能会产生两个同名DLL的IID，这在标准编译器编译出来的程序中是极为少见的（我不确定是否
是能通过配置编译选项，作出那个效果来）,对检测来说，这是很重要的一点，可以配合其它的检测信息来确定是否是隐形解密类病毒感染的。下面将从3方面入手进行检测。
5.1.代码段扫描
我们知道，即便宿主没有导入advapi32，也会由病毒添加了一个advapi32 IID到PE结构中,其里面的API名称是由cryptAPI系列和随机的用于混淆的特征检的其它api组成,而这
些api并不会所有的,都在宿主程序中被调用，而正常程序的导入表的api都是由编译器自行生成的，都是源代码中一定调用的，这样我们可以通过扫描代码段来发现这样的差异。
同样对整个节进行扫描，注意，我们扫描整个节数据,仅当我们忽略对寄存器调用这种情况的分析时，会发现，被其感染后的宿主程序会有如下明显的特征序列，所以该方式也可
以作为检测依据，当然，仅当被感染的宿主程序使用如下结构的调用方式：
mov Rx , 0x7xxxxxx ;0x7xxxxxx => CreateProcessA address
call Rx ;=> call CreateProcessA
// -------------------------------------------------------------------------------------------------------------
api call -> off:0x00000913:CryptDecrypt
api call -> off:0x00002a8a:CryptHashData
api call -> off:0x000046e8:CryptAcquireContextA
api call -> off:0x0000544e:CryptCreateHash
api call -> off:0x000059dd:CryptDeriveKey
api call -> off:0x00000913:CryptDecrypt
api call -> off:0x00002a8a:CryptHashData
api call -> off:0x000046e8:CryptAcquireContextA
api call -> off:0x0000544e:CryptCreateHash
api call -> off:0x000059dd:CryptDeriveKey
api call -> off:0x00000913:CryptDecrypt
api call -> off:0x00002a8a:CryptHashData
api call -> off:0x000046e8:CryptAcquireContextA
api call -> off:0x0000544e:CryptCreateHash
api call -> off:0x000059dd:CryptDeriveKey
api call -> off:0x00000913:CryptDecrypt
api call -> off:0x00002a8a:CryptHashData
api call -> off:0x000046e8:CryptAcquireContextA
api call -> off:0x0000544e:CryptCreateHash
// --------------------------------------------------------------------
注意APIs前面的地址数据值，都是间距很大的跨越，这是”碎片化“解密器的结果。
....
5.2.动态代码分析
在bytehero team内部的动态代码分析环境（Win32/Leon的anti-emultor对bdv无效）中分析，会发现如下调用方式：
0x90000052(0x02E3F91C)--->0x01006B22 CreateFileW -->@ safe api
0x90000C87(0x02E3F91C)--->0x010052EE CryptAcquireContextA --># decryptor code
0x90000038(0x02E3F91C)--->0x01001CFC CompareStringW -->@ safe api
0x90000C8A(0x02E3F91C)--->0x01006054 CryptCreateHash --># decryptor code
0x90000C9F(0x02E3F91C)--->0x01003690 CryptHashData --># decryptor code
0x90000038(0x02E3F91C)--->0x010058CF CompareStringW -->@ safe api
0x90000C8C(0x02E3F91C)--->0x010065E3 CryptDeriveKey --># decryptor code
0x90000C8B(0x02E3F91C)--->0x01001519 CryptDecrypt --># decryptor code
0x90000247(0x02E3F91C)--->0x01018E7D LocalAlloc
0x90000247(0x02E3F91C)--->0x01018E7D LocalAlloc
0x90000247(0x02E3F91C)--->0x01018E7D LocalAlloc
0x90000247(0x02E3F91C)--->0x01018E7D LocalAlloc
0x90000051(0x02E3F91C)--->0x01030B80 CreateFileMappingW
0x90000241(0x02E3F91C)--->0x01030B29 LoadLibraryA
0x90000241(0x02E3F91C)--->0x01030B29 LoadLibraryA
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000241(0x02E3F91C)--->0x01030B29 LoadLibraryA
0x90000052(0x02E3F91C)--->0x01030B80 CreateFileW
0x90000052(0x02E3F91C)--->0x01030B80 CreateFileW
0x90000197(0x02E3F91C)--->0x01030B29 GetProcAddress
0x90000241(0x02E3F91C)--->0x01030B29 LoadLibraryA
0x90000051(0x02E3F91C)--->0x01030B80 CreateFileMappingW
0x90000051(0x02E3F91C)--->0x01030B80 CreateFileMappingW
0x90000197(0x02E3F91C)--->0x01030B29 GetProcAddress
0x90000038(0x02E3F91C)--->0x01030B80 CompareStringW
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x900001D1(0x02E3F91C)--->0x01018FDC GetTickCount
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x900000D0(0x02E3F91C)--->0x01030B29 FindFirstFileA
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000592(0x02E3F91C)--->0x01030B29 MessageBoxA -->@ payload
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000371(0x02E3F91C)--->0x01030B29 VirtualProtect
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000371(0x02E3F91C)--->0x01030B29 VirtualProtect
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000371(0x02E3F91C)--->0x01030B29 VirtualProtect
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000371(0x02E3F91C)--->0x01030B29 VirtualProtect
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000371(0x02E3F91C)--->0x01030B29 VirtualProtect
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000371(0x02E3F91C)--->0x01030B29 VirtualProtect
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000371(0x02E3F91C)--->0x01030B29 VirtualProtect
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000371(0x02E3F91C)--->0x01030B29 VirtualProtect
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000371(0x02E3F91C)--->0x01030B29 VirtualProtect
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x90000371(0x02E3F91C)--->0x01030B29 VirtualProtect
0x90000031(0x02E3F91C)--->0x01030B80 CloseHandle
0x9000006C(0x02E3F91C)--->0x010315AC CreateThread
0x90000175(0x02E3F91C)--->0x01006AF7 GetModuleHandleA
... //转向宿主程序调用
这样配合前面提到过的被感染程序IID方面的信息，就可以检测出当前程序是否被感染Win32/Leon了。
5.3.静态代码分析
由于Win32/Leon的payload仅是个msgbox，如果在动态环境中在执行GetModuleHandleA前还不能完全确认其感染，此时动态可转调静态分析，静态分析开头的部分情况如下：
0x0 : 0x1006b63 call[0] - > __p__fmode
0x1 : 0x1006b71 call[0] - > __p__commode
0x2 : 0x1006b8b call[1] - > sub_1006d10
0x4 : 0x1006b9d call[0] - > __setusermatherr
0x5 : 0x1006ba4 call[1] - > sub_1006cfe
0x6 : 0x1006d08 call[1] - > _controlfp
0x8 : 0x1006bb3 call[0] - > _initterm
0x9 : 0x1006bd6 call[0] - > __getmainargs
0xa : 0x1006be9 call[0] - > _initterm
0xb : 0x1006c28 call[0] - > GetStartupInfoA
0xc : 0x1006c4f call[1] - > sub_1002801
0xd : 0x1002809 call[1] - > GetCommandLineW
0xe : 0x1002818 call[1] - > GetSystemMetrics
0xf : 0x100281f call[1] - > GetProcAddress
0x10 : 0x1002838 call[2] - > sub_1001b4a
0x11 : 0x1001b75 call[2] - > CharNextW
0x13 : 0x1002844 call[2] - > sub_10041ca
0x14 : 0x10041d5 call[2] - > RegisterWindowMessageW
0x15 : 0x10041fe call[2] - > GetDC
0x16 : 0x100420f call[3] - > sub_1003d57
0x17 : 0x1003d5b call[4] - > sub_1003cf2
0x18 : 0x1003d15 call[4] - > LoadStringW
0x19 : 0x1003d2d call[4] - > LocalFree
0x1a : 0x1003d40 call[4] - > LocalAlloc
0x1b : 0x1003d5b call[4] - > sub_1003cf2
0x1c : 0x1003d70 call[4] - > LocalAlloc
0x1d : 0x1003d81 call[4] - > LocalSize
0x1e : 0x1003d9c call[4] - > LoadStringW
0x1f : 0x1003dbb call[4] - > lstrcpynW
0x20 : 0x1003e04 call[4] - > MessageBoxW
0x21 : 0x1003e3f call[5] - > sub_1003c15
0x22 : 0x1003c28 call[5] - > CharUpperW
0x24 : 0x1003e5d call[4] - > GetSystemMenu
0x25 : 0x1003e73 call[4] - > LoadAcceleratorsW
...
可以看到，这是一个标准VC++编写的程序开头，同时出现了在病毒程序中一般不会出现的，窗口类,字体，图形类API，可以肯定GetModuleHandleA前开头的代码可能是宿主程序
被加壳后的代码，或是被病毒感染后的结果。
总结一下检测的依据：
1）被感染程序出现同名advapi.dll的IID,同时导入了cryptapi。再通过壳特征库，排除壳的可能。
2）代码段扫描，发现crypt API固定序列，advapi.dll导入函数不是完全被调用。
3) 动态代码分析下，出现crypt AIP固定序列，在调用CryptDecrypt解密结束后，存在大的跨段跳转。
4) 动态代码分析下，出现查找当前目录文件,依据条件感染文件，执行payload，此时动态分析可以确定病毒，停止分析。
5）跳向宿主程序，静态分析出现病毒少见的API调用（窗口类,字体，图形类API）情况，该项依据被感染的宿主程序而定,是补充条件。
这样再配合被感染程序自身的文件特性，就可综合的得出被Win32/Leon感染的结论了。
[0x06].其他
Win32/Leon 使用的隐形解密技术是对AVs有效的一个反击，而且它的规则化引擎也非常有趣，但对反病毒研究人员来说，强大的动态代码分析能力，仍然是对抗这类复杂病毒的
最有效武器。
附参考文献:
[1] kaze. 《Stealth api-based decryptor》
- 标 题：隐形解密技术病毒的分析与对抗
- 作 者：neineit
- 时 间：2010-04-07 22:05:46
- 链 接：http://bbs.pediy.com/showthread.php?t=110428