ssdtswtich

ssdt hook 是32位系统下大家最喜欢用的技术,稳定而实用,深为大家所喜爱,不过恶意还是反恶意的
都往上挂,KeServiceDescriptorTable 简直就是千苍百孔,而各种恢复工具也是层出不穷.SSDT TABLE
成了主战场.其实也许并不要千军万马过独木桥,换条僻静小道也许更好.
  
  SSDTSWITCH在不改变SSDT 表里任何数据的情况下可以随时让你切换系统内存当前SSDT 和原始SSDT
而不需要恢复SSDT 表.同样在里面你也可以HOOK,而让所有SSDT 恢复工具无效.同样的技术可以杀人,也能救人.

其实本来也毫无技术含量,有兴趣的测试下.
用法很简单,和我以前的DISABLECONTROL一样,/DRVSTART /DRVSTOP加载和卸载驱动./ENABLE使用原始SSDT
/DISABLE 使用内存当前SSDT,驱动加载默认使用原始SSDT. 同样在里面我也HOOK 了ZWTERMINATEPROCESS,虽然没有一个
工具能检测到SSDT里的变化.在退出每个程序都DBGPRINT下.
   注意不能开SOFTICE,虽然我并没有有意反调试,但SOFTICE的BUG可能会导致系统崩溃.同时如果用360 SAFEBOX的话,不要用他
来结束360 SAFEBOX,不然也会死,嘿嘿,最好不要同时使用360 SAFEBOX否则后果自负.
USE IT AT YOUR OWN RISK.
测试环境：XPSP2 2K3SP1

你的也被mj的恢复了~

MJ能恢复很正常,还有个基于VMM的,不敢拿出来,嘿嘿......

支持CV，反对逆向~~
现在有人动不动就去反别人的东西，自己写的却很少，无不无聊~~~

是改KiFastCallEntry里的 call ebx吧

墨者，江民，诺顿都有此类的技术~~
360也有~
瑞星曾经有过~

可后来都放弃了,难道有什么不稳定因素吗?只看见360还在用,不过我是开放给大家使用的,不是给安全软件用的,安全软件方面应该用更强大的处理.主要是考虑很多游戏程序也做HOOK,而且还自我保护,很不爽,偏偏我又是个游戏白痴,所以......

代码修改了系统原来实现的FastCallEntry.

80882f8e 8b1c87           mov     ebx,[edi+eax*4]
80882f91 2be1             sub     esp,ecx             <-old
80882f93 c1e902           shr     ecx,0x2             <-old
80882f96 8bfc             mov     edi,esp              <-old
80882f98 3b35e8588980     cmp     esi,[nt!_MmUserProbeAddress (808958e8)]
80882f9e 0f83ac010000     jnb     nt!KiSystemCallExit3+0x90 (80883150)
80882fa4 f3a5             rep     movsd
80882fa6 ffd3             call    ebx

80882f8e 8b1c87           mov     ebx,[edi+eax*4]
80882f91 ba11008080       mov     edx,0x80800011 <-new
80882f96 ffd2             call    edx                   <-new
80882f98 3b35e8588980     cmp     esi,[nt!_MmUserProbeAddress (808958e8)]
80882f9e 0f83ac010000     jnb     nt!KiSystemCallExit3+0x90 (80883150)
80882fa4 f3a5             rep     movsd
80882fa6 ffd3             call    ebx

这个不会被我恢复啊，我恢复call ebx前会判断是不是被XX钩的~

不过冲突是很可能的~~~

现在用fastcallentry HOOK的越来越多了，，江民，墨者，诺顿，真是一个个都没创意啊，太挫了太挫了

360里面patch神奇地址，所以稳定~只要不冲突就好啦~
至于wowocock的hook，太邪恶了，居然hook在那里了~

学习中，谢了