Software piracy protection. Készítette: Szücs Balázs

Átírás

1 Software piracy protection Készítette: Szücs Balázs

2 Tartalom Bevezetés, jogi háttér A védelem típusai Egy gyakorlati példa bemutatása Támadások bemutatása A kalózkodás gazdasági hatásai Konklúzió, tanulságok 2

3 Bevezetés Mi is az a kalózkodás? Mi által tiltott? 3

4 Jogi háttér A kalózkodás alatt azt értjük, amikor egy szoftvert jogosulatlanul használnak, másolják vagy terjesztik! Amikor megvásárolunk egy szoftvert, akkor általában egy szerződést is elfogadunk a telepítéssel. Valaki olvassa? (Pedig kellene ) Mi van bennük? Chrome:,, you give Google a perpetual, irrevocable, license to reproduce,, and distribute any Content which you submit, post or display on or through, Far Cry: It is not permitted: To modify the Multimedia Product To decompile, reverse engineer or disassamble 4

5 Védelem Típusok, megoldások 5

6 A védelem típusai Security by obscurity Másolásvédelem Egyszerű ellenőrzés Szoftveres Hardveres Obfuszkáció A jogtalan hozzáférés felismerése 6

7 Security by obscurity Inkább történelmi szempontból fontos Nem tekinthető kiforrott védelmi megoldásnak Leginkább a hobbisták versengése volt Apple II Nem voltak szabványos driverek Direkt floppy fej vezérlés Atari (8 bites számítógépek) Bad sectors - szándékosan olvashatatlan szektorok Töltődéskor a szoftver ezeket kereste Hibakódokat verifikált 7

8 Másolásvédelem CD másolásvédelem pl. DPM: az adatok fizikai helyét vizsgálja (az első és utolsó használt blokk közötti szökget) Roppant nehéz tökéletes másolatot létrehozni Nem kifizetődő egy olyan ipari eszközt megfizetni Digitális aláírás hozzáadása Installer A szoftver ellenőrzi egy szubrutinnal A CD írók nem tudják (fizikailag) kiírni Nem nehéz feltörni, de a registry kulcsok, különböző használt könyvtárak megnehezítik a másolást Programmal (automatizáltan) könnyebb a feltárás 8

9 Ellenőrzés alapú megoldások I. Szoftveres megoldások Általában egy kulcs, azonosító, vagy fájl birtoklását ellenőrzik Regisztrációval egybekötve Azért, hogy ne lehessen több gépre is telepíteni Korábban mindössze az érték egyezésének vizsgálata Módosított implementációk,,,heurisztikák Általában csak bonyolultabb mód, nem nehezebb 9

10 Ellenőrzés alapú megoldások II. Hardveres megoldások Dongle - nélküle nem futtatható a program Jellemzően USB Pendrive, de alapvetően bármilyen portra csatlakoztatható Smart card - kriptográfiai tároló A kártyán található kulcspár segítségével lehetséges például a kód kititkosítása, és futtatása (persze először szimmetrikus kulcs számítása) Hardware security unit - a program futását vezérli Az alkalmazást kisebb egységekre szedjük, majd összekeverjük Ha véget ér a futás egy egységben, akkor az eszköz mondja meg, hol folytatódjon 10

11 Smart card 11

12 Hardware security unit 12

13 Obfuszkáció Már hallottunk róla Kócsó Balázstól a Deobfuscation of obfuscated software c. előadásából Ezen a területen is kiemelten fontos az alkalmazása Gyakorlatban is alkalmazott Része a gyakorlati példának 13

14 A jogtalan hozzáférés felismerése Példa: ismert a programnak egy törése Ahelyett, hogy befoltoznák, egy későbbi kiadásban olyan kódot implementálnak, ami felismeri azt a törést! Ha felfedezi, akkor használhatatlanná teszi magát Akár előre is fel lehet rá készülni A szerveren ellenőrizzük az egyediséget Ha sérül, akkor visszaküldjük a kliensnek, ami reagál Fingerprinting (watermarking) Egyedi azonosítót kapcsolunk a kiadott szoftver példányokhoz Nyomon követjük - ha valamelyik,,elterjed, akkor észre tudjuk venni 14

15 Egy gyakorlati példa bemutatása Komplex megoldás.net alkalmazásokhoz 15

16 1. Licensz menedzsment Cél: egy licensszel egy gépen használhassák az alkalmazást Itt tipikus hiba a szimmetrikus kulcsú titkosítás, és a kódba,,rejtett kulcs használata. A megoldás: ECC Elfogadhatóan hosszú lesz csak a kulcs mérete Aszimmetrikus! A generálást házon belül oldjuk meg, a publikus kulcs beépül az alkalmazásba Aktiváció: mindenképpen a saját szerver végezze Nehéz elég jól megvalósítani (még HTTPS esetén szerver tanúsítványt használó validációval is) Pl. a betöltött futtatható állomány módosítása Példa könyvtár: SoftActivate Licensing SDK 16

17 2. Assembly merging Cél: az érzékeny, licenszelés-hez tartozó állományok összefésülése a fő állománnyal Azért van rá szükség, hogy az obfuszkáció hatékonyabb legyen Az obfuszkáció külön állományban hagyná, ami nagyban megkönnyebbítené az analízist Példa tool: Microsoft ILMerge 17

18 3. Obfuszkáció Már ismerjük, a kód szemantikájának megértését, az algoritmusok sérülékenységeinek felfedezését nehezítik Teszteljük a kapott eredményt! Az obfuszkátorok adott esetben el is ronthatják a működést! Eredményesebb egy jó toolnak a használata, mint több, adott esetben kevésbé jónak (viszont mindegyiknek megvan a maga erőssége) Példák: Eazfuscator.Net, Obfuscar, DotFuscator Community Edition 18

19 4: Állományok erős elnevezése A cél: felfedezzük, ha módosították a futtatható állományt a buildelés óta A Visual Studio beépítve tudja Ez speciális.netes téma, de más platformokon is van rá megoldás, például Mac OS X: írjuk alá az állományt az Apple-től kapott tanúsítvánnyal, így az ellenőrizhető az operációs rendszer által betöltéskor (és a futtató által is, kézzel, a rendszer parancsait használva) 19

20 Támdások Néhány eset gyakorlati bemutatása 20

21 Szoftver regisztráció átugrása Effektív, ha ezt egyszer kell megtenni, és a regisztrációnak semmilyen mellékterméke sincs Futtassuk a programot egy debuggerben Keressünk releváns hívásokat (dialog box megnyitása, stb ), majd állítsunk be rájuk breakpointot Írjunk be egy véletlenszerű kulcsot Ha megáll egy breakpointnál, akkor jót választottunk Lépkedjünk tovább egy ellenőrző utasításig (pl test eax) Írjuk át a visszatérési értéket (eax regiszter értékét) 0-ról 1-re (vagy fordítva ) Folytassuk a végrehajtást 21

22 Kulcs generálása Vannak olyan alkalmazások, amelyekben a hitelesítő kulcsot úgy ellenőrzik, hogy a szoftver maga is generál egyet, és összehasonlítja a szerverrel kapottal Itt a megadott név alapján történik a generálás, így,,mindössze arra kell rájönni, hogy milyen módszerrel áll elő a generált kulcs A módszer hasonló, a memória átírásával végig kell járni, hogy mikor milyen karaktert vár a verifikációt végző algoritmus Érdemes néhány különböző értékkel végigmenni, majd utána elemezni, hogy milyen módszerrel történik a generálás Lehet pl. szimmetrikus kripto, hash, stb 22

23 A kalózkodás gazdasági hatásai Mekkora mértékű, és milyen hatása van ránk? 23

24 Gazdasági hatások Az emberek mindössze 40 százaléka nem használ illegálisan szoftvert (globális adatat) Tény, hogy a fejlett országokban kisebb ez az arány A jogtalanul megszerzett szoftverek összértéke a fejlett országokban lassan, a fejlődő országokban rohamosan emelkedik A cégeknek a védekezés nem feltétlenül éri meg! Egy illegális letöltő akkor sem feltétlenül venné meg a szoftvert, ha nem tudná beszerezni 24

25 Konklúzió, tanulságok 25

26 Tanulság Általában a szoftvergyártóknak sem érdekük az, hogy feltörhetetlen programokat adjanak ki Csak olyan szintű védelmet implementálnak, ami gazdaságilag megéri A kalózkodásra nem úgy tekintünk, mint a fizikai értelemben vett lopásra,,there is no good technological solution to a behavioral problem. 26

27 Köszönöm a figyelmet! 27

28 Források Gareth Cronin: A Taxonomy of Methods for Software Piracy Prevention (2002) Qiang Liu: Techniques using exterior component against software piracy (2003) Budiyoso Kurniawan, Laurent Lazard: Software copyright protection technology (Project report) 2011 BSA Global software piracy study (2012) bypass-software-registration / generate-software-keys / 28