windows:重写openprocess函数跨进程读数据

   外挂、木马、病毒等可能需要读取其他进程的数据,windows提供了OpenProcess、ReadProcessMemory等函数。但越是大型的软件,防护做的越好,大概率会做驱动保护,比如hook SSDT表等,这些系统调用都会先被过滤一次,导致返回的数据不是想要的;为了确保能读到目标进程数据,最好重写ReadProcessMemory;要想读取其他进程的内容,思路大概有一下几种:

  •  注册PsSetLoadImageNotifyRoutine函数,其他进程加载模块会时调用我们注册的函数,这个时候已经进入目标进程的空间,可用memcpy复制数据
  •     KeStackAttachProcess可以切换到目标进程,然后用memcpy复制数据,最后调用KeUnstackDetachProcess切换回来
  •     利用进程ID查找EPROCESS,根据名称得到目标EPROCESS后再读取CR3,最用利用目标进程的CR3读取其内存数据;

  前两种方式要调用大家熟知的函数,目的性比较明显,这些函数肯定会被大厂家重点关注,返回的结果可能在逻辑上有误;而第三种方式仅仅根据ID查询EPROCESS,相对前两种更加“人畜无害”,被拦截的概率要小很多,今天详细介绍第三种方式。

  1、为了验证读取数据是否正确,先在notepad随便写一些内容,然后用CE查看地址,如下,后续就选这个地址来测试了;

            

       这里多说几句:CE为了防止被针对,自己重写了关键的内存扫描/读写、进程打开函数,并未使用windows原生自带的系统调用函数;

           

 

   2、遍历进程,根据ID查找EPROCESS,进而得到进程名、CR3等关键信息,这块也比较简单,如下:

PEPROCESS LookupProcess(HANDLE Pid)
{
    PEPROCESS eprocess = NULL;
    NTSTATUS Status = STATUS_UNSUCCESSFUL;
    Status = PsLookupProcessByProcessId(Pid, &eprocess);
    if (NT_SUCCESS(Status))
        return eprocess;
    return NULL;
}

    因不同版本EPROCESS结构体可能有细微区别,保险起见最好在windbg下通过dt _EPROCESS查看一下CR3的偏移,我这里是0x28,那么CR3的获取代码:

ULONG64 target_CR3 = *(PULONG64)((ULONG64)eproc + 0x28);

  3、目标CR3都拿到了,接下来就可以读进程数据了,这里的环境是win10 x64,默认开启了PAE;最初的想法很简单,系统用的是9-9-9-9-12分页,那么先把虚拟地址拆分,再用CR3一步一步跟踪不就得到物理地址了吗? 物理地址都有了,再读取数据岂不是探囊取物般简单了么?

     所以刚开始的代码是这样的:(1)先拆分虚拟地址,得到各个层级的偏移  (2)再仿造windbg种逐步计算的方式一步一步得到物理地址;  (3)这里有点要注意:& 和移位的优先级较低,注意使用括号,避免计算的逻辑错误;

    ULONG64 PML4E_index = (virtualAddress >> 39) & 0x1ff;
    ULONG64 PDPE_index = (virtualAddress >> 30) & 0x1ff;
    ULONG64 PDE_index = (virtualAddress >> 21) & 0x1ff;
    ULONG64 PTE_index = (virtualAddress >> 12) & 0x1ff;
    ULONG64 physical_offset = virtualAddress & 0xfff;
    ULONG64 PML4E = CR3 + (PML4E_index << 3);
    ULONG64 PDPE = (*(PULONG64)PML4E & 0x00000007fffff000) + (PDPE_index << 3);//上一级table entry的12~35位提供下一级table物理基地址的高24位,此时36~51是保留位,必须置0,低12位补零
    ULONG64 PDE = (*(PULONG64)PDPE & 0x00000007fffff000) + (PDE_index << 3);
    ULONG64 PTE = (*(PULONG64)PDE & 0x00000007fffff000) + (PTE_index << 3);
    ULONG64 physicalAddress = (*(PULONG64)PTE & 0x00000007fffff000) + physical_offset;

   然而一运行就蓝屏,通过下断点逐步跟踪,发现罪魁祸首在这行:ULONG64 PDPE = (*(PULONG64)PML4E & 0x00000007fffff000) + (PDPE_index << 3)

   这样代码做的运算有好几个,为了彻查到底是哪个运算导致的蓝屏,继续把代码拆分地更细,最终发现导致蓝屏的真凶:*(PULONG64)PML4E;

     这行代码本身很简单,就是把PML4E转换成指针,再读取其指向的内容,这么简单的操作,为啥会导致蓝屏了?这就牵扯到win10 x64下用户态CR3和内核态CR3的区别了;本案例用的是驱动,在0环内核态执行,自然用的是内核态CR3。但代码读取数据的虚拟地址明显是3环的,属于用户态。不同的CR3会映射到不同的物理地址,最终出错。问题找到了,怎么解决了?既然是CR3不对,那么读取内存之前先切换一下不就行了? 

          由于vs2019对于x64的程序不允许内联汇编,这里单独新建一个asm文件来切换CR3,如下:

_swapCR3 PROC
        mov cr3,rcx;
        ret
_swapCR3 Endp

  然后继续单步调试,切换CR3的函数执行完后,CR3成功更改:

       

   但是在执行*(PULONG64)PML4E前查看时CR3又变回了内核态CR3:

        

   继续执行不出意外又蓝屏:

        

    为什么函数 _swapCR3 执行完后,CR3又变回了内核态?经过多次反复尝试,发现都是断点惹的祸:代码里面设置了断点,执行到断点时会被系统进程接管,然后CR3自然就切换;

  既然ret后CR3又被改回,那么只能在汇编代码里面读取虚拟地址的内容了,这次重新写一个_ReadVirtualMemory代码,如下(这里直接使用mov rax,[rdx],还省去了繁琐的地址转换,这部分直接让cpu自动做了):

_ReadVirtualMemory PROC
        push rax;
        push rbx;
        mov rbx,cr3;保存旧的CR3
        mov cr3,rcx;
        mov rax,[rdx];第二个参数,是VirtualMemory
        mov data,rax
        mov cr3,rbx;还原旧的CR3
        pop rbx;
        pop rax;
        ret
_ReadVirtualMemory Endp

 

  在这里读的数据终于对了,效果如下:0x7ffd350ca309 地址前2个字节的内容确实是CC,和通过CE查找到的一致;

       

 

   完整代码如下:主文件

#include "ReadProcessMemory.h"

ULONG64 data;

// 根据进程ID返回进程EPROCESS结构体,失败返回NULL
PEPROCESS LookupProcess(HANDLE Pid)
{
    PEPROCESS eprocess = NULL;
    NTSTATUS Status = STATUS_UNSUCCESSFUL;
    Status = PsLookupProcessByProcessId(Pid, &eprocess);
    if (NT_SUCCESS(Status))
        return eprocess;
    return NULL;
}

VOID EnumProcess()
{
    PEPROCESS eproc = NULL;
    for (int temp = 0; temp < 100000; temp += 4)
    {
        eproc = LookupProcess((HANDLE)temp);
        if (eproc != NULL )
        {
            if (!strcmp(PsGetProcessImageFileName(eproc),"notepad.exe"))
            {
                DbgPrint("进程名: %s --> 进程PID = %d --> 父进程PPID = %d -->EPROCESS地址:%p \r\n", PsGetProcessImageFileName(eproc), PsGetProcessId(eproc),
                    PsGetProcessInheritedFromUniqueProcessId(eproc), eproc);
                ULONG64 target_CR3 = *(PULONG64)((ULONG64)eproc + 0x28);
                KdBreakPoint();
                _ReadVirtualMemory(target_CR3, 0x7ffd350ca309);
                DbgPrint("存储内容:%c \r\n", data);
                ObDereferenceObject(eproc);
                return;
            }
            
        }
    }
}

VOID UnDriver(PDRIVER_OBJECT driver)
{
    DbgPrint(("Uninstall Driver Is OK \n"));
}

NTSTATUS DriverEntry(IN PDRIVER_OBJECT Driver, PUNICODE_STRING RegistryPath)
{
    EnumProcess();
    Driver->DriverUnload = UnDriver;
    return STATUS_SUCCESS;
}

  头文件:

#ifndef READPROCESSMEMORY_
#define READPROCESSMEMORY_

#include <ntifs.h>

NTKERNELAPI UCHAR* PsGetProcessImageFileName(IN PEPROCESS Process); //未公开的进行导出即可
NTKERNELAPI HANDLE PsGetProcessInheritedFromUniqueProcessId(IN PEPROCESS Process);//未公开进行导出

extern void Dbg_Break();
extern void _swapCR3(ULONG64 target_CR3);
extern void _ReadVirtualMemory(ULONG64 target_CR3, ULONG64 VirtualMemory);

extern ULONG64 data;

#endif

     asm文件:这里切换CR3的时候为了保险起见,建议先保存旧CR3,用完了再切回去;

EXTERN data:qword

.code
 
Dbg_Break Proc
        int 3
        ret
Dbg_Break Endp

_swapCR3 PROC
        mov cr3,rcx;
        ret
_swapCR3 Endp

_ReadVirtualMemory PROC
        push rax;
        push rbx;
        mov rbx,cr3;保存旧的CR3
        mov cr3,rcx;
        mov rax,[rdx];第二个参数,是VirtualMemory
        mov data,rax
        mov cr3,rbx;还原旧的CR3
        pop rbx;
        pop rax;
        ret
_ReadVirtualMemory Endp

END

   最后注意: VS2019在x64的默认调用约定是_stdcall,不是_fastcall,建议改成_fastcall;

 

posted @ 2020-06-24 17:29  第七子007  阅读(1667)  评论(0编辑  收藏  举报