Gadu gadu Skype

Archiwum dla tagu: ‘Software’

lut
12

Zabezpieczanie oprogramowania

Spook, Luty 12 2012

Skomentowany 1 raz

Właśnie wypuściłem wersję 1.0.0 ProCalca. Program ten funkcjonuje w dwóch trybach: darmowym (prostym) i rozszerzonym; ten ostatni dostępny jest po zarejestrowaniu programu poprzez instalację pliku licencyjnego. Z uwagi na fakt, iż część programu jest zablokowana przed dostępem dla każdego użytkownika, zacząłem myśleć o tym, w jaki sposób go zabezpieczyć.

Zacząłem więc szukać w informacji w Internecie – od rozwiązań prostych, darmowych do bardziej skomplikowanych, płatnych. Myślałem o tym, jakiego rodzaju zabezpieczenia mogę wprowadzić, i w jaki sposób będzie można byłoby je złamać. Przeczytałem sporo artykułów w poszukiwaniu skutecznej metody zabezpieczenia programu. I wiecie, do jakiego doszedłem wniosku?

Nie da się tego zrobić.

Sprawa jest bardzo prosta. W momencie publikacji programu wszystkie jego binaria stają się dostępne użytkownikowi końcowemu, który z natury rzeczy może z nimi zrobić cokolwiek zapragnie. W praktyce więc każde zabezpieczenie jest on w stanie złamać – jedyną kwestią jest czas, w jakim się to stanie. Jeżeli ktokolwiek powie Ci coś innego – kłamie.

Zaakceptowanie powyższego stwierdzenia przyszło mi ze sporym trudem. Piszę programy hobbystycznie w wolnym czasie, wkładam w nie całe serce i gdy ktoś łamie moje oprogramowanie, czuję się, jakby wyjmował mi pieniądze z kieszeni. Nic dziwnego więc, że do kwestii zabezpieczeń podszedłem z dosyć osobistym nastawieniem. Ale fakty są faktami: moje oprogramowanie zostanie złamane. Kropka.

Nie wygląda to zbyt różowo, prawda? Ale poczytałem trochę więcej o strategiach zabezpieczania programu i okazuje się, że rozwiązania problemu nie należy szukać w paranoicznych zabezpieczeniach, tylko we właściwej strategii jego dystrybucji.

Po pierwsze, zdefiniujmy jasno nasz target. Są ludzie, którzy naszego programu nie kupią. Jeśli ktoś przygotuje cracka, to będą używali pirata, jeśli nie, to go nie będą używać w ogóle. Na tych osobach po prostu nie zarobimy. Z drugiej jednak strony mamy firmy, które nie mogą pozwolić sobie na pracę na pirackim oprogramowaniu oraz ludzi, który nie chcą tego ryzykować, uważają takie zachowanie za niewłaściwe albo choćby nie mają dostatecznego doświadczenia, aby znaleźć crack do programu. I to są właśnie nasi docelowi klienci: nawet jeśli zabezpieczenia programu zostaną złamane, oni go kupią.

Druga sprawa: trzeba mieć cały czas na uwadze, że istotą crackowania programu jest zdejmowanie zabezpieczeń. Czyli osoba, która używa pirata żadnego z tych zabezpieczeń nie zobaczy na oczy – w przeciwieństwie jednak do uczciwego klienta, który nasz program kupił. W efekcie każdy pojedynczy DRM, który zostanie dodany do naszego programu utrudnia życie osobom, które kupiły nasze oprogramowanie.

Kiedyś kupiłem sobie grę – był to bodaj Tomb Raider Anniversary. Zainstalowałem, uruchamiam (oczywiście klucz podany, płyta w napędzie i tak dalej), a tu gra mi mówi, że się nie uruchomi, bo na komputerze znajduje się ProcMon (to takie narzędzie diagnostyczne, bardzo pomocne w pracy programisty, ale można go też używać do łamania zabezpieczeń). I koniec, nie byłem w stanie uruchomić gry. Skończyło się na tym, że przeszukałem Internet i znalazłem cracka. O ironio! Musiałem łamać zabezpieczenia gry, za którą uczciwie zapłaciłem. Jest to chyba najlepszy dowód na bezsens windowania mechanizmów DRM w aplikacji.

Przeciwko pisaniu skomplikowanych zabezpieczeń przemawia jeszcze jeden argument: czas spożytkowany na ich pisanie to czas, który spędziliśmy na walce z wiatrakami zamiast na pisaniu naszego oprogramowania. Użytkownik nie kupi programu, który jest wprawdzie zabezpieczony przed niepowołanym dostępem lepiej niż sam Pentagon, ale liczba zabezpieczeń przewyższa liczbę jego praktycznych funkcji.

Jaką więc strategię przyjąć podczas walki z łamaniem zabezpieczeń naszego oprogramowania?

Pierwszym krokiem jest całkowite wyeliminowanie jednego z naszych przeciwników; mowa tu o tzw. keygenach, czyli programach, które są w stanie wygenerować prawidłowe klucze licencyjne do naszego programu. Keygen to bardzo duży problem; cracker łamie program raz, a potem napisany przez niego generator działa dla każdej wersji naszego programu. Gdy w takiej sytuacji zdesperowani zmienimy algorytmy odpowiedzialne za weryfikację kluczy, nagle okaże się, że musimy wysłać wszystkim dotychczasowym klientom nowe klucze, co po pierwsze jest kłopotliwe z punktu widzenia logistyki, a po drugie – stanowi niedogodność dla tych ostatnich, którzy nagle są zmuszeni do ponownej rejestracji programu.

Dobra wiadomość jest taka, że zabezpieczenie się przed keygenami jest stosunkowo łatwe – wystarczy zastosować zwykłe szyfrowanie asymetryczne: szyfrujemy kluczem prywatnym licencję (lub jej skrót), a w programie zaszywamy klucz publiczny. Program jest wówczas w stanie rozszyfrować i zweryfikować licencję, ale sam klucz publiczny (który wprawdzie można łatwo wyciągnąć z zasobów programu) nie wystarcza, żeby wygenerować nową licencję. Pirat ma dwa wyjścia: spróbować złamać szyfr albo ukraść nam klucz prywatny. Jeżeli tylko zabezpieczymy odpowiednio ten drugi, to drugą połowę roboty odwali za nas matematyka algorytmiki szyfrowania asymetrycznego. Dosyć powiedzieć, że złamanie algorytmu pokroju RSA w rozsądnym czasie jest praktycznie niemożliwe.

Postawiony w takiej sytuacji cracker zostanie zmuszony do obejścia zabezpieczenia zamiast jego złamania, co prawdopodobnie w końcu mu się uda. Efektem jego pracy będzie crack, czyli program, który modyfikuje pliki naszego programu tak, by zabezpieczenia przestały działać, bądź wręcz same zmodyfikowane pliki.

Wiemy już, że nie uda nam się rozwiązać tego problemu bezpośrednio. Ale możemy to zrobić w inny sposób: często wypuszczając nowe wersje programu (nawet z niewielkimi zmianami). Jeżeli program zawiera inteligentnie napisany mechanizm aktualizacji, to końcowy użytkownik nie odczuje za bardzo częstych release’ów, ale dla crackera będzie to już spory problem, ponieważ będzie zmuszony do łamania każdej wersji z osobna i wypuszczania nowych cracków – szczególnie, gdy w mechanizmach zabezpieczających wprowadzimy jakieś niewielkie zmiany.

Jest jeszcze jeden aspekt, o którym się nie wypowiedziałem: cena. Jeżeli promowanemu programowi ustalimy bardzo wygórowaną cenę, więcej osób zdecyduje się na korzystanie z kopii pirackich zamiast z wersji pełnych. Ewolucję cen we właściwym kierunku da się zauważyć na rynku gier na urządzenia mobilne. Kiedyś gry na Nokię N-Gage kosztowały po 150-200 PLN. Teraz gry, które są o kilka rzędów bardziej rozwinięte technologicznie w odpowiednich sklepach (Android Market, App Store itd.) można kupić po 3 PLN. Jeżeli ktoś może taką grę kupić za trzy złote, to nie opłaca mu się tracić czasu na szukanie wersji pirackiej – i tu programista wygrywa z piratem. Warto popatrzeć na to jeszcze z tej perspektywy: łatwiej znaleźć 1000 osób, które zapłacą złotówkę niż jedną, która zapłaci 1000 PLN.

Fakt istnienia oprogramowania pirackiego wbrew pozorom ma trochę zalet. Programiści i wydawcy są zmuszeni wyjść naprzeciw użytkownikom, a poza tym – bądźmy szczerzy – piractwo stanowi również formę promocji oprogramowania. Mam jednak nadzieję, że niebawem rynek oprogramowania zmieni się w taki sposób, że piractwo przestanie się po prostu opłacać.

Edit: Kilka dyskusji wartych przeczytania.