Manipulace s výsledky internetových soutěží (4)
Zdroj: SOOM.cz [ISSN 1804-7270]Autor: .cCuMiNn.
Datum: 9.8.2011
Hodnocení/Hlasovalo: 1.3/20
Kdyby bylo vždy možné podívat se flashovým souborům pod kapotu a ze zdrojových kódů vyčíst, jak je vytvářen kontrolní hash, měli by se nepoctiví hráči jako prasata v žitě. Je tu ovšem jedno "ale"...
Vývojáři flashových her jsou si totiž někdy dobře vědomi praktik těchto nepoctivých hráčů a při programování používají techniky obfuskace kódu. Když se pak běžný smrtelník ke zdrojáku dostane, stejně se z něj nic nedozví, protože mu nebude rozumnět. Pod obfuskací kódu si představ jeho zmatení a znepřehlednění. Rozluštit takový kód je tak často skutečným oříškem.
Je pochopitelné, že psát kód přímo ve zmatené podobě by bylo pro vývojáře dosti nepraktické a jen málokdo z nich by toho byl vůbec schopen. K dispozici je proto řada nástrojů, které tuto obfuskaci kódu nebo jeho zašifrování vykonají za ně až nad výsledným swf souborem. Mezi rozšířenými nástroji k šifrování a obfuskaci kódu ActionScriptu najdede například: Amayeta SWF Encrypt, DoSWF, SWFProtection, Flash protection, SWF Protector, nebo on-line aplikaci SWF Cry. Povětšinou se jedná o placené nástroje.
Jak jsem uvedl výše, nebude nám v případě použití podobných nástojů průzkum zdrojových kódů moc platný. Jak tedy v takovém případě postupovat? Máme-li k dispozici nástroje pro šifrování kódu, často najdeme také jejich protějšky určené k dešifrování kódu. Zde můžeme vybírat z nástrojů, mezi které patří například: SWF Decrypt, Swifty Unprotector nebo Sothink SWF Decrypt.
Pokud tyto nástroje nezaberou a my ze zrojového kódu stále nejme schopni dopátrat se použitého algoritmu pro tvorbu hashe, nezbývá než doufat, že vývojáři udělali nějakou drobnou chybku a nechali nám ve hře slabé místo, jehož využití výsledek poněkud vylepší, nebo alespoň umožní samotnou hru zjednodušit.
Podobných chybiček, které se dali zneužít jste našli několik i u testovací hry z minulého dílu, kde jste je popsali v komentářích. Jedná se například o skutečnost, že je pro tvorbu hashe použit krátký řetězec spojený s výsledným skóre. Pokud je tento řetězec kratší než 7 znaků, pak je často možné zjistit (například zde) jakému řetězci tento hash odpovídá a můžete si tak odvodit algoritmus jeho tvorby i bez znalosti zdrojových kódů. Další chybka v minulé testovací hře se týkala například neošetřeného vertikálního opuštění hrací plochy. Stačilo načíst hru v novém okně a zúžit okno takovým způsobem, aby jeho výška byla větší než jeho šířka. Chybiček se našlo ještě více a možná další přibudou.
V testovací hře, kterou jsem si pro vás připravil tentokrát, se minimálně jedno slabé místo také nachází.
Mnoho flashových her není tvořeno pouze jedniným swf souborem. Často se setkáte s preloaderem nebo se swf souborem samotné hry, který si dotahuje další údaje z externích souborů. Mezi těmito soubory mohou být jednak obrázky, zvuky a videa, ale také (a to je pro nás zajímavé) se může jednat o XML soubory, které definují rozmístění a další vlastnosti jednotlivých objektů ve flashové hře. V praxi jste se mohli s podobným přístupem setkat například v soutěži se zlatým trezorem od společnosti Magnum. Jednalo se o poměrně slušně zabezpečenou hru, která ovšem načítala podklady pro jednotlivé herní úrovně právě přes XML soubory.
Externí XML soubor načítá i flashová hra, která je připojena u tohoto dílu. Pokud si odchytnete komunikaci při načítání webové stránky s hrou a následně si do nového okna načtete jen samotnou hru, zjistíte, že vám v zachycené komunikaci uvízne i požadavek na soubor data.xml. Když si pak obsah tohoto souboru zobrazíte (například odesláním požadavku do nového okna prohlížeče), zjistíte, že obsahuje právě definice pro umístění a rychlost jednotlivých objektů.
Není tedy nic jednoduššího než obsah tohoto souboru pozměnit během jeho načítání flashovou hrou. Zde už nám ale doplněk Tamper Data, který jsme používali v minulých dílech nebude stačit, protože umožňuje zachytávat pouze odchozí požadavky a my tentokrát potřebujeme pozměnit obsah dat vrácených serverem. Sáhneme proto k nástroji WebScarab, o kterém v tomto seriálu již také padla zmínka. Protože by někomu mohlo činit problémy najít na stránce projektu WebScarab odkaz s downloadem, raději jej zde také uvedu: http://sourceforge.net/projects/owasp/files/WebScarab/
Webscarab je multiplatformní aplikace napsaná v Javě a není závislá na použitém webovém prohlížeči. Při použití ale musíte nejprve nastavit svůj browser, aby pro spojení využíval lokální proxy server localhost nebo 127.0.0.1. V defaultním nastavení naslouchá WebScarab na portu 8008, ale tento port můžete libovolně změnit na kartě Proxy / listeners.
Pokud si přejeme, aby nám WebScarab pozastavoval jednotlivé požadavky nebo odpovědi na ně, musíme na kartě Proxy / Manual edit zatrhnout ještě odpovídající volby Intercept requests respektive Intercept responses. Pod volbou Intercept responses je navíc pole pro zadání MIME typů, které mají být pozastavovány. My zde uvedeme application/xml pro xml data, která nás v tuto chvíli zajímají. K dispozici máme také nějaké doplňující volby, kterými můžeme filtrovat pouze určitý druh komunikace, ale těmi se nyní nebudeme zabývat. Po nastavení patřičných změn ve WebScarabu je potřeba jej ještě restartovat, aby došlo k načtení nově nastavené konfigurace.
Pokud načteme flashovou hru a zachytíme si odpověď serveru, ve které se nám vrací obsah souboru data.xml, můžeme v něm provést patřičné úpravy dříve, než jej předáme samotné hře. Můžeme například změnit umístění jednotlivých firewallů a rychlost jejich pohybu, nebo posunout a omezit pohyb objektu počítače. Mějte ale na paměti, že flash často ukládá xml soubory do vyrovnávací paměti a před opakovaným načtením hry bude někdy nutné tuto cache vyprázdnit, aby se projevily provedené změny.
Pro úplnost přikládám ještě video zachycující uvedený postup.