DRM w systemie operacyjnym CROOK-5: Różnice pomiędzy wersjami

Jak się okazuje, historia odnalezionych zabezpieczeń sięga dalej, zarówno w czasie jak i przestrzeni, niż piąta wersja systemu operacyjnego z Politechniki Gdańskiej.

Wszystko zaczęło się w Instytucie Informatyki Uniwersytetu Warszawskiego. Pracujące tam MERY-400 działały pierwotnie pod kontrolą systemu operacyjnego SOM-3. Z czasem, kiedy rozwijane w Instytucie oprogramowanie dojrzało do stanu, w którym można je było oferować odpłatnie potencjalnym klientom, pojawił się problem: jak radzić sobie z nielegalnymi kopiami? Rozwiązaniem stała się modyfikacja SOM-3, implementująca mechanizmy uniemożliwiające poprawną pracę pirackich wersji chronionych programów.

Pierwszym, kluczowym elementem mechanizmu jest identyfikator systemu. W zmodyfikowanym systemie SOM-3 był on zapisany w ciele systemu operacyjnego i różnił się między kopiami dostarczanymi użytkownikom końcowym. Pozwalał więc rozróżnić kopie SOM-3, ale nie maszyny, na których system był uruchamiany. W CROOK-5 identyfikator jest natomiast sprzętowy, a więc związany z konkretnym egzemplarzem komputera. Istnieją dwie implementacje rozwiązania i w zależności od lokalizacji identyfikator potocznie nazywany był „numerem procesora” lub „numerem zegara”. Obie wersje zrodziły się w Instytucie Okrętowym Politechniki Gdańskiej i tam też powstał prototyp pierwszej z nich. W systemie operacyjnym CROOK-5 identyfikator dostępny jest w przestrzeni jądra pod zmienną nazwaną w źródłach '''PROCNU'''.

W nieco starszej wersji rozwiązania, identyfikator schowany jest w [[Zegar czasu rzeczywistego Amepolu|zegarze czasu rzeczywistego]]. Urządzenie to, instalowane jako kolejna jednostka w kanale znakowym, dysponuje również pamięcią PROM, na której zapisany jest bootloader pozwalający „ściągnąć” system operacyjny z dysku do pamięci komputera (poprzez mechanizm [[Wczytywanie binarne|wczytywania binarnego]]). Tuż za znacznikiem końca kodu bootloadera zapisany jest identyfikator systemu, zwany wtedy (ze względu na swoją lokalizację) „numerem zegara”.

Po uruchomieniu systemu CROOK-5 za pomocą tego bootloadera, sprzętowy licznik adresujący kolejne bajty w pamięci PROM zegara nie zmienia swojej wartości. Dzięki temu, wysyłając do urządzenia kolejne rozkazy czytania, można kontynuować pobieranie danych. Identyfikator systemu zapisany jest na trzech kolejnych bajtach pamięci PROM. Ich cztery najmłodsze bity zawierają kolejne (od najstarszej) cyfry identyfikatora zapisane w kodzie BCD.

Późniejsze, ostateczne rozwiązanie używa do przechowywania identyfikatora ostatniego słowa pamięci stałej (zrealizowanej na kościach EEPROM) w [[Pamięć MEGA|pamięci MEGA]] Amepolu. System operacyjny wczytuje go podczas startu:

Lokalizacja adresów jest w zasadzie dowolna, jednak z założenia o niejawności powinny znajdować się one w odległych miejscach programu, tak, aby możliwie dobrze ukryć przed wzrokiem intruza dane pod nimi zapisane. Jedyną wymuszoną lokalizacją jest adres słowa zawierającego '''A1+C'''.

* załaduj zawartość '''A3''' (=A2+C) i sprawdź poprawność '''A2''',

== Ograniczenie działania nielegalnej kopii programu ==

Rysunek obok pokazuje w jakie obszary w przestrzeni procesu system operacyjny trafia losowymi adresami. Generator liczb pseudolosowych czerpał entropię z informacji o tym, w jakim momencie okresu pracy planisty systemu operacyjnego nastąpiło wywołanie systemowe czytania ze strumienia. Ocena jakości generatora nie ma sensu w warunkach emulacji, ponieważ parametry czasowe pracy takiego systemu odbiegają znacznie od prawdziwej maszyny.

Umieszczenie stosownej struktury danych w programie jest tylko przygotowaniem terenu. Obserwacja zachowań systemu operacyjnego pokazuje, że pole '''SYSID''' musi jeszcze zostać w specyficzny sposób wypełnione. Służy do tego dodatkowe narzędzie: '''UZDAT'''.

Zachowanie to jest o tyle ciekawe, że identyfikator systemu nie jest informacją dostępną dla programu użytkowego wprost. Narzędzie używa sztuczki korzystającej z faktu, że system operacyjny w trakcie ładowania zabezpieczonego programu zapisuje pod '''SECRET_M''' różnicę między numerem systemu zapisanym w programie, a znanym sobie, uprzednio wymieszanym numerem procesora. UZDAT jest „zabezpieczonym” programem - zawiera strukturę danych go identyfikującą, ale w polu '''SYSID''' wpisane ma '''0'''. '''SECRET_M''' jest więc po uruchomieniu programu ustawione przez system operacyjny na '''SYSID''' wymieszane funkcją '''GEN()'''. Ponieważ funkcja ta jest odwracalna i programowi znane są wartości '''C''', '''A3''' i '''A2''', '''UZDAT''' może z '''SYSID''' obliczyć faktyczny numer procesora.

Pozostaje jeszcze pytanie dlaczego CROOK-5 nie niszczy UZDAT, skoro ten ma wpisany niepoprawny, zerowy identyfikator systemu? Autor narzędzia, znając oczywiście zachowanie CROOK-a, zabezpieczył się przed jego niszczycielskimi zapędami używając do czytania danych wyłącznie ekstrakodów transmisji blokowych, które nie wyzwalają procedury nadpisującej zawartość pamięci procesu.

Atak na identyfikator systemu wymaga najmniej zaangażowania intelektualnego, ale jest jednocześnie najmniej elastyczny. Zakładając, że komuś udałoby się uzyskać wiedzę o istnieniu i lokalizacji numeru procesora lub numeru zegara, mógł on przygotować „klon” innego komputera i z powodzeniem uruchamiać na nim oprogramowanie zakupione dla klonowanej maszyny. Choć mało elastyczne, rozwiązanie to nie jest pozbawione praktycznego zastosowania - dwóch lub więcej użytkowników systemu mogło „umówić” się i dzielić kosztami oprogramowania. Atak ten ma jedną silną zaletę: nie wymaga absolutnie żadnej wiedzy na temat tego, jak mechanizm zabezpieczeń naprawdę działa.

Ataki na system operacyjny wymagają największej wiedzy, są najtrudniejsze w realizacji, ale dają najlepsze rezultaty. Raz złamany CROOK-5 zawsze już uruchomi dowolny program, przeznaczony dla dowolnego innego komputera. Można rozpatrzyć dwa różne podejścia. W obu przypadkach atakujący musi przede wszystkim zdeasemblować i przeanalizować jądro systemu. O ile deasemblacja nie stanowi problemu, a analiza, choć żmudna, ma ten sam poziom skomplikowania co i dziś, o tyle śledzenie działania systemu wymaga podejścia do niego „z zewnątrz”. A jedyną w praktyce dostępną technologią, która pozwalała na to w latach '80 było użycie pulpitu technicznego MERY-400. To czyni z zadania iście syzyfową pracę.

Dodatkowo, po odpowiednim „poprawieniu” systemu operacyjnego czeka na intruza jeszcze jedna niespodzianka. CROOK-5, zarówno podczas startu, jak i cyklicznie, w trakcie działania, sprawdza swoją sumę kontrolną. A z niewłaściwą sumą kontrolną odmówi uruchomienia się. Ostatnim krokiem musi więc być odnalezienie gdzie i jak liczona jest wspomniana suma i albo jej poprawienie, albo zablokowanie również tego mechanizmu.

Atak na program użytkowy jest o tyle prostszy od ataku na jądro CROOK-a, że śledzenie wykonywania procesu w systemie można przeprowadzić za pomocą debuggera DEBU dostarczanego wraz z CROOK-iem, co jest znacznie efektywniejsze, niż używanie pulpitu technicznego. Problem polega na tym, że bez żadnej podpowiedzi trudno jest odnaleźć sprytnie schowaną między linijkami programu strukturę danych, która w najlepszym wypadku używana jest jednokrotnie, a i to tylko w jednym jej punkcie.

Ostatecznym rezultatem ataku jest natomiast „złamany” program, który nie tylko jest już na zawsze gotowy do użycia na danej maszynie, ale zadziała również na innych komputerach. Po niewątpliwie czasochłonnym rozgryzaniu zabezpieczeń jednego programu użytkowego dostaje się też przepis, który bez wysiłku pozwala odblokowywać kolejne programy. Wystarczy bowiem tylko: