Windows内核无法直接读写用户态虚拟内存，因地址空间隔离是体系结构强制要求；正确方式是使用MmCopyVirtualMemory函数安全跨空间拷贝，它自动处理页表切换、权限检查及SMEP/SMAP绕过。
不能在 Windows 内核中直接读写用户态进程的虚拟内存空间——这不是权限或驱动签名问题，而是体系结构层面的禁止行为。内核模式代码运行在 Ring 0，其页表视图与用户进程（Ring 3）完全隔离；强行映射或访问会触发 #GP、#PF 或导致系统崩溃。
为什么 ZwReadVirtualMemory / ZwWriteVirtualMemory 不适用于内核驱动
这两个函数是 ntdll.dll 导出的用户态 API，内部封装了 NtReadVirtualMemory 系统调用。它们只接受用户态句柄（如 HANDLE），且调用路径依赖用户态上下文（如当前进程的 EPROCESS、PEB、句柄表）。在内核驱动中硬调用会立即引发 STATUS_INVALID_HANDLE 或蓝屏（IRQL_NOT_LESS_OR_EQUAL）。
常见错误现象：
- 编译通过但运行时
ZwReadVirtualMemory返回0xC0000008（STATUS_INVALID_HANDLE） - 传入用户进程的
EPROCESS地址后，读到全零或随机垃圾数据 - 未切换地址空间就直接解引用用户地址，触发
ACCESS_VIOLATION或KMODE_EXCEPTION_NOT_HANDLED
正确做法：用 MmCopyVirtualMemory 安全跨地址空间拷贝
MmCopyVirtualMemory 是 Windows 内核唯一支持在两个不同进程地址空间之间安全复制内存的函数。它由内核自动处理页表切换、权限检查和异常捕获，无需手动 KeAttachProcess 或修改 CR3。
立即学习“C++免费学习笔记（深入）”；
使用要点：
通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。
- 源地址和目标地址都必须是**有效、可访问的用户态虚拟地址**（不能是内核地址）
- 源进程和目标进程的
EPROCESS指针必须合法，且调用者需有PROCESS_VM_READ或PROCESS_VM_WRITE权限（通常需 SeDebugPrivilege） - 缓冲区长度不能为 0，且两端地址 + 长度不能越界（否则返回
STATUS_ACCESS_VIOLATION） - 函数在 PASSIVE_LEVEL 执行，不可在 DISPATCH_LEVEL 调用
示例片段：
SIZE_T bytesCopied = 0;
NTSTATUS status = MmCopyVirtualMemory(
SourceProcess, // EPROCESS* of target process
UserAddress, // PVOID in target's address space
PsGetCurrentProcess(), // current driver's EPROCESS
KernelBuffer, // PVOID in driver's local buffer
BufferSize,
KernelMode, // from user to kernel
&bytesCopied
);
if (!NT_SUCCESS(status)) {
// 处理 STATUS_PARTIAL_COPY、STATUS_ACCESS_VIOLATION 等
}绕过保护机制（如 SMAP/SMEP）的风险与限制
现代 CPU 启用 SMEP（Supervisor Mode Execution Prevention）和 SMAP（Supervisor Mode Access Prevention）后，内核模式代码默认禁止执行或访问用户页。即使你设法映射了用户页，直接读写仍可能触发硬件异常。
关键事实：
-
MmCopyVirtualMemory自动绕过 SMEP/SMAP，因为它走的是内核内存管理路径，不是直接指针解引用 - 手动用
MmMapLockedPagesSpecifyCache映射用户物理页是危险且不推荐的——用户页可能被换出、被写时复制、或被VirtualFree释放，导致映射失效或数据错乱 - 试图禁用 SMEP/SMAP（如清 CR4.SMEP）会导致系统不稳定，且从 Windows 10 1607 起被内核强制保护，驱动无法修改
真正需要“内核读写用户内存”的场景，应优先考虑用户态方案
绝大多数需求其实不需要内核介入：
- 调试器类工具：用
ReadProcessMemory/WriteProcessMemory（需PROCESS_VM_READ权限） - Hook 或监控：用 Microsoft Detours、MinHook，或 ETW 事件订阅，避免驱动级操作
- 性能分析：用
QueryPerformanceCounter+ 用户态采样，而非内核轮询 - 仅当必须拦截系统调用或过滤 I/O 时，才进入内核——此时也应通过
ObRegisterCallbacks或FltRegisterFilter，而非裸内存读写
内核驱动中直接碰用户虚拟内存，99% 的情况是设计误入歧途。复杂点在于：地址空间隔离不是障碍，而是 Windows 内存模型的基石；绕过它等于主动放弃稳定性保障。
