Ochrana před debuggingem - detekce hardwarových breakpointů - Builder.cz - Informacni server o programovani

Navigace:  » Úvodní stránka  » Rubriky  » Assembler  

21. června 2001, 00.00 | Další díl seriálu o ochraně vašeho software před crackery. V minulém díle jsme se naučili bránit softwarovým breakpointům. V dnešním díle navážeme a ukážeme si, co dělat s hardwarovými..

V minulém díle jsme se naučili bránit softwarovým breakpointům. V dnešním díle si ukážeme, co dělat s těmi již zmíněnými hardwarovými.
Jak již bylo řečeno v minulém díle, tyto breakpointy se ukládají do tzv. debuggových registrů přímo v CPU. 
Tímto faktem se nemusíte vůbec zatěžovat v případě, že použijete k jejich detekci funkce samotného SoftIcu - o této problematice jsme již hovořili v minulých dílech (FGJM interface) a pokud jste si stáhli mnou doporučené dokumentace (není možné vše napsat do tohoto seriálu - tato dokumentace má více jak 8MB čistého textu!!!), mohli jste tuto metodu s úspěchem vyzkoušet. Bohužel (bohudík:-))) jsem však přišel na to, že na některých BETA verzích SoftIcu (třeba na té mé…) tato metoda nefunguje. Proto bych ji já sám moc nedoporučoval. Raději zjistíme dané informace přímo z CPU.

Debuggové registry

Debuggové registry jsou definovány ve struktuře CONTEXT jako DWORDy Dr0-Dr3, Dr6 a Dr7:

typedef struct _CONTEXT { …. DWORD Dr0; DWORD Dr1; DWORD Dr2; DWORD Dr3; DWORD Dr6; DWORD Dr7; ….. } CONTEXT;

SoftIce využívá jen registry Dr0-Dr3.
Pokud programujete v ASM, můžete vyzkoušet následující příklad pro přístup k debuggovým registrům:

MOV Ebx, Dr1

Sami uvidíte, že dojde k chybě, protože tyto instrukce lze provádět jen v určitých Ring módech procesoru (konkrétně v Ring0). Samozřejmě, že mezi nimi můžete přepínat a uvést tak do chodu výše zmiňovaný příklad, ale vzhledem ke stabilitě vaší aplikace na různých verzích Windows to asi nebude to nejlepší řešení.
Proto doporučuji využití tzv. SEHu - tedy Structured Exception Handlingu. Tato metoda využívá toho, že každá chyba, která vznikne v programu s sebou nese spoustu velmi užitečných informací - od druhu chyby (struktura EXCEPTION_RECORD) až po hodnoty všech registrů, včetně těch debuggových (struktura CONTEXT) (no…, ve skutečnosti je problematika SEHu daleko, daleko složitější, neobviňujte mě proto za to, že jsem uvedl nepřesné informace - pro naši věc to bohatě stačí).. 
Ve světě operačních systémů, které podporují multitasking však není nic tak jednoduché, jak by se zdálo. Každá aplikace má své vlastní prostředky a pokud způsobíte v programu nějakou chybu, následně ji opravíte a ze získaných struktur zkontrolujete obsah debuggových registrů, kontrolujete pouze obsah registrů dané aplikace. To ale nestačí - my musíme zkontrolovat registry aplikace jiné (v našem případě SoftIcu).

Řešení

Naše aplikace zaplní debuggové registry vlastními daty, resp. adresami, na které se tím pádem nastaví hardwarový breakpointy. Jednoduše řečeno - aplikace nastaví breakpointy sama na sebe (myslím, že není třeba upozorňovat vás na to, že si k tomuto účelu musíte v programu vytvořit prostor). 
Pak zkontrolujeme, jestli k nim došlo - pokud ne, byly přerušeny breakpointy nějaké "nadřazené" aplikace - tedy debuggeru! 
Stejně bych vám ale doporučil trochu se obeznámit s problematikou SEHu a se všemi možnostmi, které přináší. Zde najdete snad všechny opravdu dobré materiály, které se dají na INTERNETU sehnat (Greetz go to EliCZ). Pokud patříte mezi "anti-angličany" nebo se vám prostě nechce, nevadí - v přespříštím díle si řekneme něco víc o dalších možnostech využití SEHu k ochraně softwaru.

Zde si stáhněte ukázkový příklad výše zmiňované metody - kompletní vysvětlení toho, jak pracuje najdete v příštím díle.