-
-
[原创]CR3解密之MMPFN->EPROCESS通杀分析
-
发表于: 2025-7-27 20:14
-
// 遍历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);
if (Buddy == eproc || EPROCESS== eproc)
{
dribase = i<< PAGE_SHIFT; //这里就是你要的真实CR3地址
break;
}
}
因为我们不需要从EPROCESS中拿dirbase 不管CR3加密与否
0: kd> dt _KPROCESS
nt!_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.exe
ffffad8b1c7f3080+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地址
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
