上次我已经分析了火绒是如何杀死我们进程的,可是没想到哇,客户竟然还会使用文件粉碎机粉碎我们的文件,被逼无奈,我只能继续的分析一下火绒的粉碎文件的实现,我不得不说为什么它会很多的方式去粉碎文件,一个地方注意不到文件就会被删除。难受哇!话不多说,我们现在看看火绒粉碎机是如何粉碎的文件。
首先我们需要找一个很好的切入点去分析,还是从导入表入手,然后再gitHub上找一找别人是如何使用驱动删除文件。驱动删除文件我们就从这个github上看到的删除文件看一下火绒驱动的导入表,还是经典的下断环节。
winDBG开始下断点
命中了第一个断点,还是原来的操作直接让函数返回失败(根据杀死进程的分析,火绒的驱动会使用多种方法去完成所需的功能,因此这个返回失败,它就会调用其他的驱动口,真的很恶心!)然后让第一个断点失效,我们看它还会调用哪个驱动的口。同样的步骤,我们去掉第二个命中的断点,我们又命中了第3个断点,我们依旧如此操作 还是返回失败貌似我们这样都返回失败了以后,我们的文件没有被删除。不过我之前这几个函数返回失败了以后,也依旧被删除了。我们继续看看调用ZwQuerySystemInformation的地方,我已经下断确定过了,也会通过这里获取句柄信息,造成我们的文件被删除。
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入!
CaptainNeil hook火绒的DeviceIoControl确实可以防止文件粉碎,但是如何判断粉碎的是自己的文件还是别人的文件呢? 如果不能的话,那么会导致火绒的文件粉碎功能失效