Многие пользователи привыкли к тому, что в Windows NT диспетчер задач показывает все процессы, и многие считают, что скрыться от него вообще невозможно. На самом деле, скрыть процесс черезвычайно просто. Для этого существует множество методов, и их реализации доступны в исходниках. Остается только удивляться, почему так редки трояны использующие эти методики? Их буквально 1 на 1000 не умеющих скрываться. Я думаю, это объясняется тем, что авторам троянов лень, ведь для этого необязательно писать что-то свое, всегда можно взять готовый исходник и вставить в свою программу. Поэтому следует ожидать, что скоро скрытие процессов будет применяться во всех широкораспостраненных рядовых троянах.

Естественно, от этого нужно иметь защиту. Производители антивирусов и фаерволлов отстали от жизни, так как их продукты не умеют обнаруживать скрытые процессы. Для этого существует только несколько утилит, из которых единственной бесплатной является Klister(работает только на Windows 2000), а за остальные производители требуют немалых денег. Причем все эти утилиты довольно легко обходятся.

Все имеющиеся сейчас программы для обнаружения скрытых процессов построены на каком-то одном принципе, поэтому для их обхода можно придумать метод скрытия от конкретного принципа обнаружения, либо привязываться к одной конкретной программе, что гораздо проще в реализации. Пользователь купивший коммерческую программу не может изменить ее, а поэтому привязка к конкретной программе будет работать достаточно надежно, поэтому этот метод используется в коммерческих руткитах (например hxdef Golden edition). Единственным выходом будет создание бесплатной Opensource программы для обнаружения скрытых процессов в которой будут применены несколько методов обнаружения, что позволит защититься от фундаментальных принципов скрытия, а от привязки к конкретным программам может защититься каждый пользователь, для этого нужно всего лишь взять исходники программы и переделать ее под себя.

В этой статье я хочу рассмотреть основные методы обнаружения скрытых процессов, привести примеры кода использующего эти методы и создать в конце законченную программу для обнаружения скрытых процессов, которая удовлетворяла бы всем вышеприведенным требованиям.

Обнаружение в User Mode
Для начала рассмотрим простые методы обнаружения, которые могут быть применены в 3 кольце, без использования драйверов. Они основаны на том, что каждый запущенный процесс порождает побочные проявления своей деятельности, по которым его и можно обнаружить. Этими проявлениями могут быть открытые им хэндлы, окна, созданные системные объекты. От подобных методик обнаружения несложно скрыться, но для этого нужно учесть ВСЕ побочные проявления работы процесса. Ни в одном из публичных руткитов это пока еще не сделано (приватные версии к сожалению ко мне не попали). Юзермодные методы просты в реализации, безопасны в применении, и могут дать положительный эффект, поэтому их использованием не стоит пренебрегать.

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

type
PProcList = ^TProcList;
TProcList = packed record
NextItem: pointer;
ProcName: array [0..MAX_PATH] of Char;
ProcId: dword;
ParrentId: dword;
end;

Получение списка процессов через ToolHelp API
Для начала определим образцовую функцию получающую список процессов, с ее результатами мы будем сравнивать результаты полученные всеми другими способами:

{
Получение списка процессов через ToolHelp API.
}
procedure GetToolHelpProcessList(var List: PListStruct);
var
Snap: dword;
Process: TPROCESSENTRY32;
NewItem: PProcessRecord;
begin
Snap := CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
if Snap INVALID_HANDLE_VALUE then
begin
Process.dwSize := SizeOf(TPROCESSENTRY32);
if Process32First(Snap, Process) then
repeat
GetMem(NewItem, SizeOf(TProcessRecord));
ZeroMemory(NewItem, SizeOf(TProcessRecord));
NewItem^.ProcessId := Process.th32ProcessID;
NewItem^.ParrentPID := Process.th32ParentProcessID;
lstrcpy(@NewItem^.ProcessName, Process.szExeFile);
AddItem(List, NewItem);
until not Process32Next(Snap, Process);
CloseHandle(Snap);
end;
end;
Очевидно, что любой скрытый процесс при таком перечислении найден не будет, поэтому эта функция будет образцовой для отделения скрытых процессов от нескрытых.

Получение списка процессов через Native API
Следующим уровнем проверки будет получение списка процессов через ZwQuerySystemInformation (Native API). На этом уровне также врядли что-нибудь обнаружиться, но проверить все-таки стоит.

{
Получение списка процессов через ZwQuerySystemInformation.
}
procedure GetNativeProcessList(var List: PListStruct);
var
Info: PSYSTEM_PROCESSES;
NewItem: PProcessRecord;
Mem: pointer;
begin
Info := GetInfoTable(SystemProcessesAndThreadsInformation);
Mem := Info;
if Info = nil then Exit;
repeat
GetMem(NewItem, SizeOf(TProcessRecord));
ZeroMemory(NewItem, SizeOf(TProcessRecord));
lstrcpy(@NewItem^.ProcessName,
PChar(WideCharToString(Info^.ProcessName.Buffer)));
NewItem^.ProcessId := Info^.ProcessId;
NewItem^.ParrentPID := Info^.InheritedFromProcessId;
AddItem(List, NewItem);
Info := pointer(dword(info) + info^.NextEntryDelta);
until Info^.NextEntryDelta = 0;
VirtualFree(Mem, 0, MEM_RELEASE);
end;

Получение списка процессов по списку открытых хэндлов.
Многие программы скрывающие процесс, не скрывают открытые им хэндлы, следовательно перечислив открытые хэндлы через ZwQuerySystemInformation мы можем построить список процессов.

{
Получение списка процессов по списку открытых хэндлов.
Возвращает только ProcessId.
}
procedure GetHandlesProcessList(var List: PListStruct);
var
Info: PSYSTEM_HANDLE_INFORMATION_EX;
NewItem: PProcessRecord;
r: dword;
OldPid: dword;
begin
OldPid := 0;
Info := GetInfoTable(SystemHandleInformation);
if Info = nil then Exit;
for r := 0 to Info^.NumberOfHandles do
if Info^.Information[r].ProcessId OldPid then
begin
OldPid := Info^.Information[r].ProcessId;
GetMem(NewItem, SizeOf(TProcessRecord));
ZeroMemory(NewItem, SizeOf(TProcessRecord));
NewItem^.ProcessId := OldPid;
AddItem(List, NewItem);
end;
VirtualFree(Info, 0, MEM_RELEASE);
end;
На этом этапе уже можно кое-что обнаружить. Но полагаться на результат такой проверки не стоит, так как скрыть открытые процессом хэндлы ничуть не сложнее, чем скрыть сам процесс, просто многие забывают это делать.

Получение списка процессов по списку открытых ими окон.
Получив список окон зарегистрированных в системе и вызвав для каждого GetWindowThreadProcessId можно построить список процессов имеющих окна.

{
Получение списка процессов по списку окон.
Возвращает только ProcessId.
}
procedure GetWindowsProcessList(var List: PListStruct);

function EnumWindowsProc(hwnd: dword; PList: PPListStruct): bool; stdcall;
var
ProcId: dword;
NewItem: PProcessRecord;
begin
GetWindowThreadProcessId(hwnd, ProcId);
if not IsPidAdded(PList^, ProcId) then
begin
GetMem(NewItem, SizeOf(TProcessRecord));
ZeroMemory(NewItem, SizeOf(TProcessRecord));
NewItem^.ProcessId := ProcId;
AddItem(PList^, NewItem);
end;
Result := true;
end;

begin
EnumWindows(@EnumWindowsProc, dword(@List));
end;

Окна не скрывает почти никто, поэтому эта проверка также позволяет что-то найти, но полагаться на нее тоже не стоит.

Получение списка процессов с помощью прямого системного вызова.
Для скрытия процессов в User Mode обычно используется технология внедрения своего кода в чужие процессы и перехвата функции ZwQuerySystemInformation из ntdll.dll. Функции ntdll на самом деле являются переходниками к соответствующим функциям ядра системы, и представляют из себя обращение к интерфейсу системных вызовов (Int 2Eh в Windows 2000 или sysenter в XP), поэтому самым простым и эффективным способом обнаружения процессов скрытых Usermode API перехватчиками будет прямое обращение к интерфейсу системных вызовов минуя API.

Вариант функции заменяющей ZwQuerySystemInformation будет выглядеть для Windows XP так:

{
Системный вызов ZwQuerySystemInformation для Windows XP.
}
Function XpZwQuerySystemInfoCall(ASystemInformationClass: dword;
ASystemInformation: Pointer;
ASystemInformationLength: dword;
AReturnLength: pdword): dword; stdcall;
asm
pop ebp
mov eax, $AD
call @SystemCall
ret $10
@SystemCall:
mov edx, esp
sysenter
end;
В связи с другим интерфейсом системных вызовов, для Windows 2000 этот код будет выглядеть иначе.

{
Системный вызов ZwQuerySystemInformation для Windows 2000.
}
Function Win2kZwQuerySystemInfoCall(ASystemInformationClass: dword;
ASystemInformation: Pointer;
ASystemInformationLength: dword;
AReturnLength: pdword): dword; stdcall;
asm
pop ebp
mov eax, $97
lea edx, [esp + $04]
int $2E
ret $10
end;
Теперь остается перечислить процессы не с помощью функций из ntdll.dll, а с помощью только что определенных функций. Вот код, который это делает:

{
Получение списка процессов через системный вызов
ZwQuerySystemInformation.
}
procedure GetSyscallProcessList(var List: PListStruct);
var
Info: PSYSTEM_PROCESSES;
NewItem: PProcessRecord;
mPtr: pointer;
mSize: dword;
St: NTStatus;
begin
mSize := $4000;
repeat
GetMem(mPtr, mSize);
St := ZwQuerySystemInfoCall(SystemProcessesAndThreadsInformation,
mPtr, mSize, nil);
if St = STATUS_INFO_LENGTH_MISMATCH then
begin
FreeMem(mPtr);
mSize := mSize * 2;
end;
until St STATUS_INFO_LENGTH_MISMATCH;
if St = STATUS_SUCCESS then
begin
Info := mPtr;
repeat
GetMem(NewItem, SizeOf(TProcessRecord));
ZeroMemory(NewItem, SizeOf(TProcessRecord));
lstrcpy(@NewItem^.ProcessName,
PChar(WideCharToString(Info^.ProcessName.Buffer)));
NewItem^.ProcessId := Info^.ProcessId;
NewItem^.ParrentPID := Info^.InheritedFromProcessId;
Info := pointer(dword(info) + info^.NextEntryDelta);
AddItem(List, NewItem);
until Info^.NextEntryDelta = 0;
end;
FreeMem(mPtr);
end;
Этот метод практически 100% обнаруживает юзермодные руткиты, например все версии hxdef (в том числе и Golden) им обнаруживаются.

Получение списка процессов путем анализа связанных с ним хэндлов.
Также, можно применить еще один метод основанный на перечислении хэндлов. Его суть состоит в том, чтобы найти не хэндлы открытые искомым процессом, а хэндлы других процессов связанные с ним. Это могут быть хэндлы самого процесса либо его потоков. При получении хэндла процесса, можно определить его PID с ZwQueryInformationProcess. Для потока можно вызвать ZwQueryInformationThread и получить Id его процесса. Все процессы существующие в системе были кем-то запущены, следовательно родительские процессы будут иметь их хэндлы (если только не успели их закрыть), также хэндлы всех работающих процессов имеются в сервере подсистемы Win32 (csrss.exe). Также в Windows NT активно используются Job объекты, которые позволяют обьединять процессы (например все процессы определенного прользователя, или какие-либо службы), следовательно при нахождении хэндла Job объекта, не стоит принебрегать возможностью получить Id всех обьединенных им процессов. Делается это с помощью функции QueryInformationJobObject с классом информации - JobObjectBasicProcessIdList. Код производящий поиск процесов путем анализа открытых другими процессами хэндлов будет выглядеть так:

{
Получение списка процессов через проверку хэнжлов в других процессах.
}
procedure GetProcessesFromHandles(var List: PListStruct; Processes, Jobs, Threads: boolean);
var
HandlesInfo: PSYSTEM_HANDLE_INFORMATION_EX;
ProcessInfo: PROCESS_BASIC_INFORMATION;
hProcess : dword;
tHandle: dword;
r, l : integer;
NewItem: PProcessRecord;
Info: PJOBOBJECT_BASIC_PROCESS_ID_LIST;
Size: dword;
THRInfo: THREAD_BASIC_INFORMATION;
begin
HandlesInfo := GetInfoTable(SystemHandleInformation);
if HandlesInfo nil then
for r := 0 to HandlesInfo^.NumberOfHandles do
if HandlesInfo^.Information[r].ObjectTypeNumber in [OB_TYPE_PROCESS, OB_TYPE_JOB, OB_TYPE_THREAD] then
begin
hProcess := OpenProcess(PROCESS_DUP_HANDLE, false,
HandlesInfo^.Information[r].ProcessId);

if DuplicateHandle(hProcess, HandlesInfo^.Information[r].Handle,
INVALID_HANDLE_VALUE, @tHandle, 0, false,
DUPLICATE_SAME_ACCESS) then
begin
case HandlesInfo^.Information[r].ObjectTypeNumber of
OB_TYPE_PROCESS : begin
if Processes and (HandlesInfo^.Information[r].ProcessId = CsrPid) then
if ZwQueryInformationProcess(tHandle, ProcessBasicInformation,
@ProcessInfo,
SizeOf(PROCESS_BASIC_INFORMATION),
nil) = STATUS_SUCCESS then
if not IsPidAdded(List, ProcessInfo.UniqueProcessId) then
begin
GetMem(NewItem, SizeOf(TProcessRecord));
ZeroMemory(NewItem, SizeOf(TProcessRecord));
NewItem^.ProcessId := ProcessInfo.UniqueProcessId;
NewItem^.ParrentPID := ProcessInfo.InheritedFromUniqueProcessId;
AddItem(List, NewItem);
end;
end;

OB_TYPE_JOB : begin
if Jobs then
begin
Size := SizeOf(JOBOBJECT_BASIC_PROCESS_ID_LIST) + 4 * 1000;
GetMem(Info, Size);
Info^.NumberOfAssignedProcesses := 1000;
if QueryInformationJobObject(tHandle, JobObjectBasicProcessIdList,
Info, Size, nil) then
for l := 0 to Info^.NumberOfProcessIdsInList - 1 do
if not IsPidAdded(List, Info^.ProcessIdList[l]) then
begin
GetMem(NewItem, SizeOf(TProcessRecord));
ZeroMemory(NewItem, SizeOf(TProcessRecord));
NewItem^.ProcessId := Info^.ProcessIdList[l];
AddItem(List, NewItem);
end;
FreeMem(Info);
end;
end;

OB_TYPE_THREAD : begin
if Threads then
if ZwQueryInformationThread(tHandle, THREAD_BASIC_INFO,
@THRInfo,
SizeOf(THREAD_BASIC_INFORMATION),
nil) = STATUS_SUCCESS then
if not IsPidAdded(List, THRInfo.ClientId.UniqueProcess) then
begin
GetMem(NewItem, SizeOf(TProcessRecord));
ZeroMemory(NewItem, SizeOf(TProcessRecord));
NewItem^.ProcessId := THRInfo.ClientId.UniqueProcess;
AddItem(List, NewItem);
end;
end;

end;
CloseHandle(tHandle);
end;
CloseHandle(hProcess);
end;
VirtualFree(HandlesInfo, 0, MEM_RELEASE);
end;

К сожалению, некоторые из вышеприведенных методов позволяют определить только ProcessId, но не имя процесса. Следовательно, нам нужно уметь получить имя процесса по pid. ToolHelp API для этого использовать естественно не стоит, так как процесс можкт быть скрытым, поэтому мы будем открывать память процесса на чтение и читьть имя из его PEB. Адрес PEB в процессе можно определить с помощью функции ZwQueryInformationProcess. А вот и код осуществляющий все это:

function GetNameByPid(Pid: dword): string;
var
hProcess, Bytes: dword;
Info: PROCESS_BASIC_INFORMATION;
ProcessParametres: pointer;
ImagePath: TUnicodeString;
ImgPath: array[0..MAX_PATH] of WideChar;
begin
Result := '';
ZeroMemory(@ImgPath, MAX_PATH * SizeOf(WideChar));
hProcess := OpenProcess(PROCESS_QUERY_INFORMATION or PROCESS_VM_READ, false, Pid);
if ZwQueryInformationProcess(hProcess, ProcessBasicInformation, @Info,
SizeOf(PROCESS_BASIC_INFORMATION), nil) = STATUS_SUCCESS then
begin
if ReadProcessMemory(hProcess, pointer(dword(Info.PebBaseAddress) + $10),
@ProcessParametres, SizeOf(pointer), Bytes) and
ReadProcessMemory(hProcess, pointer(dword(ProcessParametres) + $38),
@ImagePath, SizeOf(TUnicodeString), Bytes) and
ReadProcessMemory(hProcess, ImagePath.Buffer, @ImgPath,
ImagePath.Length, Bytes) then
begin
Result := ExtractFileName(WideCharToString(ImgPath));
end;
end;
CloseHandle(hProcess);
end;
Естественно, юзермодные методы обнаружения на этом не заканчиваются. Если приложить немного усилий, то можно придумать еще несколько новых (например загрузку своей Dll в доступные процессы с помощью SetWindowsHookEx с последующим анализом списка процессов, где наша Dll оказалась), но пока этих методов нам хватит. Их достоинство в том, что они просты в программировании, но позволяют обнаружить только процессы скрытые API перехватом в User Mode, либо плохо скрытые из Kernel Mode. Для действительно надежного обнаружения скрытых процессов нам придется писать драйвер и работать с внутренними структурами ядра Windows.

Kernel Mode detection
Вот мы и дошли до методов обнаружения скрытых процессов в режиме ядра. От юзермодных методов они отличаются в первую очередь тем, что списки процессов можно построить не используя API, а работая напрямую с структурами планировщика. Скрыться от таких методов обнаружения гораздо труднее, так как они основаны на самых принципах работы системы, и удаление всех следов процесса из списков планировщика приведет к невозможности его работы.

Что представляет из себя процесс изнутри? Каждый процесс имеет свое адресное пространство, свои дескрипторы, потоки, и.т.д. С этими вещами связаны соответствующие структуры ядра. Каждый процесс описывается структурой EPROCESS, структуры всех процессов связаны в кольцевой двухсвязный список. Один из методов скрытия процессов заключается в изменении указателей так, чтобы перечисление шло в обход скрываемого процесса. Для работы процесса некритично, будет ли он участвовать в перечислении или нет. Но структура EPROCESS всегда должна быть, она необходима для работы процесса. Большинство методов обнаружения скрытых процессов в Kernel Mode так или иначе связаны с обнаружением этой структуры.

Сначала определимся с форматом хранения полученной информации о процессах. Формат этот должен быть удобен для передачи из драйвера в приложение. Пусть этим форматом будет следующая структура:

typedef struct _ProcessRecord
{
ULONG Visibles;
ULONG SignalState;
BOOLEAN Present;
ULONG ProcessId;
ULONG ParrentPID;
PEPROCESS pEPROCESS;
CHAR ProcessName[256];
} TProcessRecord, *PProcessRecord;
Пусть структуры располагаются в памяти по порядку, и у последней из них сброшен флаг Present.

Получение списка процессов через ZwQuerySystemInformation в ядре.
Начнем как всегда с простого, с получения образцового списка процессов через ZwQuerySystemInformation:

PVOID GetNativeProcessList(ULONG *MemSize)
{
ULONG PsCount = 0;
PVOID Info = GetInfoTable(SystemProcessesAndThreadsInformation);
PSYSTEM_PROCESSES Proc;
PVOID Mem = NULL;
PProcessRecord Data;

if (!Info) return NULL; else Proc = Info;

do
{
Proc = (PSYSTEM_PROCESSES)((ULONG)Proc + Proc->NextEntryDelta);
PsCount++;
} while (Proc->NextEntryDelta);

*MemSize = (PsCount + 1) * sizeof(TProcessRecord);

Mem = ExAllocatePool(PagedPool, *MemSize);

if (!Mem) return NULL; else Data = Mem;

Proc = Info;
do
{
Proc = (PSYSTEM_PROCESSES)((ULONG)Proc + Proc->NextEntryDelta);
wcstombs(Data->ProcessName, Proc->ProcessName.Buffer, 255);
Data->Present = TRUE;
Data->ProcessId = Proc->ProcessId;
Data->ParrentPID = Proc->InheritedFromProcessId;
PsLookupProcessByProcessId((HANDLE)Proc->ProcessId, &Data->pEPROCESS);
ObDereferenceObject(Data->pEPROCESS);
Data++;
} while (Proc->NextEntryDelta);

Data->Present = FALSE;

ExFreePool(Info);

return Mem;
}
Пусть эта функция будет образцовой, так как любой Kernel Mode метод скрытия процесса не будет ею обнаружен. Но юзермодные руткиты типа hxdef будут здесь обнаружены.

В этом коде применяеся функция GetInfoTable для простого получения информации. Для того чтобы не возникало вопросов что это такое я приведу ее здесь полностью:

/*
Получение буфера с результатом ZwQuerySystemInformation.
*/
PVOID GetInfoTable(ULONG ATableType)
{
ULONG mSize = 0x4000;
PVOID mPtr = NULL;
NTSTATUS St;
do
{
mPtr = ExAllocatePool(PagedPool, mSize);
memset(mPtr, 0, mSize);
if (mPtr)
{
St = ZwQuerySystemInformation(ATableType, mPtr, mSize, NULL);
} else return NULL;
if (St == STATUS_INFO_LENGTH_MISMATCH)
{
ExFreePool(mPtr);
mSize = mSize * 2;
}
} while (St == STATUS_INFO_LENGTH_MISMATCH);
if (St == STATUS_SUCCESS) return mPtr;
ExFreePool(mPtr);
return NULL;
}
Я думаю, что понимание смысла этой функции ни у кого затруднений не вызовет.

Получение списка процессов из двусвязного списка структур EPROCESS.
Итак, идем дальше. Следующим шагом будет получение списка процессов проходом по двухсвязному списку структур EPROCESS. Список начинается с головы - PsActiveProcessHead, поэтому для корректного перечисления процессов нам сначала нужно найти этот неэкспортируемый символ. Для этого проще всего будет воспользоваться тем свойством, что процесс System является первым в списке процессов. Нам нужно находясь в DriverEntry получить указатель на текущий процесс с помощью PsGetCurrentProcess (драйвера загруженные с помощью SC Manager API или ZwLoadDriver всегда грузятся в контексте процесса System), и Blink по смещению ActiveProcessLinks будет указывать на PsActiveProcessHead. Выглядит это примерно так:

PsActiveProcessHead = *(PVOID *)((PUCHAR)PsGetCurrentProcess + ActiveProcessLinksOffset + 4);
Теперь можно пройтись по двухсвязному списку и построить список процессов:

PVOID GetEprocessProcessList(ULONG *MemSize)
{
PLIST_ENTRY Process;
ULONG PsCount = 0;
PVOID Mem = NULL;
PProcessRecord Data;

if (!PsActiveProcessHead) return NULL;

Process = PsActiveProcessHead->Flink;

while (Process != PsActiveProcessHead)
{
PsCount++;
Process = Process->Flink;
}

PsCount++;

*MemSize = PsCount * sizeof(TProcessRecord);

Mem = ExAllocatePool(PagedPool, *MemSize);
memset(Mem, 0, *MemSize);

if (!Mem) return NULL; else Data = Mem;

Process = PsActiveProcessHead->Flink;

while (Process != PsActiveProcessHead)
{
Data->Present = TRUE;
Data->ProcessId = *(PULONG)((ULONG)Process - ActPsLink + pIdOffset);
Data->ParrentPID = *(PULONG)((ULONG)Process - ActPsLink + ppIdOffset);
Data->SignalState = *(PULONG)((ULONG)Process - ActPsLink + 4);
Data->pEPROCESS = (PEPROCESS)((ULONG)Process - ActPsLink);
strncpy(Data->ProcessName, (PVOID)((ULONG)Process - ActPsLink + NameOffset), 16);
Data++;
Process = Process->Flink;

}

return Mem;
}
Для получения имени процесса, его Process Id и ParrentProcessId используются смещения данных полей в структуре EPROCESS (pIdOffset, ppIdOffset, NameOffset, ActPsLink). Эти смещения различаются в различных версиях Windows, поэтому их получение вынесено в отдельную функцию, которую вы можете увидеть в исходном коде программы Process Hunter (в приложении к статье).

Любое скрытие процесса методом API перехвата будет обнаружено вышеприведенным способом. Но если процесс скрыт с помощью метода DKOM (Direct Kernel Object Manipulation), то этот способ не поможет, так как при этом процесс удаляется из списка процессов.

Получение списка процессов по спискам потоков планировщика.
Один из методов обнаружения такого скрытия состоит в получнии списка процессов по списку потоков в планировщике. В Windows 2000 имеется три двусвязных списка потоков: KiWaitInListHead, KiWaitOutListHead, KiDispatcherReadyListHead. Первые два списка содержат потоки ожидающие наступления какого-либо события, а третий содержит потоки готовые к исполнению. Пройдясь по спискам и вычев смещение списка потоков в стуктуре ETHREAD мы получим указатель на ETHREAD потока. Эта структура содержит несколько указателей на процесс связанный с потоком, это struct _KPROCESS *Process (0x44, 0x150) и sruct _EPROCESS *ThreadsProcess (0x22C, смещения указаны для Windows 2000). Первые два указателя не оказывают никакого влияния на работу потока, поэтому легко могут быть подменены в целях скрытия. А третий указатель используеся планировщиком при переключении адресных пространств, поэтому подменен быть не может. Его мы и будем использовать для определения процесса владеющего потоком.

Этот метод обнаружения применяется в программе klister, главный недостаток которой - работа только под Windows 2000 (и то не со всеми сервиспаками). Обусловлен это недостаток тем, что в Klister жестко зашиты адреса списков потоков, которые меняются почти с каждым сервиспаком системы.

Зашивать адреса списков в программу - это очень плохой метод, так как гарантирует неработоспособность программы с следующими обновлениями ОС, да и помогает укрыться от этого метода обнаружения, поэтому адреса списков придется искать динамически, анализом кода функций, в которых они используются.

Для начала попробуем найти KiWaitItListHead и KiWaitOutListHead в Windows 2000. Адреса этих списков используются в функции KeWaitForSingleObject в коде следующего вида:

.text:0042DE56 mov ecx, offset KiWaitInListHead
.text:0042DE5B test al, al
.text:0042DE5D jz short loc_42DE6E
.text:0042DE5F cmp byte ptr [esi+135h], 0
.text:0042DE66 jz short loc_42DE6E
.text:0042DE68 cmp byte ptr [esi+33h], 19h
.text:0042DE6C jl short loc_42DE73
.text:0042DE6E mov ecx, offset KiWaitOutListHead

Для получения адресов этих списков надо пройтись дизассемблером длин инструкций (будем использовать мой LDasm) по KeWaitForSingleObject и когда указатель (pOpcode) будет на команде mov ecx, KiWaitInListHead, то pOpcode + 5 будет указывать на test al, al, а pOpcode + 24 на mov ecx, KiWaitOutListHead. После этого адреса KiWaitItListHead и KiWaitOutListHead извлекаются по указателям pOpcode + 1 и pOpcode + 25 соответственно. Код поиска этих адресов будет выглядеть так:

void Win2KGetKiWaitInOutListHeads()
{
PUCHAR cPtr, pOpcode;
ULONG Length;

for (cPtr = (PUCHAR)KeWaitForSingleObject;
cPtr Flink;

while (Item != ListHead)
{
CollectProcess(*(PEPROCESS *)((ULONG)Item + WaitProcOffset));
Item = Item->Flink;
}
}

return;
}
CollectProcess - это функция добавляющая процесс в список, если он еще не был туда добавлен.

Получение списка процессов перехватом системных вызовов.
Любой работающий процесс взаимодействует с системой через API, и большинство этих запросов превращаються в обращения к ядру системы через интерфейс системных вызовов. Конечно, процесс может работать не вызывая API, но тогда никакой полезной (или вредной) работы он выполнять не сможет. В общем идея состоит в том, чтобы перехватить обращения к интерфейсу системных вызовов, а в обработчике получать указатель на EPROCESS текущего процесса. Список указателей придется собирать определенное время, и в него не войдут процессы ни разу не выполнявшие системные вызовы за время сбора этой информации (например процессы, потоки которых находятся в состоянии ожидания).

В windows 2000 для системного вызова используется прерывание 2Eh, поэтому для перехвата системных вызовов нам нужно изменить дескриптор соответствующего прерывания в idt. Для этого нам нужно сначала определить положение idt в памяти с помощью команды sidt. Эта команда возвращает следующую структуру:

typedef struct _Idt
{
USHORT Size;
ULONG Base;
} TIdt;
Код изменяющий вектор прерывания 2Eh будет выглядеть так:

void Set2kSyscallHook()
{
TIdt Idt;
__asm
{
pushad
cli
sidt [Idt]
mov esi, NewSyscall
mov ebx, Idt.Base
xchg [ebx + 0x170], si
rol esi, 0x10
xchg [ebx + 0x176], si
ror esi, 0x10
mov OldSyscall, esi
sti
popad
}
}
Естественно, перед выгрузкой драйвера нужно все восстанавливать:

void Win2kSyscallUnhook()
{
TIdt Idt;
__asm
{
pushad
cli
sidt [Idt]
mov esi, OldSyscall
mov ebx, Idt.Base
mov [ebx + 0x170], si
rol esi, 0x10
mov [ebx + 0x176], si
sti
xor eax, eax
mov OldSyscall, eax
popad
}
}