Ochrana před debuggingem – standardy - Builder.cz - Informacni server o programovani

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

29. května 2001, 00.00 | Pokračování seriálu o ochraně vašeho software před crackery. Dnes navážeme na minulý díl a podíváme se na
standardní způsoby detekce aktivního debuggeru.

Nebudeme se zbytečně zdržovat a hned navážeme na minulý díl.

Mezi dnes již standardní a běžně používané způsoby detekce SoftIcu je používání jeho vlastních metod. SoftIce totiž obsahuje funkce, s jejichž pomocí ho můžete částečně ovládat i z jiných programů. Mezi ty nejznámější patří tzv. BCHK (BoundsChecker) interface a FGJM interface. A jak to celé pracuje?? Velice jednoduše - pokusíme se využít tyto funkce a pokud nám k nim nebude umožněn přístup, znamená to, že SoftIce není aktivní; pokud ano, tak nejenom, že SoftIce je aktivní, ale můžeme využít jejich služeb i pro naše potřeby.

Zde je ukázka k BoundsCheckeru:
V asembleru: 

1. push EBP; //pro jistotu uložíme EBP 2. mov EBP,04243484B; // (HEX)4243484B = (ASCII)BCHK  3. mov AL,00; //AL obsahuje požadovanou funkci 4. INT 3 5. pop EBP; //obnovení EBP

Pokud programujete v C++, můžete využít direktivy __asm:

#define BCHK \ __asm { _emit 0x55 };\ __asm { _emit 0xbd };\ __asm { _emit 0x4b };\ __asm { _emit 0x48 };\ __asm { _emit 0x43 };\ __asm { _emit 0x42 };\ __asm { _emit 0x66 };\ __asm { _emit 0xb8 };\ __asm { _emit 0x00 };\ __asm { _emit 0x00 };\ __asm { _emit 0xcc };\ __asm { _emit 0x5d };\

Pak už jen kamkoli v kódu napište BCHK a provede se výše zmiňovaný kód (postupně použiji více způsobů používání ASM v C++ - nelekněte se proto, všechny jsou ekvivalentní a vy si můžete vybrat, který je vám nejpříjemnější). 

Jak to vlastně celé funguje? 
Obecně řečeno: Zavoláme INT 3 - pokud je SoftIce aktivní, toto volání zpracuje a prověří, jestli není náhodou určeno jemu (jsou zadány správné hodnoty v registrech - v EBP BCHK a v AL 0) - pokud ano, zpracuje ho a již nedojde k chybě programu, která by jinak voláním INT 3 nastala (byl by totiž zpracován systémem).
Teď si asi říkáte: "Co když nebude SoftIce aktivní - dojde pak k chybě v programu a ten se ukončí!". Samozřejmě, že máte pravdu - nesmíme proto zapomenou ještě před tím zavolat API funkci SetUnhandledExceptionFilter, která místo zobrazení chybové hlášky provede vámi požadovaný kód. Ukázkový příklad si samozřejmě můžete stáhnout, proto již nebudu uvádět programový kód.

Také druhý zmiňovaný FGJM interface pracuje na stejném principu - jen se používají jiné registry a hodnoty. Požadovanou službu interfacu obsahuje registr AX:

__asm { mov AX,0912h }; //AX obsahuje požadovanou službu __asm { mov SI,4647h }; //(HEX)4647 = (ASCII)FG __asm { mov DI,4A4Dh }; //(HEX)4a4d = (ASCII)JM __asm { _emit 0xCC };

Možná si teď říkáte, co je to vlastně ta "požadovaná služba", která se ukládá do AL respektive AX. To je jednoduché - vždy se jedná o nějaké číslo reprezentující příslušnou funkci daného interfacu - například spuštění příkazu debuggerem, informace o breakpointech…atd. Možností je opravdu mnoho - já jsem zvolil pouze bezvýznamné funkce (aby je SoftIce zpracoval), ale vy nemusíte. Pomocí některých funkcí můžete zjistit velice užitečné informace - v tom případě bych vám doporučil např. vynikající Ralf Brown's Interrupt List (kompletní refere všech INTů snad pro všechny známé i neznámé programy) nebo SoftIce Internals od +Spath (kompletní reference INTů pro SoftIce).

Ovšem crackeři jsou vždy o krok před námi a tak se čas od času můžete setkat se SoftIcem, jehož tzv. magické hodnoty (BCHK a FGJM) byly změněny. Pokud pak narazíte na systém, kde je SoftIce nainstalován ( můžete použít již zmiňovanou metodu s autoexecem), ale volání na kterýkoli interface neodpovídá, fulltextově prohledejte celý soubor winice.exe a hledejte například string KHCB, jestli není náhodou změněn (pozpátku - pořadí v zásobníku).

Můžete klidně znemožnit spuštění vašeho programu, i když je debugger jen nainstalován a není spuštěn - v takovém případě bych však zvážil všechna pro a proti - přece jen můžete poškodit někoho, kdo má debugger nainstalován a nepoužívá ho. 

Vůbec dobrý nápad je prohledat celý disk a hledat soubor winice.exe a potřebné DLL knihovny. Bohužel to může být časově dost náročné…. - třeba u instalace to ale není zas tak špatný nápad.

Fantazii se meze nekladou a to jak na naší straně, tak i na straně crackerů :-((.

To by tak pro dnešek stačilo a příště si ukážeme nějaké další možnosti v oblasti debuggingu.