读书笔记-改变线程EIP注入-原理和方式笔记

12.1.2 改变线程EIP注入

• 1.CreatRemoteThread
  • [test pass]
    原理:
    1.在目标进程中申请内存，并向其中写入dll路径
    2.然后调用CreatRemoteThread ,在目标进程中创建线程，线程函数的地址写 LoadLibrarA(W),参数为步骤1中dll的路径存放内存指针
    
    PS:
    要求拥有目标进程的4个权限:
    PROCESS_CREATE_THREAD
    PROCESS_QUERY_INFORMATION
    PROCESS_VM_OPERATION
    PROCESS_VM_WRITE
    win7及其以上版本要求更多的权限
    问题:
    Vista以上版本增加了会话(Session)隔离，调用CreateRemoteThread时对会话进程检查，不再统一会话会调用CsrClientCallServer 登记新线程失败，但是这个过程在KernelBase.dll中进行，可以使用Shellcode将其Patch掉。
    但即使如此，如果涉及需要CSRSS子系统支持操作，其创建和执行就会失败。
    
• 2.RtlCreateUserThread
  • [test fail] -- 这个好奇怪原始代码编译运行也不行
    原理:
    RtlCreateUserThread
    ntdll中Rtl执行体的一部分，与CreateRemoteThread类似,最终都是用NtCreateThreadEx 来创建线程实体。
    但它一般用来创建特殊线程
    （eg： Native 程序的smss.exe 用其来创建监听线程，
                 以及在调试器附加到进程时创建DbgUiRemoteBreakin线程）
    所以不需要经过csrss的验证登记。
    diff:  与CreateRemoteThread不同的是，使用RtlCreateUserThread创建的线程需要自己结束自己
    
    • PS:
      • + - native程序介绍:
        
        • https://www.cnblogs.com/BoyXiao/archive/2011/09/21/2183059.html
          在一开始的 Windows NT 内核中是支持三个环境子系统的，即 POSIX,WINDOWS,OS/2，这些子系统属于同一层，它们共用了 Windows NT 所提供的 API，
          即每一个子系统中的 API 的调用都会转换到下一层的相同调用上，
          在 Windows 环境子系统(有 Windows,Posix,OS/2)中的程序，
          都会调用其相对于的子系统下的 API，比如 Windows 子系统中的程序有可能会调用 Win32 API CreateProcess，
          
          而 Posix 子系统中的程序也有可能会调用 Posix API CreateProcess(当然有可能在 POSIX 下创建进程不是这个名称)，
          但是终归来说，这两个 CreateProcess 的调用都会转换到 Ntdll.dll 中的 NtCreateProcess 中，
          也就是上面的三个子系统最后的调用都会回归到 ntdll.dll 上，
          而我们的 Native Application 则是绕过 Windows 子系统，
          直接自己调用 Native API，比如创建进程的话，我就不再通过子系统中的神马 CreateProcess 来完成了，
          而是直接在程序中调用 ntdll.dll 中的 Native API NtCreateProcess 来完成，
          而这类程序即称之为 Native Application !
                    
          
          Native Application 的运行环境：
          上面也说了，Native Application 是只能够访问 ntdll.dll 中的内容的，
          而如果是在子系统下运行一个程序的话，必然会加载其他的 DLL，
          比如在 Windows 子系统下一个 kernel32.dll 是必不可少的吧，
          如果 Native Application 能够运行在 Windows 子系统下的话，必然也会加载到 Kernel32.dll，
          这样不就和上面相违背了嘛 ~
          总之：Native Application 是不能够运行在任何子系统下的 !
          
        + - smss.exe与native的启动时机
        
        • Native Application 的启动时机：
          对于 Windows 操作系统的引导过程，这里需要带一笔的，Windows 操作系统启动时，
          当 Windows 内核的引导完成以后，就会启动会话管理器 smss.exe 进程了，
          smss.exe 进程虽然是一个用户模式的进程，但是这个进程相对于其他用户模式进程是具有一定特殊性的，
          首先 smss.exe 进程是直接建立在 Windows NT 内核上的，其不依赖于任何一个环境子系统，
          至于不依赖于任何一个环境子系统这一说的话，还是可以很好的解释的，
          因为当环境子系统进程(Windows 子系统进程为 csrss.exe)就是由 smss.exe 进程启动的，
          然后 smss.exe 是 Windows 操作系统启动的第一个用户态进程，
          而 Native Application 也属于用户态程序，自然 Native Application 的启动是在 smss.exe 之后，
          而后前面也说过，Native Application 运行时，子系统进程还尚未启动，
          所以 Native Application 的启动则是在 csrss.exe 之前的，
          而话又说回来，csrss.exe 就是由会话管理器(smss.exe)启动的，
          所以 Native Application 的启动时机也就只有一种可能了，
          
          即 smss.exe 先启动 Native Application，然后 Native Application 开始执行，
          等到 Native Application 都给执行完了后 smss.exe 再启动 csrss.exe 进程。
          （事实上，Win32 应用程序环境子系统 csrss.exe 本质上也是一个 Native Application ~）
          
• 3.QueueUserApc/NtQueueAPCThread
  • [?] 这个没有提供原始代码
    原理:
    线程从等待状态苏醒时，会检测是否有APC交个自己执行，如果有则执行。
    APC分两种，内核APC和用户模式APC，这里通过QueueUserAPC将APC过程添加到目标线程中APC队列，等待线程从等待状态到苏醒切换时，执行此线程。