能力值：
( LV4，RANK：50 )
|
-
-
2 楼
PAGE_EXECUTE_WRITECOPY 在你修改进程在内存中的代码段的时候不会影响到硬盘中的PE文件，否则的话修改之后硬盘上的也被改掉
|
能力值：
( LV2，RANK：10 )
|
-
-
3 楼
PAGE_EXECUTE_READWRITE 一样不会modify原文件。
我今天专门编了个程序实验了一下， 两种参数没有啥差别。
同时打开同一exe的两个process ， 修改其中一个（比如把一个函数jmp到另外一个）
不会影响该exe的另一个process 。
所以我觉得， 对于exe/dll image来说， 这两个protect没有区别。
|
能力值：
( LV2，RANK：10 )
|
-
-
4 楼
PAGE_EXECUTE_WRITECOPY 的意思是copyonwrite->本节写入时复制->本节内所有page都可以writeoncopy，READWRITE只是单纯的写入无copy
|
能力值：
( LV4，RANK：50 )
|
-
-
5 楼
因为你加上了可写属性
|
能力值：
( LV3，RANK：30 )
|
-
-
6 楼
当系统 中存在 两份EXE/DLL 以上时，才会有作用，PAGE_EXECUTE_WRITECOPY 映射到同一块物理内存，PAGE_EXECUTE_READWRITE是不同的物理内存
|
能力值：
( LV2，RANK：10 )
|
-
-
7 楼
我觉得对于exe/dll image来说， PAGE_EXECUTE_READWRITE 也是copy on write 。
不可能在原image上写入， 也是在page file里新copy一块。
|
能力值：
( LV2，RANK：10 )
|
-
-
8 楼
建议看 wrk 的源码！
|
能力值：
( LV2，RANK：10 )
|
-
-
9 楼
WRITECOPY肯定不会map到同一个physical address ， 而READWRITE也不是同一个 。
对于两个instance来说， 它们都是不同的address
今天又研究了一下， 做个总结。
首先， 我犯了个错误， 那就是WRITECOPY对于编程来说， 是弄不出来的。
无论是VirtualAlloc还是VirtualProtect都不支持。
我用VirtualProtect把一处函数地址修改为PAGE_EXECUTE_WRITECOPY 返回为TRUE ， 就以为成功了。
而事实上， 后来再去查询结果是PAGE_EXECUTE_READWRITE
所以， 我们可以忘掉WRITECOPY ， 这个只能是linker能做出来， 我们程序员做不出来。
那么什么时候生成文件中会有WRITECOPY的section呢？
我编程扫描了一下， 发现了.textbss 这个section是PAGE_EXECUTE_WRITECOPY ， 查了一下， 这个是在linker里面， 开启incremental linking之后， 由linker生成的。
这个section是最容易找到的WRITECOPY ， 至少我目前不知道其他任何方式能够生成WRITECOPY的page
|
|
|
|
