WriteProcessMemory与它的坑

Posted by Qfrost on 2021-12-31
Estimated Reading Time 2 Minutes
Words 763 In Total
Viewed Times

属于是没想到,我会因为一个API写一篇博客。没办法,它的坑实在是太大了,让我惊叹于微软文档工程师的“牛逼”。

起因是,我想跨进程的对一个程序的代码段做修改。代码段通常是可读可执行不可写的,三环程序WriteProcessMemory可以直接修改成功,但是我Ring0调用MmCopyVirtualMemory却失败返回STATUS_PARTIAL_COPY。因为之前知道WriteProcessMemory底层调用的就是MmCopyVirtualMemory,所以认为有上层操作对它改了权限。然后逆向一波ntoskrnl

WriteProcessMemory进入零环后,调用NtWriteVirtualMemory,而NtWriteVirtualMemory仅调用了MiReadWriteVirtualMemory。而在MiReadWriteVirtualMemory中,可以看到先获取了上下文和Mode,然后对地址范围做了检查

然后可以看到通过目标进程句柄获取到对象后,就调用MmCopyVirtualMemory去写内存了。

也就是说,从 NtWriteVirtualMemory -> MiReadWriteVirtualMemory -> MmCopyVirtualMemory ,并没有看到有修改内存权限的操作。那么,为什么对同一段不具有写权限的代码段,WriteProcessMemory可以修改而MmCopyVirtualMemory却不行。

我把这个问题抛到了群里想问问WriteProcessMemory是在哪里把内存属性改掉的,但是师傅们的答案却让我很震惊。大家都是在WriteProcessMemory之前调用VirtualProtect去修改内存属性,他们甚至非常惊讶为什么我可以直接用WriteProcessMemory去修改一个不具有可写权限的内存页。 然后,有意思的来了,我们去翻了微软官方文档

可以看到,官方文档说,使用WriteProcessMemory,需要句柄拥有 PROCESS_VM_WRITE 和 PROCESS_VM_OPERATION 权限,并且目标进程地址空间是具有可写权限的。 可是我们确实使用了这个API对读可执行不可写的代码段做了修改。

然后我们又做了一些测试,发现WriteProcessMemory并不是可以对所有存在的内存页都修改成功的,比如我们测试修改一个模块的PE头(尝试把内存中ntdll的PE MagicNumber从0x4D5A改成0x0000)就失败了,非常的迷惑。

后面和存哥在三环WriteProcessMemory上下断点,虚拟机+Windbg从三环向零环跟,发现在KernelBase.dll里,有神奇操作。


惊了,KenelBase.dll的WriteProcessMemory里,竟然调了这么多API,其中有NtQueryVirtualMemory查询内存属性、有NtProtectVirtualMemory修改内存属性!以Windows10为例,说一下里面的操作流程:

  1. 首先调用 NtQueryVirtualMemory 查询内存信息
  2. 如果原内存属性可写,直接调用 NtWriteVirtualMemory 写入内存
  3. 如果原内存属性不可执行,则还原内存属性,然后返回 STATUS_ACCESS_VIOLATION
  4. 如果内存类型为 MEM_IMAGE,则修改内存属性为 OldAccessProtection | PAGE_ENCLAVE_UNVALIDATED | PAGE_EXECUTE_WRITECOPY
  5. 如果内存类型为 MEM_PRIVATE,则修改内存属性为 OldAccessProtection | OldAccessProtection | PAGE_EXECUTE_READWRITE
  6. 调用NtWriteVirtualMemory写入内存
  7. 还原内存属性

最后吐槽一下,这种三环的究极封装,严重影响效率就算了,文档也不改就离谱(甚至好像Windows7下就可以用WriteProcessMemory改可读可执行的内存了)

参考资料:

http://blog.rin-ne.moe/archives/218/




浙ICP备19044916号-1