• Articles
• admin

fiatal voltam, az internet csak most kezdődött, és tudtuk, hogy rengeteg szoftver ingyen. Ez volt ingyenes, mert valaki ott volt “kedves” ahhoz, hogy kiváló/patch a .exe fájl.

már fel “kedves” idézőjelek között, mert ez volt a nézet volt, amikor gyerek voltam. Most szoftvermérnök vagyok, és tudom, hogy mennyi erőfeszítést igényel a szoftver elkészítése. Ezért kérjük, ne töltsön le repedt szoftvert. Támogassa a fejlesztőt és vásároljon licencet!

egy ilyen repedés alkalmazása, az exe javítása, mindig is szerettem volna tudni, hogyan kell csinálni egy ilyen dolgot. Kiderül, hogy meg kell értened az assemblert, egy olyan gépi nyelvet, amelyet csak a CPU ért (és néhány más majmot is). Mivel túl nehéz volt, soha nem tudtam megtanulni. Egészen a közelmúltig(mint 20 évvel később).

egy évvel ezelőtt vettem szoftvert (licenccel!), hogy szüksége van egy USB dongle dolgozni. Nagyon nehézkes, hogy ez a dongle mindig veled van. Főleg, ha úton vagy. Ezért kerestem a módját, hogy megkerüljem. Az első dolog, amivel találkoztam, ez a MultiKey nevű kulcsemulátor volt. A dongle memóriáját a rendszerleíró adatbázisba dobja, majd a rendszerleíró adatbázisból olvasva emulálja a dongle-t. Ez rendben működött, amíg nem akartam futtatni a Windows 10 rendszeren. Nyilvánvaló, hogy a Microsoft nem olyan nagy rajongója a MultiKey-nek. A valóságban nem nagy rajongója az aláíratlan illesztőprogramoknak, a MultiKey pedig aláíratlan illesztőprogramot használ. Tehát más megoldásra volt szükségem. Ideje belemerülni abba a dologba, amit összeszerelési kódnak hívnak!

mindig tudtam, hogy létezik egy eszköz a visszafejtéshez, az úgynevezett IDA. Ez képes visszafordítani a .exe fájlt, és azt mutatják, hogy mi folyik itt. Sajnos a felületet nagyon nehéz megérteni. Az OllyDbg-ről is tudtam. Ez egy hibakereső. A hibakereső lehetővé teszi, hogy a program futása közben lépjen át az összeszerelő kódon! Ez azt jelenti, hogy például, ha hibakeresést végezne a Számológép alkalmazásban, akkor valóban láthatja, hogy egy gombnyomást kezel, elvégzi a számítást, és megmutatja az eredményt a képernyőn. Pokol, akkor is pauze és változtassa meg a memóriát, hogy a számológép visszatér 5, amikor megkérdezi, hogy mi 2 + 2!

de nem azért vagyok itt, hogy megváltoztassam a kalkulust (bár ez klassz lenne). Meg akarok szabadulni a dongle-tól. Tehát megnyitottam az alkalmazásomat az OllyDbg – vel.

ez valóban elsöprő volt. Fogalmam sem volt, mit jelentenek ezek a kódok. Nem is beszélve arról, hogy hol kezdjem. Így visszamentem a tervezőasztalhoz. Kiderült, hogy van valami úgynevezett RetDec, egy dekompilátor, amely megpróbálja C kódot kinyomtatni a gépi kódból. Beletelt egy kis időbe, mire beállítottam és lefuttattam a dekompilációt, de az erőfeszítés kifizetődött. Az eredmény hatalmas volt .c fájl, több mint 2 millió sornyi kód félig olvasható kóddal.

valójában meglehetősen egyszerűnek találtam a kódot, amely a dongle bájtjait olvassa:

ezzel az információval visszafordultam a hibakeresőmhöz. Közben kiderült, hogy az OllyDbg nagyon régi (2000-től), és 2013 óta nem frissült. Így találtam ezt az új, továbbfejlesztett hibakeresőt, x64dbg néven. Nyílt forráskódú, és nagy fejlesztői közösség dolgozik rajta.

gépi nyelv olvasása

gépi nyelven minden utasításnak van memóriacíme. Tehát a RetDec kódban található címekkel az x64dbg-hez fordultam, és íme, a kód, amely kiolvassa a dongle-t:

az összeszerelési kódban a függvény argumentumai a veremmutató esp segítségével kerülnek a memóriába. Kódunkban ez közvetlenül a funkció hívása előtt történik. (a 3 mov utasítás azt jelzi, hogy a hívás 3 argumentumot vesz igénybe). A hívás után a veremmutatónk visszaáll, és egy ellenőrzés (teszt) történik, ha a funkció hívása sikeres volt. Ha nem, akkor látjuk, hogy a kód ugrik (jne). Ez az ugrás egy kódrészletre mutat, amely azt jelzi, hogy a hardverkulcs nincs jelen.

mint látható, van egy hívást, hogy egy adott funkció kiolvasni a hardverkulcs. Megnéztem a referencia útmutatót, hogy megtudjam, mit csinál ez a funkció:

a funkció 2 bájt memóriát (egy szót) olvas a hardverkulcsból. Mint sejtette, a függvény 3 argumentumot vesz fel, ahol az utolsó argumentum 2 bájtra mutató mutató, amely tartalmaz néhány adatot a hardverkulcsból.

az összeszerelési kódban az argumentumok fordított sorrendben vannak betöltve. Az utolsó érv átadása ez:

az utolsó argumentum az esi-re mutat, ami azt jelenti, hogy a dongle adatait azon a memóriacímen tárolják, amelyre az esi mutat.

valójában, amikor közvetlenül a hívás után szünetet tartunk, láthatjuk az eredményt a memóriában:

0x74. Ez az, amit kiolvasott a dongle és tárolja a memóriában a fő program.

a hívás kihagyásához csak 0x74-et kell írnom a memóriába, ahol az esi mutat. Ez olyan egyszerű, mint a fenti 7 sor cseréje:

mint látható, én is nop-ed a többi assembler utasításokat, beleértve a teszt, ha a hívás funkció érvényes volt. Ez azt jelenti, hogy az ugrás nem történik meg, és a program továbbra is működik az ellenőrzés nélkül.

a hardverkulcsot érintő összes hívás javítása után elmentettem az újat .exe. Elővettem a dongle-t, megcsináltam a custom-ot .exe és a saját csodálkozásomra működött! Sikeresen feltörtem egy szoftvert.

egy másik dolog, amit keresztezek a bakancslistámon, a következők:

Ps: a legtöbb dolgot elhomályosították, például a 0x74-et és az alkalmazás nevét. Ez nem károsítja a keményen dolgozó fejlesztőket, akik bármilyen módon létrehozták ezt a szoftvert. Szintén nagyon szerencsés voltam, hogy a dongle csak bájtokat adott vissza, és önmagában nem végzett titkosítást.