关于对GKR测试的一点解释~算是道歉吧

这里要说明两件事情。

首先,icesword是需要在第一次启动时静态加载驱动的,完成这个步骤后,就是ring0级别的东西了,而且加载驱动成功后,不会保留原文件,而是删除,所以也无法找到它。由于虚拟机中多用于测试病毒,所以icesword的使用频率是十分高的,为了图方便,自己手工把它的驱动做成了一个类似于服务的启动加载项目,导致了在GKR中测试可以直接越过防御启动icesword的现象。

至于格式化的问题,文章并没有指明使用format指令来做这件事情,你可以采用其他的方式,这个微软的msdn光盘中类似的底层读写工具很多,这个不是讨论的话题所在,应为前面已经被icesword等破坏了环境,所以可能存在偏差,我使用的是pq也就是分区魔法师的中文版本做到的。

关于icesword解决卡巴的问题,其实,只要前面的驱动加载完成,那么结束卡巴是轻而易举的事,即使打开了自我保护也是无效的。

现在回过头来说说GKR的实际情况。

对于驱动方面的加载保护做的还是十分到位的,保护了驱动的关键项目,也hook了一些必要的ssdt节点。

这些hook点帮助了这个软件的监控得到了提升,同时,由于把文件,注册表,进程进行了分离编写,所以就不容易被破坏。可以相互恢复(虽然没有这样测试过。)

对于启动项,还是中规中矩的服务+GUI的形式

对于这两个进程而言,对于debug攻击的防御还是做的比较好的,没有出现一调试就挂的现象.

静态驱动的分布,总共4个。

测试后的不足之处:

1、对于ring3的冷僻方式的保护还是不够,能够被古老版本的工具摘驱就说明之间存在需要改进的地方。

2、防火墙需要加强,真的不能只靠端口防御来解决问题,虽然说企业中有网关,用硬件防火墙等等,对于桌面产品,我觉得防水的意义更大一些。

3、不知道是否支持arp的防御,由于没有测试环境,所以无法测试。

4、制定性有待提高,虽然产品时时刻刻体现出简约的风格,但是适当的设置功能还是需要留给用户的,例如自定义规则,这个可以参考咖啡。

5、还是建议采用inline-hook的方式,虽然相对于ssdt来说要求更高,但是ssdt注定是不稳定和不可控的挂载模式。

写在最后:

由于我的失误,犯了一个十分幼稚的错误,这点先在此道歉,同时也十分感谢大小姐对我的支持。对于已经散发出去的文章,我希望大家一笑了之。从发出去的帖子的反馈看,更多的朋友关注的是文章中关于国内环境的论述,而非针对于产品。这点让我松了一口气,至少没有让别人损失。

谢谢大家的支持~

alex

Related posts

发表评论