您所在位置：主题：Windows 核心编程研究系列之一
luzhouke
[专家分：0] 发布于 2006-12-18 14:17:00
楼主 [原创/探讨]Windows 核心编程研究系列之一(改变进程 PTE)首先要说明的是我一般在汇编区活动，但考虑到客观人气问题，所以发到这里，这篇
文章的目的在于想结识一些有同好的朋友一起探讨，完整包括图片的文章可以到我
的blog（hopy.blogchina.com）观赏。另外如有不如何错误请多多指正，不胜感谢。
Windows 核心编程研究系列之一
-改 变 进 程 PTE 属 性-
这是我研究windows 核心编程的第一篇正式文章，之所以叫核心编程而不叫
内核编程，是我觉得从字面上来看核心(core)比内核(kernel)更靠近windows中心，
当然只是偶本人的看法的拉。
我们知道在 win NT 中，系统把每个进程的虚拟4G空间分为两大部份，低2G
归用户所有，高2G归系统所有。用户不得访问系统的空间，连读都不行，更别说
写了！
低2G的用户空间也并不是都能写入的。现在我要说一个特殊的区域：在每个
进程虚拟地址 0x7ffe0000 开始的一段空间称为 USER_SHARED 区域，他和虚拟
地址空间0xffdf0000指向同一物理地址空间，这片区域的长度为 0x2d8。所以不
同进程的这一虚拟地址空间被映射到同一个物理地址空间，如果可以写入该区域
就可以实现系统中所有进程共享数据的目的，注意是所有进程！但可惜的是虽然
0x7ffe0000在低2G的空间，归用户所有，但它只能读不能写，写他的后果如图1所示。
图1
很不爽哦!我前不久在网上看到一篇可以读写物理内存的文章，其实现的思想是：
1 通过系统特权API取得 System Object PhysicalMemory 的写权限；
2 通过分析 MmGetPhysicalAddress 写出其在 ring3 下的伪代码，
从而得到任意虚拟地址映射的实际物理地址
3 写入物理地址
我用汇编重写后好像不能实现其目的，编译运行原来VC++代码也不成功。但据作者
说他可以运行成功。因为这篇文章写得较早，我怀疑是 windows 在后来的PACK中关
闭了这个通道。但只是猜测，也不排除还有我未考虑到的因素，希望搞成功过的朋友
谈谈具体的过程。
我实现的是另一种方法，其主要思想是:
1 找到该虚拟地址在进程页表中的位置；
2 将对应页表项第2位改为1
每个进程的页表被映射到其虚拟地址空间的 0xc0000000 – 0xc003fffff 空间中。
经过简单的计算后得到其页表项位置为:0xc0000000 + 0x1FFF80 = 0xC01FFF80 察看
其内容如图2所示，其最低3位决定了它存在，属于用户区域，但是只读不能写入！
图2
我们下面要做的也非常简单，就是打开其写入标志，使其可写。
就是将 0x25 改为 0x27 。关键代码如下:
mov ebx,0c01fff80h
mov edx,[ebx]
mov al,27h
mov byte ptr [ebx],al
mov eax,cr3
mov cr3,eax
通过一个 kernel driver 注入，修改成功。下面就是在ring3中修改 0x7ffe0080
的内容，以下是代码:
mov ebx,7ffe0080h
mov eax,12345678h
mov dword ptr [ebx],eax
执行结果可以用任意ring3调试器来证实，就是在调试任意程序时察看其进程地址
0x7ffe0080都会发现其值被改为 0x12345678。图3是验证情况。
图3
到这里貌似可以告一段落了，但是还有更值得挖掘的东西，那就是在ring3种直接改写
高2GB的系统内核区域，下面马上将给出的是就是关于改写0x80000000 – 0xffffffff
内核区域的方法，敬请期待。
此帖转自:[url]http://www.programfan.com/team/team.asp?team_id=1189[/url]
文章的目的在于想结识一些有同好的朋友一起探讨，完整包括图片的文章可以到我
的blog（hopy.blogchina.com）观赏。另外如有不如何错误请多多指正，不胜感谢。
Windows 核心编程研究系列之一
-改 变 进 程 PTE 属 性-
这是我研究windows 核心编程的第一篇正式文章，之所以叫核心编程而不叫
内核编程，是我觉得从字面上来看核心(core)比内核(kernel)更靠近windows中心，
当然只是偶本人的看法的拉。
我们知道在 win NT 中，系统把每个进程的虚拟4G空间分为两大部份，低2G
归用户所有，高2G归系统所有。用户不得访问系统的空间，连读都不行，更别说
写了！
低2G的用户空间也并不是都能写入的。现在我要说一个特殊的区域：在每个
进程虚拟地址 0x7ffe0000 开始的一段空间称为 USER_SHARED 区域，他和虚拟
地址空间0xffdf0000指向同一物理地址空间，这片区域的长度为 0x2d8。所以不
同进程的这一虚拟地址空间被映射到同一个物理地址空间，如果可以写入该区域
就可以实现系统中所有进程共享数据的目的，注意是所有进程！但可惜的是虽然
0x7ffe0000在低2G的空间，归用户所有，但它只能读不能写，写他的后果如图1所示。
图1
很不爽哦!我前不久在网上看到一篇可以读写物理内存的文章，其实现的思想是：
1 通过系统特权API取得 System Object PhysicalMemory 的写权限；
2 通过分析 MmGetPhysicalAddress 写出其在 ring3 下的伪代码，
从而得到任意虚拟地址映射的实际物理地址
3 写入物理地址
我用汇编重写后好像不能实现其目的，编译运行原来VC++代码也不成功。但据作者
说他可以运行成功。因为这篇文章写得较早，我怀疑是 windows 在后来的PACK中关
闭了这个通道。但只是猜测，也不排除还有我未考虑到的因素，希望搞成功过的朋友
谈谈具体的过程。
我实现的是另一种方法，其主要思想是:
1 找到该虚拟地址在进程页表中的位置；
2 将对应页表项第2位改为1
每个进程的页表被映射到其虚拟地址空间的 0xc0000000 – 0xc003fffff 空间中。
经过简单的计算后得到其页表项位置为:0xc0000000 + 0x1FFF80 = 0xC01FFF80 察看
其内容如图2所示，其最低3位决定了它存在，属于用户区域，但是只读不能写入！
图2
我们下面要做的也非常简单，就是打开其写入标志，使其可写。
就是将 0x25 改为 0x27 。关键代码如下:
mov ebx,0c01fff80h
mov edx,[ebx]
mov al,27h
mov byte ptr [ebx],al
mov eax,cr3
mov cr3,eax
通过一个 kernel driver 注入，修改成功。下面就是在ring3中修改 0x7ffe0080
的内容，以下是代码:
mov ebx,7ffe0080h
mov eax,12345678h
mov dword ptr [ebx],eax
执行结果可以用任意ring3调试器来证实，就是在调试任意程序时察看其进程地址
0x7ffe0080都会发现其值被改为 0x12345678。图3是验证情况。
图3
到这里貌似可以告一段落了，但是还有更值得挖掘的东西，那就是在ring3种直接改写
高2GB的系统内核区域，下面马上将给出的是就是关于改写0x80000000 – 0xffffffff
内核区域的方法，敬请期待。
此帖转自:[url]http://www.programfan.com/team/team.asp?team_id=1189[/url]