Anti-code editing - Builder.cz - Informacni server o programovani

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

21. září 2001, 00.00 | Několik rad, jak se bránit před před editování kódu vašeho programu.

Prázdniny skončily, škola začala, ale to nic nemění na tom, že je tu další díl seriálu Cracker Proof. V dnešním díle se zaměříme na algoritmy znesnadňující editaci samotného programového kódu.
V podstatě lze program "patchnout" (editovat programový kód) dvěma základními způsoby - přímo(na HDD..) a v paměti.
Pokud je program editován přímo na disku, je využito nějakého hexadecimálního editoru a následné změny jsou uloženy přímo do souboru.
Pokud je program editován až v paměti (nejčastěji API funkcí WriteProcessMemory), přepisuje se pouze dané místo v paměti, kam je program nahrán - nikoli však samotný soubor.
Možná se teď ptáte jaký je v těchto způsobech rozdíl. Uvedu jednoduchý příklad z minulosti - kdysi dávno (ne.., zas tak dávno to nebylo) softwarový vývojáři ve snaze zabránit patchování jejich softwaru začali používat kontrolu integrity dat tak jak tomu bylo například při komprimaci dat nebo při přenosu dat přes internet. 
Celá ta nádhera fungovala docela obstojně - nejdříve byla zavolána API funkce CreateFileA, následně ReadFile a poté vypočítán kontrolní součet z načtených dat. Bohužel si nikdo neuvědomoval, že data jsou načítána z disku a nikoli z paměti. Proto stačilo jen počkat, až se program nahraje do paměti a zde změnit požadovaná místa - programům, které to dělají za vás se většinou říká loadery. A to ani nemluvím o tom, jak bylo a je snadné lokalizovat API funkci CreateFileA a vše uvést "do pořádku".
Tuto chybu obsahovala také neblaze známá komerční "try-buy" ochrana Sales Agent (např. Norton Utilities, produkty firmy Macromedia….atd.) a mnoho dalších. 
Proto se v dnešních moderních ochranách setkáte spíše s kontrolou integrity (často taky nazývanou jako CRC check) paměti. Tato metoda přináší několik výhod - tou hlavní je, že pokud jsou v paměti nastaveny nějaké softwarové breakpointy (tj. data jsou přepsána na hodnotu CC hex.) jsou bez problému nalezeny.
V dnešní době existuje řada výpočetních algoritmů pro kontrolu integrity dat - nejčastěji se můžete setkat s algoritmem CRC-32 (cyclic redundancy check; samozřejmě existuje také jeho 16-ti bitová verze s názvem CRC-16). Jeho implementace si můžete stáhnout odkudkoli z I-netu.
Osobně se ale domnívám, že je tento algoritmus pro rychlou a jednoduchou kontrolu v proti-pirátské ochraně nevyhovující. 
Obecně totiž nezáleží na dokonalosti tohoto algoritmu, ale spíše na tom, jak dobře ho ukryjete. Nemyslete si totiž, že když ho útočník najde, bude zkoumat, jak úžasně a dokonale pracuje:-))
Zde je implementace velice jednoduchého, ale zato rychlého algoritmu pro výpočet integrity dat:

mov ecx, délka dat mov edi, odkud začít xor eax,eax  xor ebx,ebx  xor esi,esi Looop: mov al,byte ptr [edi] mul esi add ebx,eax  inc edi inc esi loop Looop //--> ebx = checksum

Dle mého názoru je tento algoritmus pro využití v proti-pirátské ochraně plně dostačující. Samozřejmě má posloužit spíše jen jako inspirace.
Teď se ovšem nabízí jedna otázka - co dělat s vypočítaným checksumem….jistě, můžete pouze porovnat správný a právě vypočítaný checksum, ale pamatujte si - vždycky je lepší něco využít než to prostě porovnat. Můžete třeba správným checksumem něco zakódovat a pak to vypočítaným checksumem dekódovat. Pro útočníka se tak odstranění CRC checku stává mnohem složitější.
Je třeba se také zmínit o v dnešní době čím dál tím více populárních PE cryptorech, které chrání kód programu před editací tím, že ho prostě zakódují a dekódují až při jeho spuštění. To je však poněkud obsáhlé téma a konec konců to uvidíte sami, až si (po několika dalších dílech) naprogramujete svůj vlastní PE cryptor.
Pro dnešek je to všechno - příště se podíváme na "neblaze" proslulý program FrogIce a řekneme si, jak se mu bránit.