内核DUMP问题（8月6日更新）

我一直想模仿IceSword编个查内核模块钩子的程序，今天终于把最重要且最基础的一步实现了
——DUMP内核模块的内存到Ring3级，我保存成了个文件，然后和原始的内核文件
用Ultra比较了一下，结果很令我意外，有很多不一样，除了钩子以外

我原以为是没DUMP对，用IceSword内存读取抽了几处发现都是和我DUMP的一样，说明方法没错！想了下
发现是早该想到却没意识到的问题——静态加载和动态加载的不同，也就是说，除了第三方钩子
还有很多内核程序运行时就填入的动态参数，这个就让我寻找钩子很困难，我想了几种思路，但都很悬：

1、我从网上找了个反汇编开源代码，可以运行，现在正在尝试整合，但是有个问题：这样可以查JMP的钩子，
从它是否跳出内核模块范围外（这个用R3编还是R0编就是问题），然后我知道SSDT属于重定位段，可以特殊
处理查找。但是我曾经见过瑞星2007有个很特别的钩子（就HOOK两个字节你就杀不死它），不属于
SSDT和360的KiFastCall钩子，虽然冰刀可以找出，我如果只盯JMP是不可能的发现的

2、IceSword并不属于内核模块逐字节比对，我甚至发现他自己有个NtTerminateThread内联钩子，明明
有7处与原始内核文件不一样，他却报告说此处只有5个不一样（JMP XXXXXXXX），而且RkU也这么说，
这说明ARK软件查钩子决不是仅仅内置个反汇编和一些特征函数入口这么简单。

能成功DUMP只是开始，就象有把钥匙可以开所有门但你却不一定找得到东西，Windows游戏规则很复杂啊！
我不想就此放弃，请大家支招，应该如何“继续”？提点建议思路也行

up一下，顺便问下我是不是应该弄个数据库来进行钩子的细节判断？？似乎钩子的判断还需要整合一些东西……

多谢各位的指教，在下已经弄了一些了，但是还有一点问题需要各位前辈指点
我现在可以确立JMP的位置，但是钩子排查不严，还是和IS有出入（我是比的某一段，确立这些区域还要整合一个PE文件的段头部的分析模块）
也就是说JMP区域很难确认正常与否，江明似乎有个钩子居然会跳到0x90000000以下部分，怀疑是不是空穴感染
不知各位有何高见，再次拜谢。
还有一个问题，希望有人能讲下，JMP所跳转区域到底那些算正常？至少我很想知道，内核模块和那些驱动模块应该有正常联系啊？
有时JMP甚至会到0x00300000的地方（Ring0跳到RING3？）

我测试过,不过会有很多误判,就是说系统自身也会做些修改和磁盘上的代码不同,不过好处是所有的处于代码段的不同之处全部可以找到,并且也可以完全恢复,不过现在很多都用KOH,内核中用到很多指针跳转,导致比较难处理.不过RKU我人为还是目前来说做的比较好的了.

读取硬盘上的文件，计算出各个段的虚拟地址，
枚举内存中的模块基地址，然后分析重定向表，找到代码段的位置，
然后代码段进行对比。
以前我做试验查看ntoskrnl被挂接的情况，的时候是这样做的。
如果是重定向表被丢弃了，可以使用内核中的函数地址，和文件内的函数虚拟地址，反推代码段的地址的。