能力值:
( 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
|
|
|