驱动小牛
|
40楼#
发布于：2007-02-02 14:02
突然在驱网冒出如此多的大牛,
 我们这些菜鸟以后有福了. |
|
41楼#
发布于：2007-02-03 00:27
来到这里学习以下
|
|
|
42楼#
发布于：2007-02-03 17:23
来到这里学习以下
 |
|
|
43楼#
发布于：2007-02-08 18:48
呵呵。rt也来了
|
|
|
44楼#
发布于：2007-02-08 23:13
...怎么看都是我比你们早来！
|
|
|
45楼#
发布于：2007-02-09 09:57
哈哈，finalseraph也来了。 |
|
|
46楼#
发布于：2007-02-09 21:35
都是高手前辈，等等说不定有扫地僧出现
|
|
|
47楼#
发布于：2007-02-09 22:51
kao, finalseraph，潜得真深啊。。。
２００１年３月，比我还早几个月啊 |
|
|
|
48楼#
发布于：2007-02-12 10:15
wowocock不要着急啊~~~~~哈哈哈哈，保证给你惊喜
|
|
|
|
49楼#
发布于：2007-02-12 16:02
还是欣赏卡卡的做法,简单有效,无招胜有招. 觉得"破冰"相对碎甲而言,处理细节太多有些繁琐. 没有详细看逆向代码,不过看过酒肉和尚给我的代码,觉得和楼上的实现有些类似.也是做了很多恢复性的工作.
不知cnnic如果把反恢复的工作做到线程里面, 每隔几毫秒,就hook一下接口,释放一下文件,修改一下注册表,最重要的发现只要发现自己hook的内容,被修改,或者内存模块中多出了一个驱动,该驱动模块的内存空间存在与cnnic冲突的调用(反hook),直接调用bugcheck. 把蓝屏的责任推给360. 这样在这次交通肇事中,360将负全责.并且也可以用来保护自己. 360superkill代码公开了,对方只要稍微做一些文章,把代码中用到的系统调用能hook就hook,给360一个返回假的信息,并对每一个加载的驱动文件内容以及驱动内核模块进行过滤和扫描,发现fastfat ntfs ntfs.sys fastfat.sys cnnic ZwQuerySystemInformation 以及对cr0寄存器的操作关键代码,加权统计,超过一定的阈值,就可以视为"鬼子来了", 于是"大刀向鬼子的头上砍去",千方百计阻止这样的驱动加载起来. 不过cnnic也挺垃圾的,官不像官,商不像商,互联网本身没有管好,偏偏去热衷于做这等无聊的事情.没有自知之明,让别人给自己写卸载程序. 觉得还是希望抢夺启动引导顺序,看谁hook的早.虽然卡卡的碎甲被拆解后,路人尽知,不过可以相信或许还会存在比driverentry入口调用返回地址之前,还会存在更早更巧妙的地方可以被inline hook 调用. |
|
|
50楼#
发布于：2007-02-12 16:10
“发现fastfat ntfs ntfs.sys fastfat.sys cnnic ZwQuerySystemInformation 以及对cr0寄存器的操作关键代码,加权统计,超过一定的阈值,就可以视为"鬼子来了", 于是"大刀向鬼子的头上砍去”
这样做不太好吧，很容易会跟其他驱动发生冲突。。。 |
|
|
|
51楼#
发布于：2007-02-12 18:10
卡卡的做法已经被证实至少在RS手里是失败的了，我想就没有必要讨论了
一劳永逸的办法永远都不存在 CNNIC专杀出来后，CNNIC多次针对我们更新，我们都在2小时内反映并更新了新的驱动出去 不管CNNIC如何HOOK，如何阻拦，我们的恢复都会是有用的，不外乎变换一下，加点功能而已。兵来将挡水来土淹，技术对抗只能如此，卡卡想一招结束RK，实在太幼稚了 |
|
|
|
52楼#
发布于：2007-02-12 18:22
引用第50楼xikug于2007-02-12 16:10发表的“”: 驱动这种小东西特征码比较难取，R3的程序尚不能用简单的寄存器，字符串来判断，何况驱动？ guaiguai的方法比较。。。 呵呵 CNNIC对于我们的驱动是找关键代码，取特征码，然后ZwLoadDriver拦截，还有File system filter,fsd inline/dispatch hook处对于执行的路径拦截（不允许包含360的路径有bin执行)等等拦截动作，不过结果当然是完全无效 另外CNNIC驱动经过多年已经稳定下来，是一套有很多功能的稳定系统，他们的量也不小也要考虑稳定性问题，不可能说改就改，不过CNNIC的驱动里还有好多功能没有启用呢，呵呵 |
|
|
|
53楼#
发布于：2007-02-12 19:46
嗯。。。没什么好争的。。。大家都是在较量中进步，没有突破不了的防线。。。
什么建线程，ＴＩＭＥＲ去检测也是只能抵挡一时。。。你这边出来这招，另一边可能就会把你什么线程，ＴＩＭＥＲ之类的东西都停掉。。。 |
|
|
|
54楼#
发布于：2007-02-12 20:28
引用第52楼WQXNETQIQI于2007-02-12 18:22发表的“”: 不但r3能，r0也能。靠汇编指令编码可能会出现误判比较麻烦，但是提取字符串信息以及导入函数表，却很有效。 不是所有的驱动所在的内核模块里面都会出现cnnic关键字，随机字符串出现cnnic的机率是255的５次方分之一。也不是所有的驱动里面都会出现fastfat ntfs ntfs.sys fastfat.sys cnnic ZwQuerySystemInformation，在考虑到你使用ZwCreateFile加载 ntoskrnl.exe文件，很明显有恢复ｓｓｄｔ的嫌疑，这些破绽如果叠加起来，可以百分之百确定这个驱动要和ｃｎｎｉｃ过意不去，除非你刻意来避开，一般不会误判的。再说ｃｎｎｉｃ加载在先，挂接了大量的内核调用，包括文件系统，注册表操作，想不让你的驱动加载到内存，应该是易如反掌。 至于说很容易和其他驱动冲突，我想一般不会，既然你的驱动里面出现了ｃｎｎｉｃ以及本驱动忌讳的关键字比如本设备创建的设备名称，即使出现误判，错误封杀，不让加载也是活该，谁让你非和本驱动过意不去啊。 不过你打我，我打你，拿用户的机器开涮，也挺没意思的，cnnic也早该撤出实名不为人看好的市场了，老鸟们早已不用实名，菜鸟们现在都被老鸟教会了如何使用搜索引擎，谁还会在地址栏输中文啊？ |
|
|
55楼#
发布于：2007-02-12 21:08
1.导入表（不用导入表了，自己Get一下）和字符串的加密，容易到不需要我再说了吧，至于什么判断啊，楼上想得太复杂了。我为什么要出现CNNIC呢？CNNIC专杀的驱动一定要出现CNNIC字样吗？楼上的逻辑显然有问题。拦截一个专杀的驱动，尤其对于一个可以随意升级的恶意软件来说，一点点特征码就够了，
2.至于什么挂接什么东东，正如楼主所说，任何都只能抵挡一时，不管CNNIC用什么方法阻止我的驱动加载，那么简单，bypass之即可，非常简单。 |
|
|
|
56楼#
发布于：2007-02-12 21:35
MmGetSystemRoutineAddress照样需要函数名字符串，除非你不用它，手工对函数寻址。那将十分烦琐，否则是绕不过去的。至于其他，同意你的说法。
不过你改我也跟着改，永远没有尽头，弄得都很累的。 |
|
|
57楼#
发布于：2007-02-12 21:55
引用第56楼guaiguaiguan于2007-02-12 21:35发表的“”: 手工寻址也不是很麻烦。。。 同意“累”！不如大家都不弄电脑了。。。呵呵。。。  |
|
|
|
58楼#
发布于：2007-02-12 23:02
你改我改大家改看谁拼到最后！！ 正义必胜！ 360万岁！！！ PS：MMGet的函数名稍微加密一下即可 |
|
|
|
59楼#
发布于：2007-02-13 08:42
MJ还在舌战群儒啊,不容易,嘿嘿......
|
|
|
