在Windows系统中，我们可以跨进程修改另一个进程的内存。例如，如果进程A想要修改进程B的内存，A可以调用系统函数WriteProcessMemory。大致形式如下：
BOOL flag = WriteProcessMemory(handler, p_B_addr, &p_A_buff, write_size); ...
此函数返回一个布尔值，表示写入操作是否成功。它需要通过四个参数，让我们看看这四个参数：
处理程序。这是一个进程句柄，可以用来查找B进程。
p_B_addr。在进程B中，要写入存储器的地址偏移量。
p_A_buff。在进程A中，指向写入数据缓冲区的指针。
write_size。要写入的字节数。
我对第一个参数处理程序感到困惑，它是HANDLE类型的变量。例如，当我们的程序实际运行时，进程B的ID是2680，然后我想向进程B写入内存。首先我需要使用这个2680来获得进程A中进程B的句柄。具体形式是handler=OpenProcess(process_ALL_ACCESS，FALSE，2680(，然后你可以使用这个handler落入内核来修改进程B的内存。
既然它们都被困在内核函数中，以便跨进程修改内存，为什么WriteProcessMemory函数没有设计为WriteProcessMemory(B_procID，p_B_addr，&p_A_buff，write_size(的形式？
其中，B_procID是B进程的ID，因为每个进程都有唯一的ID。系统内核是否找不到B进程的虚拟地址可以通过此B_procID映射的物理地址？为什么必须传入A进程中B进程的进程句柄索引？
原因有很多，都在评论中提到了。
- 使用寿命。进程id只是一个数字，知道id并不能使进程保持活动状态。拥有进程的开放句柄意味着内核EPROCESS结构和进程地址空间将保持不变，即使所述进程通过调用
ExitProcess结束。Windows尝试不立即重新使用新进程的id，但如果有足够的时间，这将在未来某个时候发生 - 安全/访问控制。在Windows NT中，访问控制是在打开对象时执行的，而不是每次与对象交互时执行的。在这种情况下，内核需要知道调用者具有对进程的PROCESS_VM_WRITE和PROCESS_VM.OPERATION访问权限。这与第3点，效率有关
- 速度。Windows当然可以实现一个
WriteProcessMemoryById函数，该函数调用OpenProcess+WriteProcessMemory+CloseHandle，但这鼓励次优设计，并允许您接受与第1点相关的竞争条件。这同样适用于"；为什么没有CCD_ 6函数"；(以及所有其他读/写功能(