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

14. prosince 2001, 00.00 | Další díl seriálu Cracker proof zaměřený na tvorbu vlastního PE cryptoru. Dnes se podíváme na problematiku kódování.

Jak a čím kódovat?

Řekli jsme si, že základem PE cryptoru, je zakódování jednotlivých sekcí v souboru. Volbu kódovacího/dekódovacího algoritmu zcela ponechávám na vás a vaší fantazii. Osobně využívám algoritmu BlowFish - jednak pro jeho velkou rychlost a také pro to, že se jedná o source-free produkt. Implementaci není zas tak složitá a vy nemusíte ke své aplikaci přidávat spoustu DLL knihoven. Maximální délka klíče 448-bitů je dle mého názoru více než dostačující.
Často je také využívána vynikající kompresní knihovna aPLib, kterou mnozí z vás jistě dobře znají. 
Domnívám se ale, že pro základní výukové potřeby není moc vhodné používat složitější kódovací algoritmy. Pro začátek plně postačí obyčejný XOR, který potom zaměníte požadovaným kódováním.

Jak moc záleží na volbě kódovacího algoritmu

aneb mám se obávat pokusů o jeho prolomení?

Na tuto otázku je složité odpovědět. Je třeba znát alespoň úplné základy toho, jak cracker postupuje při "rozpakování" (uvedení souboru do stejné podoby, jakou měl před použitím PE cryptoru) souboru.
Cracker se nebude pokoušet a prolomení samotného kódování - samozřejmě nepředstavujete-li si pod pojmem zakódování např. zvětšení/zmenšení každého bajtu o jedničku.
Bez potřebných informací o souboru, kódovacím algoritmu a dekódovacím klíči je to téměř nemožné. Navíc by ještě musel zjistit spoustu jiných informací o souboru, aby ho vůbec bylo možné uvést do provozu.
Proto se musí cracker ponořit do samotného programového kódu. Aby to však mohl učinit, musí odstranit drtivou většinu anti-… prvků (anti-debugging,anti-breakpoint..) v režijním kódu. A proč by toho všeho pak nechával (a ještě zjišťoval další nepotřebné informace o klíčí, algoritmu..atd.) a pokoušel se o manuální dekódování?? Vždyť by si jenom přidělával práci! Naopak, počká až za něj veškeré potřebné operace (včetně dekódování) provede režijní kód. Co z toho tedy plyne??
Pokud vaše kódování nebude příliš (opravdu PŘÍLIŠ) primitivní a nebude tudíž patrné bez studia samotného režijní kódu, záleží spíše na kvalitě samotného režijního kódu než kódovacího algoritmu (a pokud i režijní kód bude příliš primitivní, tak už vám není pomoci :-)).
Prostě a jednoduše - pokud se poohlédnete na I-netu po nějakých rozumných kódovacích algoritmech, máte po problémech. Vzhledem k tomu, že několik dní strávíte nad tvorbou režijního kódu, není několik minut hledání na I-netu zas tak velkou časovou investicí - co říkáte.

Co kódovat a co ne?

Pokud žijete v představě, že všechno bezhlavě zakódujete a soubor zůstane funkční, tak jste na omylu. V podstatě by se dalo říct, že smíte "natvrdo" zakódovat většinu sekcí v souboru, z kterých nečerpá PE loader při načítání souboru žádná data.
Se sekcemi jako např. .rsrc, .edata...atd. už je to trochu složitější. Je třeba se vědět, jestli jejich zpracování provedete sami nebo ho necháte na PE loaderu. Podle toho se také odvíjí, zda-li je můžete kódovat, popř. jakou část. 
Mluvíme tu však příliš obecně, což není (zrovna v tomto případě) vhodné - situace se mění od sekce k sekci v závislosti na tom jestli a popř. jak s nimi naložíte. Těmto problémům se proto budeme věnovat až později, kdy se zaměříme na každou sekci zvlášť. Domnívám se, že by se zatím obecně dalo říct asi toto: 

1. Nekódujte sekce s nulovou hodnotou PointerToRawData nebo SizeOfRawData (např. sekce .bss). 
2. Sekce s tabulkou exportů (u exe souborů většinou .edata) a relokacemi (převážně .reloc) jsou z hlediska využitelnosti pro případného útočníka více či méně bezvýznamné (pokud se pletu, tak by mě opravdu zajímalo, jak je využít), takže pokud si zbytečně nechcete přidělávat práci, je lepší je nekódovat a nechat jejich zpracování na loaderu. 
3. Sekce s importovanými funkcemi (převážně .rdata…) a TLS (.tls) s největší pravděpodobností budete muset zpracovat sami, sekce s resoursy (.rsrc…) pokud se vám chce. 

Jak už jsem ale říkal - je třeba si vše ukázat na jednotlivých situacích.