检测隐藏进程(3)

{
__asm
{
pushad
mov ecx, 0x176
rdmsr
mov OldSyscall, eax
mov eax, NewSyscall
xor edx, edx
wrmsr
popad
}
}

恢复原始的系统调用管理器代码：

Code:

void XpSyscallUnhook()
{
__asm
{
pushad
mov ecx, 0x176
mov eax, OldSyscall
xor edx, edx
wrmsr
xor eax, eax
mov OldSyscall, eax
popad
}
}

Windows XP的另外一个特性是它既可以使用sysenter也可以使用int 2Eh来进行系统调用，所以我们要替换这两种情况下的系统调用管理器。

我们的新的系统调用管理器应该得到当前进程的EPROCESS指针，并且如果是一个新的进程，我们要把这个新的进程加到我们的进程列表中。
新的系统调用管理器代码如下：

Code:

void __declspec(naked) NewSyscall()
{
__asm
{
pushad
pushfd
push fs
mov di, 0x30
mov fs, di
mov eax, fs:[0x124]
mov eax, [eax + 0x44]
push eax
call CollectProcess
pop fs
popfd
popad
jmp OldSyscall
}
}

得到进程列表的这段代码应该在某个时间段内工作，所以我们有这样的问题：如果在列表中的进程被删除掉，在随后的时间内我们将保留一些

无效指针，结果就是检测隐藏进程失败或者导致系统BSOD。解决这个问题的办法是，用PsSetCreateProcessNotifyRoutine函数注册我们的回调

函数，这个回调函数将会在系统创建或者销毁一个进程的时候被调用。当进程被销毁时，我们也应该把它从我们的表中删除掉。
回调函数的原型如下：

Code:

VOID
(*PCREATE_PROCESS_NOTIFY_ROUTINE) (
IN HANDLE ParentId,
IN HANDLE ProcessId,
IN BOOLEAN Create
);

安装回调函数的代码如下：

Code:

PsSetCreateProcessNotifyRoutine (NotifyRoutine, FALSE);

取消回调函数的代码：

Code:

PsSetCreateProcessNotifyRoutine (NotifyRoutine, TRUE);

这里有一个问题，回调函数总是在系统被销毁的时候创建，因此我们不可能直接在这个回调函数中删除进程列表中的相应进程。这样我们就要

用系统的work items，首先调用IoAllocateWorkItem函数为work item分配内存，然后调用IoQueueWorkItem函数（俄文翻译者kao注：这一句我

不太确定...）将任务放置到工作线程队列中。在处理过程中我们不仅仅从进程列表中删除掉已经终止的进程，而且还要加入新创建的线程。处

理代码如下：

Code:

void WorkItemProc(PDEVICE_OBJECT DeviceObject, PWorkItemStruct Data)
{
KeWaitForSingleObject(Data->pEPROCESS, Executive, KernelMode, FALSE, NULL);

DelItem(&wLastItem, Data->pEPROCESS);

ObDereferenceObject(Data->pEPROCESS);

IoFreeWorkItem(Data->IoWorkItem);

ExFreePool(Data);

return;
}

void NotifyRoutine(IN HANDLE ParentId,
IN HANDLE ProcessId,
IN BOOLEAN Create)
{
PEPROCESS process;
PWorkItemStruct Data;

if (Create)
{
PsLookupProcessByProcessId(ProcessId, &process);

if (!IsAdded(wLastItem, process)) AddItem(&wLastItem, process);

ObDereferenceObject(process);

} else
{
process = PsGetCurrentProcess();

ObReferenceObject(process);

Data = ExAllocatePool(NonPagedPool, sizeof(TWorkItemStruct));

Data->IoWorkItem = IoAllocateWorkItem(deviceObject);

Data->pEPROCESS = process;

IoQueueWorkItem(Data->IoWorkItem, WorkItemProc, DelayedWorkQueue, Data);
}

return;
}

这是一个相对可靠的隐藏进程的检测方式，然而虽然没有进程能够不倚赖系统调用，但还是有一些进程可以在很长一段时间处于等待状态不进

行系统调用，我们无法检测出这样的进程。

只要想做，躲避开这种检测方式还是很容易的。想要做到这一点，那就需要改变隐藏进程的系统调用方式（重定向到另外一个中断或者GDT中的

调用门）。在Windows XP下做这个工作是相当简单的，因为可以给ntdll.dll中的KiFastSystemCall函数打补丁和创建一个相应的系统调用门。

在Windows 2000平台下就稍微有点难度了，因为int 2Eh调用分散遍及整个ntdll，但是找到并patch所有的地方也并不是很复杂。综上所述，依

赖于这种检测方式可不是聪明之举。

通过遍历句柄表得到进程列表。
如果你曾经尝试过利用删除PsActiveProcesses链表中的进程节点来隐藏进程，可能你会注意到当你调用ZwQuerySystemInformation函数枚举句

柄的时候，隐藏进程的句柄也会被枚举出来，并且还能被检测出它的ProcessId。这是因为为了方便枚举句柄，所有的句柄表都是由一个双向链

表HandleTableList维护的。Windows 2000下HANDLE_TABLE结构在链表中的偏移等于0x054，Windows XP下为0x01C，链表由

HandleTableListHead开始。HANDLE_TABLE结构包括它的宿主进程的指针（QuotaProcess），Windows 2000下这个偏移等于0x00C，Windows XP

下这个偏移为0x004。通过遍历这个句柄链表我们就可以构建进程列表了。

首先我们得找到HandleTableListHead。反汇编内核显示它的引用定位在函数的深处，所以前面我们用过的反汇编代码的方法已经不能在这里使

用了。要找到HeadleTableListHead，我们要注意到HandleTableListHead是一个全局的内核变量，因此它一定是在内核文件的某一个段

（Section）里面，并且HandleTableList的其他成员是在动态分配的内存中，所以总是受到内核地址空间的限制。根据这些，我们需要得到任

何一个进程的HandleTable的指针，然后遍历链表直到找到定位在这个内核地址空间的成员，那么这个成员就是HandleTableListHead了。

我们使用ZwQuerySystemInformation和SystemModuleInformation类计算系统内核的基址和大小。它将返回一个所有已经加载了的模块的描述符

表，并且这个表的第一个成员始终是"system"。综上所述，查找HandleTableListHead的代码如下：

Code:

void GetHandleTableListHead()
{
PSYSTEM_MODULE_INFORMATION_EX Info = GetInfoTable(SystemModuleInformation);
ULONG NtoskrnlBase = (ULONG)Info->Modules[0].Base;
ULONG NtoskrnlSize = Info->Modules[0].Size;
PHANDLE_TABLE HandleTable = *(PHANDLE_TABLE *)((ULONG)PsGetCurrentProcess() + HandleTableOffset);
PLIST_ENTRY HandleTableList = (PLIST_ENTRY)((ULONG)HandleTable + HandleTableListOffset);
PLIST_ENTRY CurrTable;

ExFreePool(Info);

for (CurrTable = HandleTableList->Flink;
CurrTable != HandleTableList;
CurrTable = CurrTable->Flink)
{
if ((ULONG)CurrTable > NtoskrnlBase && (ULONG)CurrTable < NtoskrnlBase + NtoskrnlSize)
{
HandleTableListHead = CurrTable;
break;
}
}
}

这段代码是非常通用的，它可以运行于任何Windows NT版本的系统上，并且不仅可以用来查找HandleTableListHead，也可以用于其他类似的结

构。

得到HandleTableListHead地址后我们就可以遍历句柄表并基于这些信息来构建进程列表了。

Code:

void ScanHandleTablesList()
{
PLIST_ENTRY CurrTable;
PEPROCESS QuotaProcess;

for (CurrTable = HandleTableListHead->Flink;
CurrTable != HandleTableListHead;
CurrTable = CurrTable->Flink)
{
QuotaProcess = *(PEPROCESS *)((PUCHAR)CurrTable - HandleTableListOffset + QuotaProcessOffset);
if (QuotaProcess) CollectProcess(QuotaProcess);
}
}

F-Secure Black Light和KProcCheck的最后一个版本用的就是这种检测方法。我想你将会很轻松地找到对付这种检测的方法。

通过扫描PspCidTable得到进程列表。

有一件有趣的事情需要注意：如果仅仅把进程节点从PsActiveProcesses链表中删除，它不能够防止使用API函数OpenProcess打开进程。这样就

有一种检测进程的方法就是尝试穷举Pid然后调用OpenProcess。我不推荐这个方法，因为它没有任何优点，我甚至想说这是一种“狗屁”方案

。不过它的存在意味着在系统中除了通过PsActiveProcesses得到进程列表之外还可以通过调用OpenProcess。当穷举ProcessId的时候我们会注

意到一个进程可以被几个不同的Pid打开，这暗示可能存在着有点像HANDLE_TABLE的另一个进程列表。为了证明这个的猜想，我们来看看

ZwOpenProcess函数：

Code:

PAGE:0049D59E ; NTSTATUS __stdcall NtOpenProcess(PHANDLE ProcessHandle, ACCESS_MASK DesiredAccess,
POBJECT_ATTRIBUTES ObjectAttributes,PCLIENT_ID ClientId)
PAGE:0049D59E public NtOpenProcess
PAGE:0049D59E NtOpenProcess proc near
PAGE:0049D59E
PAGE:0049D59E ProcessHandle = dword ptr 4
PAGE:0049D59E DesiredAccess = dword ptr 8
PAGE:0049D59E ObjectAttributes= dword ptr 0Ch
PAGE:0049D59E ClientId = dword ptr 10h
PAGE:0049D59E
PAGE:0049D59E push 0C4h
PAGE:0049D5A3 push offset dword_413560 ; int
PAGE:0049D5A8 call sub_40BA92
PAGE:0049D5AD xor esi, esi
PAGE:0049D5AF mov [ebp-2Ch], esi
PAGE:0049D5B2 xor eax, eax
PAGE:0049D5B4 lea edi, [ebp-28h]
PAGE:0049D5B7 stosd
PAGE:0049D5B8 mov eax, large fs:124h
PAGE:0049D5BE mov al, [eax+140h]
PAGE:0049D5C4 mov [ebp-34h], al
PAGE:0049D5C7 test al, al
PAGE:0049D5C9 jz loc_4BE034
PAGE:0049D5CF mov [ebp-4], esi
PAGE:0049D5D2 mov eax, MmUserProbeAddress
PAGE:0049D5D7 mov ecx, [ebp+8]
PAGE:0049D5DA cmp ecx, eax
PAGE:0049D5DC jnb loc_520CDE
PAGE:0049D5E2 loc_49D5E2:
PAGE:0049D5E2 mov eax, [ecx]
PAGE:0049D5E4 mov [ecx], eax
PAGE:0049D5E6 mov ebx, [ebp+10h]
PAGE:0049D5E9 test bl, 3
PAGE:0049D5EC jnz loc_520CE5
PAGE:0049D5F2 loc_49D5F2:
PAGE:0049D5F2 mov eax, MmUserProbeAddress
PAGE:0049D5F7 cmp ebx, eax
PAGE:0049D5F9 jnb loc_520CEF
PAGE:0049D5FF loc_49D5FF:
PAGE:0049D5FF cmp [ebx+8], esi
PAGE:0049D602 setnz byte ptr [ebp-1Ah]
PAGE:0049D606 mov ecx, [ebx+0Ch]
PAGE:0049D609 mov [ebp-38h], ecx
PAGE:0049D60C mov ecx, [ebp+14h]
PAGE:0049D60F cmp ecx, esi
PAGE:0049D611 jz loc_4CCB88
PAGE:0049D617 test cl, 3
PAGE:0049D61A jnz loc_520CFB
PAGE:0049D620 loc_49D620:
PAGE:0049D620 cmp ecx, eax
PAGE:0049D622 jnb loc_520D0D
PAGE:0049D628 loc_49D628:
PAGE:0049D628 mov eax, [ecx]
PAGE:0049D62A mov [ebp-2Ch], eax
PAGE:0049D62D mov eax, [ecx+4]
PAGE:0049D630 mov [ebp-28h], eax
PAGE:0049D633 mov byte ptr [ebp-19h], 1
PAGE:0049D637 loc_49D637:
PAGE:0049D637 or dword ptr [ebp-4], 0FFFFFFFFh
PAGE:0049D63B loc_49D63B:
PAGE:0049D63B
PAGE:0049D63B cmp byte ptr [ebp-1Ah], 0
PAGE:0049D63F jnz loc_520D34
PAGE:0049D645 loc_49D645:
PAGE:0049D645 mov eax, PsProcessType
PAGE:0049D64A add eax, 68h
PAGE:0049D64D push eax
PAGE:0049D64E push dword ptr [ebp+0Ch]
PAGE:0049D651 lea eax, [ebp-0D4h]
PAGE:0049D657 push eax
PAGE:0049D658 lea eax, [ebp-0B8h]
PAGE:0049D65E push eax
PAGE:0049D65F call SeCreateAccessState
PAGE:0049D664 cmp eax, esi
PAGE:0049D666 jl loc_49D718
PAGE:0049D66C push dword ptr [ebp-34h] ; PreviousMode
PAGE:0049D66F push ds:stru_5B6978.HighPart
PAGE:0049D675 push ds:stru_5B6978.LowPart ; PrivilegeValue
PAGE:0049D67B call SeSinglePrivilegeCheck
PAGE:0049D680 test al, al
PAGE:0049D682 jnz loc_4AA7DB
PAGE:0049D688 loc_49D688:
PAGE:0049D688 cmp byte ptr [ebp-1Ah], 0
PAGE:0049D68C jnz loc_520D52
PAGE:0049D692 cmp byte ptr [ebp-19h], 0
PAGE:0049D696 jz loc_4CCB9A
PAGE:0049D69C mov [ebp-30h], esi
PAGE:0049D69F cmp [ebp-28h], esi
PAGE:0049D6A2 jnz loc_4C1301
PAGE:0049D6A8 lea eax, [ebp-24h]
PAGE:0049D6AB push eax
PAGE:0049D6AC push dword ptr [ebp-2Ch]
PAGE:0049D6AF call PsLookupProcessByProcessId
PAGE:0049D6B4 loc_49D6B4:

正如你看到的，这段代码拷贝给定的指针，检查是否指向用户地址空间，核对访问权限和是否有“SetDebugPrivilege”的权限，然后从

CLIENT_ID结构中找到ProcessId并传递给PsLookupProcessByProcessId函数，PsLookupProcessByProcessId的功能是得到ProcessId的EPROCESS

。函数的其余部分对我们来说没什么用，现在我们来看看PsLookupProcessByProcessId:

Code:

PAGE:0049D725 public PsLookupProcessByProcessId
PAGE:0049D725 PsLookupProcessByProcessId proc near
PAGE:0049D725
PAGE:0049D725
PAGE:0049D725 ProcessId = dword ptr 8
PAGE:0049D725 Process = dword ptr 0Ch
PAGE:0049D725
PAGE:0049D725 mov edi, edi
PAGE:0049D727 push ebp
PAGE:0049D728 mov ebp, esp
PAGE:0049D72A push ebx
PAGE:0049D72B push esi
PAGE:0049D72C mov eax, large fs:124h
PAGE:0049D732 push [ebp+ProcessId]
PAGE:0049D735 mov esi, eax
PAGE:0049D737 dec dword ptr [esi+0D4h]
PAGE:0049D73D push PspCidTable
PAGE:0049D743 call ExMapHandleToPointer
PAGE:0049D748 mov ebx, eax
PAGE:0049D74A test ebx, ebx
PAGE:0049D74C mov [ebp+ProcessId], STATUS_INVALID_PARAMETER
PAGE:0049D753 jz short loc_49D787
PAGE:0049D755 push edi
PAGE:0049D756 mov edi, [ebx]
PAGE:0049D758 cmp byte ptr [edi], 3
PAGE:0049D75B jnz short loc_49D77A
PAGE:0049D75D cmp dword ptr [edi+1A4h], 0
PAGE:0049D764 jz short loc_49D77A
PAGE:0049D766 mov ecx, edi
PAGE:0049D768 call sub_4134A9
PAGE:0049D76D test al, al
PAGE:0049D76F jz short loc_49D77A
PAGE:0049D771 mov eax, [ebp+Process]
PAGE:0049D774 and [ebp+ProcessId], 0
PAGE:0049D778 mov [eax], edi
PAGE:0049D77A loc_49D77A:
PAGE:0049D77A push ebx
PAGE:0049D77B push PspCidTable
PAGE:0049D781 call ExUnlockHandleTableEntry
PAGE:0049D786 pop edi
PAGE:0049D787 loc_49D787:
PAGE:0049D787 inc dword ptr [esi+0D4h]
PAGE:0049D78D jnz short loc_49D79A
PAGE:0049D78F lea eax, [esi+34h]
PAGE:0049D792 cmp [eax], eax
PAGE:0049D794 jnz loc_52388A
PAGE:0049D79A loc_49D79A:
PAGE:0049D79A mov eax, [ebp+ProcessId]
PAGE:0049D79D pop esi
PAGE:0049D79E pop ebx
PAGE:0049D79F pop ebp
PAGE:0049D7A0 retn 8

以上我们所看到的，证实了存在像HANDLE_TABLE一样组织结构的第2个进程列表。这个表叫做PspCidTable，它包括进程和线程的列表，

PsLookupProcessThreadByCid函数和PsLookupThreadByThreadId函数都用到了这个表。我们看到，句柄和句柄表的指针被传递给了

ExMapHandleToPointer函数，该函数（在句柄有效的情况下）返回一个指向描述给定句柄的表的一个元素 - HANDLE_TABLE_ENTRY。当我们用

PDBdump分析完ntoskrnl.pdb并且得到分析日志后，会得到如下结果：

Code:

struct _HANDLE_TABLE_ENTRY {
// static data ------------------------------------
// non-static data --------------------------------
/*<thisrel this+0x0>*/ /*|0x4|*/ void* Object;
/*<thisrel this+0x0>*/ /*|0x4|*/ unsigned long ObAttributes;
/*<thisrel this+0x0>*/ /*|0x4|*/ struct _HANDLE_TABLE_ENTRY_INFO* InfoTable;
/*<thisrel this+0x0>*/ /*|0x4|*/ unsigned long Value;
/*<thisrel this+0x4>*/ /*|0x4|*/ unsigned long GrantedAccess;
/*<thisrel this+0x4>*/ /*|0x2|*/ unsigned short GrantedAccessIndex;
/*<thisrel this+0x6>*/ /*|0x2|*/ unsigned short CreatorBackTraceIndex;
/*<thisrel this+0x4>*/ /*|0x4|*/ long NextFreeTableEntry;
};// <size 0x8>

We can recover HANDLE_TABLE_ENTRY structure from this:
我们还原一下HANDLE_TABLE_ENTRY结构的C代码：

Code:

typedef struct _HANDLE_TABLE_ENTRY
{
union
{
PVOID Object;
ULONG ObAttributes;
PHANDLE_TABLE_ENTRY_INFO InfoTable;
ULONG Value;
};

union
{
union
{
ACCESS_MASK GrantedAccess;
struct
{
USHORT GrantedAccessIndex;
USHORT CreatorBackTraceIndex;
};
};

LONG NextFreeTableEntry;
};
} HANDLE_TABLE_ENTRY, *PHANDLE_TABLE_ENTRY;

怎么使用它呢？首先，我们比较感兴趣的是Object域的内容，它是被句柄描述的目标指针和这个表的给定元素的用法标志（我将稍后解释这句

话）。GrantedAccess域指定了通过这个句柄对目标的访问权限许可，这个很有趣。比如，以只读方式打开一个文件，修改这个域之后就可以写