就驱动的使用，给病毒作者一些忠告：
1. 使用CreateServiceA来创建驱动服务，你以为安全软件都是盲的么？要拦截你的驱动加载是很容易的事。你至少采用个有创意点的吧。
2. 对注册表做了N多操作之后再加载驱动，还原SSDT？那你在之前的注册表操作中很容易就被拦截了。
单单这前两项，你的驱动就很可能完全没有发挥作用的机会。3. 你在R3情况下通过加载ntoskrnl.exe，搜索其重定位表，定位ntoskrnl.exe中填充KeServiceDescriptorTable的指令，以找到SSDT表在ntoskrnl.exe中的偏移。
我敢肯定你这个是抄的。这样虽然可行，但是需要时间和RP。
实际上驱动很容易就直接得到SSDT表在内核中的位置，配合ntoskrnl.exe在内核空间的基址，就直接得到其相对偏移，而这个偏移在文件中是不变的。只要在驱动响应IRP_MJ_DEVICE_CONTROL的例程中加上一段，让R3程序与之通信，从驱动返回SSDT表的偏移，就完全不用遍历重定位表那么庞大的工作量了。
这样你甚至都不用用LoadLibraryExA把ntoskrnl.exe加载（这又是一个容易被人发现的地方，比如卡巴就HOOK住了这个API），直接CreateFileA读文件都行了，因为ntoskrnl.exe的内存映像和文件区段其实是完全对齐的，你连内存偏移到文件偏移的换算都可以不需要。
至于你抄袭的对象，为什么要用重定位表的方法，我想很可能人家是为了不用驱动在R3就对SSDT表进行还原，所以要采取这样麻烦的手法（这个你不用想学了，这样一来SSM恐怕马上报你读取物理内存），你既然还是要用驱动，却要学得四不像，那是你自己的问题了。
4.你的驱动写得很烂。不，是抄得很烂，肯定是把人家一个实验性的“习作”抄过来了。代码太简单了，必要的判断都没有，对传入的函数地址，连一个MmIsValidAddress都不做，对驱动的稳定性也太不负责任了吧？
这相当于造成一个新的漏洞，
只要了解你的驱动接口，就可以往SSDT表任意位置写入任意地址，既可以用作SSDT HOOK，也可能分分钟导致严重的系统问题。更何况你偷吃还不擦嘴，
你创建的设备名，到底是"\Device\SSDTCL"，还是"\Device\NetApi00"？
既然是后者，为什么还留着前者的RtlInitUnicodeString操作？
我看这完全是抄来的结果，敢情人家本来创建的是"\Device\SSDTCL"，你把它改成"\Device\NetApi00"，但是却忘了删去人家本来的RtlInitUnicodeString操作，从而造成了连续两次RtlInitUnicodeString。搞出这么滑稽的事情，你这个“拿来主义”，也拿得太失败了一点吧？！
