能力值:
( LV5,RANK:75 )
|
-
-
2 楼
mark
|
能力值:
( LV2,RANK:10 )
|
-
-
3 楼
mark
|
能力值:
( LV12,RANK:380 )
|
-
-
4 楼
mark
|
能力值:
(RANK:290 )
|
-
-
5 楼
VT 是接管不是重载 .在说如果是HOOK是要触发PG的
win7 x64 shadown 是不触发PG
win8 10才要
win 10需要设置CR3,另外CPUID也要返回给系统处理
|
能力值:
( LV2,RANK:10 )
|
-
-
6 楼
我知道VT只是负责处理系统对MSR的检测,但现在的问题是修复相对偏移,然后改MSR到我的函数之后,会随机性出错,而且在测试这个代码的时候是没有开启VT的,把MSR改成卡巴驱动里的函数就没有问题
出错的时候是在WinDbg中断下来提示Access Violation,而不是触发PG的BugCheck
|
能力值:
( LV5,RANK:60 )
|
-
-
7 楼
应该是你么个opcode计算错误吧,你在仔细比对下修正后的汇编
|
能力值:
(RANK:290 )
|
-
-
8 楼
===卡巴 是怎么重载内存的,不是寻址问题,全局变量,会有很大问题?
|
能力值:
( LV2,RANK:10 )
|
-
-
9 楼
KiSystemCall64里一共有这几个全局变量:
lea r10,[nt!KeServiceDescriptorTable]
lea r11,[nt!KeServiceDescriptorTableShadow]
cmp rsi,qword ptr [nt!MmUserProbeAddress]
cmovae rsi,qword ptr [nt!MmUserProbeAddress]
test dword ptr [nt!PerfGlobalGroupMask+0x8],40h
lea rdi,[nt!KeServiceDescriptorTableShadow+0x20]
算上所有的call xxxxxxxx 都已经在我自己的驱动空间里处理好了
|
能力值:
( LV2,RANK:10 )
|
-
-
10 楼
看了一下,是有一个地方没处理好
lea rdi,[nt!KeServiceDescriptorTableShadow+0x20]
后面那个+0x20我没有注意到
但是这个改好之后还是出错啊,内存中的汇编我逐字节和卡巴自己的函数对比了,都是一样的
难道是自己处理的SSDT表有问题?
|
能力值:
(RANK:290 )
|
-
-
11 楼
|
能力值:
( LV2,RANK:10 )
|
-
-
12 楼
参考了类似方法之后成功了,感谢!
但是为什么卡巴那种方式却不能用呢?应该还是我的代码有问题吧
|
能力值:
( LV2,RANK:10 )
|
-
-
13 楼
mark
|
能力值:
( LV5,RANK:75 )
|
-
-
14 楼
bug report (win7x64) :
1.Fix FF15 Call
2.In FixOpcodeTestInDriver:
your : test qword ptr [XXX], 40h
sys : test dword ptr [nt!PerfGlobalGroupMask+0x8], 40h
3.your_SSDT_Table[i] |= sys_SSDT_Table[i] & 0xF;
your_SSSDT_Table[i] |= sys_SSSDT_Table[i] & 0xF;
|
能力值:
( LV2,RANK:10 )
|
-
-
15 楼
mark
|
|
|