查看文章 |
2008/12/10 哎,微点的响应速度真快,一下就改进了.微点升级后的效果如下: nt!NtSetSystemInformation+0x358: 或许微点在有的机器上有效,在有的机器上无效??? 还是看了这篇搓文后立马修改了代码??? 靠, 真不厚道!!!升级之后总得说一声吧,害得我为了兼容微点,还得换其他方法搞. 囧 ----------------------------------------------------------------------------------------------------------------------------------- 2008/12/06 老技术,所以随便提醒下. 关于HOOK MmLoadSystemImage.可以监测到由SCM、ZwLoadDriver、ZwSetSystemInformation等加载的驱动信息,以便进行及时的记录,patch, 当然瑞星的卡卡助手06年用的老技术 -- 从DriverEntry回溯一层找到IopLoadDriver中call DriverEntry,再进行patch拦截,也是个不错的选择. 其他诸如SSDT层面的就不说了. by sudami 2008-12-06 微点之所以在拦截驱动加载方面过滤不严格,不是他们没有注意这块,而是在处理hook MmLoadSystemImage上code的写法有问题,如下: 1. MP110003.SYS 调用ZwSetSystemInformation来加载到C盘根目录的测试驱动"\\??\\c:\\hook.sys".时未attach到CSRSS.EXE进程空间, 而是在SYSTEM空间中去调,显然EPROCESS中的ProcessInSession标志位是0, 自然没有足够的section来存放新的Driver,于是很强大的返回0xC0000017(STATUS_NO_MEMORY)错误.根本进不到微点瞬间下的钩子里面去. 2. 微点很猥琐的通过栈回溯找到了Call MmLoadSystemImage地址,既而找到原始的MmLoadSystemImage地址.不过微点的驱动开发人员却还要进一步特征匹配,在地址-0x100h内搜索出 0x266Ah 才肯HOOK. 这样匹配还不如找Call MmLoadSystemImage下方的call RtlImageNtHeader校验. 我测试了N中环境,都没有出现过0x266Ah字符串,所以微点自然放弃了对ZwSetSystemInformation内部调用MmLoadSystemImage处的CALL HOOK. 不过微点挂了NtMapViewOfSection,还有个ImageNotify,监控起来也差不多了.据MJ同学说ImageNotify比MmLoadSystemImage更底层,所有的回调都是很底层的,不过我觉得Notify太容易被摘了(当然HOOK也很好恢复,没有万能的对策). 找MmLoadSystemImage的地址,方法很多,若要暴搜,绝对不要全部硬编码特征匹配,很搓很不稳定, 所以啊MJ同学说搜一个XX即可,"(应某同学要求,打成马赛克)"哈哈,我的想法是在xxxx里面找每个call,分析call的函数地址开头0x20字节,就可以快速找到了. 不过我是这样做的,通过栈回溯找到MmLoadSystemImage,然后把它里面的那个xx搞成别的, 嘿嘿,这样我的程序强奸完系统后,其他恶意程序暴搜的话就够呛了... 简单用栈回溯做了个监控的,如下:
至于在fake_MmLoadSystemImage里面做处理,就可随自己做了. 比如黑白名单判断,patch 驱动的XX,单纯的记录... 也可在创建Object或Section时候拦截,效果也不错. 其实没必要这样复杂嘛.挂钩下ZwLoadDriver足矣,再把几个进R0的关键API挂上, 一个小型监控驱动加载的HIPS就成型了. 啊啊啊啊啊啊啊啊~~~ 我呢,非常搓,看见微点更挫,所以我便用更加搓的方式来搞了.各位同学切勿效仿切勿效仿~  |
