// 遍历MMPFN 获取真实CR3地址 for (ULONG64 i = 0; i < maxCount; ++i) { ULONG64 Buddy = (ULONG64)local_MMPFN[i].u1.Buddy; if (Buddy == NULL) continue;
// 计算解密后的 eprocess 值 ULONG64 EPROCESS = (((Buddy>>0xD)&0xFFFFFFFFFFFFFFF0)|0xFFFF800000000000);
因为我们不需要从EPROCESS中拿dirbase 不管CR3加密与否
0: kd> dt _KPROCESSnt!_KPROCESS +0x000 Header : _DISPATCHER_HEADER +0x018 ProfileListHead : _LIST_ENTRY +0x028 DirectoryTableBase : Uint8B
关于CR3的加密 就是 各大AC修改了EPROCESS->DirectoryTableBase的数值 然后接管了内核全局异常处理
KeAttachProcess或者操作错误的CR3 都会触发异常 然后走它的异常接管 它上报或者给你返回空字节的分页给你
这就是为什么频繁的附加进程上下文导致GG和读不到数据
那么就有人要问了为什么要这样运算 (((Buddy>>0xD)&0xFFFFFFFFFFFFFFF0)|0xFFFF800000000000) ，你去问微软
至于外面杂七杂八一大堆的解密 这里不做点评 ，你觉得好用你就去用
W7-W10是这套固定的运算方法 W7的MMPFN中EPROCESS并未经过运算保存 直接就是对象地址
W10需要位运算还原出对象地址 这套方案不管加密没加密都能返回正确的EPROCESS
maxCount=最大物理页数量 MmGetPhysicalMemoryRanges可以获取到
接下来是W11各版本的通杀方案 这里以24H2为例子
Owning Process ffffad8b1c7f3080 Image: procexp64.exeffffad8b1c7f3080+0x28=0x0000001146a3002 CR3 00000001`146a3002&~FFF >> 12 =1146A3 页目录索引
然后众所周知MMPFN结构大小为0x30 固定的 其中+0x0=加密后的对象地址 +0x8=ptebaseaddress w7中+0x10=tebaseaddress
根据以上信息得知该MMPFN地址为MmPfnDataBase+0x1146A3 *0x30
00008000`638fe613 这个数值就是加密后的对象地址
MMPFN调试下断得出MiGetPageTablePfnBuddyRaw为解密对象地址的函数，参数1为MMPFN地址
回复或点赞可查看完整内容
---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-287780.htm