Ebben a részben arról olvashatnak, milyen módszerekkel törik fel a különféle szoftvervédelmi rendszereket, s arról is miként védekezhetünk ez ellen.
A biztonság
A kulcs hardver-másolatának megalkotása
Speciális programok, illetve hardverek segítségével beolvassák a kulcson található memória integrált áramkörének tartalmát, majd ugyancsak speciális eszközök segítségével ezeket az adatokat hasonló IC-kbe másolják be. Ilyen módon létrehozzák a kulcs másolatát, amely alkalmas a védett programmal való együttműködésre.
Ezt a módszert csak abban az esetben alkalmazzák, amikor ismert a memória IC-jének típusa, és rendelkezésre állnak a másoláshoz szükséges eszközök. De ami a legfontosabb ebben az esetben, az az, hogy a memória semmilyen módon ne legyen másolástól védett. Pontosan ez az a feltétel, ami bizonyos típusú kulcsok gyenge pontja. Nagyon sok kulcsban ugyanis gyenge, vagy egyáltalán nincs ilyen típusú védelem, ami nagyban megkönnyíti a másolásukat, ezért ez egy meglehetősen elterjedt módszer.
Ennek a módszernek viszont több hátránya is van. A legjelentősebb probléma az, hogy ha még sikerül is megszereznünk vagy előállítanunk a kulcs illegális másolatát, nem fogjuk tudni terjeszeteni azt, hiszen a kulcs másolata továbbra is védett maradt, egész egyszerűen most már egy másik kulcshoz van kötve ez az információ. Ezenkívül az ilyen másolás meglehetősen drága. Gyakran egyszerűen olcsóbb megvásárolni a szoftver legális változatát, mint fizetni a feltörésért. Ezért ez a módszer nem örvend túl nagy népszerűségnek.
A kulcs emulátorának létrehozása
A kulcs belső logikáját tanulmányozva, egy programot lehet alkotni, ami mondjuk DLL, eszközkészlet stb. Ez imitálja a kulcs működését. Egy jó minőségű program képes a minden részletében tökéletesen utánozni az eredeti kulcsot. Ennek eredménye az lesz, hogy a védett szoftver kiválóan fog működni, nem is sejtve azt, hogy illegálisan működik.
Az ilyen utánzatokat osztályozni is lehet.
Vannak univerzálisak (ezek az emulátorok egy adott márkán belül minden kulcs számára kivállóan működnek), és vannak nem univerzálisak, vagy crack-ek (ezek a programok minden kulcs számára egyedileg, külön készülnek).
A működési elvük alapján a következőképpen oszthatjuk fel őket.
Amelyek a kulcs szerkezetének működésén alapulnak (általában ezek olyan emulátorok, melyek olyan kulcsok esetében működnek, amik nem rendelkeznek, vagy csak nagyon primitív hardver algoritmussal rendelkeznek), illetve, melyek a kulcs által adott válaszokon alapulnak. Az első esetben a kulcs szerkezetét teljesen utánozzák, minden egyes apró részletre kitérve, a második esetben pedig egy speciális táblázatot alkalmaznak, amelyik a kulcs helyes válaszait tartalmazza.
Mindkét esetben az emulátoroknak nemcsak az a feladatuk, hogy helyesen reagáljanak a lekérdezésekre, hanem az is, hogy helyesen végezzék az adatcsere protokollját (ellenkező esetben ugyanis a védelmi program nem fogja tudni megfelelőképp értelmezni az utánzat által küldött adatokat).
Ez a módszer nagyon hatékonynak minősül a szoftverek feltörése terén, és meglehetősen népszerű. Manapság a kulcsok gyártói a következő védekezési módszereket alkalmazzák az emulátorokkal szemben.
1. "Mobil" adatcsere-protokoll az elektronikus kulccsal. A program és az elektronikus kulcs közötti adatcserébe mesterségesen "zajt" kevernek. Ennek során a "zaj" jellege az idő változásával ugyancsak változik. Mivel az emulátornak nemcsak a kulcs irányából érkező adatokat kell feldolgozni, hanem az adatcsere protokolljának minden sajátosságát is, ezért az információ "zajossága" nagyban megnehezíti az ilyen jellegű programok megírását. Manapság gyakorlatilag minden kulcsgyártó alkalmazza ezt a megoldást.
2. A hardver algoritmusok alkalmazása. Ez nagyban megnöveli a kulcs logikájának bonyolultságát, mivel a program lekérdezéseire ez a kulcs jóval bonyolultabb válaszokat fog adni, mint hogy "igen vagy nem". Ennek megfelelően, ahhoz, hogy megalkossuk az ilyen kulcs emulátorát, meg kell szerkesztenünk az összes lehetséges válasz táblázatát, ami egy nagyon munka-, időigényes és költséges feladat.
Manapság nagyon sok kulcs rendelkezik ezzel a megoldással. Ezek különbözhetnek bonyolultságuk és tulajdonságaik tekintetében is. Azonban nem minden ilyen algoritmus képes megbízhatóan biztosítani a teljes körű védelmet. A hardver algoritmusnak bonyolultnak kell lennie, hogy azt ne lehessen kikövetkeztetni; ebben az esetben a kulcsnak nagy mennyiségű információt kell feldolgoznia egy lekérdezés során (pl. ha a kulcs egyszerre két bájtot képes feldolgozni, akkor az összes lehetséges kérdés és válasz száma 65 536). Hogy egy ilyen kulcs lehetséges válaszainak teljes táblázatát összeállíthassuk, legalább egy órára van szükség. Minden felhasználó esetében ennek a kulcsnak különbözőnek kell lennie, hogy ne legyen lehetőség egy univerzális emulátor megalkotására.
Az automatikus védelem önálló moduljai
A kész programok automatikus védelmének módszere (envelope módszer) gyakorlatilag mindenki számára elérhető. Az előnye a következő: speciális program segítségével, mindössze néhány másodperc alatt meg lehet oldani bármilyen programvédelmi problémát. Nagyon sok időt spórolunk meg, nem kell rendelkeznünk semmilyen tudással a programvédelem terén, és vannak olyan esetek is, amikor ez az egyetlen védekezési mód (pl. ha valamilyen oknál fogva nem áll rendelkezésünkre a védett program forráskódja).
Ugyanakkor ennek a módszernek vannak gyenge pontjai is. Mivel a védelem már egy kész programra kerül, ezért nem alkot a védett programmal egy egységes egészet. Az automatikus védelem modulja csak "illeszkedik" a programhoz, ami azt jelenti, hogy elméletileg lehetőség van ennek a modulnak a leválasztására, miközben maga a program semmilyen módon nem sérül. Egyébként ezen a téren meglehetősen nagy tapasztalattal rendelkeznek a programok feltörői, annyira, hogy olyan programok is vannak, melyek automatikusan elvégzik az ilyen módon kódolt programok feltörését.
Abszolút biztonságos védelem nem létezik, és a programok feltörése minden esetben csupán idő kérdése. És ez az idő a védekezési mód minőségétől függ. Leginkább azok a rendszerek sebezhetők, melyek megalkotói nem integrálták a már feltört programok tapasztalatait. Azonban vannak olyan automatikus védelmen alapuló módszerek is, melyeket nem lehet univerzális programok segítségével feltörni. A feltörésükhöz komoly programozói tudásra is szükség van.
Ebben az esetben természetesen megnövekszik a feltörés költsége, és az esetek többségében sokkal ésszerűbb és olcsóbb a legális változat megvásárlása.
A másik meglehetősen biztonságos védekezési mód, az automatikus védelem és az API funkciók védelmének kombinációja. Ebben az esetben, még ha sikerül is a védelmi modul leválasztása, akkor sem biztos, hogy használni tudjuk a terméket.
Az API funkciók alkalmazása
Az automatikus védelmi lehetőségek mellett meglehetősen elterjedt az API funkciók alkalmazása. Általában az API rendelkezésre áll minden korszerű programozási nyelv esetében, és a lehető legkülönfélébb tulajdonságokkal rendelkezhet. A felhasználónak be kell írnia a program szövegébe a megfelelő helyen a megfelelő funkciót, és ilyen módon egy bizonyos szintű biztonságot tud elérni.
Eredményképp a védelem a program mélyébe lesz beágyazva, és annak elválaszthatatlan része lesz. Egy ilyen típusú biztonsági eszközt jóval bonyolultabb feltörni, mint mondjuk az automatikus biztonsági rendszert. Ennek az az oka, hogy ebben az esetben nincs lehetőség univerzális crack megalkotására.
Különböző disassembler programok segítségével vizsgálják a program logikai szerkezetét, és így próbálják megtalálni azokat a helyeket, melyek az API funkciókat alkalmazzák. Ezek után ezeken a helyeken módosítják a programot. Az iyen feltörési módszerek ellen a következő lehetőségek állnak rendelkezésünkre:
1. Az API és az automatikus védelem kombinálása. Egy megfelelő biztonságot nyújtó védelmi program képes megvédeni a védett programot a disassemblerektől is. Ez azt jelenti, hogy mielőtt hozzákezdenének a program feltöréséhez, meg kell szünteni az automatikus védelem modulját. Minden fejlesztő javasolja ennek a két módszernek a kombinálását. Az automatikus védelem modulja a védekezés "külső szintjét" alkotja, amely elzárja az illetéktelenek elől az API funkciókat.
2. Bonyolultabb logikájú védelmi modulok alkalmazása. A professzionális védelmi rendszerek rendelkeznek belső védelmi módszerekkel. A modulok szövegének kódolása, a kódok részleteinek "zajosítása" (konkrét információt nem hordozó adatok hozzáadása), a kontrollösszegek (CRC) alkalmazása. Ezek és a hasonló megoldások nagyban képesek megnehezíteni a feltörés folyamatát.
3. Nem triviális logika kidolgozása. Nem túl nehéz egy olyan programot feltörni, amely az API funkció által generált értéket egy egyszerű összehasonlításra használj, mint pl. "igaz/hamis".Rengeteg olyan hatásos módszer van, mellyel bonyolítani lehet a védelem logikáját.
Az ilyen lehetőségeket alkalmazva olyan védelmi programokat alkothatunk, melyek feltörése már jóval nehezebb feladat lesz. Ennek az lesz az eredménye, hogy minimálisra csökken annak a valószínűsége, hogy a programból sikerül minden API funkciót kiiktatni. A védelem "maradványai" pedig jelen lesznek a már feltört programban, akadályozva az ilyen program normális működését. Ebben az esetben a felhasználó nem lesz képes a program összes lehetőségét kihasználni, és előbb vagy utóbb kénytelen lesz megvásárolni a legális változatot.
4. A hardver válaszainak alkalmazása a program működése során. A védelem megszervezése során a program számára fontos adatokat le lehet kódolni a hardver segítségével, és ilyen kódolt formában is be lehet írni a programba. A munka folyamata során a program a szükséges időpontban a hardver algoritmust fogja futtatni, amely ezen adatok dekódolására szolgál, majd ezeket az adatokat a program már a célnak megfelelően fogja alkalmazni. Ebben az esetben még az sem segít, ha minden API funkciótól sikerül megszabadulnia a feltörőnek. Hiszen a legfontosabb adatok még mindig kódolt formában lesznek jelen a programban, és ezek dekódolása elektronikus kulcs hiányában lehetetlen.
A Stealth kulcsokról bővebben itt olvashatnak.
Előző rész.
Forrás: http://www.sura.ru/shadow/
|