狙剑V-测试进程保护初探.doc

狙剑V-测试进程保护初探

————————————————————————————————
———————————————————————————————— 日期：

8

狙剑V2021-0218测试版进程保护初探
在作毕业设计之余实在无聊，就在电脑中随手点开狙剑，来回倒腾着，突然对狙剑的进程保护产生了兴趣，就用icesword以及电脑中所收集的其它ARK工具在虚拟机中来对狙剑的进程保护测试，发现用icesword也不能结束它，其它的ARK工具，很多在结束它时反而让它给结束了。于是就决定对它的进程保护深入研究下。
首先看看它都挂了进程相关的哪些函数，用Rootkit Unhooker v3.7的Code Hooks选项来查看系统中被hook的函数的情况，发现内核函数PsLookupThreadByThreadId和KeInsertQueueApc被inline hook到SnipeSword.sys模块中。在pjf大牛的<终止进程的内幕.>一文中，我们知道线程的终止其实就是线程的“自杀〞，系统通过KeInitializeApc/KeInsertQueueApc把一个APC插入核心态或者用户态中，使线程在运行中自己调用PspExitThread自行了断，因此snipesword的进程防杀还是很底层的，难怪那么多工具结束不了它。我们从被hook到的地址0x f410e570和0Xf7b304cb来看，好似在该驱动自己申请的非分页内存中。于是翻开windbg，切换到本机内核调试中准备看看这个地址的内容，发现windbg不能连接本机，看来是作了反调试的处理，于是又运行了softice，结果。。。又发现不能下断点。。。。
于是只好重新运行icesword，在进程中选择snipesword.exe进程，右键菜单项选择择内存读写，在起始地址中输入0xf7b30570，长度中输入0xff，然后点读内存，之后点反汇编，就是这个位置的hook PsLookupThreadByThreadId代码：
f7b30570 PUSH EBP
f7b30571 MOV EBP,ESP
f7b30573 ADD ESP,-4
f7b30576 PUSHAD
f7b30577 MOV EAX,[EBP+8]
f7b3057a CMP EAX,[F7B3D044]
f7b30580 JNZ SHORT F7B3058C
f7b30582 POPAD
f7b30583 MOV EAX,C0000022
f7b30588 LEAVE
f7b30589 RETN 8
f7b3058c PUSH DWORD PTR [EBP+C]
f7b3058f PUSH DWORD PTR [EBP+8]
f7b30592 CALL F7B305A2
f7b30597 MOV [EBP-4],EAX
f7b3059a POPAD
f7b3059b MOV EAX,[EBP-4]
f7b3059e LEAVE
f7b3059f RETN 8
f7b305a2 MOV EDI,EDI
f7b305a4 PUSH EBP
f7b305a5 MOV EBP,ESP
f7b305a7 NOP
f7b305a8 NOP
f7b305a9 NOP
f7b305aa NOP
f7b305ab NOP
f7b305ac NOP
f7b305ad NOP
f7b305ae NOP
f7b305af NOP
f7b305b0 NOP
f7b305b1 NOP
f7b305b2 PUSH 80579A8A
f7b305b7 RETN
拷贝到文本编辑器中，又用同样的方法获取另一个地址处hook KeInsertQueueApc的代码，
f7b304cb PUSH EBP
f7b304cc MOV EBP,ESP
f7b304ce ADD ESP,-4
f7b304d1 PUSHAD
f7b304d2 MOV ESI,[EBP+8]
f7b304d5 MOV EAX,[ESI+8]
f7b304d8 CMP EAX,[F7B3D048]
f7b304de JNZ SHORT F7B3053E
f7b304e0 MOV EAX,[ESI+14]
f7b304e3 CMP EAX,90000000
f7b304e8 JBE SHORT F7B304F2
f7b304ea CALL F7B3B6E4
f7b304ef MOV [ESI+8],EAX
f7b304f2 CMP DWORD PTR [F7B41C59],0
f7b304f9 JE SHORT F7B3053E
f7b304fb MOV EAX,[ESI+1C]
f7b304fe AND EAX,FFFFF000
f7b30503 MOV ECX,[F7B41C59]
f7b30509 AND ECX,FFFFF000
f7b3050f CMP EAX,ECX
f7b30511 JNZ SHORT F7B3053E
f7b30513 CALL F7B3B6E4
f7b30518 MOV [ESI+8],EAX
f7b3051b MOV ESI,[F7B3D048]
f7b30521 ADD ESI,[F7B3CFF0]
f7b30527 XOR EAX,EAX
f7b30529 MOV [ESI],EAX
f7b3052b MOV ESI,[F7B3D040]
f7b30531 ADD ESI,[F7B3CFEC]
f7b30537 MOV EAX,[ESI]
f7b30539 SUB EAX,8
f7b3053c MOV [ESI],EAX
f7b3053e PUSH DWORD PTR [EBP+14]
f7b30541 PUSH DWORD PTR [EBP+10]
f7b30544 PUSH DWORD PTR [EBP+C]
f7b30547 PUSH DWORD PTR [EBP+8]
f7b3054a CALL F7B3055A
f7b3054f MOV [EBP-4],EAX
f7b30552 POPAD
f7b30553 MOV EAX,[EBP-4]
f7b30556 LEAVE
f7b30557 RETN 10
f7b3055a MOV EDI,EDI
f7b3055c PUSH EBP
f7b3055d MOV EBP,ESP
f7b3055f NOP
f7b30560 NOP
f7b30561 NOP
f7b30562 NOP
f7b30563 NOP
f7b30564 NOP
f7b30565 NOP
f7b30566 NOP
f7b30567 NOP
f7b30568 NOP
f7b30569 NOP
f7b3056a PUSH 804E69A6
f7b3056f RETN
获取这些代码后，又在WRK v1.2的代码包中找到这两个函数的函数声明：
NTSTATUS
PsLookupThreadByThreadId(
__in HANDLE ThreadId,
__deref_out PETHREAD *Thread
)；
BOOLEAN
KeInsertQueueApc (
__inout PRKAPC Apc,
__in_opt PVOID SystemArgument1,
__in_opt PVOID SystemArgument2,
__in KPRIORITY Increment
)；
获取这些后，发现这样看实在是麻烦，还是把snipesword的驱动倒腾出来在IDA v5.2中反汇编了看的好。用PEIDv0.94查看发现snipesword没有加壳，就用PE Explorer翻开该文件，在资源中找到RC Data中发现一个带PE的资源，将资源导出，更名为snipesword.sys,之后用KmdManager v1.4在虚拟机中加载试验了一下，发现确实可以加载，看来这个就使狙剑的驱动了。然后用IDA v5.2翻开这个驱动文件，开始反汇编。
以下为hooked KeInsertQueueApc反汇编注释的代码：
.text:000114CB HookedKeInsertQueueApc proc near ; DATA XREF: sub_119B3+36o
.text:000114CB
.text:000114CB Apc = dword ptr 8
.text:000114CB arg_4 = dword ptr 0Ch
.text:000114CB arg_8 = dword ptr 10h
.text:000114CB arg_C = dword ptr 14h
.text:000114CB
.text:000114CB push ebp
.text:000114CC mov ebp, esp
.text:000114CE add esp, 0FFFFFFFCh
.text:000114D1 pusha
.text:000114D2 mov esi, [ebp+Apc] ; Apc指针
.text:000114D5 mov eax, [esi+8] ; Apc->Thread
.text:000114D8 cmp eax, MyPTHREAD ；MyPTHREAD为要保护线程的THREAD
.text:000114DE jnz short KeInsertQueueApc ; 不相等那么跳转
.text:000114E0 mov eax, [esi+14h] ; Apc->KernelRoutine
.text:000114E3 cmp eax, 90000000h
.text:000114E8 jbe short Lable1 ; 低于等于时才跳转
.text:000114EA call KeGetCurrentThread
.text:000114EF mov [esi+8], eax
.text:000114F2 Lable1:
.text:000114F2 cmp PNormalRoutine, 0 ；很令人迷惑的是在icesword中看到的PnormalRoutine指向的是PspTerminateThreadByPointer地址
.text:000114F9 jz short KeInsertQueueApc ; 等于零那么跳转
.text:000114FB mov eax, [esi+1Ch] ; [esi+1Ch]为Apc->NormalRoutine
.text:000114FE and eax, 0FFFFF000h
.text:00011503 mov ecx, PNormalRoutine
.text:00011509 and ecx, 0FFFFF000h
.text:0001150F cmp eax, ecx
.text:00011511 jnz short KeInsertQueueApc
.text:00011513 call KeGetCurrentThread
.text:00011518 mov [esi+8], eax
.text:0001151B mov esi, MyPTHREAD
.text:00011521 add esi, Offset0x248
.text:00011527 xor eax, eax
.text:00011529 mov [esi], eax ;其中eax为EPROCESS结构中的CrossThreadFlags
.text:0001152B mov esi, PEPRCESS
.text:00011531 add esi, aoffset0x248
.text:00011537 mov eax, [esi] ; [esi]为 EPROCESS结构中的Flags
.text:00011539 sub eax, 8
.text:0001153C mov [esi], eax
.text:0001153E
.text:0001153E KeInsertQueueApc: ; 此处调用的是原来的
.text:0001153E ; HookedKeInsertQueueApc+2Ej ...
.text:0001153E push [ebp+arg_C]
.text:00011541 push [ebp+arg_8]
.text:00011544 push [ebp+arg_4]
.text:00011547 push [ebp+Apc]
.text:0001154A call MyKeInsertQueueApc
.text:0001154A HookedKeInsertQueueApc endp
.text:0001154F ; ---------------------------------------------------------------------------
.text:0001154F mov [ebp-4], eax
.text:00011552 popa
.text:00011553 mov eax, [ebp-4]
.text:00011556 leave
.text:00011557 retn 10h
以上是hooked KeInsertQueueApc代码，在该段代码中，通过判断传入的第一个参数Apc中的Thread指针是否示要保护的线程KTHREAD，来到达保护的作用。如果示要保护的线程
KTHREAD，那么会判断当前线程是否是要保护的线程本身，如果是线程本身要结束，那么跳转到MyKeInsertQueueApc执行，否那么将Apc中的Thread修改成当前要执行此insert apc操作的线程的KTHREAD指针，这就是为什么任务管理器以及其它的很多ARK工具结束snipesword时不但没有把snipesword结束掉，反而被snipesword结束掉的原因，因为将Apc中的Thread指针修改成当前线程指针后，等于是这些软件把自己结束了。
通过观察，我们发现在代码中并没有重新跳回原来的KeInsertQueueApc函数中取执行，而是自己构建了一个函数，我在此将给函数标记为MyKeInsertQueueApc，在MyKeInsertQueueApc中将跳转指令覆盖的指令补充齐全了，调用了原来的KeInsertQueueApc。
MyKeInsertQueueApc的反汇编代码如下：
.text:0001155A MyKeInsertQueueApc proc near ; CODE XREF:
.text:0001155A nop
.text:0001155B nop
.text:0001155C nop
.text:0001155D nop
.text:0001155E nop
.text:0001155F nop
.text:00011560 nop
.text:00011561 nop
.text:00011562 nop
.text:00011563 nop
.text:00011564 nop
.text:00011565 nop
.text:00011566 nop
.text:00011567 nop
.text:00011568 nop
.text:00011569 nop
.text:0001156A push 0
.text:0001156F retn
.text:0001156F MyKeInsertQueueApc endp
在静态反汇编中会发现很多NOP空指令，其中的代码使运行时动态填充进去的，以下是通过ICESWORD获取的该处的代码：
f7b3055a MOV EDI,EDI ；前三行示把跳转指令覆盖的指令补充完整，使其得以执行
f7b3055c PUSH EBP
f7b3055d MOV EBP,ESP
f7b3055f NOP
f7b30560 NOP
f7b30561 NOP
f7b30562 NOP
f7b30563 NOP
f7b30564 NOP
f7b30565 NOP
f7b30566 NOP
f7b30567 NOP
f7b30568 NOP
f7b30569 NOP
f7b3056a PUSH 804E69A6 ；804E69A6为KeInsertQueueApc+5的地址
f7b3056f RETN
通过观察会发现在MyKeInsertQueueApc函数中跳转回原KeInsertQueueApc函数并没有使用JMP指令，而是使用PUSH/RET方式，到达返回的目的。
Hook函数PsLookupThreadByThreadId的代码较为简单，代码如下：

f7b30577 MOV EAX,[EBP+8] ；[EBP+8]中是要获取ETHREAD指针的线程的HANDLE
f7b3057a CMP EAX,[F7B3D044] ；[F7B3D044]为要保护线程的HANDLE
f7b30580 JNZ SHORT F7B3058C

这段代码只是简单的判断要求获取ETHREAD指针的线程是否是保护的线程HANDLE，如果是的话，直接返回STATUS_ACCESS_DENIED，使其获取失败。

通过上面的分析，我们发现snipesword的进程保护作的还是很出色的，它根本对进程结束的最底层作了保护，不过还真不知道会不会出现更BT的呢？自己操作APC队列。。。。？“完全的进程保护是不可能也没有这个必要的〞。

这两个函数的c代码在附文的 两个函数的C代码.txt中。