Denuvo, de nuevo, de nem nuevo? - A DRM és ami fölötte van

Először is elnézést kell kérnünk a címben szereplő szójátékért, csupán találgatás, de a program talán a spanyol „de nuevo” szóösszetételről kaphatta nevét, amelynek jelentése „újra, ismét”. De ha valami újra történik, akkor igazából annyira nem is új nem? Reméljük, hamarosan világos lesz, mi mindenre akarunk utalni, tartsatok velünk!

Olvasóink legtöbbje már biztosan hallott az osztrák szuper-védelemről, a kalózok és modderek ellenségéről, amelyet a nagy kiadók, újabban pedig független fejlesztők is előszeretettel alkalmaznak a termékeik védelmére. Bizony, a Denuvoról van szó, amelyet bár úgy hisszük, hogy ismerünk, pár téves elképzelés azonban mégis kialakult és elterjedt körülötte. Cikkünk célja ezeknek eloszlatása, és egy átfogó betekintés nyújtása az alkalmazott technikák hátterébe.

Mert ez nem DRM

Kezdjük a tévhitek eloszlatásával, amelyek közül talán a legelterjedtebb, hogy a Denuvo tulajdonképpen nem más, mint egy új, feltörhetetlen DRM. A lehető legrövidebben: nem az. Se nem feltörhetetlen, de legfőképpen nem DRM.

Mert mi is az a DRM (Digital Rights Management)? Anélkül, hogy nagyon messzire kalandoznánk, a DRM megoldások célja a szerzői jogok megsértésének megakadályozása, ami játékok és egyéb szoftverek esetén nagyjából abban merül ki, hogy egy licencelt terméket ne lehessen sokszorosítani, módosítani, vagy használni a jogtulajdonos engedélye nélkül. Mivel a digitális tartalmak lemásolásának megakadályozása gyakorlatilag lehetetlen, hiszen csak egyesek és nullák sorozatát kell reprodukálni, megoldásként marad a kódolás, titkosítás, amelyek mind-mind azt a célt szolgálják, hogy ha már a másolás meg is történt, ne lehessen használni, elindítani a szoftvert.

Mindannyian ismerjük a termékkulcsokat, a több karakterből álló kódsorokat, amik a programok aktiválásához kellenek, de önmagukban ezek sem elegendőek, hiszen azokat is le lehet másolni. Valahogy biztosítani kell, hogy azt csak egyetlen személy használhassa fel. Megoldásként szolgálhat az aktiválás után a hardverhez (alaplaphoz, processzorhoz) kötés, de ez nem túl előnyös a felhasználó számára, hiszen a megvásárolt licenc által biztosított hozzáféréshez való joga sérül, ha alkatrészt cserél.

Itt lépnek a képbe az online DRM megoldások, vagyis a Steam, az Origin vagy az Uplay, amelyeken keresztül online aktiváljuk a kulcsot, ami cserébe a játék letöltését és telepítését engedélyezi és egyúttal a hozzánk tartozó, jelszóval és egyéb módon védett profilhoz csatolja azt. A DRM legtöbbször egész egyszerűen annyiból áll, hogy a futtatható állomány (exe) forráskódja egy vagy több helyen ellenőrzi, vagy akár online „hazatelefonál”, hogy a megfelelő kulccsal, a megfelelő profillal, a már engedélyezett eszközön fut. Egy hasonlattal szemléltetve olyan ez, mint az autópályán az igazoltatás és a forgalom-ellenőrző kapuk, kamerák.

A védelmet védő védelem

A Denuvo viszont nem ezt csinálja, nem végez online aktiválást vagy ellenőrzést, és amennyire tudjuk, lemezcsekkolást vagy más hardverellenőrzést sem, hanem egy extra védelmi rétegként magukat a DRM-keretrendszereket közvetetten védi attól, hogy manipulálják őket. Eddig úgy nézett ki a dolog, hogy a megjelenés után pár nappal vagy csupán órákkal már volt is crack vagy installer, amely lényegében a DRM szoftvereket emulálta, vagyis a feltört program „elhitte”, hogy az igazi rendszerrel, online azonosíttatta magát. Ez viszont nem nagyon akar sikerülni, ha Denuvo védi az azonosítást végző fájlokat, vagyis a futtatható állományokat, bár nem kizárt, hogy mélyebbre is nyúlnak. Visszatérve az autópályás analógiához, a DRM tehát az ellenőrző pontokat jelenti, a Denuvo (DRM védelem) ezeket rejti el a kíváncsi szemek elől, amennyire az lehetséges.

Feltörhetetlen védelem azonban, ahogy már mondtuk, nincs. Az osztrák cég munkatársai sem állították soha, a szó csupán hatás- és klikkvadász cikkek címeiben szerepel. Az igazság az, hogy „csak” nagyon-nagyon megnehezíti a crackerek dolgát és sokáig tart, mire sikerülhet feltörni a védelmet, és mire összejön, addigra az első vásárlási hullám, vagyis az az időszak, amíg a legmagasabb az érdeklődés a játék iránt, már lecsengett, a kiadókat pedig ez érdekli, de nagyon.

Háttéranalízis

Na de mégis mi lehet a módszer? Természetesen sok mindent nem árulnak el a Denuvo képviselői (hülyék lennének), de azt tudjuk, hogy eredetileg Sony DADC néven volt ismeretes a cég, ám ha ez nem is ismerős, akkor korábbi tevékenységükből a SecuROM nevű termékük már inkább az lehet. A sokak által gyűlölt SecuROM azonban minden szempontból DRM volt, a másolást, sokszorosítást lehetetlenítette el – gondolom, nem kell említeni a hírhedt „háromszor-ötször-hétszer telepítheted a játékot” eseteket. Persze lehetett többször is, csak a terméktámogatással kellett felvenni a kapcsolatot és igazolni az eredetiséget, valamint indokolni az igényt.

De ne kalandozzunk el. Nem túl messzemenő következtetés tehát, hogy valami hasonló megoldást alkalmaznak a Denuvonál is, mint korábbi programjuknál. De, hogy megértsük, milyen elven működhet, kicsit mélyebbre kell ásnunk, és a végéről megközelíteni a dolgot. Mielőtt azonban bárki azt hinné, hogy most crackert faragunk mindenkiből, leszögeznénk: csak a felszínt fogjuk karcolgatni.

Hogy egy védelemhez hozzá lehessen férni, először meg kell érteni annak működését, fel kell fedni az „igazoltatások” helyszínét, azaz analizálni kell a futtatható állományt – erre kétféle módszer létezik, a statikus és a dinamikus analízis. A statikus analízis során kódvisszafejtést hajtanak végre (decompiling), azaz a futás során az elfogott gépi kódból (bytecode, gyakorlatilag egyesek és nullák sorozata) ember számára is értelmezhető forráskódot hoznak létre (ez az, amit a programozók írnak, magas szintű kódnak is nevezik). Ezt követően kerülik ki az esetleges védelmeket, de ez a módszer a dinamikusan változó vagy titkosított állományoknál nem hatékony, vagy egyáltalán nem is működhet.

Az ilyen esetekben a dinamikus analízis vezethet eredményre, amelynek során egy úgynevezett debugger keretrendszerben futtatják az analizálni kívánt programot, amelyben nyomon követhető, hogy mikor mi történik, mit csinál a program, majd úgy módosítják, hogy kikerülje, átugorja a védelmi algoritmusokat, vagy „elhitetik” azzal, hogy minden szabályszerűen zajlik. Még ha titkosítva is van a kód, egy legálisan beszerzett kulcsot felhasználva „belülről” látható, hogy miként lehet áthidalni a titkosítást.

Nincs új a nap alatt

A megoldás tehát a debugger összezavarása. Lenne, mert léteznek ugyan anti-debug eljárások, algoritmusok, de ezek mindegyike ismert, a statikus analízis ellen nem is nyújtanak védelmet, ráadásul lassítják a program futását, ami esetünkben, azaz játékok védelménél nem előnyös. Tehát, ha a debuggert magát nem lehet akadályozni, a következő lépcső az analízis nehezítése, amelyre két megoldás kínálkozik: a kód mutálása és/vagy virtualizálása.

A mutáció azt jelenti, hogy a már kész, működő gépi kódot úgy alakítják át, hogy nehezen értelmezhető legyen, értelmetlen, „halott” kóddal töltenek fel szakaszokat, fölösleges, „üres” vagy „szemét” parancsokat tesznek bele, titkosítják egyes elemeit, elnevezéseket változtatnak meg. Így a gépi kód visszafejtését nyújtják el, és az ezt követő analízis lehetetlenül hosszú folyamattá válik.

A virtualizáció során a forráskódot, vagy egyes részeit egy úgynevezett értelmező program (interpreter) futtatja le saját gépi kóddá alakítva azt, ami csakis az általa kezelt virtuális gép (egy szimulált számítógép, gyakorlatilag gép-a-gépben) számára értelmezhető. Tehát a gépi kód visszafejtéséhez először a virtuális gép felépítését kell megérteni, amihez viszont idő kell, úgynevezett disassemblert kell írni, ami alacsony szintű kóddá fordítja a virtuális gép bytecode-ját. Csak ezután lehet nekikezdeni a gyakorlati visszafejtésnek a már ismertetett analízis útján, és ha az is megvan, akkor a már bejáratott módokon a DRM kijátszható.

Zárszó

Akik eddig velünk voltak, azoknak nagy pacsi, ti már sejthetitek, hogy a legmagasabb szintű védelmet a (akár többszörös) virtualizáció és a mutáció kombinálása jelenti, ami minden esetben az emberi tényezőre épít, és erősen gyanítható, hogy ezt emelték új szintre a Denuvo esetében. Mert ember kell, aki meglátja a kódban azt, amit ki kell kerülni. A decompiler és debugger lefut, de nem azok törik fel a programot. Ha a feltörést végző cracker munkájának „emberi” részét nehezítik, amennyire csak lehet, akkor nyert az ügy. Persze csak egy ideig, hiszen idővel mindent fel lehet törni, lassan, de biztosan minden Denuvo védelem kiiktatható. A helyzetet viszont cifrázza, hogy nem ülnek a babérokon az osztrákok sem, a kikerülő crackek alapján megfejtik, hogy hol és miként kerülik ki a védelmet, és befoltozzák a lyukat, vagy változtatnak a módszereiken – tehát egy végtelenségig folytatható macska-egér párharc kezdetének vagyunk a tanúi.