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

5. června 2001, 00.00 | Jedním z nejčastějších způsobů, jak se dostat co nejblíže k požadovanému algoritmu v programu je detekce určitého volání pomocí breakpointů. Obrana před touto činností není lehká, ale ani nemožná..

V dnešním díle našeho seriálu si ukážeme, jak detekovat nastavené breakpointy. 

Nevíte co je to breakpoint a k čemu je vám dobrý?? 

Jedním z nejčastějších způsobů, jak se dostat co nejblíže k požadovanému algoritmu v programu (nejčastěji toho ochranného) je "odchytit" si nějaké volání programu. Právě k tomuto "odchycení" nám slouží tzv. breakpointy - jedná se v podstatě o příkaz debuggeru, který zajistí, aby se po dosažení určitého programového kódu debugger automaticky objevil a přerušil tím běh programu. Nejjednodušeji se samozřejmě odchytávají volání programu k OS (ve WINDOWS to nejčastěji bývají API funkce), protože je nám ochotní programátoři velmi dobře zdokumentovali. Díky tomu se cracker dostane přesně tam, kam potřebuje a odtud už si může zadávat breakpointy třeba na funkce samotného programu. Sami vidíte, že to není nic příjemného, protože právě díky breakpointům se cracker během chvilky může dostat přímo k vašemu ochrannému algoritmu.

Jak tomu ale zabránit?? Odpověď na tuto otázku je poněkud složitější.

Breakpointů je totiž více druhů, v zásadě je ale můžeme rozdělit na softwarové a hardwarové.
Softwarové jsou např. již ty zmiňované breakpointy na API (a jiné) funkce, přerušení ..atd. Ty se ukládají přímo do softwaru (čtěte dál..) a jdou proto poměrně snadno detekovat. S těmi hardwarovými je to ovšem horší. K jejich ukládání se používají tzv. debuggové registry přímo v CPU - tímto druhem breakpointů se však bude zabývat celý příští díl.

Softwarové breakpointy

Trocha teorie: SoftIce místa v programu, kde jsou nastaveny softwarové breakpointy přepisuje voláním INT 3 (populární J) - pomocí toho pak pozná, že má přerušit běh programu. Při spuštění je pak tato hodnota přepsána zpět na tu původní.
My tedy jen zkontrolujeme, jestli není nějaký bajt (v ukázce kontrolujeme 5 bajtů) vybrané funkce, paměťové lokace… (kontrolujeme API funkci WriteProcessMemory) přepsán v paměti na CC - tedy INT 3.

HMODULE handle = GetModuleHandle("Kernel32"); FARPROC pamet = GetProcAddress(handle,"WriteProcessMemory"); //pozn.-pokud např. budete kontrolovat paměťovou lokaci ve vašem programu (..atd.) a znáte ji, není třeba uvádět předešlý kód   byte pMem[4];   memcpy(&pMem,pamet,sizeof pMem);   for (int i = 0;i < 5; i++)    {    if (pMem[i] == 0x0CC)     {     MessageBox("Breakpoint found…",NULL,MB_OK);     return;    }   } MessageBox("No Breakpoints found",NULL,MB_OK);

Využití API funkce GetProcAddress k získání adresy funkce není však jediným způsobem, jak tuto adresu získat - můžeme ji také dostat z PE hlavičky souboru. O tom si však řekneme více až v budoucnu (už se těším…:-))).

Samozřejmě si upravte algoritmus (název API funkce…) podle svých požadavků - pokud naleznete nastavený breakpoint můžete třeba využít chyby procesorů řady Pentium a způsobit chybu programu:

/*******Pentium MMX Bug*******/ __asm { _emit 0x75 }; __asm { _emit 0x00 }; __asm { _emit 0xF0 }; __asm { _emit 0x0F }; __asm { _emit 0xC7 }; __asm { _emit 0xC8 };

V žádném případě však o tom neinformujte uživatele pouhým MessageBoxem (Markova pravidla…) - způsobů, jak poněkud drasticky ukončit běh programu je opravdu mnoho - myslím si, že vás určitě napadne něco originálnějšího.

Dalším způsobem jak se vypořádat s nastaveným breakpointem, je při prvním spuštění programu uložit několik bajtů z každé kontrolované API funkce. Pokud je pak nalezen aktivní breakpoint, je hodnota CC přepsána na původní hodnotu - breakpoint se tak nezpracuje a cracker se může jen divit.

Příště si řekneme něco a hardwarových breakpointech a o tom, jak se jim bránit.
Jako vždy si můžete stáhnou ukázkový příklad.