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

Odběr fotomagazínu

Fotografický magazín "iZIN IDIF" každý týden ve Vašem e-mailu.
Co nového ve světě fotografie!

 

Zadejte Vaši e-mailovou adresu:

Kamarád fotí rád?

Přihlas ho k odběru fotomagazínu!

 

Zadejte e-mailovou adresu kamaráda:

Soutěž

Sponzorem soutěže je:

IDIF

 

Ve kterém roce se narodil autor fotografií z výstavy "Ostravská periferie"?

V dnešní soutěži hrajeme o:



Assembler

Anti-code editing

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.

Obsah seriálu (více o seriálu):

Tématické zařazení:

 » Rubriky  » Assembler  

 

 

 

Nejčtenější články
Nejlépe hodnocené články

 

Přihlášení k mému účtu

Uživatelské jméno:

Heslo: