Poslední poznámky k SEHu - Builder.cz - Informacni server o programovani

18. července 2001, 00.00 | Pokračování seriálu o ochraně vašeho software.
V minulých dílech jsme úspěšně nakousli problematiku SEH, v souvislosti s metodami, které záměrně vyvolávají v programech chyby, aby se dostali k důležitým datům. Dnes tuto problematiku dokončíme.

V minulých dílech jsme úspěšně nakousli problematiku Structured Exception Handlingu, v souvislosti s metodami, které záměrně vyvolávají v programech chyby, aby se dostali k důležitým datům. Pokud jste pozorní čtenáři a sledujete tento seriál pravidelně, mohli jste si při zkoušení příkladů z minulých dílů všimnou některých velice zajímavých věcí , ke kterým se dá SEH ještě využít.

Pamatujete si ještě na tento řádek z minulého dílu?

pexcept_point->ContextRecord->Eip +=1;

Přidal hodnotu 1 k registru Eip, který ukazuje na poslední zpracovanou instrukci v programu a tím odstranil vzniklou chybu v programu. V podstatě tím "chybnou" instrukci přeskočil.
Možná už vás to teď taky napadlo - nejsme nikterak limitování v adrese, na kterou registr EIP přepíšeme. Dalo by se tím tedy říct, že můžeme libovolně přeskakovat při zpracovávání instrukcí v programu. Pokud tedy chybu, kterou nejdříve musíte způsobit, dobře zamaskujete ostatním kódem, můžete třeba přeskočit z funkce A do funkce B tak, aniž by si toho někdo na první pohled všiml (samozřejmě ne v deseti-řádkovém kódu, k získání požadované adresy můžete použít postup z minulé ukázky).
Možná jste si také při debuggování příkladu z minulého dílu všimli něčeho opravdu zajímavého. Jakmile jste debuggerem najeli na instrukce NOP, na které byly nastaveny breakpointy, nemohli jste pak již pokračovat v single-stepování - debugger se jaksi "zasekl".
Této chybičky můžeme využít. Mezi důležitý kód lze vkládat zcela nesmyslné a bezvýznamné instrukce (NOP či MOV X,X nebo kombinace INC X a DEC X..atd.), na které budete nastavovat handlované breakpointy, čímž velice ztížíte debuggování programu.
A nejenom to - určitě jste si také všimli faktu, že při debuggování algoritmů využívajících SEH, nedochází díky aktivnímu debuggeru ke zpracování SEH handleru. Můžete toho využít např. při psaní anti-tracing a anti-debugging algoritmů. Samozřejmě, že zkušenějšího útočníka na tyto praktiky asi jen těžko nachytáte, ale začátečníkům to zcela jistě zamotá hlavu.
Nikdy však nezapomínejte, že luxus, s kterým SEH využíváte, můžou crackeři využít i proti vám. Např. u komerčních ochran ARMADILLO či VBox bylo k odhalení debuggeru využito kombinace volání INT3 a API funkce SetUnhandledExceptionFilter - tento způsob byl detailně popsán v jednom z minulých dílů, ale jen pro připomenutí - pokud nedošlo k chybě v programu voláním INT3, zpracoval toto volání debugger => byl aktivní. Bohužel však program nerozlišoval, k jaké chybě konkrétně došlo a tak pro obejití této ochrany stačilo paradoxně vyvolat v programu jakoukoli jinou chybu (většinou se používalo obyčejné dělení nulou) a ochrana byla zneškodněna. Proto vždy dobře propracujte svůj exception handler.
Pokud chcete svou ochranu softwaru založit na využití SEHu, zvažte využití několikanásobných exception handlerů (handler na handler na handler…). Zkoumat, jak pracují handlery, které si mezi sebou předávají složité struktury (třeba i zašifrované) a kód se generuje např. podle kódu vzniklé chyby už opravdu není zábava. Natož pak v assembleru!! Vše potřebné k tomuto tématu naleznete v nápovědě k C++ (nebo co to vlastně používáte).
Ale jak už však dnes platí snad o všech formách ochrany softwaru - nespoléhejte jen na SEH jako na hlavní pilíř celé ochrany (i když je na něm založena většina dnešních ochran).
Myslím, že to by k SEHu bohatě stačilo a příště již načneme novou kapitolu - ukážeme si, jak se bránit statickému rozkladu na assembler, tzv. disassemblingu.