能力值:
( LV3,RANK:20 )
|
-
-
2 楼
加载内核文件自己比对
|
能力值:
( LV2,RANK:10 )
|
-
-
3 楼
听起来有点抽象,我刚下载了PsNull的代码,听说里面有相关代码,不知道能不能请大N讲一下大概的原理和流程,我再根据代码学习一下,多谢了
|
能力值:
( LV2,RANK:10 )
|
-
-
4 楼
rrrfff ,能不能给个简单的实例看一看,这几天看那个PsNull的代码,没有文档,直接看,有点一头雾水......
因为我现在是恢复几类函数,一个是SSDT导出的函数,另一类是Shadow SSDT导出的函数,最后一类是在ntkrnlpa.exe里面导出了的函数。所以我需要加载两个内核文件,就是ntkrnlpa.exe和win32k.sys
比如我上面的图里面就是win32k.sys里面的函数,如果我的驱动自己加载映射到内存空间,那么基址肯定不一样,这样有些变量或者函数的地址需要重定位,那基址不一样,重定位后的这些值应该还是不一样?
不知道PsNull里面是如何实现inline hook的恢复,如果哪位想要PsNULL的代码请留下邮箱,我发给你们,还请帮忙看一下
|
能力值:
( LV2,RANK:10 )
|
-
-
5 楼
我自己来解答一下吧,狂读了一下PsNull的代码,思路是有了,不过代码还没有出来,没有时间
只是想把VB的代码转换成VC,不过不懂VB的我始终有中困难
加载文件进行比对的思路:
1. 把内核文件和win32k.sys加载到内存
2. 重建里面的导出函数的地址和重定位表,按当前系统实际基址进行重建
3. 和当前内核所在内存进行比对,进行inline hook的恢复也很方便
|
能力值:
( LV9,RANK:610 )
|
-
-
6 楼
加载原始文件时最好不要用map原始文件的方法,对于win32k.sys会有些问题……直接read进来好了~
|
能力值:
( LV2,RANK:10 )
|
-
-
7 楼
恩,现在用的Read可以进来了,在修复重定位表时有个疑问:
KeServiceDescriptorTable 在 ntkrnlpa.exe 里面,指向函数的地址可以修复
但是
KeServiceDescriptorTableShadow 也在 ntkrnlpa.exe的内存里面,但是里面有些函数是指向win32k.sys的,根本就不是一个模块了,里面指向的函数地址怎么修复呢?
|
能力值:
( LV9,RANK:610 )
|
-
-
8 楼
KeServiceDescriptorTableShadow这个变量是在ntoskrnl.exe里,但是里面的函数表是在win32k.sys里,从win32k.sys里找原始函数表进行修复吧~~
|
能力值:
( LV2,RANK:10 )
|
-
-
9 楼
achillis,太感谢了,能理解你的意思,再请教一下,KeServiceDescriptorTable所导出的函数表可以直接在ntoskrnl.exe里进行修复,通过重定位表
你的意思是不用管KeSericeDescriptorTableShadow,直接在win32k.sys里面修复函数表,但是函数表的地址在哪儿找?
因为导出表没有导出这些函数,如果直接通过重定位表修复了这些函数,但是我从哪里找这些函数的地址,通过对比函数头部来进行inline hook的修复?
还请赐教
|
能力值:
( LV9,RANK:610 )
|
-
-
10 楼
恢复SSDT Shadow的HOOK和InlineHOOK与搞SSDT没什么不一样啊,自己按PE格式加载win32k.sys,按当前win32k.sys的真实加载基址做好重定位修复,然后根据W32pServiceTable的实际位置计算它相对于win32k.sys基址的偏移,按这个偏移到你自己加载的那份win32k.sys里面就可以找到函数表了~~恢复InlineHook同样对比就行了~
|
能力值:
( LV9,RANK:610 )
|
-
-
11 楼
还有,InlineHook不一定在函数头部。。。
|
能力值:
( LV2,RANK:10 )
|
-
-
12 楼
已经把SSDT的inline hook搞定,过几天再弄Shadow SSDT的,多谢achillis的指点
|
能力值:
( LV2,RANK:10 )
|
-
-
13 楼
SSDT,Shadow SSDT全部搞定,多谢achillis一直的指点
|
|
|