驱动用mdl强写或者挂靠强写，这样你加载dll都会变成你改的不会触发写拷贝

“IMAGE_SCN_MEM_SHARED”特征

根据Microsoft的文档，IMAGE_SCN_MEM_SHARED标志表示“该节可以在内存中共享”。但是，这到底是什么意思呢？在网络中没有找到太多关于该标志的说明文档，但事实证明，如果启用该标志，该节的内存将在加载了该映像的所有进程之间共享。例如，如果进程A和B加载一个PE映像，其中包含一个“共享”（并且可写）的节，那么进程A中该节的内存中的任何变化都将反映在进程B中。

与我们将在本文中讨论的理论密切相关的一篇文献是“DLL shared sections: a ghost of the past”。在这篇文章中，Coldwind探讨了由具有IMAGE_SCN_MEM_SHARED特征的PE节的二进制文件所带来的潜在风险。

Coldwind解释说，这些PE映像带来的风险“是一个古老而众所周知的安全问题”，并引用了微软在2004年发表的一篇文章，题为“ Why shared sections are a security hole”。该文章只考察了“读/写共享节”和“只读共享节”所构成的威胁，而没有讨论第三种可能，即“读/写/执行共享节”。

利用共享节

尽管研究人员和微软本身知道共享节的一般风险已经有很长一段时间了，但还没有文献对可读、可写和可执行(RWX-S)的共享节的潜在滥用进行过深入介绍。

RWX-S二进制文件具有极大的进攻潜力，这是因为：如果您可以使远程进程加载指定的RWX-S二进制文件，那么您就在远程进程中获得了一个可执行的内存页，即使您对这个内存页进行修改，基于内核的防御解决方案也是看不到的。为了注入代码，攻击者可以将RWX-S二进制文件加载到自己的进程中，并在内存中使用他们想要的任何恶意代码编辑该节，然后将RWX-S二进制文件加载到远程进程中，这时，他们自己进程中的修改也会反映在受害者进程中。

加载RWX-S二进制文件本身的操作对防御性解决方案仍然是可见的，但正如我们将在后面的部分中讨论的那样，对于在恶意上下文之外使用的合法RWX-S二进制文件，实际上有很多选择的余地。

网上随便找的一段说明，具体可以去查msdn

.DATA?
    BufferDLL db 1024 dup(?)

.CODE

DllEntry proc hinstDLL:HINSTANCE, fdwReason:QWORD, lpvReserved:QWORD
         
    mov    rax, TRUE
    ret

DllEntry Endp

DllToExe proc 
    
    lea    rax,BufferDLL
    ret

DllToExe endp

ExeToDll proc uses rdi 
    
    ;zero clearing BufferDLL 
    xor    rax,rax
    lea    rdi,BufferDLL
    mov    rcx,1024
    rep    stosb

    lea    rax,BufferDLL
    ret

ExeToDll endp


End DllEntry

1，这个DLL在生成时，加“/SECTION:.text,rwe ”使调用它的进程能写DLL的缓存。

2，这个DLL有2个输出功能函数DllToExe、ExeToDll，没有输入参数，返回值是缓存的地址。当进程写时，调用ExeToDll，它就告诉进程：1024的缓存我已清零，请写到我这儿。当进程读时，调用DllToExe，它就告诉进程：数据在我这儿，请拿走。

3，假设A进程写，B进程读。当A进程写完后，就发消息WM_USER+1，告诉B进程“我已写完，请读走”；当B进程收到消息WM_USER+1，就读走数据。

这是效果图。

        Windows操作系统提供了应用程序之间通信和数据共享的诸多机制，其中有：
        裁剪板（Clipboard）、组件对象模型（COM）、数据拷贝（Data Copy）、动态数据交换（DDE）、文件映射（File Mapping）、邮槽（Mailslots）、远程过程调用（RPC）、命名管道（Pipes）、套接字（Windows Sockets），这些机制为应用程序之间的分工协作提供了便利。当然还有其它机制可实现应用程序之间通信和数据共享，例如：
         Event Pipes；
         Mutexes；
         Semaphores；
         OLE/ActiveX；
         Distributed Component Object Model (DCOM)；
         Remote Method Invocation (RMI)；
         Common Object Request Broker Architecture (CORBA)；
         Local Procedure Call (LPC)；
         Microsoft Message Queue (MSMQ)；
         DLL(动态连接库)
        这些机制各有优缺点，有的效率高、有的易于实现、有的不易监控、有的运行稳定、有的隐蔽性强。这么多Windows操作系统提供的应用程序之间通信和数据共享的机制总有一款适合你的应用。其中DLL(动态连接库)实现的机制结构简单、运行稳定。

利用重映射就行了.不要太多代码,直接把整个DLL模块映射可执行读写就行了.
然后A进程正常重映射A.dll后,再直接同一个hSection映射到B进程应该就OK了.
理论上应该是行得通的,自己去看下下面这帖子的重映射,就行了.
记住,映射一定要0x10000对齐,不懂的直接把整个模块映射成PAGE_EXECUTE_READWRITE就没问题,简单粗暴

https://bbs.kanxue.com/thread-268057.htm

1,如果OS打了最新的补丁，即便是生成DLL时，加了“/SECTION:.text,rwe”参数，在R3层OS也禁止调用它的进程写DLL的缓存。因此，只能让DLL自己写自己的缓存。

.DATA?
    BufferDLL db 1024 dup(?)

.CODE

DllEntry proc hinstDLL:HINSTANCE, fdwReason:QWORD, lpvReserved:QWORD
         
    mov    rax, TRUE
    ret

DllEntry Endp

DllToExe proc 
    
    lea    rax,BufferDLL
    ret

DllToExe endp

ExeToDll proc uses rsi rdi DataBuffer:qword,DataSize:qword
    
    ;zero clearing BufferDLL 
    xor    rax,rax
    lea    rdi,BufferDLL
    mov    rcx,1024
    rep    stosb

    ;copy DataBuffer -> BufferDLL 
    lea    rdi,BufferDLL
    mov    rcx,DataSize
    mov    rsi,DataBuffer
    rep    movsb
    
    ret

ExeToDll endp

2，这里的示例是半工状态，即A进程只能写，B进程只能读，且模式是一对一。你可测试时，改为全工状态：A、B进程能通过DLL读写彼此的数据。也可尝试一对多，多对多，增加通讯协议，数据分类。

看起来你只是想实现用B.exe去读A的内存而不一定要用到内存映射，如果是这样的话你用ReadProcessMemory函数去读取就好，网上搜索ReadProcessMemory读取应用内存，代码现成。