Просмотр скрытых процессов windows

Обнаружение скрытых процессов — Архив WASM.RU

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

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

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

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

Обнаружение в User Mode

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

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

3.  TProcList = packed record
5.    ProcName: array [0..MAX_PATH] of Char;

Получение списка процессов через ToolHelp API

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

2.  Получение списка процессов через ToolHelp API.
4. procedure GetToolHelpProcessList(var List: PListStruct);
7.  Process: TPROCESSENTRY32;
10.   Snap := CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
11.   if Snap <> INVALID_HANDLE_VALUE then
13.       Process.dwSize := SizeOf(TPROCESSENTRY32);
14.       if Process32First(Snap, Process) then
16.           GetMem(NewItem, SizeOf(TProcessRecord));
17.           ZeroMemory(NewItem, SizeOf(TProcessRecord));
18.           NewItem^.ProcessId  := Process.th32ProcessID;
19.           NewItem^.ParrentPID := Process.th32ParentProcessID;
20.           lstrcpy(@NewItem^.ProcessName, Process.szExeFile);
22.          until not Process32Next(Snap, Process);

Очевидно, что любой скрытый процесс при таком перечислении найден не будет,
поэтому эта функция будет образцовой для отделения скрытых процессов от
нескрытых.

Получение списка процессов через Native API

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

2.   Получение списка процессов через ZwQuerySystemInformation.
4. procedure GetNativeProcessList(var List: PListStruct);
10.   Info := GetInfoTable(SystemProcessesAndThreadsInformation);
14.    GetMem(NewItem, SizeOf(TProcessRecord));
15.    ZeroMemory(NewItem, SizeOf(TProcessRecord));
16.    lstrcpy(@NewItem^.ProcessName,
17.            PChar(WideCharToString(Info^.ProcessName.Buffer)));
18.    NewItem^.ProcessId  := Info^.ProcessId;
19.    NewItem^.ParrentPID := Info^.InheritedFromProcessId;
21.    Info := pointer(dword(info) + info^.NextEntryDelta);
22.   until Info^.NextEntryDelta = 0;
23.   VirtualFree(Mem, 0, MEM_RELEASE);

Получение списка процессов по списку открытых хэндлов.

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

2.   Получение списка процессов по списку открытых хэндлов.
3.   Возвращает только ProcessId.
5. procedure GetHandlesProcessList(var List: PListStruct);
7.  Info: PSYSTEM_HANDLE_INFORMATION_EX;
13.   Info := GetInfoTable(SystemHandleInformation);
15.   for r := 0 to Info^.NumberOfHandles do
16.     if Info^.Information[r].ProcessId <> OldPid then
18.        OldPid := Info^.Information[r].ProcessId;
19.        GetMem(NewItem, SizeOf(TProcessRecord));
20.        ZeroMemory(NewItem, SizeOf(TProcessRecord));
21.        NewItem^.ProcessId   := OldPid;
24.   VirtualFree(Info, 0, MEM_RELEASE);

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

Получение списка процессов по списку открытых ими окон.

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

2.   Получение списка процессов по списку окон.
3.   Возвращает только ProcessId.
5. procedure GetWindowsProcessList(var List: PListStruct);
7.  function EnumWindowsProc(hwnd: dword; PList: PPListStruct): bool; stdcall;
12.   GetWindowThreadProcessId(hwnd, ProcId);
13.    if not IsPidAdded(PList^, ProcId) then
15.      GetMem(NewItem, SizeOf(TProcessRecord));
16.      ZeroMemory(NewItem, SizeOf(TProcessRecord));
17.      NewItem^.ProcessId   := ProcId;
18.      AddItem(PList^, NewItem);
24.  EnumWindows(@EnumWindowsProc, dword(@List));

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

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

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

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

2.  Системный вызов ZwQuerySystemInformation для Windows XP.
4. Function XpZwQuerySystemInfoCall(ASystemInformationClass: dword;
5.                                  ASystemInformation: Pointer;
6.                                  ASystemInformationLength: dword;
7.                                  AReturnLength: pdword): dword; stdcall;

В связи с другим интерфейсом системных вызовов, для Windows 2000 этот код
будет выглядеть иначе.

2.   Системный вызов ZwQuerySystemInformation для Windows 2000.
4. Function Win2kZwQuerySystemInfoCall(ASystemInformationClass: dword;
5.                                     ASystemInformation: Pointer;
6.                                     ASystemInformationLength: dword;
7.                                     AReturnLength: pdword): dword; stdcall;

Теперь остается перечислить процессы не с помощью функций из ntdll.dll, а с
помощью только что определенных функций. Вот код, который это делает:

2.   Получение списка процессов через системный вызов
3.   ZwQuerySystemInformation.
5. procedure GetSyscallProcessList(var List: PListStruct);
16.   St := ZwQuerySystemInfoCall(SystemProcessesAndThreadsInformation,
18.   if St = STATUS_INFO_LENGTH_MISMATCH then
23.  until St <> STATUS_INFO_LENGTH_MISMATCH;
24.  if St = STATUS_SUCCESS then
28.      GetMem(NewItem, SizeOf(TProcessRecord));
29.      ZeroMemory(NewItem, SizeOf(TProcessRecord));
30.      lstrcpy(@NewItem^.ProcessName,
31.              PChar(WideCharToString(Info^.ProcessName.Buffer)));
32.      NewItem^.ProcessId  := Info^.ProcessId;
33.      NewItem^.ParrentPID := Info^.InheritedFromProcessId;
34.      Info := pointer(dword(info) + info^.NextEntryDelta);
36.     until Info^.NextEntryDelta = 0;

Этот метод практически 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. А вот и код осуществляющий все это:

1. function GetNameByPid(Pid: dword): string;
4.  Info: PROCESS_BASIC_INFORMATION;
5.  ProcessParametres: pointer;
6.  ImagePath: TUnicodeString;
7.  ImgPath: array[0..MAX_PATH] of WideChar;
10.  ZeroMemory(@ImgPath, MAX_PATH * SizeOf(WideChar));
11.  hProcess := OpenProcess(PROCESS_QUERY_INFORMATION or PROCESS_VM_READ, false, Pid);
12.  if ZwQueryInformationProcess(hProcess, ProcessBasicInformation, @Info,
13.                               SizeOf(PROCESS_BASIC_INFORMATION), nil) = STATUS_SUCCESS then
15.    if ReadProcessMemory(hProcess, pointer(dword(Info.PebBaseAddress) + $10),
16.                         @ProcessParametres, SizeOf(pointer), Bytes) and
17.       ReadProcessMemory(hProcess, pointer(dword(ProcessParametres) + $38),
18.                         @ImagePath, SizeOf(TUnicodeString), Bytes)  and
19.       ReadProcessMemory(hProcess, ImagePath.Buffer, @ImgPath,
20.                         ImagePath.Length, Bytes) then
22.           Result := ExtractFileName(WideCharToString(ImgPath));

Естественно, юзермодные методы обнаружения на этом не заканчиваются. Если
приложить немного усилий, то можно придумать еще несколько новых (например
загрузку своей Dll в доступные процессы с помощью SetWindowsHookEx с последующим
анализом списка процессов, где наша Dll оказалась), но пока этих методов нам
хватит. Их достоинство в том, что они просты в программировании, но позволяют
обнаружить только процессы скрытые API перехватом в User Mode, либо плохо
скрытые из Kernel Mode. Для действительно надежного обнаружения скрытых
процессов нам придется писать драйвер и работать с внутренними структурами ядра
Windows.

Kernel Mode detection

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

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

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

1. typedef struct _ProcessRecord
10. } TProcessRecord, *PProcessRecord;

Пусть структуры располагаются в памяти по порядку, и у последней из них
сброшен флаг Present.

Получение списка процессов через ZwQuerySystemInformation в
ядре.

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

1. PVOID GetNativeProcessList(ULONG *MemSize)
4.     PVOID Info = GetInfoTable(SystemProcessesAndThreadsInformation);
9.     if (!Info) return NULL; else Proc = Info;
13.         Proc = (PSYSTEM_PROCESSES)((ULONG)Proc + Proc->NextEntryDelta); 
15.     } while (Proc->NextEntryDelta);
17.     *MemSize = (PsCount + 1) * sizeof(TProcessRecord);
19.     Mem = ExAllocatePool(PagedPool, *MemSize);
21.     if (!Mem) return NULL; else Data = Mem;
26.         Proc = (PSYSTEM_PROCESSES)((ULONG)Proc + Proc->NextEntryDelta);
27.         wcstombs(Data->ProcessName, Proc->ProcessName.Buffer, 255);
29.         Data->ProcessId  = Proc->ProcessId;
30.         Data->ParrentPID = Proc->InheritedFromProcessId;
31.         PsLookupProcessByProcessId((HANDLE)Proc->ProcessId, &Data->pEPROCESS);
32.         ObDereferenceObject(Data->pEPROCESS);
34.     } while (Proc->NextEntryDelta);
36.     Data->Present = FALSE;

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

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

2.   Получение буфера с результатом ZwQuerySystemInformation.
4. PVOID GetInfoTable(ULONG ATableType)
11.         mPtr = ExAllocatePool(PagedPool, mSize);
15.             St = ZwQuerySystemInformation(ATableType, mPtr, mSize, NULL);
17.         if (St == STATUS_INFO_LENGTH_MISMATCH)
22.     } while (St == STATUS_INFO_LENGTH_MISMATCH);
23.     if (St == STATUS_SUCCESS) return mPtr;

Я думаю, что понимание смысла этой функции ни у кого затруднений не
вызовет.

Получение списка процессов из двусвязного списка структур
EPROCESS.

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

1. PsActiveProcessHead = *(PVOID *)((PUCHAR)PsGetCurrentProcess + ActiveProcessLinksOffset + 4);

Теперь можно пройтись по двухсвязному списку и построить список
процессов:

1. PVOID GetEprocessProcessList(ULONG *MemSize)
8.     if (!PsActiveProcessHead) return NULL;
10.     Process = PsActiveProcessHead->Flink;
12.     while (Process != PsActiveProcessHead)
15.         Process = Process->Flink;
20.     *MemSize = PsCount * sizeof(TProcessRecord);
22.     Mem = ExAllocatePool(PagedPool, *MemSize);
23.     memset(Mem, 0, *MemSize);
25.     if (!Mem) return NULL; else Data = Mem;
27.     Process = PsActiveProcessHead->Flink;
29.     while (Process != PsActiveProcessHead)
32.         Data->ProcessId   = *(PULONG)((ULONG)Process — ActPsLink + pIdOffset);
33.         Data->ParrentPID  = *(PULONG)((ULONG)Process — ActPsLink + ppIdOffset);
34.         Data->SignalState = *(PULONG)((ULONG)Process — ActPsLink + 4);
35.         Data->pEPROCESS   = (PEPROCESS)((ULONG)Process — ActPsLink);
36.         strncpy(Data->ProcessName, (PVOID)((ULONG)Process — ActPsLink + NameOffset), 16);       
38.         Process = Process->Flink;

Для получения имени процесса, его 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 в коде
следующего вида:

1. .text:0042DE56                 mov     ecx, offset KiWaitInListHead
2. .text:0042DE5B                 test    al, al
3. .text:0042DE5D                 jz      short loc_42DE6E
4. .text:0042DE5F                 cmp     byte ptr [esi+135h], 0
5. .text:0042DE66                 jz      short loc_42DE6E
6. .text:0042DE68                 cmp     byte ptr [esi+33h], 19h
7. .text:0042DE6C                 jl      short loc_42DE73
8. .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 соответственно. Код поиска этих адресов
будет выглядеть так:

1. void Win2KGetKiWaitInOutListHeads()
6.     for (cPtr = (PUCHAR)KeWaitForSingleObject;
7.          cPtr < (PUCHAR)KeWaitForSingleObject + PAGE_SIZE;
10.         Length = SizeOfCode(cPtr, &pOpcode);
14.         if (*pOpcode == 0xB9 && *(pOpcode + 5) == 0x84 && *(pOpcode + 24) == 0xB9)
16.             KiWaitInListHead  = *(PLIST_ENTRY *)(pOpcode + 1);
17.             KiWaitOutListHead = *(PLIST_ENTRY *)(pOpcode + 25);

KiDispatcherReadyListHead в Windows 2000 ищется аналогичным путем, с помощью
поиска в функции KeSetAffinityThread следующего кода:

1. .text:0042FAAA                 lea     eax, KiDispatcherReadyListHead[ecx*8]
2. .text:0042FAB1                 cmp     [eax], eax

А вот и функция ищущая KiDispatcherReadyListHead:

1. void Win2KGetKiDispatcherReadyListHead()
6.     for (cPtr = (PUCHAR)KeSetAffinityThread;
7.          cPtr < (PUCHAR)KeSetAffinityThread + PAGE_SIZE;
10.         Length = SizeOfCode(cPtr, &pOpcode);
14.         if (*(PUSHORT)pOpcode == 0x048D && *(pOpcode + 2) == 0xCD && *(pOpcode + 7) == 0x39)
16.             KiDispatcherReadyListHead = *(PVOID *)(pOpcode + 3);

К сожалению, в Windows XP ядро довольно сильно отличается от Windows 2000.
Планировщик в XP имеет не три, а только два списка потоков: KiWaitListHead и
KiDispatcherReadyListHead. KiWaitListHead можно найти сканированием функции
KeDelayExecutionThread на следующий код:

1. .text:004055B5                 mov     dword ptr [ebx], offset KiWaitListHead
2. .text:004055BB                 mov     [ebx+4], eax

Такой поиск осуществляется следующим кодом:

1. void XPGetKiWaitListHead()
6.     for (cPtr = (PUCHAR)KeDelayExecutionThread;
7.          cPtr < (PUCHAR)KeDelayExecutionThread + PAGE_SIZE;
10.         Length = SizeOfCode(cPtr, &pOpcode);
14.         if (*(PUSHORT)cPtr == 0x03C7 && *(PUSHORT)(pOpcode + 6) == 0x4389)
16.             KiWaitInListHead = *(PLIST_ENTRY *)(pOpcode + 2);

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

1. .text:00404E72                 mov     byte ptr [edi+50h], 1
2. .text:00404E76                 call    sub_404C5A
4. .text:00404E7D                 call    sub_404EB9

Первый call в этом участке кода указывает на функцию, в которой есть ссылка
на KiDispatcherReadyListHead, но поиск адреса осложняется тем, что нужное нам
место функции имеет различный вид в Winows XP SP1 и SP2. В SP2 оно выглядит
так:

1. .text:00404CCD                 add     eax, 60h
2. .text:00404CD0                 test    bl, bl
3. .text:00404CD2                 lea     edx, KiDispatcherReadyListHead[ecx*8]
4. .text:00404CD9                 jnz     loc_401F12
5. .text:00404CDF                 mov     esi, [edx+4]

А в SP1 так:

1. .text:004180FE                 add     eax, 60h
2. .text:00418101                 cmp     [ebp+var_1], bl
3. .text:00418104                 lea     edx, KiDispatcherReadyListHead[ecx*8]
4. .text:0041810B                 jz      loc_418760
5. .text:00418111                 mov     esi, [edx]

Искать только по одной инструкции lea ненадежно, поэтому мы будем также
проверять присутствие после lea команды с rel32 смещением (функция IsRelativeCmd
в LDasm). Полный код поиска KiDispatcherReadyListHead будет выглядеть
так:

1. void XPGetKiDispatcherReadyListHead()
7.     for (cPtr = (PUCHAR)KiDispatchInterrupt;
8.          cPtr < (PUCHAR)KiDispatchInterrupt + PAGE_SIZE;
11.         Length = SizeOfCode(cPtr, &pOpcode);
15.         if (*pOpcode == 0xE8 && *(PUSHORT)(pOpcode + 5) == 0x01B1)
17.             CallAddr = (PUCHAR)(*(PULONG)(pOpcode + 1) + (ULONG)cPtr + Length);
22.     if (!CallAddr || !MmIsAddressValid(CallAddr)) return;
24.     for (cPtr = CallAddr; cPtr < CallAddr + PAGE_SIZE; cPtr += Length)
26.         Length = SizeOfCode(cPtr, &pOpcode);
30.         if (*(PUSHORT)pOpcode == 0x148D && *(pOpcode + 2) == 0xCD && IsRelativeCmd(pOpcode + 7))
32.             KiDispatcherReadyListHead = *(PLIST_ENTRY *)(pOpcode + 3);

После нахождения адресов списков потоков, мы можем легко перечислить их
процессы с помощью следующей функции:

1. void ProcessListHead(PLIST_ENTRY ListHead)
7.         Item = ListHead->Flink;
11.             CollectProcess(*(PEPROCESS *)((ULONG)Item + WaitProcOffset));

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

Получение списка процессов перехватом системных вызовов.

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

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

Код изменяющий вектор прерывания 2Eh будет выглядеть так:

Естественно, перед выгрузкой драйвера нужно все восстанавливать:

1. void Win2kSyscallUnhook()

В Windows XP используется интерфейс системных вызовов построенный на основе
команды sysenter/sysexit которые появились в процессорах Pentium 2. Работой этих
команд управляют модельно-специфичные регистры (MSR). Адрес обработчика
системного вызова задается в MSR регистре SYSENTER_EIP_MSR (номер 0x176). Чтение
MSR регистра выполняется командой rdmsr, перед этим в ЕСХ должен быть помещен
номер читаемого регистра, а результат помещается в пару регистров EDX:EAX. В
нашем случае регистр SYSENTER_EIP_MSR 32 битный, поэтому в EDX будет 0, а в EAX
адрес обработчика системных вызовов. Аналогично, с помощью wrmsr выполняется
запись в MSR регистр. Но тут существует один подводный камень: при записи в 32
битный MSR регистр, EDX должен быть обнулен, иначе это вызовет исключений и
приведет к немедленному падению системы.

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

А восстанавливающий старый обработчик так:

Особенность Windows XP в том, что системный вызов может быть произведен как
через sysenter, так и через int 2Eh, поэтому нам нужно заменить оба обработчика
своими.

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

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

1. void __declspec(naked) NewSyscall()

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

2. (*PCREATE_PROCESS_NOTIFY_ROUTINE) (

Установка обработчика производится так:

1. PsSetCreateProcessNotifyRoutine(NotifyRoutine, FALSE);

А удаление так:

1. PsSetCreateProcessNotifyRoutine(NotifyRoutine, TRUE);

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

1. void WorkItemProc(PDEVICE_OBJECT DeviceObject, PWorkItemStruct Data)
3.     KeWaitForSingleObject(Data->pEPROCESS, Executive, KernelMode, FALSE, NULL);
5.     DelItem(&wLastItem, Data->pEPROCESS);
7.     ObDereferenceObject(Data->pEPROCESS);
9.     IoFreeWorkItem(Data->IoWorkItem);
17. void NotifyRoutine(IN HANDLE  ParentId,
26.         PsLookupProcessByProcessId(ProcessId, &process);
28.         if (!IsAdded(wLastItem, process)) AddItem(&wLastItem, process);
30.         ObDereferenceObject(process);
34.         process = PsGetCurrentProcess();
36.         ObReferenceObject(process);
38.         Data = ExAllocatePool(NonPagedPool, sizeof(TWorkItemStruct));
40.         Data->IoWorkItem = IoAllocateWorkItem(deviceObject);
42.         Data->pEPROCESS  = process;
44.         IoQueueWorkItem(Data->IoWorkItem, WorkItemProc, DelayedWorkQueue, Data);

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

Обойти этот метод обнаружения при желании также несложно, для этого нужно
изменить метод выполнения системного вызова в скрываемых процессах (перестроить
на другое прерывание или на каллгейт в 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 будет
выглядеть так:

1. void GetHandleTableListHead()
3.     PSYSTEM_MODULE_INFORMATION_EX Info = GetInfoTable(SystemModuleInformation);
4.     ULONG NtoskrnlBase = (ULONG)Info->Modules[0].Base;
5.     ULONG NtoskrnlSize = Info->Modules[0].Size;
6.     PHANDLE_TABLE HandleTable = *(PHANDLE_TABLE *)((ULONG)PsGetCurrentProcess() + HandleTableOffset);
7.     PLIST_ENTRY HandleTableList = (PLIST_ENTRY)((ULONG)HandleTable + HandleTableListOffset);
12.     for (CurrTable = HandleTableList->Flink;
13.          CurrTable != HandleTableList;
14.          CurrTable = CurrTable->Flink)
16.         if ((ULONG)CurrTable > NtoskrnlBase && (ULONG)CurrTable < NtoskrnlBase + NtoskrnlSize)
18.             HandleTableListHead = CurrTable;

Этот код весьма универсален, так как работает в любых версиях Windows NT, и к
тому же может применяться не только для поиска HandleTableListHead, но также и
любых других списков имеющих подобную структуру.

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

1. void ScanHandleTablesList()
6.     for (CurrTable =  HandleTableListHead->Flink;
7.          CurrTable != HandleTableListHead;
8.          CurrTable =  CurrTable->Flink)
10.         QuotaProcess = *(PEPROCESS *)((PUCHAR)CurrTable — HandleTableListOffset + QuotaProcessOffset);
11.         if (QuotaProcess) CollectProcess(QuotaProcess);

Этот метод обнаружения скрытых процессов применяется в программах F-Secure
Black Light и в последней версии KProcCheck. Как его обойти, я думаю вы сами
догадаетесь.

Получение списка процессов путем сканирования PspCidTable.

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

1. PAGE:0049D59E ; NTSTATUS __stdcall NtOpenProcess(PHANDLE ProcessHandle, ACCESS_MASK DesiredAccess,
2.                                                  POBJECT_ATTRIBUTES ObjectAttributes,PCLIENT_ID ClientId)
3. PAGE:0049D59E                 public NtOpenProcess
4. PAGE:0049D59E NtOpenProcess   proc near              
6. PAGE:0049D59E ProcessHandle   = dword ptr  4
7. PAGE:0049D59E DesiredAccess   = dword ptr  8
8. PAGE:0049D59E ObjectAttributes= dword ptr  0Ch
9. PAGE:0049D59E ClientId        = dword ptr  10h
12. PAGE:0049D5A3                 push    offset dword_413560 ; int
13. PAGE:0049D5A8                 call    sub_40BA92
14. PAGE:0049D5AD                 xor     esi, esi
15. PAGE:0049D5AF                 mov     [ebp-2Ch], esi
16. PAGE:0049D5B2                 xor     eax, eax
17. PAGE:0049D5B4                 lea     edi, [ebp-28h]
19. PAGE:0049D5B8                 mov     eax, large fs:124h
20. PAGE:0049D5BE                 mov     al, [eax+140h]
21. PAGE:0049D5C4                 mov     [ebp-34h], al
22. PAGE:0049D5C7                 test    al, al
23. PAGE:0049D5C9                 jz      loc_4BE034
24. PAGE:0049D5CF                 mov     [ebp-4], esi
25. PAGE:0049D5D2                 mov     eax, MmUserProbeAddress
26. PAGE:0049D5D7                 mov     ecx, [ebp+8]
27. PAGE:0049D5DA                 cmp     ecx, eax
28. PAGE:0049D5DC                 jnb     loc_520CDE
29. PAGE:0049D5E2 loc_49D5E2:                            
30. PAGE:0049D5E2                 mov     eax, [ecx]
31. PAGE:0049D5E4                 mov     [ecx], eax
32. PAGE:0049D5E6                 mov     ebx, [ebp+10h]
34. PAGE:0049D5EC                 jnz     loc_520CE5
35. PAGE:0049D5F2 loc_49D5F2:                          
36. PAGE:0049D5F2                 mov     eax, MmUserProbeAddress
37. PAGE:0049D5F7                 cmp     ebx, eax
38. PAGE:0049D5F9                 jnb     loc_520CEF
39. PAGE:0049D5FF loc_49D5FF:                            
40. PAGE:0049D5FF                 cmp     [ebx+8], esi
41. PAGE:0049D602                 setnz   byte ptr [ebp-1Ah]
42. PAGE:0049D606                 mov     ecx, [ebx+0Ch]
43. PAGE:0049D609                 mov     [ebp-38h], ecx
44. PAGE:0049D60C                 mov     ecx, [ebp+14h]
45. PAGE:0049D60F                 cmp     ecx, esi
46. PAGE:0049D611                 jz      loc_4CCB88
48. PAGE:0049D61A                 jnz     loc_520CFB
49. PAGE:0049D620 loc_49D620:                            
50. PAGE:0049D620                 cmp     ecx, eax
51. PAGE:0049D622                 jnb     loc_520D0D
52. PAGE:0049D628 loc_49D628:
53. PAGE:0049D628                 mov     eax, [ecx]
54. PAGE:0049D62A                 mov     [ebp-2Ch], eax
55. PAGE:0049D62D                 mov     eax, [ecx+4]
56. PAGE:0049D630                 mov     [ebp-28h], eax
57. PAGE:0049D633                 mov     byte ptr [ebp-19h], 1
58. PAGE:0049D637 loc_49D637:                      
59. PAGE:0049D637                 or      dword ptr [ebp-4], 0FFFFFFFFh
60. PAGE:0049D63B loc_49D63B:                    
62. PAGE:0049D63B                 cmp     byte ptr [ebp-1Ah], 0
63. PAGE:0049D63F                 jnz     loc_520D34
64. PAGE:0049D645 loc_49D645:                            
65. PAGE:0049D645                 mov     eax, PsProcessType
66. PAGE:0049D64A                 add     eax, 68h
68. PAGE:0049D64E                 push    dword ptr [ebp+0Ch]
69. PAGE:0049D651                 lea     eax, [ebp-0D4h]
71. PAGE:0049D658                 lea     eax, [ebp-0B8h]
73. PAGE:0049D65F                 call    SeCreateAccessState
74. PAGE:0049D664                 cmp     eax, esi
75. PAGE:0049D666                 jl      loc_49D718
76. PAGE:0049D66C                 push    dword ptr [ebp-34h] ; PreviousMode
77. PAGE:0049D66F                 push    ds:stru_5B6978.HighPart
78. PAGE:0049D675                 push    ds:stru_5B6978.LowPart ; PrivilegeValue
79. PAGE:0049D67B                 call    SeSinglePrivilegeCheck
80. PAGE:0049D680                 test    al, al
81. PAGE:0049D682                 jnz     loc_4AA7DB
82. PAGE:0049D688 loc_49D688:                          
83. PAGE:0049D688                 cmp     byte ptr [ebp-1Ah], 0
84. PAGE:0049D68C                 jnz     loc_520D52
85. PAGE:0049D692                 cmp     byte ptr [ebp-19h], 0
86. PAGE:0049D696                 jz      loc_4CCB9A
87. PAGE:0049D69C                 mov     [ebp-30h], esi
88. PAGE:0049D69F                 cmp     [ebp-28h], esi
89. PAGE:0049D6A2                 jnz     loc_4C1301
90. PAGE:0049D6A8                 lea     eax, [ebp-24h]
92. PAGE:0049D6AC                 push    dword ptr [ebp-2Ch]
93. PAGE:0049D6AF                 call    PsLookupProcessByProcessId
94. PAGE:0049D6B4 loc_49D6B4:                            

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

1. PAGE:0049D725                 public PsLookupProcessByProcessId
2. PAGE:0049D725 PsLookupProcessByProcessId proc near    
5. PAGE:0049D725 ProcessId       = dword ptr  8
6. PAGE:0049D725 Process         = dword ptr  0Ch
8. PAGE:0049D725                 mov     edi, edi
10. PAGE:0049D728                 mov     ebp, esp
13. PAGE:0049D72C                 mov     eax, large fs:124h
14. PAGE:0049D732                 push    [ebp+ProcessId]
15. PAGE:0049D735                 mov     esi, eax
16. PAGE:0049D737                 dec     dword ptr [esi+0D4h]
17. PAGE:0049D73D                 push    PspCidTable
18. PAGE:0049D743                 call    ExMapHandleToPointer
19. PAGE:0049D748                 mov     ebx, eax
20. PAGE:0049D74A                 test    ebx, ebx
21. PAGE:0049D74C                 mov     [ebp+ProcessId], STATUS_INVALID_PARAMETER
22. PAGE:0049D753                 jz      short loc_49D787
24. PAGE:0049D756                 mov     edi, [ebx]
25. PAGE:0049D758                 cmp     byte ptr [edi], 3
26. PAGE:0049D75B                 jnz     short loc_49D77A
27. PAGE:0049D75D                 cmp     dword ptr [edi+1A4h], 0
28. PAGE:0049D764                 jz      short loc_49D77A
29. PAGE:0049D766                 mov     ecx, edi
30. PAGE:0049D768                 call    sub_4134A9
31. PAGE:0049D76D                 test    al, al
32. PAGE:0049D76F                 jz      short loc_49D77A
33. PAGE:0049D771                 mov     eax, [ebp+Process]
34. PAGE:0049D774                 and     [ebp+ProcessId], 0
35. PAGE:0049D778                 mov     [eax], edi
36. PAGE:0049D77A loc_49D77A:                                                                
38. PAGE:0049D77B                 push    PspCidTable
39. PAGE:0049D781                 call    ExUnlockHandleTableEntry
41. PAGE:0049D787 loc_49D787:                          
42. PAGE:0049D787                 inc     dword ptr [esi+0D4h]
43. PAGE:0049D78D                 jnz     short loc_49D79A
44. PAGE:0049D78F                 lea     eax, [esi+34h]
45. PAGE:0049D792                 cmp     [eax], eax
46. PAGE:0049D794                 jnz     loc_52388A
47. PAGE:0049D79A loc_49D79A:                                                            
48. PAGE:0049D79A                 mov     eax, [ebp+ProcessId]

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

1. struct _HANDLE_TABLE_ENTRY {
2.  // static data ————————————
3.  // non-static data ———————————
4.   /*<thisrel this+0x0>*/ /*|0x4|*/ void* Object;
5.   /*<thisrel this+0x0>*/ /*|0x4|*/ unsigned long ObAttributes;
6.   /*<thisrel this+0x0>*/ /*|0x4|*/ struct _HANDLE_TABLE_ENTRY_INFO* InfoTable;
7.   /*<thisrel this+0x0>*/ /*|0x4|*/ unsigned long Value;
8.   /*<thisrel this+0x4>*/ /*|0x4|*/ unsigned long GrantedAccess;
9.   /*<thisrel this+0x4>*/ /*|0x2|*/ unsigned short GrantedAccessIndex;
10.   /*<thisrel this+0x6>*/ /*|0x2|*/ unsigned short CreatorBackTraceIndex;
11.   /*<thisrel this+0x4>*/ /*|0x4|*/ long NextFreeTableEntry;

Из этого можно составить такую структуру HANDLE_TABLE_ENTRY:

1. typedef struct _HANDLE_TABLE_ENTRY
7.         PHANDLE_TABLE_ENTRY_INFO InfoTable;
15.           ACCESS_MASK GrantedAccess;
18.               USHORT GrantedAccessIndex;
19.               USHORT CreatorBackTraceIndex;
25. } HANDLE_TABLE_ENTRY, *PHANDLE_TABLE_ENTRY;

Что полезного мы можем из этого извлечь? Первым делом нас интересует
содержимое поля Object, которое является суммой указателя на описываемый хэндлом
объект и флага указывающего на занятость данного элемента таблицы (подробнее
этот момент мы рассмотрим немного позже). Весьма интересным является поле
GrantedAccess, которое указывает допустимые права доступа к объекту по этому
хэндлу. Нпример, можно открыть файл на чтение, поправить поле GrantedAccess и
писать в этот файл. Подобный метод можно использовать для чтения/записи файлов,
которых не удается открыть с требуемыми правами доступа (например занятых другим
процессом). Но вернемся к нашей задаче — получить список процессов путем
просмотра PspCidTable. Для этого нам нужно разобраться с форматом таблицы
хендлов, для того чтобы суметь их перечислить. С этого момента начинается
серьезная разница между Windows 2000 и Windows XP. Форматы их таблиц хэндлов
сильно отличаются, и нам придется разобраться с их форматом для каждой ОС
отдельно.

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

1. PAGE:00493285 ExMapHandleToPointer proc near          
4. PAGE:00493285 HandleTable     = dword ptr  8
5. PAGE:00493285 Handle          = dword ptr  0Ch
8. PAGE:00493286                 push    [esp+Handle]
9. PAGE:0049328A                 push    [esp+4+HandleTable]
10. PAGE:0049328E                 call    ExpLookupHandleTableEntry
11. PAGE:00493293                 mov     esi, eax
12. PAGE:00493295                 test    esi, esi
13. PAGE:00493297                 jz      short loc_4932A9
15. PAGE:0049329A                 push    [esp+4+HandleTable]
16. PAGE:0049329E                 call    ExLockHandleTableEntry
18. PAGE:004932A5                 sbb     eax, eax
19. PAGE:004932A7                 and     eax, esi
20. PAGE:004932A9 loc_4932A9:                            
23. PAGE:004932AA ExMapHandleToPointer endp

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

1. PAGE:00493545 ExpLookupHandleTableEntry proc near    
4. PAGE:00493545 HandleTable     = dword ptr  0Ch
5. PAGE:00493545 Handle          = dword ptr  10h
9. PAGE:00493547                 mov     edi, [esp+Handle]
10. PAGE:0049354B                 mov     eax, 0FFh
11. PAGE:00493550                 mov     ecx, edi
12. PAGE:00493552                 mov     edx, edi
13. PAGE:00493554                 mov     esi, edi
14. PAGE:00493556                 shr     ecx, 12h
15. PAGE:00493559                 shr     edx, 0Ah
17. PAGE:0049355F                 and     ecx, eax
18. PAGE:00493561                 and     edx, eax
19. PAGE:00493563                 and     esi, eax
20. PAGE:00493565                 test    edi, 0FC000000h
21. PAGE:0049356B                 jnz     short loc_49358A
22. PAGE:0049356D                 mov     eax, [esp+HandleTable]
23. PAGE:00493571                 mov     eax, [eax+8]
24. PAGE:00493574                 mov     ecx, [eax+ecx*4]
25. PAGE:00493577                 test    ecx, ecx
26. PAGE:00493579                 jz      short loc_49358A
27. PAGE:0049357B                 mov     ecx, [ecx+edx*4]
28. PAGE:0049357E                 test    ecx, ecx
29. PAGE:00493580                 jz      short loc_49358A
30. PAGE:00493582                 lea     eax, [ecx+esi*8]
31. PAGE:00493585 loc_493585:                            
35. PAGE:0049358A loc_49358A:                                                      
36. PAGE:0049358A                 xor     eax, eax
37. PAGE:0049358C                 jmp     short loc_493585
38. PAGE:0049358C ExpLookupHandleTableEntry endp

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

2.   // static data ————————————  
3.   // non-static data ———————————
4.   /*<thisrel this+0x0>*/ /*|0x4|*/ unsigned long Flags;
5.   /*<thisrel this+0x4>*/ /*|0x4|*/ long HandleCount;
6.   /*<thisrel this+0x8>*/ /*|0x4|*/ struct _HANDLE_TABLE_ENTRY*** Table;
7.   /*<thisrel this+0xc>*/ /*|0x4|*/ struct _EPROCESS* QuotaProcess;
8.   /*<thisrel this+0x10>*/ /*|0x4|*/ void* UniqueProcessId;
9.   /*<thisrel this+0x14>*/ /*|0x4|*/ long FirstFreeTableEntry;
10.   /*<thisrel this+0x18>*/ /*|0x4|*/ long NextIndexNeedingPool;
11.   /*<thisrel this+0x1c>*/ /*|0x38|*/ struct _ERESOURCE HandleTableLock;  
12.   /*<thisrel this+0x54>*/ /*|0x8|*/ struct _LIST_ENTRY HandleTableList;
13.   /*<thisrel this+0x5C>*/ /*|0x10|*/ struct _KEVENT HandleContentionEvent;

По этим данным восстановим структуру таблицы хэндлов:

1. typedef struct _WIN2K_HANDLE_TABLE
5.     PHANDLE_TABLE_ENTRY **Table;
8.     LONG                  FirstFreeTableEntry;
9.     LONG                  NextIndexNeedingPool;
10.     ERESOURCE             HandleTableLock;
11.     LIST_ENTRY            HandleTableList;
12.     KEVENT                HandleContentionEvent;
13. } WIN2K_HANDLE_TABLE , *PWIN2K_HANDLE_TABLE ;

Из всего этого очевидно, что значение хэндла раскладывается на три части,
которые являются индексами в трехуровневой таблице объектов. Теперь посмотрим в
функцию ExLockHandleTableEntry:

1. PAGE:00492E2B ExLockHandleTableEntry proc near        
4. PAGE:00492E2B var_8           = dword ptr -8
5. PAGE:00492E2B var_4           = dword ptr -4
6. PAGE:00492E2B HandleTable     = dword ptr  8
7. PAGE:00492E2B Entry           = dword ptr  0Ch
10. PAGE:00492E2C                 mov     ebp, esp
15. PAGE:00492E32                 xor     ebx, ebx
16. PAGE:00492E34 loc_492E34:                                                                
17. PAGE:00492E34                 mov     eax, [ebp+Entry]
18. PAGE:00492E37                 mov     esi, [eax]
19. PAGE:00492E39                 test    esi, esi
20. PAGE:00492E3B                 mov     [ebp+var_8], esi
21. PAGE:00492E3E                 jz      short loc_492E89
22. PAGE:00492E40                 jle     short loc_492E64
23. PAGE:00492E42                 mov     eax, esi
24. PAGE:00492E44                 or      eax, 80000000h      // set WIN2K_TABLE_ENTRY_LOCK_BIT
25. PAGE:00492E49                 mov     [ebp+var_4], eax
26. PAGE:00492E4C                 mov     eax, [ebp+var_8]
27. PAGE:00492E4F                 mov     ecx, [ebp+Entry]
28. PAGE:00492E52                 mov     edx, [ebp+var_4]
29. PAGE:00492E55                 cmpxchg [ecx], edx
30. PAGE:00492E58                 cmp     eax, esi
31. PAGE:00492E5A                 jnz     short loc_492E64
33. PAGE:00492E5E loc_492E5E:                            
38. PAGE:00492E64 loc_492E64:              
39. PAGE:00492E64                 mov     eax, ebx
42. PAGE:00492E6A                 jb      loc_4BC234
43. PAGE:00492E70                 mov     eax, [ebp+HandleTable]
44. PAGE:00492E73                 push    offset unk_46D240 ; Timeout
45. PAGE:00492E78                 push    0               ; Alertable
46. PAGE:00492E7A                 push    0               ; WaitMode
47. PAGE:00492E7C                 add     eax, 5Ch
48. PAGE:00492E7F                 push    0               ; WaitReason
49. PAGE:00492E81                 push    eax             ; Object
50. PAGE:00492E82                 call    KeWaitForSingleObject
51. PAGE:00492E87                 jmp     short loc_492E34
52. PAGE:00492E89 loc_492E89:                        
54. PAGE:00492E8B                 jmp     short loc_492E5E
55. PAGE:00492E8B ExLockHandleTableEntry endp

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

1. void ScanWin2KHandleTable(PWIN2K_HANDLE_TABLE HandleTable)
4.     PHANDLE_TABLE_ENTRY Entry;
6.     for (i = 0; i < 0x100; i++)
8.         if (HandleTable->Table[i])
10.             for (j = 0; j < 0x100; j++)
12.                 if (HandleTable->Table[i][j])
14.                     for (k = 0; k < 0x100; k++)
16.                         Entry = &HandleTable->Table[i][j][k];
19.                           ProcessObject((PVOID)((ULONG)Entry->Object | WIN2K_TABLE_ENTRY_LOCK_BIT));

Эта функция перебирает все объекты в таблице и вызывает для каждого из них
функцию ProcessObject, которая определяет тип объекта и соответствующим образом
его обрабатывает. Вот код этой функции:

1. void ProcessObject(PVOID Object)
3.     POBJECT_HEADER ObjectHeader = OBJECT_TO_OBJECT_HEADER(Object);
5.     if (ObjectHeader->Type == *PsProcessType) CollectProcess(Object);
7.     if (ObjectHeader->Type == *PsThreadType)  ThreadCollect(Object);

Итак, с форматом таблицы объектов в Windows 2000 мы разобрались, теперь пора
приступить к ее разбору в Windows XP. Начнем с дизассемблирования функции
ExpLookupHandleTableEntry:

1. PAGE:0048D3C1 ExpLookupHandleTableEntry proc near    
4. PAGE:0048D3C1 HandleTable     = dword ptr  8
5. PAGE:0048D3C1 Handle          = dword ptr  0Ch
7. PAGE:0048D3C1                 mov     edi, edi
9. PAGE:0048D3C4                 mov     ebp, esp
10. PAGE:0048D3C6                 and     [ebp+Handle], 0FFFFFFFCh
11. PAGE:0048D3CA                 mov     eax, [ebp+Handle]
12. PAGE:0048D3CD                 mov     ecx, [ebp+HandleTable]
13. PAGE:0048D3D0                 mov     edx, [ebp+Handle]
15. PAGE:0048D3D6                 cmp     edx, [ecx+38h]
16. PAGE:0048D3D9                 jnb     loc_4958D6
18. PAGE:0048D3E0                 mov     esi, [ecx]
19. PAGE:0048D3E2                 mov     ecx, esi
20. PAGE:0048D3E4                 and     ecx, 3     // ecx — table level
21. PAGE:0048D3E7                 and     esi, not 3 // esi — pointer to first table
23. PAGE:0048D3ED                 jnz     loc_48DEA4
24. PAGE:0048D3F3                 lea     eax, [esi+eax*8]
25. PAGE:0048D3F6 loc_48D3F6:                            
27. PAGE:0048D3F7 loc_48D3F7:                            
30. PAGE:0048DEA4 loc_48DEA4:                            
32. PAGE:0048DEA5                 mov     ecx, eax
33. PAGE:0048DEA7                 jnz     loc_52F57A
35. PAGE:0048DEB0                 mov     ecx, [esi+ecx*4]  
36. PAGE:0048DEB3 loc_48DEB3:                            
37. PAGE:0048DEB3                 and     eax, 1FFh
38. PAGE:0048DEB8                 lea     eax, [ecx+eax*8]
39. PAGE:0048DEBB                 jmp     loc_48D3F6
40. PAGE:0052F57A loc_52F57A:                            
41. PAGE:0052F57A                 shr     ecx, 13h
42. PAGE:0052F57D                 mov     edx, ecx
43. PAGE:0052F57F                 mov     ecx, [esi+ecx*4]
44. PAGE:0052F582                 shl     edx, 13h
45. PAGE:0052F585                 sub     eax, edx
46. PAGE:0052F587                 mov     edx, eax
48. PAGE:0052F58C                 mov     ecx, [ecx+edx*4]
49. PAGE:0052F58F                 jmp     loc_48DEB3

Теперь посмотрим на структуру HANDLE_TABLE из дампа ntoskrnl.pdb:

2.  // static data ————————————
3.  // non-static data ———————————
4.   /*<thisrel this+0x0>*/ /*|0x4|*/ unsigned long TableCode;
5.   /*<thisrel this+0x4>*/ /*|0x4|*/ struct _EPROCESS* QuotaProcess;
6.   /*<thisrel this+0x8>*/ /*|0x4|*/ void* UniqueProcessId;
7.   /*<thisrel this+0xc>*/ /*|0x10|*/ struct _EX_PUSH_LOCK HandleTableLock[4];
8.   /*<thisrel this+0x1c>*/ /*|0x8|*/ struct _LIST_ENTRY HandleTableList;
9.   /*<thisrel this+0x24>*/ /*|0x4|*/ struct _EX_PUSH_LOCK HandleContentionEvent;
10.   /*<thisrel this+0x28>*/ /*|0x4|*/ struct _HANDLE_TRACE_DEBUG_INFO* DebugInfo;
11.   /*<thisrel this+0x2c>*/ /*|0x4|*/ long ExtraInfoPages;
12.   /*<thisrel this+0x30>*/ /*|0x4|*/ unsigned long FirstFree;
13.   /*<thisrel this+0x34>*/ /*|0x4|*/ unsigned long LastFree;
14.   /*<thisrel this+0x38>*/ /*|0x4|*/ unsigned long NextHandleNeedingPool;
15.   /*<thisrel this+0x3c>*/ /*|0x4|*/ long HandleCount;
16.   /*<thisrel this+0x40>*/ /*|0x4|*/ unsigned long Flags;
17.   /*<bitfield this+0x40>*/ /*|0x1|*/ unsigned char StrictFIFO:0:1;

И восстановим по нему описание структуры:

1. typedef struct _XP_HANDLE_TABLE
6.     EX_PUSH_LOCK             HandleTableLock[4];
7.     LIST_ENTRY               HandleTableList;
8.     EX_PUSH_LOCK             HandleContentionEvent;
9.     PHANDLE_TRACE_DEBUG_INFO DebugInfo;
13.     ULONG                    NextHandleNeedingPool;
17. } XP_HANDLE_TABLE, *PXP_HANDLE_TABLE;

Из приведенного кода очевидно, что функция ExpLookupHandleTableEntry
извлекает значение TableCode из структуры HANDLE_TABLE и в зависимости от его
двух младших бит определяет число уровней таблицы. Оставшиеся биты представляют
из себя указатель на таблицу первого уровня. Следовательно HANDLE_TABLE в
Windows XP может иметь от одного до трех уровней вложенности, при этом размер
таблицы на любом уровне равен 1FFh. При увеличении количества записей в таблице,
система может автоматически увеличить уровень вложенности. Очевидно, что второй
уровень таблица будет иметь при количестве записей большем 0x200, а третий
уровень — при количестве большем 0x40000. Производит ли система уменьшение числа
уровней таблице при освобождении объектов мне неизвестно, во всяком случае я
такого не наблюдал.

Функция ExLockHandleTableEntry в Windows XP отсутствует, поэтому код
производящий блокировку элемента таблицы находится в функции
ExMapHandleToPointer. Дизассемблируем эту функцию и посмотрим что же она
делает:

1. PAGE:0048F61E ExMapHandleToPointer proc near          
4. PAGE:0048F61E var_8           = dword ptr -8
5. PAGE:0048F61E var_4           = dword ptr -4
6. PAGE:0048F61E HandleTable     = dword ptr  8
7. PAGE:0048F61E Handle          = dword ptr  0Ch
9. PAGE:0048F61E                 mov     edi, edi
11. PAGE:0048F621                 mov     ebp, esp
15. PAGE:0048F626                 mov     edi, [ebp+Handle]
16. PAGE:0048F629                 test    di, 7FCh
17. PAGE:0048F62E                 jz      loc_4A2A36
21. PAGE:0048F637                 push    [ebp+HandleTable]
22. PAGE:0048F63A                 call    ExpLookupHandleTableEntry
23. PAGE:0048F63F                 mov     esi, eax
24. PAGE:0048F641                 test    esi, esi
25. PAGE:0048F643                 jz      loc_4A2711
26. PAGE:0048F649                 mov     [ebp+var_4], esi
27. PAGE:0048F64C loc_48F64C:                                                              
28. PAGE:0048F64C                 mov     ebx, [esi]
30. PAGE:0048F651                 mov     [ebp+var_8], ebx
31. PAGE:0048F654                 jz      loc_508844
32. PAGE:0048F65A                 lea     eax, [ebx-1]
33. PAGE:0048F65D                 mov     [ebp+Handle], eax
34. PAGE:0048F660                 mov     eax, [ebp+var_8]
35. PAGE:0048F663                 mov     ecx, [ebp+var_4]
36. PAGE:0048F666                 mov     edx, [ebp+Handle]
37. PAGE:0048F669                 cmpxchg [ecx], edx
38. PAGE:0048F66C                 cmp     eax, ebx
39. PAGE:0048F66E                 jnz     loc_50884C
40. PAGE:0048F674                 mov     eax, esi
41. PAGE:0048F676 loc_48F676:                            
44. PAGE:0048F678 loc_48F678:                          
48. PAGE:0048F67A ExMapHandleToPointer endp

После того, как функция ExpLookupHandleTableEntry возвращает указатель на
HANDLE_TABLE_ENTRY, проверяется младший бит поля Object, и если он не
установлен, то он сбрасывается, а если не установлен, то происходит ожидание его
установки. Следовательно при извлечении адреса объекта нам надо не устанавливать
старший бит (как в Windows 2000), а сбрасывать младший. С учетом вышесказанного
составим код сканирующий таблицу объектов:

1. void ScanXpHandleTable(PXP_HANDLE_TABLE HandleTable)
4.     PHANDLE_TABLE_ENTRY Entry;
5.     ULONG TableCode = HandleTable->TableCode & ~TABLE_LEVEL_MASK;
7.     switch (HandleTable->TableCode & TABLE_LEVEL_MASK)
10.           for (i = 0; i < 0x200; i++)
12.               Entry = &((PHANDLE_TABLE_ENTRY)TableCode)[i];
14.               if (Entry->Object) ProcessObject((PVOID)((ULONG)Entry->Object & ~XP_TABLE_ENTRY_LOCK_BIT));
19.           for (i = 0; i < 0x200; i++)
21.               if (((PVOID *)TableCode)[i])
23.                   for (j = 0; j < 0x200; j++)
25.                       Entry = &((PHANDLE_TABLE_ENTRY *)TableCode)[i][j];
27.                       if (Entry->Object) ProcessObject((PVOID)((ULONG)Entry->Object & ~XP_TABLE_ENTRY_LOCK_BIT));
34.           for (i = 0; i < 0x200; i++)
36.               if (((PVOID *)TableCode)[i])
38.                   for (j = 0; j < 0x200; j++)
40.                       if (((PVOID **)TableCode)[i][j])
42.                           for (k = 0; k < 0x200; k++)
44.                               Entry = &((PHANDLE_TABLE_ENTRY **)TableCode)[i][j][k];
47.                                 ProcessObject((PVOID)((ULONG)Entry->Object & ~XP_TABLE_ENTRY_LOCK_BIT));

Итак, с форматом таблиц объектов мы разобрались. Теперь для перечисления
процессов нам нужно найти сам адрес PspCidTable. Как вы уже догадались, искать
его мы будем дизассемблируя функцию PsLookupProcessByProcessId, в которой первый
call будет содержать адрес PspCidTable. А вот и код производящий
поиск:

6.     for (cPtr = (PUCHAR)PsLookupProcessByProcessId;
7.          cPtr < (PUCHAR)PsLookupProcessByProcessId + PAGE_SIZE;
10.         Length = SizeOfCode(cPtr, &pOpcode);
14.         if (*(PUSHORT)cPtr == 0x35FF && *(pOpcode + 6) == 0xE8)
16.             PspCidTable = **(PVOID **)(pOpcode + 2);

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

Получение списка процессов перехватом SwapContext.

Если в системе имеется процесс, то соотвестсвенно он будет иметь свои потоки.
Если нам удастся поймать переключение потоков, то можно будет по полученным
данным построить список процессов. Для начала кратко рассмотрим механизм
переключения потоков. Через определенные промежутки времени (10-15 мс) системный
таймер генерирует прерывание, которое вызывает планировщик и если квант времени
связанный с текущим потоком истек, то происходит переключение потоков. Само
переключение потоков выполняется неэкспортируемой функцией ядра SwapContext,
которую тем не менее можно найти в отладочных символах на ntoskrnl.exe. Эта
функция вызывается планировщиком при истечении кванта времени потока, либо при
ожидании потоком какого-либо события. В первом случае эта функция вызывается из
KiDispatchInterrupt, а во втором случае из неэкспортируемой функции находящейся
глубоко в недрах ядра, которая в свою очередь вызывается из
KeWaitForSingleObject, KeDelayExecutionThread и KeWaitForMultipleObjects.
Параметры функции SwapContext передаются в регистрах и имеют следующее
назначение: cl — определяет режим обработки APC, edi — указатель на поток
отдающий управление, esi — указатель на поток получающий управление, ebx —
указатель на PCR. Нас интересуют только указатели на переключающиеся потоки
передаваемые в регистрах esi и edi. Для начала нам нужно найти адрес функции
SwapContext. Для этого будем дизассемблировать KiDispatchInterrupt и искать код
следующего вида:

1. .text:00404E76                 call    sub_404C5A
3. .text:00404E7D                 call    SwapContext

Из этого участка мы и будем извлекать адрес SwapContext. Этот метод поиска
весьма надежен и универсален, так как позволяет найти SwapContext в любой
Windows, начиная он 2000 и заканчивая 2003 server включая все их сервиспаки. А
вот и код осуществляющий поиск SwapContext:

1. void GetSwapContextAddress()
6.     for (cPtr = (PUCHAR)KiDispatchInterrupt;
7.          cPtr < (PUCHAR)KiDispatchInterrupt + PAGE_SIZE;
10.         Length = SizeOfCode(cPtr, &pOpcode);
14.         if (*(PUSHORT)pOpcode == 0x01B1 && *(pOpcode + 2) == 0xE8)
16.             pSwapContext = (PVOID)(*(PULONG)(pOpcode + 3) + (ULONG)cPtr + 7);

После нахождения адреса SwapContext нам нужно ее перехватить. Единственный
возможный в этом случае способ — это сплайсинг ее кода. Для этого скопируем
первые несколько инструкций с перехватываемой функции в буфер, в его конце
поставим jmp на продолжение, а начало своей функции заменим на jmp на свой
обработчик. При этом если в копируемом в буфер коде нам встретятся команды
содержащие relative offset, то нужно их подкорректировать, иначе мы получим
неизбежный BSOD. Для установки и снятие таких хуков воспользуемся следующим
кодом:

1. #define MemOpen()  __asm cli; __asm mov eax, cr0; __asm mov oData, eax; \
2.                    __asm and eax, 0xFFFEFFFF; __asm mov cr0, eax;
3. #define MemClose() __asm mov eax, oData; __asm mov cr0, eax; __asm sti;
6. UCHAR SaveOldFunction(PUCHAR Proc, PUCHAR Old)
14.     Offset = (ULONG)Proc — (ULONG)Old;
18.         Size = SizeOfCode(Proc, &pOpcode);
19.         memcpy(oPtr, Proc, Size);
20.         if (IsRelativeCmd(pOpcode)) *(PULONG)((ULONG)pOpcode — (ULONG)Proc + (ULONG)oPtr + 1) += Offset;
25.     *(PUCHAR)((ULONG)Old + Result) = 0xE9;
26.     *(PULONG)((ULONG)Old + Result + 1) = Offset — 5;
31. PVOID HookCode(PVOID TargetProc, PVOID NewProc)
38.     Address = (ULONG)NewProc — (ULONG)Proc — 5;
40.     OldFunction = ExAllocatePool(NonPagedPool, 20);
41.     *(PULONG)OldFunction = (ULONG)Proc;
42.     *(PUCHAR)((ULONG)OldFunction + 4) = SaveOldFunction((PUCHAR)Proc, (PUCHAR)((ULONG)OldFunction + 5));
44.     *(PULONG)((ULONG)Proc + 1) = Address;
46.     return (PVOID)((ULONG)OldFunction + 5);
50. void UnhookCode(PVOID OldProc)
58.     Proc = (PUCHAR)(*(PULONG)((ULONG)OldProc — 5));
60.     SaveSize = *(PUCHAR)((ULONG)OldProc — 1);
61.     Offset   = (ULONG)Proc — (ULONG)OldProc;
63.     memcpy(Proc, OldProc, SaveSize);
65.     while (ThisSize < SaveSize)
67.         Size = SizeOfCode(Proc, &pOpcode);
68.         if (IsRelativeCmd(pOpcode)) *(PULONG)((ULONG)pOpcode + 1) -= Offset;
73.     ExFreePool((PVOID)((ULONG)OldProc — 5));

Сам обработчик SwapContext будет выглядеть так:

1. void __declspec(naked) NewSwapContext()

Метод сплайсинга несомненно легок и удобен, но при неправильном применении он
может создать весьма немало проблем. Опасными являются моменты установки и
снятия хуков, так как на многопроцессорной системе (либо на системе с
Hiperthreading процессором) другой поток может вызвать перехватываемую функцию в
когда патч ее кода еще не завершен. Давайте сделаем приблизительную оценку
величины этой вероятности. Средняя частота вызова этой функции на
двухпроцессорном Pentium 4 2400 была равна 785 вызовов в секунду. Допустим, что
патч начала функции занимает 0.01 мкс (на самом деле гораздо меньше), при этом
мы получаем вероятность радения системы равную 0,00000785, тоесть на 127380
запусков программы будет одно падение системы. Для такой программы как детектор
руткитов (который к тому же редко запускают), это вполне приемлемая величина, но
если подобный метод будет использоваться в постоянно применяемой программе
(например антивирусе), то использовать сплайсинг следует исключительно
однократно (установка хуков без их последующего снятия), и только в момент
загрузки системы (в boot драйвере). В этом случае вероятность падения системы
настолько приближена к нулю, что ее можно вообще не принимать в расчет. Пока что
я не наблюдал ни одного случая падения системы из за этой причины. Но существует
еще одна, гораздо более реальная причина нестабильности сплайсинга (и любых
другим методов хуков тоже). Если драйвер допускает выгрузку и при выгрузке
снимает хуки, то выгрузка может произойти в тот момент, когда какой-либо поток
находится внутри обработчика перехвата. Вероятность такого расклада зависит от
содержимого обработчика перехвата и от частоты вызова перехватываемой функции.
Практика показала, что вероятность падения системы при выгрузке драйвера
достаточно велика, и смириться с ней никак нельзя, но этого можно избежать, если
синхронизировать выгрузку драйвера с функцией обработчиком. А еще лучше —
сделать драйвер невыгружаемым, что избавит нас от тормозов при синхронизации.
Как вы видите, при правильном применении сплайсинг может быть абсолютно
безопасным, хотя непонимание его работы может привести к весьма неслабым глюкам,
так что используйте, но с осторожностью.

Приложение:

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

Файл	Описание
Process Hunter (266 кб)	Детектор скрытых процессов Process Hunter

© Ms-Rem