556
Kapitola 15 – Techniky analýzy škodlivého kódu
dows (stejně jako Windows z Windows, nebo Linux z Windows). To nám může hodně pomoci při práci se škodlivým kódem v uživatelském režimu. Je-li potřeba analyzovat rootkity nebo viry v režimu jádra za běhu, je nezbytné mít debugger, který dokáže trasovat kód v tomto režimu. Je velice málo dobrých debuggerů, které umí trasovat škodlivý kód, používající funkcionalitu režimu jádra. Mým oblíbeným debuggerem, který podporuje ladění v režimu jádra systémů Windows je SoftICE. Jeho jméno je odvozeno od výkonného debuggovacího zařízení na úrovni hardware, nazvaného jako ICE ("in-circuit emulator"). Předpona "Soft" pak naznačuje, že se jedná o debugger na úrovni softwaru, nikoli hardwaru. Systémy ICE obvykle používají další procesor a u běžícího procesu dokáží zobrazit detaily na úrovni mikrokódu. Jedná se o nejvýkonnější typ nástrojů pro ladění vůbec, jsou však extrémně drahá, čímž tak zůstávají mimo dosah většiny z nás. Řešení na úrovni software mohou být rovněž poměrně výkonná a SoftICE jistě takovým nástrojem je. Začal jsem jej používat už v dobách DOSu, ale úplně jsem mu propadnul, když jsem začal vyvíjet ovladače režimu jádra pro Windows NT. V roce 1996 byl velice potřebný, protože WinDGB od Microsoftu byl teprve v raném stadiu vývoje a často havaroval v různých situacích, které nastávaly při ladění. Havárie je přitom tou poslední věcí, kterou při ladění škodlivého kódu potřebujete. WinDBG naštěstí prošel dlouhým vývojem a jeho poslední verze jsou mnohem přátelštější. SoftICE může být velice užitečný v obtížných situacích, jako například při trasování kódu, který je upravený proti ladění. Jedná se například o trik, zabudovaný ve viru W95/CIH, který používá přechod do režimu jádra, založený na INT 3 (přerušení, které se využívá pro breakpointy), čímž debugger zastaví (viz kapitola 6 popisující základní obranné strategie virů). Tento trik může fungovat i ve standardním režimu SoftICE. Lze jej však obejít pomocí příkazu BPM (breakpoint on memory access) tohoto debuggeru, který nepoužívá breakpoint založený na INT 3, ale ladící registry. Tím, že není závislý na INT 3 jako podmínce přerušení, je lépe chráněn proti oklamání škodlivým kódem. V současné době však existuje mnoho dalších metod proti ladění škodlivého kódu (viz kapitola 6), které mohou být problémem i pro ty nejlepší debuggery, zejména tehdy, pokud si tuto skutečnost neuvědomujete a nedáváte na ni pozor. SoftICE je velice užitečný při zobrazování jmen API a v mnoha případech i jejich parametrů. Do systému je možné zavést další tabulku symbolů a s její pomocí rychleji prohlížet škodlivý kód. SoftICE je také výkonný při práci s triky, které souvisí se zachycováním výjimek, běžnými ve škodlivém kódu. Při práci s debuggerem v uživatelském režimu, jako Turbo Debugger, lze stopu takového kódu snadno ztratit, protože ovladače výjimek ve Windows spustí kód v režimu jádra, do kterého debugger nemůže umístit breakpoint. K trasování červa CodeRed v akci jsem používal SoftICE. Bylo to nutné pro pochopení útoku pomocí přetečení zásobníku, který byl založen na ovládnutí ovladače přerušení ve Windows. Virtuální debuggery, například Turbo Debugger v režimu V86, vám mohou pomoci trasovat agresivní DOSový kód, který je upravený proti ladění tak, že souvisle modifikuje vektor tabulky přerušení INT 1 a INT 3. Turbo Debugger jako obranu proti tomu používá ovladač, který přepíná procesor do režimu V86, aby spustil virtuální stroj, založený na CPU. Debuggery virtuálních strojů vás ovšem v mnoha případech nezachrání. Škodlivý kód totiž může testovat, kolik času uplynulo mezi dvěma instrukcemi, odhadnout, že pomocí debuggeru trasujete kód pomaleji a podle toho se zařídit. Tento režim debuggeru mě nicméně ovlivnil při návrhu systémů ladění na bázi emulace CPU pro lepší práci se škodlivým kódem, jak popisuji dále v této kapitole.