进程线程007 进程挂靠与跨进程读写内存
文章目录
- 进程挂靠
- 进程与线程的关系
- 线程与进程如何关联
- 为什么需要ApcState.Process
- CR3的值可以随便改吗
- 分析NtReadVirtualMemory函数
- 总结
- 跨进程读写内存
- 跨进程操作
- NtReadVirtualMemory流程解析
进程挂靠
进程与线程的关系
一个进程可以包含多个线程
一个进程至少要有一个线程
进程为线程提供资源，也就是提供CR3的值，CR3中存储的是页目录表的基址，CR3确定了线程能访问的内存也就确定了
mov eax,dowrd ptr ds:[0x12345678]
CPU如何解析0x12345678这个地址呢？
- CPU解析线性地址时要通过页目录表来找到对应的物理页，页目录表基址存在CR3寄存器中
- 当前的CR3的值来源于当前的进程(
_KPROCESS.DirectoryTableBase(+0x018))
线程与进程如何关联
ETHREAD结构体：
+0x034 ApcState
+0x000 ApcListHead
+0x010 Process
+0x014 KernelApcInProgress
+0x015 KernelApcPending
+0x016 UserApcPending
+0x220 ThreadsProcess
ETHREAD结构体+0x220的位置存储的就是当前线程所属的进程。
另外在KTHREAD结构体0x34的位置是子结构体ApcState，ApcState也有一个成员Process指向了当前线程所属的进程。
这就存在一个问题，同一个线程结构体里存了两份指针，这两份指针代表什么？
为什么需要ApcState.Process
下面分析SwapContext函数：
这里首先取出目标线程的ApcState.Process存到eax里，然后比较当前线程的ApcState.Process和目标线程的这个成员是否相同，如果不相同就说明不属于同一个进程
代码继续往下走，就会切换CR3的值
线程切换的时候，会比较KTHREAD结构体0x044处指定的EPROCESS是否为同一个，如果不是同一个，会将eax的值取出，赋给CR3。eax此时存储的是目标线程的ApcState.Process。这个时候就发生了进程切换
所以，线程需要的CR3的值来源于0x44处偏移指定的EPROCESS
总结：
0x220亲生父母：这个线程谁创建的
0x44 养父母：谁在为这个线程提供资源，也就是提供CR3
一般情况下，0x220与0x44指向的是同一个进程
CR3的值可以随便改吗
正常情况下，CR3的值是由养父母提供的，但CR3的值也可以改成和当前线程毫不相关的其他进程的DirectoryTableBase
线程代码：
mov cr3,A.DirectoryTableBase
mov eax,dword ptr ds:[0x12345678] //A进程的0x12345678内存
mov cr3,B.DirectoryTableBase
mov eax,dword ptr ds:[0x12345678] //B进程的0x12345678内存
mov cr3,C.DirectoryTableBase
mov eax,dword ptr ds:[0x12345678] //C进程的0x12345678内存
将当前cr3的值改为其他进程，称为进程挂靠
分析NtReadVirtualMemory函数
接下来就通过分析NtReadVirtualMemory函数，来看看是怎么读取其他进程的内存。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hprSWzoq-1581511027410)(assets/1581507589446.png)]
首先找到NtReadVirtualMemory函数
这个函数在内部调用了MmCopyVirtualMemory，继续跟进
真正COPY的函数是MiDoMappedCopy，继续跟进
在开始读取之前先调用了KeStackAttachProcess，也就是之前说过的进程挂靠，继续
这个函数又继续调用了KiAttachProcess，继续跟进
这里先将该线程的+0x44位置的ApcState.Process修改为要读取的进程的KPROCESS
然后又调用KiSwapProcess，真正的挂靠是通过这个函数实现的，继续跟进
真正关键的代码是上面两行，首先取出要读取进程的CR3，+0x18的位置是DirectoryTableBase页目录表基址，然后修改CR3为要读取进程的CR3
NtReadVirtualMemory流程总结
- NtReadVirtualMemory
- MmCopyVirtualMemory
- MiDoMappedCopy
- KeStackAttachProcess
- KiAttachProcess 修改当前线程的ApcState.Process为要挂靠的进程
- KiSwapProcess修改CR3为要挂靠的进程的CR3
既然修改CR3就可以读取目标进程的内存，那么NtReadVirtualMemory可不可以只修改CR3，不修改当前线程的ApcState.Process为要挂靠的进程。
答案是不可以。
回顾一下之前的为什么需要ApcState.Process的问题就会发现，当调用SwapContext进行线程切换的时候，给CR3赋值的时候赋的是ApcState.Process的值。
如果没有修改ApcState.Process，那就意味着ApcState.Process指向的不是挂靠的进程，而是自己的父进程，一旦这个时候发生线程切换并且在线程切换回来的时候，NtReadVirtualMemory读取的就是自己进程的内存了。
如果我们自己来写这个代码，在切换CR3后关闭中断，并且不调用会导致线程切换的API，就可以不用修改养父母的值
总结
正常情况下，当前线程使用的CR3是由其所属进程提供的(ETHREAD 0x44偏移处指定的EPROCESS)，正因为如此，A进程中的线程只能访问A进程的内存
如果要让A进程中的内容能够访问B进程的内存，就必须修改CR3的值为B进程的页目录表基址(DirectoryTableBase)，这就是所谓的进程挂靠
跨进程读写内存
跨进程的本质就是进程挂靠，也就是修改CR3的值为目标进程的页目录表基址
跨进程操作
A进程中的线程代码
mov cr3,B.DirectoryTableBase //切换Cr3的值为B进程
mov eax,dword ptr ds:[0x12345678] //将进程B 0x12345678的值存的eax中
mov dword ptr ds:[0x00401234],eax //将数据存储到0x00401234中
mov cr3,A.DirectoryTableBase //切换回Cr3的值
这段代码的问题在于，当我切换CR3为B进程的页目录基址时，读取的是B进程的内存，那么读取的这段数据该如何传递给A进程呢？不管将这段数据放在哪个位置，始终都是B进程的内存空间。
这里需要回顾一下进程的地址空间管理，低2GB是每个进程私有的，而高2GB的操作系统共享的。如果在B进程将读取的数据放到高2GB共享的内核空间，然后在切回CR3的时候，从高2GB取数据，就解决了这个问题
NtReadVirtualMemory流程解析
我们来看一下NtReadVirtualMemory是如何解决这个问题的：
- 首先切换CR3为目标进程的页目录基址
- 接着将数据复制到高2GB的某一个位置
- 然后切回CR3
- 最后从高2GB复制到目标位置
NtWriteVirtualMemory和NtReadVirtualMemory的执行流程类似