就算是无效的,那就触发缺页中断呗 ,然后地址就有内容了

当然,本来就是无内容的地址,访问当然蓝屏

直接切换Cr3蓝屏的几率很高。并且切换Cr3的时候IRQL == DPC_L ，无法触发缺页中断，如果进程没有在内存中，一定蓝屏

切换的时irql是在dpc_level但是切换完成后进行内存操作时会降下来的。。。要么创建mdl锁住目标
这类问题都可以避免的吧

额这种情况下缺页处理还能正常工作么。。会不会存在目标进行的pde和pte也被换出的情况
感觉KiAttachProcess中判断进程是否在内存中一定有原因。。

创建一个傀儡进程。 DirectoryTableBase里面存的就页目录表基址。想读哪个进程，就把傀儡进程的DirectoryTableBase改成哪个进程的的。再用标准api读傀儡进程内存，很安全的，杀软还不报。

这个方法稳定性不错，就是隐蔽性稍有欠缺
俺希望整个过程（进入R0之后）不会被任何钩子捕获

所以Microsoft推荐的方式是创建MDL锁住内存...
如果想霸王硬上弓，一定要进__try

请教一下创建mdl锁住内存是指锁住哪。。。
读写的缓存目前采用的是用nonpagedpool作为缓存来保存

P_Mdl = MmCreateMdl(NULL, 要修改的内存地址, 长度);
MmBuildMdlForNonPagedPool(P_Mdl); //建立Mdl非分页池
P_Mdl->MdlFlags = P_Mdl->MdlFlags | MDL_MAPPED_TO_SYSTEM_VA; //修改标志为不可页出
PMap = MmMapLockedPages(P_Mdl, KernelMode); //映射并锁定MDL，返回映射页的起始地址
memcpy(PMap...); //修改内存
MmUnmapLockedPages(PMap, P_Mdl); //解除映射和锁定
IoFreeMdl(P_Mdl); //释放MDL

明白了，多谢指教。

要是这个时候目标进程的PDE已经被换出的话是不是会BSOD……

MmMapLockedPages锁定，不会被换出了

在切换CR3前先锁定PDE么？如果这个时候PDE已经被换出了能锁定么
多谢指教……

切换CR3之前，Context还不在目标进程，如何锁定？

那……切换时目标进程的PDE不在内存中不是直接挂掉了……

无论是执行访问还是读写访问，也不管PDE是否在内存中
切换进程的动作并不会访问进程的地址空间，这只是CPU执行的一个调度
执行完这个调度，IRQL便会降低到DPC_LEVEL之下
如果这时候PDE不在内存中，那么访问就会触发缺页中断，结果PDE就会被重新填充

KiAttachProcess不但切换了CR3，还挂靠了线程
所以，为了安全起见，不要直接切换CR3，模拟底层不是那么简单的

切换完之后如果目标PDE不存在，就等于载入了一个未知的页表，如果运气不好（没有遇到正好CR3错误地指向了另一个进程的页表的话）产生缺页中断也没法处理，页表乱了中断处理也不正常了。
看来得严格模拟KiAttachProcess的逻辑来处理了……

难道得严格按照KiAttachProcess模拟么。。。里面调用了线程管理的函数

越来越发现楼主扯蛋, 页表的内存为非分页内存,一直都存在内存中的.

还有cr3,不可能错误的指向另一个进程的,因为windows切换线程时,如果是另一个进程了,就切换cr3
,根本不可能cr3错误.

进程内存是可能被换出的，参考《Windows内核原理与实现》中的4.5.5节，或者WRK中的KeSwapProcessOrStack()
换出后PDE就不在物理内存中了，如果原来指向的地址正好变成了另一个进程的PDE的话就……（这种情况只是推测，未验证）:eek

N年后的今天，我也遇到了同样的问题

JWPL 创建一个傀儡进程。 DirectoryTableBase里面存的就页目录表基址。想读哪个进程，就把傀儡进程的DirectoryTableBase改成哪个进程的的。再用标准api读傀儡进程内存，很安全的 ...

直接改KPROCESS的CR3，会导致优化WorkingSet线程在MiCheckProcessShadow会蓝，导致MEMORY_MANAGEMENT。WIN10-64-1809。
ffffc086`56697770 fffff807`5e6c3f53 : ffffd30b`a04b2640 00000000`00000001 00000000`00053053 00000000`00000000 : nt!MiCheckProcessShadow+0x157691
ffffc086`566977d0 fffff807`5e742675 : 00000000`00000000 ffffc086`56697a80 ffffc086`566979b0 00000000`00000000 : nt!MiTrimOrAgeWorkingSet+0x5d3
ffffc086`566978b0 fffff807`5e741056 : fffff807`00000001 00000000`00000000 fffff807`5ea5a980 ffffd30b`94e430f0 : nt!MiProcessWorkingSets+0x255
ffffc086`56697a60 fffff807`5e79bc17 : 00000000`00000002 00000000`00000002 00000000`ffffffff 00000000`00000001 : nt!MiWorkingSetManager+0xaa
ffffc086`56697b20 fffff807`5e65aa45 : ffffd30b`94f79080 00000000`00000080 fffff807`5e79bad0 00000000`00000000 : nt!KeBalanceSetManager+0x147
ffffc086`56697c10 fffff807`5e7d7c3c : fffff807`5ce27180 ffffd30b`94f79080 fffff807`5e65a9f0 00000000`00000000 : nt!PspSystemThreadStartup+0x55
ffffc086`56697c60 00000000`00000000 : ffffc086`56698000 ffffc086`56692000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x1c

用隐藏进程之类把能遍历到的EPROCESS的双链干掉依旧会出发该BSOD。
TrimWorkingSet线程在另外一份内存会枚举到改了CR3的EPROCESS，时间一到准备优化Pages的时候就BSOD。

Jason姚 N年后的今天，我也遇到了同样的问题

兄弟,我也出了同样的问题,问一下你解决了嘛?缺页问题怎么解决的?