С учетом вышесказанного, код заменяющий обработчик системных вызовов будет выглядеть так:

void SetXpSyscallHook()
{
__asm
{
pushad
mov ecx, 0x176
rdmsr
mov OldSyscall, eax
mov eax, NewSyscall
xor edx, edx
wrmsr
popad
}
}
А восстанавливающий старый обработчик так:

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 текущего процесса, и если это новый процесс, добавить этот процесс в списки.

Соответственно, новый обработчик системного вызова будет выглядеть так:

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 Callback функции, которая будет вызвана при создании или завершении процесса. При завершении процесса его нужно удалять из списка. Callback функция имеет следующий прототип:

VOID
(*PCREATE_PROCESS_NOTIFY_ROUTINE) (
IN HANDLE ParentId,
IN HANDLE ProcessId,
IN BOOLEAN Create
);
Установка обработчика производится так:

PsSetCreateProcessNotifyRoutine(NotifyRoutine, FALSE);
А удаление так:

PsSetCreateProcessNotifyRoutine(NotifyRoutine, TRUE);
Здесь существует один неочевидный момент, Callback функция всегда вызывается в контексте завершаемого процесса, следовательно нельзя удалять процесс из списков прямо в ней. Для этого мы воспользуемся рабочими потоками системы, сначала выделим память под рабочий поток с помощью IoAllocateWorkItem, а затем поместим свое задание в очередь рабочего потока с помощью IoQueueWorkItem. В самом обработчике будем не только удалять из списка завершившиеся процессы, но и добавлять создающиеся. А вот и код самого обработчика:

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, так как достаточно пропатчить KiFastSystemCall в ntdll.dll и создать соответствующий шлюз для системного вызова. В Windows 2000 это сделать несколько сложнее, так как там вызовы int 2E разбросаны по ntdll, но найти и пропатчить все эти места также не очень сложно, поэтому полностью полагаться на результаты этой проверки тоже нельзя.

Получение списка процессов просмотром списка таблиц хэндлов.
Если вы когда-нибудь скрывали процесс методом его удаления из списка PsActiveProcesses, то наверняка обратили внимание на то, что при перечислении хэндлов с помощью ZwQuerySystemInformation хэндлы скрытого процесса участвуют в перечислении, в том числе определяется его ProcessId. Происходит это потому, что для удобства перечисления хэндлов, все таблицы хэндлов обьединены в двусвязный список HandleTableList. Смещение этого списка в структуре HANDLE_TABLE для Windows 2000 равно 0x054, а для Windows XP - 0x01C, начинается этот список с HandleTableListHead. Структура HANDLE_TABLE содержит в себе указатель на владеющий ей процесс (QuotaProcess), смещение этого указателя в Windows 2000 равно 0x00C, а в Windows XP - 0x004. Пройдя по списку таблиц хэндлов мы можем построить по ним список процессов. Для начала нам нужно найти HandleTableListHead. Дизассемблирование ядра показало, что ссылки на него находятся глубоко во вложенных функциях, поэтому метод поиска путем дизассемблирования кода, который мы применяли ранее, здесь совсем не подходит. Но для поиска HandleTableListHead можно использовать то свойство, что HandleTableListHead - это глобальная переменная ядра, и следовательно она находится в одной из секций его PE файла, а остальные элементы HandleTableList находятся в динамически выделяемой памяти, а следовательно всегда будут за его пределами. Из этого следует, что нам нужно получить указатель на HandleTable любого процесса, и двигаться по связаному списку до тех пор, пока его элемент не окажется внутри PE файла ядра. Этот элемент и будет HandleTableListHead. Для определения базы и размера файла ядра в памяти используем функцию ZwQuerySystemInformation с классом SystemModuleInformation. Она возвратит нам массив описателей загруженных модулей, в котором первым элементом всегда будет ядро. С учетом всего вышесказаного, код поиска HandleTableListHead будет выглядеть так:

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 Flink;
CurrTable != HandleTableListHead;
CurrTable = CurrTable->Flink)
{
QuotaProcess = *(PEPROCESS *)((PUCHAR)CurrTable - HandleTableListOffset + QuotaProcessOffset);
if (QuotaProcess) CollectProcess(QuotaProcess);
}
}
Этот метод обнаружения скрытых процессов применяется в программах F-Secure Black Light и в последней версии KProcCheck. Как его обойти, я думаю вы сами догадаетесь.

Получение списка процессов путем сканирования PspCidTable.
Еще одна особенность скрытия процесса с помощью удаления его из PsActiveProcesses состоит в том, что это никак не мешает открытию процесса с помощью OpenProcess. На этой особенности построен метод обнаружения процессов путем перебора их pid с попыткой открыть такой процесс. Этот метод я приводить не стал, так как по моему мнению, он лишен каких либо достоинств, в общем, можно сказать - черезжопный метод. Но сам факт его существования говорит о том, что в системе существует еще какой-то список процессов помимо PsActiveProcesses, по которому и происходит открытие процесса. При переборе ProcessId обнаруживается еще одна особенность - один процесс может быть открыт по нескольким разным pid, а это наводит на мысль о том, что второй список процессов представляет из себя ни что иное, как HANDLE_TABLE. Для того, чтобы удостовериться в этом, заглянем в функцию ZwOpenProces:

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:

Как вы видите, этот код безопасным образом копирует переданные указатели, проверяя присутствие их в границах пользовательских адресов, проверяет права доступа и наличие привилегии "SeDebugPrivilege", после чего извлекает ProcessId из структуры CLIENT_ID и передает его функции PsLookupProcessByProcessId, задача которой - получить по ProcessId указатель на EPROCESS. Дальнейшее продолжение функции приводить не имеет смысла, поэтому заглянем теперь в PsLookupProcessByProcessId:

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. Сама таблица называется PspCidTable и хранит в себе списки процессов и потоков, и используется еще в функциях PsLookupProcessThreadByCid и PsLookupThreadByThreadId. Как мы видим, хэндл и указатель на таблицу хэндлов передаются функции ExMapHandleToPointer, которая (при валидности хэндла) возвращает указатель на элемент таблицы описывающий данный хэндл - HANDLE_TABLE_ENTRY. Скормив файл ntoskrnl.pdb программе PDBdump и порывшись в полученном логе, можно откопать следующее:

struct _HANDLE_TABLE_ENTRY {
// static data ------------------------------------
// non-static data --------------------------------
/**/ /*|0x4|*/ void* Object;
/**/ /*|0x4|*/ unsigned long ObAttributes;
/**/ /*|0x4|*/ struct _HANDLE_TABLE_ENTRY_INFO* InfoTable;
/**/ /*|0x4|*/ unsigned long Value;
/**/ /*|0x4|*/ unsigned long GrantedAccess;
/**/ /*|0x2|*/ unsigned short GrantedAccessIndex;
/**/ /*|0x2|*/ unsigned short CreatorBackTraceIndex;
/**/ /*|0x4|*/ long NextFreeTableEntry;
};//
Из этого можно составить такую структуру HANDLE_TABLE_ENTRY:

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, которое указывает допустимые права доступа к объекту по этому хэндлу. Нпример, можно открыть файл на чтение, поправить поле GrantedAccess и писать в этот файл. Подобный метод можно использовать для чтения/записи файлов, которых не удается открыть с требуемыми правами доступа (например занятых другим процессом). Но вернемся к нашей задаче - получить список процессов путем просмотра PspCidTable. Для этого нам нужно разобраться с форматом таблицы хендлов, для того чтобы суметь их перечислить. С этого момента начинается серьезная разница между Windows 2000 и Windows XP. Форматы их таблиц хэндлов сильно отличаются, и нам придется разобраться с их форматом для каждой ОС отдельно.

Для начала рассмотрим формат таблицы хэндлов в Windows 2000, так как там она гораздо проще для понимания. Для начала заглянем в код функции ExMapHandleToPointer:

PAGE:00493285 ExMapHandleToPointer proc near
PAGE:00493285
PAGE:00493285
PAGE:00493285 HandleTable = dword ptr 8
PAGE:00493285 Handle = dword ptr 0Ch
PAGE:00493285
PAGE:00493285 push esi
PAGE:00493286 push [esp+Handle]
PAGE:0049328A push [esp+4+HandleTable]
PAGE:0049328E call ExpLookupHandleTableEntry
PAGE:00493293 mov esi, eax
PAGE:00493295 test esi, esi
PAGE:00493297 jz short loc_4932A9
PAGE:00493299 push esi
PAGE:0049329A push [esp+4+HandleTable]
PAGE:0049329E call ExLockHandleTableEntry
PAGE:004932A3 neg al
PAGE:004932A5 sbb eax, eax
PAGE:004932A7 and eax, esi
PAGE:004932A9 loc_4932A9:
PAGE:004932A9 pop esi
PAGE:004932AA retn 8
PAGE:004932AA ExMapHandleToPointer endp

Здесь происходит вызов функции ExMapHandleToPointer которая производит сам поиск по HANDLE_TABLE, и вызов ExLockHandleTableEntry которая устанавливает Lock Bit. Для понимания работы таблицы хэндлов нам придется разобрать обе эти функции. Начнем с ExpLookupHandleTableEntry:

PAGE:00493545 ExpLookupHandleTableEntry proc near
PAGE:00493545
PAGE:00493545
PAGE:00493545 HandleTable = dword ptr 0Ch
PAGE:00493545 Handle = dword ptr 10h
PAGE:00493545
PAGE:00493545 push esi
PAGE:00493546 push edi
PAGE:00493547 mov edi, [esp+Handle]
PAGE:0049354B mov eax, 0FFh
PAGE:00493550 mov ecx, edi
PAGE:00493552 mov edx, edi
PAGE:00493554 mov esi, edi
PAGE:00493556 shr ecx, 12h
PAGE:00493559 shr edx, 0Ah
PAGE:0049355C shr esi, 2
PAGE:0049355F and ecx, eax
PAGE:00493561 and edx, eax
PAGE:00493563 and esi, eax
PAGE:00493565 test edi, 0FC000000h
PAGE:0049356B jnz short loc_49358A
PAGE:0049356D mov eax, [esp+HandleTable]
PAGE:00493571 mov eax, [eax+8]
PAGE:00493574 mov ecx, [eax+ecx*4]
PAGE:00493577 test ecx, ecx
PAGE:00493579 jz short loc_49358A
PAGE:0049357B mov ecx, [ecx+edx*4]
PAGE:0049357E test ecx, ecx
PAGE:00493580 jz short loc_49358A
PAGE:00493582 lea eax, [ecx+esi*8]
PAGE:00493585 loc_493585:
PAGE:00493585 pop edi
PAGE:00493586 pop esi
PAGE:00493587 retn 8
PAGE:0049358A loc_49358A:
PAGE:0049358A xor eax, eax
PAGE:0049358C jmp short loc_493585
PAGE:0049358C ExpLookupHandleTableEntry endp

В дополнение к этому приведу структуру HANDLE_TABLE полученную из дампа ntoskrnl.pdb:

struct _HANDLE_TABLE {
// static data ------------------------------------
// non-static data --------------------------------
/**/ /*|0x4|*/ unsigned long Flags;
/**/ /*|0x4|*/ long HandleCount;
/**/ /*|0x4|*/ struct _HANDLE_TABLE_ENTRY*** Table;
/**/ /*|0x4|*/ struct _EPROCESS* QuotaProcess;
/**/ /*|0x4|*/ void* UniqueProcessId;
/**/ /*|0x4|*/ long FirstFreeTableEntry;
/**/ /*|0x4|*/ long NextIndexNeedingPool;
/**/ /*|0x38|*/ struct _ERESOURCE HandleTableLock;
/**/ /*|0x8|*/ struct _LIST_ENTRY HandleTableList;
/**/ /*|0x10|*/ struct _KEVENT HandleContentionEvent;
}; //
По этим данным восстановим структуру таблицы хэндлов:

typedef struct _WIN2K_HANDLE_TABLE
{
ULONG Flags;
LONG HandleCount;
PHANDLE_TABLE_ENTRY **Table;
PEPROCESS QuotaProcess;
HANDLE UniqueProcessId;
LONG FirstFreeTableEntry;
LONG NextIndexNeedingPool;
ERESOURCE HandleTableLock;
LIST_ENTRY HandleTableList;
KEVENT HandleContentionEvent;
} WIN2K_HANDLE_TABLE , *PWIN2K_HANDLE_TABLE ;
Из всего этого очевидно, что значение хэндла раскладывается на три части, которые являются индексами в трехуровневой таблице объектов. Теперь посмотрим в функцию ExLockHandleTableEntry:

PAGE:00492E2B ExLockHandleTableEntry proc near
PAGE:00492E2B
PAGE:00492E2B
PAGE:00492E2B var_8 = dword ptr -8
PAGE:00492E2B var_4 = dword ptr -4
PAGE:00492E2B HandleTable = dword ptr 8
PAGE:00492E2B Entry = dword ptr 0Ch
PAGE:00492E2B
PAGE:00492E2B push ebp
PAGE:00492E2C mov ebp, esp
PAGE:00492E2E push ecx
PAGE:00492E2F push ecx
PAGE:00492E30 push ebx
PAGE:00492E31 push esi
PAGE:00492E32 xor ebx, ebx
PAGE:00492E34 loc_492E34:
PAGE:00492E34 mov eax, [ebp+Entry]
PAGE:00492E37 mov esi, [eax]
PAGE:00492E39 test esi, esi
PAGE:00492E3B mov [ebp+var_8], esi
PAGE:00492E3E jz short loc_492E89
PAGE:00492E40 jle short loc_492E64
PAGE:00492E42 mov eax, esi
PAGE:00492E44 or eax, 80000000h // set WIN2K_TABLE_ENTRY_LOCK_BIT
PAGE:00492E49 mov [ebp+var_4], eax
PAGE:00492E4C mov eax, [ebp+var_8]
PAGE:00492E4F mov ecx, [ebp+Entry]
PAGE:00492E52 mov edx, [ebp+var_4]
PAGE:00492E55 cmpxchg [ecx], edx
PAGE:00492E58 cmp eax, esi
PAGE:00492E5A jnz short loc_492E64
PAGE:00492E5C mov al, 1
PAGE:00492E5E loc_492E5E:
PAGE:00492E5E pop esi
PAGE:00492E5F pop ebx
PAGE:00492E60 leave
PAGE:00492E61 retn 8
PAGE:00492E64 loc_492E64:
PAGE:00492E64 mov eax, ebx
PAGE:00492E66 inc ebx
PAGE:00492E67 cmp eax, 1
PAGE:00492E6A jb loc_4BC234
PAGE:00492E70 mov eax, [ebp+HandleTable]
PAGE:00492E73 push offset unk_46D240 ; Timeout
PAGE:00492E78 push 0 ; Alertable
PAGE:00492E7A push 0 ; WaitMode
PAGE:00492E7C add eax, 5Ch
PAGE:00492E7F push 0 ; WaitReason
PAGE:00492E81 push eax ; Object
PAGE:00492E82 call KeWaitForSingleObject
PAGE:00492E87 jmp short loc_492E34
PAGE:00492E89 loc_492E89:
PAGE:00492E89 xor al, al
PAGE:00492E8B jmp short loc_492E5E
PAGE:00492E8B ExLockHandleTableEntry endp

Смысл данного кода состоит в том, что он проверяет 31 бит в элементе Object структуры HANDLE_TABLE_ENTRY, устанавливает его, а в случае, если он установлен - ждет HandleContentionEvent в HANDLE_TABLE. Для нас важен лишь факт установки TABLE_ENTRY_LOCK_BIT, так как он являтся частью адреса объекта, и при сброшенном бите мы получим невалидный адрес. С форматом таблицы хэндлов мы вроде разобрались, теперь можно написать код перебора объектов в таблице:

void ScanWin2KHandleTable(PWIN2K_HANDLE_TABLE HandleTable)
{
int i, j, k;
PHANDLE_TABLE_ENTRY Entry;

for (i = 0; i Table[i])
{
for (j = 0; j Table[i][j])
{
for (k = 0; k Table[i][j][k];

if (Entry->Object)
ProcessObject((PVOID)((ULONG)Entry->Object | WIN2K_TABLE_ENTRY_LOCK_BIT));
}
CopKiller