应用从之前编写的分页表中获得的知识,可以轻松地跟随这篇文章,如果你不熟悉分页表,那么这篇文章只会是波浪线。刷新您对以下术语的含义的思考:PML4(E)、PDPT(E)、PD(E)、PT(E)、地址空间、分页和 CR3。
首先,我想明确一点:内核被映射到所有上下文(所有进程)中。在 64 位窗口上,每个 PML4 的上半部分都被委派给内核(尽管这不是强制的)。内核是全局映射的,每个进程都有自己的 PML4,这意味着只有内核 PDPT(E)、PD(E) 和 PT(E) 是真正全局映射的,而 PML4(E) 不是。分页表这个看似微不足道的事实是我的进程特定内核补丁理论的基础。通过重建特定内核地址的分页表,可以在内核与其进程中的内核映射之间产生差异。在我们继续之前,让我说明内核的哪些分页表/条目是全局映射的,哪些分页表/条目不是全局映射的。
在上面显示的图表中,绿色是与内核映射相关的进程特定的分页表/条目。红色是与内核关联的全局映射的分页表/条目。例如,如果要更改内核 PML4E,则效果将不是全局的。
知道内核的 PML4(E) 不是全局映射的,可以为给定地址重建分页表。这种重建思路就是简单地分配一个新页,将所有条目复制到新页中,最后编辑线性虚拟地址中对应分页表索引指定的分页表条目。此重建过程的图示如下所示。
尽管上面的插图没有显示分页表索引,但所有新的分页表条目都位于与重建将基于的给定线性虚拟地址对齐的索引处。
但是,像这样重建分页表会产生比要求更多的差异。如果您将 PML4E 指向新的 PDPT,则新创建的 PDPT 将与其他真实 PDPT 条目不同步。这也适用于新创建的 PD 和 PT。换句话说,某些内核分配不会出现在您的进程内部,并且您的进程内部的某些内核分配不会出现在内核内部。每次发生 KeStackAttachProcess 时都会出现问题,特别是在 MmCopyVirtualMemory 周围,因为分配了一个池,然后发生了上下文切换。这样做会导致错误检查,因为地址在一个上下文中有效,但在另一个上下文中无效。
进程特定的内核补丁可用于修补特定进程的句柄表,以将句柄权限从 PROCESS_QUERY_INFORMATION 更改为 PROCESS_ALL_ACCESS。此类补丁仅在您当前的上下文中可见,因此如果从另一个上下文调用 ExEnumHandleTable 仍将显示 PROCESS_QUERY_INFORMATION。虽然这不是补丁保护绕过,但您可以使用它来内联挂钩系统调用、修补 SSDT,甚至仅在当前进程中的 IDT。补丁守卫可能会追上你,但在你被抓住之前的时间量是未知的(但比正常时间长)。
这些概念是高度理论化的,尚未在各种处理器/Windows 版本上进行测试。与这个项目相关的所有代码都是原样的,不会被维护或更新(我真的没有什么可以添加/更新的)。在此,感谢您的阅读。我希望你可以将这些知识应用到一些很酷的东西上,比如特定于进程的系统调用或特定于进程的 IDT 补丁。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。