火绒盾（断开网络失效）问题已经查明～～【问题已经解决】

显示全部楼层 · 发表于 2012-7-31 15:28:40

本帖最后由 zhq445078388 于 2012-7-31 15:32 编辑

vardyh 发表于 2012-7-31 15:22
这图我再补充一点，启动顺序是火绒先起，360后启动，
KGetProcAddress("NdisRegisterProtocol")拿到原始 ...

那个函数没有见过
求真相
不过你的描述让我明白这个函数是取得真实地址的?
这个真实地址是从哪取得的?

不是倒入表中的rav+基地址算出来的?

额是特征扫出来的? 或者自己算偏移硬编码过去?

从ck发的图结合你的话来看
是说火绒挂了iat 然后360hook了eat 360获取到参数后执行原函数时是直接call了真实地址
所以造成iat失效?
这样火绒的网络中断功能自然失效
另外从这个图看

这个函数应该还需要模块名也就是图里的nsis.sys
和需要的函数名..额有空跟进这个函数看看

显示全部楼层 · 发表于 2012-7-31 15:32:31

z13667152750 发表于 2012-7-31 15:24
360 的流量监控和comodo的防火墙，avira的防火墙等都可以正常共存，所以。。。。。。

貌似现在还没看 ...

问题出在火绒和360都在NdisRegisterProtocol 上挂接。。。

显示全部楼层 · 发表于 2012-7-31 15:33:40

zhq445078388 发表于 2012-7-31 15:28
那个函数没有见过
求真相
不过你的描述让我明白这个函数是取得真实地址的?

eat本身是不生效的，生效的是eat传递后的iat，这种hook本身就是一种比较弱势的hook,无论是已经启动，被HOOK的IAT HOOK，还是启动后被挂IAT的hook，都会抢掉eat传递的iat,从而抢在eat的前面。
没去看火绒的代码不知道它怎么hook的IAT的能被eat抢走～

显示全部楼层 · 发表于 2012-7-31 15:34:44

china_killer 发表于 2012-7-31 15:32
问题出在火绒和360都在NdisRegisterProtocol 上挂接。。。

参考53楼，IAT正常挂接无论是先挂接还是后挂接，都是不会受EAT的干扰的，应该比EAT获取执行机会要早。

显示全部楼层 · 发表于 2012-7-31 15:38:54

BootMgr 发表于 2012-7-31 15:34
参考53楼，IAT正常挂接无论是先挂接还是后挂接，都是不会受EAT的干扰的，应该比EAT获取执行机会要早。

不管eat还是iat 其本质不就是有个加载后产生的rav么.
修改这个rav 应该就可以造成其他的hook失效啊..

这是说iat和eat有两个地址么?
不对哇..又说eat生效的是加载后产生的iat..好蛋疼..怎么这么乱啊.

..好像我自己把自己说乱了

显示全部楼层 · 发表于 2012-7-31 15:44:34

本帖最后由 BootMgr 于 2012-7-31 15:52 编辑

china_killer 发表于 2012-7-31 15:32
问题出在火绒和360都在NdisRegisterProtocol 上挂接。。。

下了个火绒，简单看了下这个的实现，搞明白原因了，根本就不是你那个贴图的调用原始的NdisRegisterProtocol 地址的问题，你还是多学习多学习再来发帖吧，再发那种什么“说一套做一套“的低级黑言论，以后连这种找低级BUG我都不帮你们科普了。

火绒是挂了镜像回调（或者如果检测TCPIP.SYS已经加载了就直接去用）去tcpip.sys 内IAT搜寻通过NdisGetRoutineAddress得到的NdisRegisterProtocol 地址，找到后符合的地址后，就去IAT挂钩那个地址

这种方式本来就不靠谱，你怎么知道TCPIP.SYS体内的地址就和你获取的一样，变数太多，这里暴露出来开发者挂钩方案选型时就由于经验不足，导致考虑不周

这里的问题是火绒的NdisRegisterProtocol 地址是启动时获得的，由于火绒启动得比较早，后面这个地址EAT被HOOK了，所以TCPIP.SYS内的NdisRegisterProtocol IAT在启动时已经被EAT传递了，所以火绒就找不到了，失败了

说到底，还是火绒的开发者经验不足，根本就没考虑到EAT HOOK的这种情况，只要同EAT HOOK任一下面三个函数的任何软件共存，功能就失效了

NdisRegisterProtocol
NdisOpenAdapter
NdisCloseAdapter

修复的方案：

修复这个低级BUG也很简单，在搜索TCPIP.SYS前才去获取当前的NdisRegisterProtocol 地址，就可以了。

真相大白了，分析和解决都给你提供了，赶紧道歉吧。

显示全部楼层 · 发表于 2012-7-31 15:47:25

BootMgr 发表于 2012-7-31 15:44
下了个火绒，简单看了下这个的实现，搞明白原因了，根本就不是你那个贴图的调用原始的NdisRegisterPro ...

mj大大v5~
这么快哇

显示全部楼层 · 发表于 2012-7-31 15:48:24

zhq445078388 发表于 2012-7-31 15:47
mj大大v5~
这么快哇

小case了，这种低级BUG都不用调试，IDA看了两下就定位了。

显示全部楼层 · 发表于 2012-7-31 15:49:17

vardyh 发表于 2012-7-31 15:22
这图我再补充一点，启动顺序是火绒先起，360后启动，
KGetProcAddress("NdisRegisterProtocol")拿到原始 ...

IAT /EAT都没学清楚就来装什么呢？都跟你说了，多学习学习，别以为前CTO就了不起了，你说的根本就不对，必然让所有IAT失效？有没有搞错啊

这个BUG的原因、本质问题和修复方案我都帮你写好了，自己看56楼吧，我说了，多学习，看完记得道歉我再多给你们一些帮助

显示全部楼层 · 发表于 2012-7-31 15:50:34

z13667152750 发表于 2012-7-31 15:24
360 的流量监控和comodo的防火墙，avira的防火墙等都可以正常共存，所以。。。。。。

貌似现在还没看 ...

看56楼的分析，根本就不是什么360NETMON抢了他的钩子调用原始函数的问题，根本就是火绒HOOK方案有问题导致的，不光是和360，和任意一个HOOK了EAT且启动比火绒晚的软件共存都会出现火绒失效的问题。

[分享] 火绒盾（断开网络失效）问题已经查明～～【问题已经解决】

评分