Najskuteczniejszym sposobem zabezpieczania aplikacji przed nielegalnym kopiowaniem są klucze sprzętowe. Niedawno pojawiło się wiele tańszych zabezpieczeń programowych.

Firma produkująca standardowe aplikacje czy twórca oprogramowania nie mogą zwiększyć kosztów produktu o cenę drogiego klucza sprzętowego. W takiej sytuacji jedynym rozwiązaniem jest zabezpieczenie programu przez umieszczenie w nim odpowiednich mechanizmów wymuszających rejestrację czy sprawiających, że nie zarejestrowana wersja po pewnym czasie przestaje działać.

Wszystko można złamać

Obecnie najczęściej spotykane zabezpieczenie wymaga, by użytkownik potwierdził zakup aplikacji, wprowadził swoje dane i podał odpowiedni kod. Jeżeli te informacje są zgodne, aplikacja zostaje odblokowana. Takie zabezpieczenie nie jest skuteczne, ponieważ często w Internecie można bez trudu znaleźć kombinację nazwy i klucza dla danej aplikacji.

Inne rozwiązanie zastosowano w systemach, w których nie ma konieczności wprowadzania informacji o użytkowniku. Aplikacja w wersji próbnej jest rozprowadzana wraz ze specjalnym plikiem, który pełni rolę klucza, odblokowującego aplikację. Przykładem takiego zabezpieczenia jest Guardian Angel Protection System (GAPS). Pozwala on tworzyć cztery typy klucza. Klucz shareware umożliwia np. określenie zawartości ekranu przypominającego o konieczności zarejestrowania produktu, a także maksymalnego czasu działania aplikacji. Informacje te GAPS skutecznie ukrywa w systemie. Klucz demo pozwala ograniczyć liczbę uruchomień aplikacji lub jej funkcjonalność. Dwa pozostałe typy klucza w pełni odblokowują aplikację: tymczasowy (wydawany gdy użytkownik zapłacił np. kartą kredytową, ale jeszcze pieniądze nie zostały przelane) i wersja pełna (klucz zawiera zakodowane informacje o użytkowniku). W systemie GASP klucz jest zakodowanym plikiem, jego zdekodowanie jest skomplikowane. Jednak można to przeprowadzić. Możliwe jest także złamanie algorytmu, za pomocą którego klucz został utworzony.

Wiele dostępnych rozwiązań opiera się na pewnym "substytucie" klucza sprzętowego. Może to być np. spec- jalnie sformatowana dyskietka czy CD-ROM. Jednak te rozwiązania utrudniają pracę legalnym użytkownikom. Nie jest bowiem wygodne, jeżeli aplikacja wymaga, by w napędzie zawsze znajdowała się określona dyskietka czy płyta.

Klucz jednorazowy

Skuteczniejsze są rozwiązania, w których klucz jest jednorazowy i pozwala zainstalować aplikację tylko raz. Po zakupieniu aplikacji, użytkownik musi podczas każdej instalacji skontaktować się z firmą ją dystrybuującą, by otrzymać klucz właściwy tylko dla tej instalacji. Zwykle klucz można otrzymać przez e-mail lub WWW . Takimi rozwiązaniami są np. systemy Modern TrialX, Crypto++ czy SG Licenser.

Modern TrialX jest przeznaczony do tworzenia wersji testowych aplikacji. Pozwala łatwo blokować poszczególne elementy funkcjonalne aplikacji. Można np. określić, że konkretna opcja będzie wykorzystana tylko 5 razy. Crypto++ dysponuje ponadto możliwością przekazywania licencji, np. dany klucz może być przeniesiony na inne stanowisko. Klucze generowane przez SG Licenser zależą głównie od konfiguracji sprzętowej komputera. Należy ponownie wystąpić o klucz np. po zmianie procesora czy rozszerzeniu pamięci.

Na poziomie kodu

Większość spośród tych produktów współpracuje z dowolnym językiem programowania Windows. Zwykle jest wymagane tylko to, by istniała możliwość dołączenia do projektu biblioteki lub wykorzystania kontrolki ActiveX. Niestety żadne z rozwiązań nie pozwala na umieszczenie kodu sprawdzającego, czy aplikacja jest zarejestrowana bezpośrednio w jej kodzie. Sprawdzenie zawsze polega na wywołaniu odpowiedniej proce- dury. W zasadzie wystarczy, by cracker zablokował w jednym miejscu pro- cedurę sprawdzającą legalność, a wtedy całe zabezpieczenie zostanie usunięte.

Część rozwiązań łączy metody zabezpieczania na podstawie specjalnego klucza ze skomplikowanym kodem utrudniającym debugowanie aplikacji (co utrudnia jej złamanie).

VBOLock firmy MoonLight Software zabezpiecza aplikację za pomocą unikalnego klucza, właściwego dla danego komputera i instalacji. Jed- nocześnie zmienia się plik wykonywalny aplikacji w taki sposób, że nie działa po skopiowaniu na inny komputer. VBOLock wykrywa zarówno działające debugery (w tym SoftIce 4.0), jak i narzędzia do śledzenia zdarzeń w systemie (APIMon itp.). W momencie, gdy VBOLock wykryje działa- jący debuger, zabezpieczona aplikacja kończy działanie. VBOLock wymaga, by programista wprowadził pewne zmiany w kodzie aplikacji. VBOWatch - inny produkt tej firmy - zawiera zaawansowane procedury, zapobiegające reverse engineering (tzn. na podstawie istniejącego kodu odczytanie modelu aplikacji), a także ma możliwość kompresji pliku wykonywalnego.

Klucz Aladyna

Zabezpieczeniem innej klasy jest Privilege firmy Aladdin. Oprócz narzędzi do programowego zabezpieczania aplikacji, programista ma do dyspozycji pełen pakiet, pozwalający elastycznie konstruować licencje na produkty. Otrzymuje również narzędzia ułatwiające stworzenie serwisu internetowego z automatyczną dystrybucją wersji testowych czy wydawaniem tymczasowych kluczy odblokowujących.

Privilege może pracować w dwóch trybach. Jeżeli aplikacja jest samodzielna (jednostanowiskowa), to wszystkie komponenty zabezpieczające są wgrywane wraz z nią. Jeżeli natomiast jest to aplikacja sieciowa, to komponenty licencyjne mogą być instalowane na specjalnym, jednym w firmie, komputerze, a wszystkie aplikacje będą się łączyć z tym serwerem, by kontrolować licencje. Serwer licencyjny może obsługiwać wiele różnych aplikacji zabezpieczonych systemem Privilege.

Privilege pozwala na wygodne zarządzanie licencjami. Licencja może być związana nie z całą aplikacją, ale z poszczególnymi modułami. Korporacja może np. kupić program, gdzie będą odblokowane tylko niektóre podstawowe moduły. Pozostałe będą dostępne jako wersja próbna czy licencja tymczasowa. Specjalne narzędzie do tworzenia raportów pozwala sprawdzić, kto i jak długo korzysta z danego modułu. Na podstawie raportu można łatwo określić, które elementy systemu są rzeczywiście potrzebne.

Unikalną cechą Privilege jest możliwość definiowania licencji, które nie są na stałe przypisane konkretnemu modułowi aplikacji. Licencje można przesuwać pomiędzy komponenta- mi. Przykładowo, zakupiono licencję na 3 moduły. Po pewnym czasie klient rezygnuje z jednego z nich i odblokowuje inny.

Wszystkie operacje związane z li- cencjami są wykonywane za poś- rednictwem automatycznie tworzonych listów elektronicznych czy komuni- kacji pomiędzy komponentem licen- cyjnym klienta a Privilege działa- jącym na serwerze producenta systemu. Można także powiązać zakup licencji, która jest wydawana natychmiast, z systemem sprzedaży (fakturowa- nia), który umożliwia wystawienie faktury.

W Privilege licencję można uzależnić od niemal dowolnego kryterium: liczby równoczesnych użytkowników, liczby instalacji, liczby uruchomień systemu, modułu czy wielkości zużytych zasobów. Możliwe jest np. takie skonstruowanie aplikacji, by klient płacił za każdy wydrukowany raport czy za złożone przetwarzanie wykonywane w systemie.

Privilege, oprócz specjalnego API, pozwalającego sprawdzać stan licencji, umożliwia "opakowanie" gotowych modułów aplikacji w specjalną kopertę, która sprawdza, czy dany element może być uruchomiony. Wtedy zabezpieczenie gotowej aplikacji trwa kilka minut. Jest to jednak zdecydowanie mniej skuteczne niż umiejętne wbudowanie wywołań API.