Szoftver másolásvédelem Írta: Pék János Dániel Neptun: LYJX3O
Kivonat Napjainkban a mobileszközökön is elérhető szélessávú internet, a digitálisan sugárzott TV csatornák, és egyáltalán a digitális információtovábbítás fénykorában különösen jelentős szerepe van a szellemi tulajdon elektronikus úton történő védelmének. Az analóg médiák korában az adathordozók másolása során az adat jelentős minőségromlást szenvedett el, ez egyfajta természetes gátja volt a hatékony kalóz többszörösítésnek. Még ezen természetes korlátok mellett is jelentős fekete iparág épült a kalózmásolatok árusítására. A digitálizált megoldások azonban lehetőséget nyitottak az eredeti jogvédett anyag minőségében teljesen azonos kópiáinak elkészítésére. Sok szempontból különleges elvárásoknak kell megfelelniük a másolásvédelem eszközeinek, amikor is szoftverek, futtatható entitások védelméről van szó. Ezen belül is többféle megközelítés létezik, melyek közül igen sok vállal kompromisszumot a nagyobb biztonság és a felhasználói élmény minősége között. Ezen védelmi mechanizmusok működéséről, összehasonlításáról, és a lehetséges hardveres segédeszközökkel megvalósítható megoldásokról hivatott felületes áttekintést nyújtani ez az összefoglaló. Szó lesz még érdekességként a szoftveres másolásvédelem múltjáról, illetve a jelenlegi trendekről.
1. Bevezetés Az évek során az ipar sokféle "trükkel" próbált a kalózok előtt járni egy lépéssel, ám kívülről nézve, leginkább macska-egér játéknak tűnhetett az egész, amely során a különböző megoldások csak ideig-óráig nyújtottak védelmet a szerzők számára. Igazán hatékony, feltörhetetlen, vagy akár csak gyakorlatilag feltörhetetlen megoldást a mai napig sem sikerült kidolgozni. A technológiák legfeljebb megnehezíteni tudják a crackerek dolgát, kényelmetlenebbé tenni a másolatok felhasználását, esetleg valamiféle hozzáadott "analóg" értékkel csábítani a vásárlókat az eredeti termék megvásárlására a kalózmásolatokkal szemben. Presztízst teremteni az igényes kivitelnek, szép borítókat tervezni, kinyomtatott dalszövegeket mellékelni, elképesztően kényelmessé tenni a vásárlási modellt (amazon 1-click model, Apple különböző online store-jai, stb). Szépen lassan az ipar is rájön, hogy fogyasztásra motiválni leginkább jó marketinggel, minőségi termékekkel, és nem béklyókkal, és retorzióval lehet. Sőt, az élelmes, szabadelvű, kissé anarchista hacker általában kihívást lát az ilyenfajta kényszerek legyűrésében, és élvezetét leli abban, ha megmutathatja a világnak, hogy számára nincs leküzdhetetlen akadály. Ezen tevékenységével azonban igen nagy károkat okoz a szerzőknek és disztribútoroknak az elmaradt jogdíjbevételek formájában. Ebben az összefoglalóban először áttekintem a szoftver másolás védelem történelmi vonatkozásait (2.), majd általános képet festek az aktuálisan lehetséges szoftveres megközelítésekről (3.), ezeket egyenként kifejtem (4-6.), majd szót ejtek az aktuálisan használt hardveres megoldásokról (7.). Ezután egyéb, a fenti kategóriákba be nem sorolható megoldásról írok (8.). Az összefoglaló utolsó részében szubjektív véleményt fogalmazok meg a szoftver másolásvédelem létjogosultságáról, illetve az alternatív utakról, melyeket jómagam üdvösnek tartok.
2. Történelem A szoftver másolásvédelemmel kapcsolatos kérdések az otthoni számítógéphasználat elterjedésével együtt vetődtek fel először. Az úgynevezett crackerek hobbit űztek abból, hogy a nagy gyártók szoftvervédelmi mechanizmusait kijátsszák, és másodpéldányokat illegálisan terjesszenek. A korai PC-ken (Apple II, Commodore 64) alkalmazott szoftveres másolásvédelem igen változatos és kreatív formákat öltött, mivel a legtöbbjük arra alapozott, hogy a floppy lemezek írása és olvasása is a szoftver által kontrollált. Az IBM PC-k esetében ezek voltak az úgynevezett 'booterek'. A booterek már a számítógép bootup folyamata során átvették a vezérlést, és ezek töltötték be az adott szoftvert. Így a standard floppy-szerkezetet módosítva el tudták érni, hogy az operációs rendszerrel ne lehessen másolni a floppyt. Erre a megoldásra hamarosan feleltek a crackerek, az első nibble másoló, a Locksmith megjelenésével. Ez képes volt gyakorlatilag az összes akkor piacon lévő másolásvédelmi módszert kijátszani, és másolni a floppy-k tartalmát, függetlenül azok nem-sztenderd felépítésétől. Egy másik, kevésbé drága módszer volt a szoftvergyártók részéről, ahol valamiféle bizonyítékot kért a felhasználótól a szoftver, hogy valóban megvette azt. Például futás közben az alábbi kérést intézte a szoftver a felhasználóhoz: "Mi a negyedik szó a hatodik sorban a kézikönyv tizenkilencedik oldalán". Az ilyen, úgynevezett felhasználói interaktivitást igénylő megoldások azonban könnyen kijátszhatóak voltak a kézikönyv egyszerű bescannelésével, és megosztásával. Sőt, ha egy ügyes cracker megtörte az alkalmazást, a tört szoftver onnantól kezdve plusz értéket hordozott az eredeti példányhoz képest, hiszen nem kellett mindenféle manual-lapozgatással bajlódnia a felhasználónak. Ilyenformán ezek a védelmi módszerek hamar el is tűntek a piacról. A CD-k megjelenésével az olyan gyártók, mint a Sony vagy a Macrovision olyan védelmi módszereket kezdtek alkalmazni, melyek során a CD-ROM olyan helyeire írtak be adatot, ahová egy egyszerű CD-író eszköz nem képes írni. Ilyen megoldást használt például a PlayStation is, s nem volt könnyű ezt kijátszani modchip-ek alkalmazása nélkül.
3. Szoftveres védelmi módszerek A szoftverek védelmének problémás volta abban a tényben gyökerezik, hogy mindenképpen a felhasználó rendelkezésére kell bocsátanunk a szoftvert, és innentől kezdve egy esetleges támadó egyén azt tehet vele, amit csak szeretne. Jelenleg nem ismerünk olyan szoftveres védelmi módszert, amelyet egy kellően elhivatott, és sok idővel rendelkező támadó fel ne tudna törni. Azonban bizonyos lépések tehetők abba az irányba, hogy a dolgát jócskán megnehezítsük. Alapvetően háromféle irányt szokás megkülönböztetni, hogy miként okozhat kárt a szoftver szerzőjének egy rosszindulatú felhasználó: • illegális másolatok terjesztése • a szoftver egyes részeinek (modulok) illetéktelen újrafelhasználása • a programban tárolt szenzitív adatok módosítása Az illegális másolatok ellen szoftverek esetében problémás lenne klasszikus DRM-technikákkal védekezni. Hiszen itt a "lejátszó" szerepében valamilyen, a szoftver lehetőségeit korlátozó futtatókörnyezet állhatna, mely elszigeteli a szoftvert az esetlegesen rosszindulatú gazdakörnyezettől. De ez érezhetően komplikált, és a felhasználói élményből is jócskán elvesz. Máshonnan közelítve, ha a felhasználó identitása valamilyen módon bizonyíthatóan és kitörölhetetlenül jelen lenne a szoftverben, akkor ez visszatartó erő lehetne a szoftver illegális terjesztésével szemben. Ezeket a technológiákat hívjuk vízjelezési (watermarking) és fingerprinting eljárásoknak. A szoftver moduljainak újrafelhasználása úgy történhet, hogy a rosszindulatú felhasználó valamilyen reverse engineering technikával visszafejti a szoftver forráskódját, majd azt értelmezve, bizonyos részeit beépíti saját szoftverébe. Az ilyen típusú visszaélések ellen az obfuszkáció módszerét tudjuk használni. Az obfuszkáció során a szoftvert olyan szemantika-őrző transzformációknak vetjük alá, mely transzformációk után a szoftver visszafejtés nagyságrendekkel
nehezebb feladattá válik, mint kezdetben volt. A szoftverben tárolt olyan adatokat is védenünk kell, melyek megváltoztatásával a felhasználó jogtalan előnyökhöz juthat. Ilyenkor bütykölés-biztos (tamper-proofing) megoldásokat tudunk alkalmazni. Ennek eredményeképpen, ha a program illegális módosítást szenved el, akkor ezáltal használhatatlanná válik, vagy hibás működést produkál. A fent leírt védelmi módszereket gyakran egymással kombinálva alkalmazzák a kívánt szoftverbiztonság elérése érdekében.
4. Vízjelezési technikák A vízjelezés során általában valamiféle plusz információ kerül transzparens módon a szoftverbe, például copyright információk. Kétféle vízjelet kell megkülönböztetnünk aszerint, hogy milyen elvárásoknak kell megfelelnie módosításokkal szemben. Az egyik az úgynevezett törékeny vízjel, amely bármilyen módosítás hatására megváltozik, illetve a robusztus vízjel, amely módosítások, transzformációk hatására sem veszti el információtartalmát. A vízjelezés fontos, speciális esete az úgynevezett fingerprinting, mely során a szoftvertermékbe bekerül a vásárló személy identitására vonatkozó valamilyen egyedi információ, melynek segítségével később bármikor visszakereshető, hogy az adott termék kihez tartozott eredetileg. Amiket elvárunk a szoftverek vízjelezése esetén: • a vízjel megbízhatóan kinyerhető a programból • a vízjel lehet kellően nagy • a vízjel jelenléte a programban nem okoz számottevő teljesítménycsökkenést • a vízjelezés után a program hasonló statisztikai tulajdonságokkal bír, mint az eredeti program, így a vízjel észrevehetetlen • a vízjel olyan matematikai tulajdonságokkal bír, melyek segítségével egyértelműen bizonyítható bizonyos szándékolt műveletek végrehajtott volta Minden konkrét vízjelezési metódus kompromisszumot kénytelen vállalni az előbb felsorolt tulajdonságok közül az első négyben. Ezek után érdemes tisztázni, milyen típusú támadásokra számítunk: • additív támadás: egy újabb vízjelet adunk hozzá a már vízjelezett szoftverhez, így ha nem állapítható meg a vízjelek hozzáadásának sorrendje, nem bizonyítható a tulajdonjog • torzító támadás: szemantika-őrző transzformációknak vetjük alá a programot, reménykedve abban, hogy egy idő után a vízjel már nem nyerhető ki belőle, ám még nem romlott le túlzottan a szoftver használhatósága • összehasonlításos támadás: a támadó több példányt is megvásárol a szoftverből, majd ezen példányok összehasonlításával képes a vízjel helyét beazonosítani, majd eltávolítani azt
4.1 Statikus vízjelezés Kétféle csoportba oszthatjuk a vízjelezési technikákat, a statikus, illetve a dinamikus vízjelekre. Ha magában a szoftver futtatható binárisában helyezzük el a vízjelet, statikus vízjelezésről beszélünk. Amennyiben a vízjel a program futása során épül fel, annak futási állapotterében van kódolva, dinamikus vízjelről van szó. Tipikus statikus vízjelezés, ha egy képben helyezzük el a vízjelet a rengeteg media-vízjelezési technika egyikével, majd ezt a képet helyezzük el a program statikus adatszekciójában. Egy másik megoldás lehet, ha a vízjelet kódoljuk a program vezérlésfolyam-gráfjának alapvető blokk szekvenciájában. Az egyik legerősebb statikus vízjelezési technika, mely során a program vezérlésfolyam-gráfját és a vízjelből épített gráfot összefésüljük, például átlátszatlan predikátumok (lásd később) segítségével. A kinyerési fázisban az eredeti program gráfjának csomópontjait beazonosíthatjuk a vízjelezett gráfon, így megkaphatjuk a vízjel gráfját. Sajnos azonban az összes ma ismert vízjelezési technika ki van szolgáltatva a torzító típusú támadásoknak, egyszerű obfuszkációs módszerekkel megsemmisíthetjük a statikusan tárolt
vízjeleket, mivel ezek a technikák jelentősen módosítják például a vezérlésfolyam-gráfot.
4.2 Dinamikus vízjelezés Négyféle dinamikus vízjelezési technika létezik. Mind a négy esetben a szoftver futása közben egy speciális, valószínűtlen inputtal a programot egy olyan állapotba hozzuk, mely állapot hivatott reprezentálni magát a vízjelet. • Húsvéti tojás vízjel: bizonyos speciális input hatására a felhasználó számára azonnal érzékelhető vízjel jelenik meg. (pl. about:mozilla beírása az URL-mezőbe) • Execution trace vízjel: a húsvéti tojással ellentétben itt nem az outputban, közvetlenül jelenik meg a vízjel, hanem a futás közben egy speciális inputra a cím trace és az operátorszekvenciák bizonyos tulajdonságainak megfigyelésével nyerhető ki • Adat struktúra vízjel: a speciális input hatására itt sem az outputban, hanem a szoftver állapotterében kódolva találhatjuk a vízjelet • Dinamikus gráf vízjel: beágyazzuk a vízjelet egy dinmaikusan épített gráf topológiájába, majd a gráfot felépítő kódot a szoftverben elhelyezzük. A gráfot felépítő kód pointer aliasing hatásai miatt nehéz analizálni és detektálni a vízjelet, és megmutatható, hogy ellenálló a legtöbb dewatermarikng technikával szemben is.
5. Obfuszkáció A security by obscurity (bizonytalanság alapú biztonság) bár a legtöbb esetben bebizonyosodott, hogy kerülendő elv, ezen területen mégis hasznát vehetjük magasabb biztonsági szint elérése érdekében. A folyamat során úgy módosítjuk a programunkat, hogy: • a módosított program érzékelhető viselkedése azonos legyen az eredeti programéval (szemantika-őrző) • az bizonytalanság jelentősen nőjön (nehezebb legyen visszafejteni az új kódot, mint az eredetit reverse engineering technikákkal) • a használt transzformációkat ne lehessen, vagy csak igen nagy időbefektetés árán lehessen visszafelé alkalmazva visszakapni az eredeti kódot • a transzformációk rejtettsége biztosítva legyen, azaz az eredeti kód, és a módosított kód statisztikai tulajdonságai közel azonosak legyenek • a költség (futtatási idő/hely büntetés, amit a transzformációk okoznak) minimális legyen A kódoptimalizálás hasonló az obfuszkációhoz, azzal a különbséggel, hogy a bizonytalanság növelése a kódoptimalizálás esetén nem cél. A cél az lenne, hogy az obfuszkált kódon egy white-box analízis közel azonos komplexitású legyen, mint az ugyanehhez tartozó black-box analízis, azaz a program binárisához való hozzáférés, és annak elemzése nem jelent előnyt ahhoz az esethez képest, ha csupán a szoftver input-output viszonyrendszere alapján tudunk következtetni.
5.1 Lexikális transzformációk A különböző azonosíók, és a program lexikális struktúrájának módosításával nehezebbé tehetjük a támadó dolgát. Az ilyen típusú obfuszkációk valószínűleg zavaróak a támadó számára, de egy valamire való elszánt támadót ez nem gátol meg abban, hogy felfedje, mit is csinál valójában a kód.
5.2 Vezérlési transzformációk A vezérlés-módosító transzformációk alapja az úgynevezett átlátszatlan predikátumok léte. Egy predikátum akkor átlátszatlan, ha az obfuszkáció idején a kimenete ismert, ám a támadó a visszafejtés során nem, vagy csak nehezen tudja megjósolni ezt a kimenetet. Ha egy predikátumról tudjuk, hogy kimenete mindig igaz, akkor egy elágazás igaz ágába helyezve a
futtatni kívánt kódrészt, a hamis ágba pedig zavaró kódot téve máris nehezebbé tettük a támadó dolgát. Ha pedig olyan predikátumot használunk, melynek kimenete néha igaz, néha hamis, akkor az elágazás ágaiba ugyanolyan hatású, de más-más kóddá transzformált műveleteket tehetünk. Egy elterjedt technika erős átlátszatlan predikátumok létrehozására, amikor is karbantart az obfuszkálandó program egy komplex adatszerkezetet. Ezt az adatszerkezetet az obfuszkált kód néha módosítja, de olyan módon, hogy néhány invariáns benne marad. Ezen invariánsokra megfogalmazott logikai állítások kimenete tehát az obfuszkáció idején is predikálható, segítségével átlátszatlan predikátumokat képezhetünk.
5.3 Adat transzformációk Ezen transzformációk során a szoftver adatstruktúráin végzünk szemantika-őrző átalakításokat. Például a változó-szétválasztás technikája során egy boolean változót reprezentálhatunk két integerrel, majd a megfelelő boolean operátorokat leképezhetjük az integerek közti operátorokra. Ennek során akár többféle operátor-szekvencia is jelentheti egyazon boolean művelet végrehajtását, így még inkább zavarva a visszafejtőt.
6. Bütykölés-biztosság Fontos védelmi szempont lehet, hogy amennyiben egy szoftvert módosítottak, az a szoftver többé ne fusson, vagy ne fusson helyesen. Ilyen helyzetek lehetnek például: • a program vízjelezett, és módosítják azt • vírust csatoltak a programhoz • egy e-kereskedelmi szoftver biztonság-kritikus részét módosították Ilyen esetekben szokás bütykölés-biztos kódot adni a szoftverhez, melytől elvárjuk, hogy: • detektálja, ha a szoftvert módosították • okozzon programhibát, ha a bütykölés bebizonyosodott Ideális esetben a detekció és a programhiba jól szét kell hogy legyen szórva a program terében, és futásidejében, hogy megtévessze a potenciális támadót. Az alábbi megközelítések léteznek: • A program ellenőrzi, hogy identikus-e saját magával. Ennek felgyorsítására MD5 ellenőrző összeget szokás használni. • Ellenőrizhetjük a program által produkált köztes eredményeket, ez alapján döntve arról, hogy módosítva lett-e. • Enkriptelhetjük a futtatható binárist, ezáltal meggátolva a támadót abban hogy módosítsa, egészen addig, amíg nem képes dekriptelni azt. Az egyik megvalósítás a védendő kódot egymásba ágyazott ciklusokba szervezi, és a ciklusbelépési kód az, ami a ciklus magját dekripteli. Ezzel a módszerrel jócskán nehezítjük a debuggerprogramok alkalmazását, és ezáltal a kód visszafejtését. Egy másik megvalósításban a programot több részre bontjuk és ezeket egyenként enkripteljük Az így létrejött kód futása során mindig csak az éppen futó szegmens van dekriptelve a memóriában. Miután egy szegmens lefutott, dekriptelhető a szükséges következő szegmens egy származtatott kulcs alapján, és a lefutott szegmens pedig ismét kriptelhető. A program továbbá úgy van konstruálva, hogy minden állapot, amelyben a program éppen lehet, függvénye az összes korábbi meglátogatott állapotának. Ezzel garantálható, hogy amennyiben akár csak egy bit is megváltozik a bütykölés-biztos kódunkban, az előbb-utóbb programhibát fog eredményezni. Ez a hiba azonban kellően távol fog kibukni a detekcióhoz képest.
7. Hardver-asszisztált másolásvédelem A hardveres megoldások a szoftver másolásvédelemben kettős megítélésűek. Egyrészt, mivel egy hardver általában jóval nehezebben sokszorosítható mint egy szoftver, amennyiben egy ilyen egyedi hardver a rendszerben való jelenlétéhez tudjuk kötni a szoftver teljes értékű működését, magasabb
védelmi szintet érhetünk el. Ugyanakkor azonban a hardvergyártásnak általában a költségvonzatai is magasabbak, mint a szoftvereké, illetve a felhasználók számára a legtöbb esetben kényelmetlenséget okoznak. Ezért ilyen megoldásokat általában csak nagyon drága termékekkel kapcsolatban alkalmaznak, mint például CAD/CAM szoftverek esetében. Most a teljesség igénye nélkül ismertetek két ilyen hardveres megoldást.
7.1 Dongle eszközök Az első ilyen eszközt a WORDCRAFT nevű szoftverhez alkalmazták, melyet a feltaláló nevezett el „dongle”-nek, megfelelő terminus technikus hiányában. Nevezik még hardverkulcsnak és hardveres tokennek is. Ezek az eszközök általában két interfésszel rendelkeznek: •
egyrészt egy adatátviteli interfész, mely tranziens adatáramlást biztosít
•
másrészt egy pull-jellegű kommunikációt megvalósító interfész, ahol a megfelelő szenzitív biztonsági adatok kiolvashatók
Léteznek olcsó, sztenderd USB flash drive alapú megvalósítások is, melyek az eszköz egyedi szériaszámát, és a dongle-ön tárolt, végfelhasználó által nehezen módosítható egyéb információkat használják, ám ezek közel sem nyújtanak olyan biztonságot, mint a direkt erre a célra tervezett dongle eszközök.
7.2 Cryptoprocesszorok Ezen eszközök leggyakrabban SMART kártyákban fordulnak elő, de alkalmazzák őket ATM-ekben, set-top boxokban illetve katonai célokra is. Az eszköz alkalmas titkosított formában érkező szoftverkód futtatására, így kihasználva azt a tényt, hogy a különböző médiatartalmakkal ellentétben itt nem szükséges a végfelhasználó számára közvetlen felfedni a programot, az végig titkosítva haladhat a számítógép buszain, és csak a cryptoprocesszorban kell dekriptelni, majd végrehajtani. Ezáltal gátolható az illetéktelen bütykölés, illetve másolás, a visszafejtés pedig igen nehéz feladattá válik, az alkalmazott kriptográfiai algoritmustól függően.
8. Egyéb megoldások Léteznek a fent elterjedt megoldásokon kívül még más módszerek is, áttekintő jelleggel néhányat itt is kiemelnék: •
szoftver feketelistázás: ezzel a módszerrel a védett szoftver képes felismerni a gazdarendszerre telepített egyéb szoftvereket, és amennyiben olyan gyanús szoftverek vannak telepítve a számítógépre, amelyek tipikus eszközei a másolásvédelmi módszerek kijátszásának, a szoftver nem fog funkcionálni, vagy hibás működést fog produkálni. Az ilyen gyanús szoftverek egy feketelistába vannak gyűjtve, tipikus példák lehetnek a Daemon Tools, vagy az Alcohol 120%
•
regisztrációs kulcs: egy számokból és betűkből álló kombináció, mely szükséges ahhoz, hogy a program elinduljon. Ez a szám egyedi minden felhasználóra, a hiányában a szoftver nem, vagy hibásan működik. Multiplayer játékok esetében például ki lehet szűrni az azonos regisztrációs kulccsal részt vevő játékosokat, és kizárni őket.
•
telefonos aktiváció: elvárja a felhasználótól, hogy egy megadott számot felhívva, regisztrálja be a termékét, majd egy számítógép-specifikus szériaszámot kap, s csak ezzel tudja használni a szoftverterméket.
9. Véleménynyilvánítás A szoftver másolásvédelem fent részletezett technológiái bizonyos esetekben hasznosak, sőt nélkülözhetetlenek. Az emberi természetből adódóan van néhány olyan terület, ahol elkerülhetetlen az, hogy felkészüljünk és védekezzünk ilyen módon is. Ilyenek például banki rendszerek, azok automatái, amelyeket működtető szoftverektől valóban elvárjuk, hogy ne foroghassanak közkézen, illetve ne lehessen őket módosítani illetéktelenek számára. A katonai alkalmazások hasonló megfontolásokból szintén indokoltak lehetnek. Azonban az iparban én a fejlődés szempontjából igen nagy gátnak tartom az ilyen jellegű technológiákra történő támaszkodást, és a szoftver, mint szellemi tulajdon kisajátítását, illetve sokak számára elérhetetlen pénzösszegeken való hozzáférhetőségét. Ráadásul megfelelő lobbihadjáratokkal, illetve durva, aggresszív marketinggel a piac vezető tényezői elérik azt, hogy gyakorlatilag ne is legyen más választásunk, minthogy használjuk, adott esetben – szükség törvényt bont alapon – ellopjuk ezeket a szoftvereket. Az informatika hőskorában nem volt ez így, a szoftver közkincs volt. S most is egyre inkább bizakodó vagyok, hiszen a különböző free software mozgalmak, alapítványok, és az egész közösség képes volt egy olyan önszerveződő egységgé kinőni magát, amely már jócskán kompetitív a profitorientált piaci résztvevőkkel. Sőt, néhány nagy cég is meglátta ebben a fantáziát, méghozzá abban a kulcsgondolatban, hogy nem feltétlen a szoftver darabszámra történő eladásában van a potenciális profitforrás, hanem az eköré épített plusz szolgáltatásokban. Ennek ékes bizonyítékai, a „software as a service” modell nagymértékű terjedése, a szerver-világban, azon belül is a webes kiszolgáló rendszerek területén a szabad szoftverek lassan egyeduralkodó pozíciója, illetve hogy egyre több irodai, és desktop környezetben váltja fel a „pénzes” megoldást a free software alternatívája. Talán még megérjük azt – és a magam részéről én ebben reménykedem – hogy nem kell többé serial kulcsokkal bajlódnunk, kártékony programokkal teli crackeroldalakon molyolnunk, és azon aggódnunk, hogy vajon melyik megvásárolt szoftver éppen milyen szenzitív információt továbbít rólunk az éterbe.
Felhasznált források •
Dr Buttyán Levente A biztonságos elektronikus kereskedelem alapjai c. tárgyának előadásfóliái
•
Christian S. Collberg és Clark Thomborson: Watermarking, Tamper-proofing, and Obfuscation – Tools for Software Protection
•
http://www.wikipedia.com/
