aneb jak obyčejné aplikace komunikují s jádrem operačního systému

Se zkratkou SSDT se můžete setkat v některých bezpečnostních aplikacích (např. Rootkit Unhooker). Protože tato písmena jsou pro většinu lidí pravděpodobně nicneříkající, rozhodli se programátoři některých bezpečnostních programů místo toho použít název "System Services" či něco podobného.

Tento název, ač vypadá srozumitelněji, však žádné vysvětlení nedává a navíc může být i zavádějící - SSDT totiž s aplikacemi zvanými "služby" nemá vůbec nic společného.

Jak již víte z podnadpisu, SSDT hraje zásadní úlohu při komunikaci aplikací (jako MS Office, ICQ) s jádrem operačního systému. Než se však dostaneme k samotné podstatě této veledůležité struktury, musíme si říci něco o tom, jak vůbec aplikace své požadavky jádru formulují a sdělují.

Uvažujme aplikaci, která chce zapsat nějaká data na disk. Soubor je již otevřený, stačí jen data zapsat. K tomu se používá funkce rozhraní API s názvem WriteFile, která je obsažena v knihovně kernel32.dll. Aplikace jen určí, co se má zapsat do jakého souboru a dál se o nic nestará. Na operačním systému je, aby tuto činnost vykonal.

Pokud se podíváme na funkci WriteFile podrobněji (například pomocí disassembleru), zjistíme, že toho moc neprovádí. Po určité manipulaci s parametry zavolá podprogram s názvem NtWriteFile.

NtWriteFile je součástí knihovny ntdll.dll. Když se podíváme i na jiné funkce z kernel32.dll, zjistíme, že také končí voláním některé funkce z ntdll.dll. To v nás může vyvolávat dojem, že ntdll.dll je spodnější vrstvou (nejen) pod kernel32.dll. A ten dojem je správný. Podívejme se tedy, jak vypadá NtWriteFile.

NtWriteFile je opravdu velmi jednoduchá funkce. Do registru EAX uloží nějaké číslo a do registru EDX adresu, kde jsou uloženy parametry. Potom se provede instrukce SYSENTER (na starších Windows je to INT 0x2E). A to je vše. Když se podíváme i na další funkce začínající prefixem "Nt", zjistíme, že vypadají velmi podobně - do EAX dosadí nějaké číslo, do EDX adresu parametrů a pak následuje SYSENTER nebo INT 0x2E. NtXXX funkce jsou jenom jakési "stuby", které přes SYSENTER nebo INT 0x2E předají řízení jádru operačního systému.

Jádro operačního systému dostane od aplikace tedy jen dvě informace - typ požadavku (v registru EAX) a adresu, kde jsou uloženy parametry (v registru EDX). Jádro zkontroluje validitu parametrů a podívá se, jestli může provést úkol, který je specifikován číslem v registru EAX. Pokud vše dopadne dobře, příjde řada na SSDT.

System Service Descriptor Table (SSDT) je struktura, která popisuje další dvě struktury - Service Dispatch Table (SDT) a Service Parameter Table (SPT). SDT je pole adres různých funkcí jádra. Každá funkce je volána jen pro určitý typ požadavku. SPT o každé z těchto rutin uvádí počet parametrů - ten je stejný jako u NtXXX funkcí v ntdll.dll.vJednotlivé funkce, jejichž adresy se nachází v SDT jsou označovány jmény příslušných NtXXX funkcí.

Jádro tedy ověří správnost parametrů a zkopíruje je do své paměti. Potom se podívá do System Service Descriptor Table, zda požadavek v registru EAX může být splněn (jestli existuje nrutina v SDT, která daný typ požadavku "vyřizuje"). Tato kontrola je velmi jednoduchá - porovná se velikost pole SDT (počet prvků) s velikostí registru EAX. Pokud je EAX menší než počet prvků v poli SDT, dojde k volání rutiny, jejíž adresa se nachází v prvku s indexem EAX. Z SPT se systém dozví, kolik má vybraná rutina parametrů, takže kód, který toto zařizuje, může být pro všechny rutiny ze SDT stejný. Po vykonání příslušné rutiny je řízení opět předáno normálním procesům.

Z tohoto popisu vidíte, jak je SSDT důležitá struktura, protože její změna může velmi ovlivnit chování normálních programů. Tohoto faktu často využívají rootkity a jiný malware - přesměrují některou z rutin v SDT na svůj kód, čímž snadno zajistí skrytí procesu, souboru, klíče registru atd. Ovšem i bezepčnostní aplikace mění SDT (i samu SSDT) za účelem vlastní ochrany či monitorování systému.

"SSDT háky" (tak se někdy říká změnám v SSDT) jsou sice jednoduché na implementaci, efektivní, leč mají jednu nevýhodu - lze je poměrně snadno objevit, stačí jen číst paměť. A zabránit ve čtení paměti není vůbec lehká záležitost, ačkoliv i takové techniky existují.

Jak zjistit adresu SSDT

Adresu SSDT zjitíme velmi jednoduše, je totiž exportována hlavním modulem jádra (většinou ntoskrnl.exe) pod názvem KeServiceDescriptorTable. Existuje však ještě "jiná" SSDT, které se říká KeServiceDescriptorTableShadow. Ta se nachází v ovladači win32k.sys. Tato "stínová" tabulka je polem struktur SSDT, přičemž standardně toto pole obsahuje dvě struktury (i "klasickou" SSDT pod symbolem KeServiceDescriptorTableShadow lze chápat jako pole struktur SSDT, které obsahuje za normálních okolností pouze jedno položku). První struktura je stejná jako v hlavním modulu jádra, druhá obsahuje informace o jiné tabulce obslužných rutin jádra. Jsou to rutiny komponent GDI a USER (práce s okny, kreslení atd.). Aplikace tyto rutiny nevolají přes ntdll.dll, ale přímo přes gdi32.dll, user32.dll či jiné knihovny. Ale jak systém pozná podle registru EAX, že má zavolat nějakou rutinu ze "stínové" SDT? Velmi jednoduše - v EAX je nastaven speciální příznak (bit).

Zajímavá otázka může také být, jakou SSDT strukturu procesy a vlákna používají. Odpověď je následující: každé vlákno po svém vzniku používá SSDT z hlavního modulu jádra. Jakmile však jednou zavolá funkci USER nebo GDI, začne používat SSDT z win32k.sys a to tak dlouho, dokud nezanikne. Každé vlákno si uchovává svoji aktuálně používanou SSDT v položce ServiceTable ve své struktuře ETHREAD.

Závěr

Doufám, že tento článek vám osvětlil, co to SSDT je a jak je důležitá. Neuvádím zde, jakou má SSDT strukturu, protože cílem tohoto článku není napsat kód, který by s touto strukturou prováděl nějaké vylomeniny, ale obecné poučení.