Autor Wątek: Budowanie prostego systemu DRM  (Przeczytany 4224 razy)

Offline revo

  • Użytkownik

# Styczeń 28, 2009, 23:41:36
Rozważam ostatnio napisanie prostego systemu DRM, dzięki któremu można by było zabezpieczać grę udostępniając ją do sprzedaży. Niestety nie bardzo wiem od której strony się do tego zabrać -- próbowałem coś szukać w sieci na ten temat, ale niestety nie udało mi się na razie.

Może ktoś, kto ma jakieś doświadczenie w tej kwestii mógłby się wypowiedzieć?

Chyba, że znacie jakieś takie dobre systemy, które dostępne są na przystępnych warunkach (np. mały, procentowy udział w zyskach). Interesuje mnie limitowanie czasu gry / dostępu do zasobów (np. części gra by nie widziała) i jakaś obsługa płatności.

Znalazłem, jakąś pracę na ten temat, Building secure software-based DRM systems
« Ostatnia zmiana: Styczeń 28, 2009, 23:52:14 wysłana przez revo »

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline misioslaw

  • Użytkownik
    • www.asmforce.eu

# Styczeń 29, 2009, 00:30:27
Chcesz to wydawać sam?
Bo o zabezpieczenia to powinien się martwić wydawca nie twórca gry.

Offline revo

  • Użytkownik

# Styczeń 29, 2009, 00:39:29
Chcesz to wydawać sam?

Rozważałem dystrybucję na swojej stronie internetowej / udostępnianie dem, których nie muszę jakoś specjalnie przygotowywać.

Offline vashpan

  • Użytkownik
    • Strona

# Styczeń 29, 2009, 01:01:31
IMO jakiekolwiek zabezpieczenia gier komputerowych po prostu mija sie z celem, byc moze dla neiwielkich niezaleznych gierek moze nie az tak bardzo, bo sa mniej "lakomym" kaskiem dla crackerow, ale wydawanie milionow $ na zabezpieczenia mainstreamowych gier moim zdaniem to kompletny nonsens, a do tego coraz bardziej irytuje legalnych uzytkownikow...

Ale do rzeczy, w takiej malej gierce wydaje mi sie ze najlepiej byloby zrobic cos na ksztalt internetowej aktywacji, albo dystrybucja kluczy/weryfikacja ich przez neta.  Chyba dosc proste, ale wymaga zaangazowania jakiegos wlasnego serwera... No ale oczywiscie to tylko moje dywagacje, doswiadczenia niestety nie mam w tych sprawach...

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Styczeń 29, 2009, 01:41:03
Cytuj
Rozważam ostatnio napisanie prostego systemu DRM, dzięki któremu można by było zabezpieczać grę udostępniając ją do sprzedaży. Niestety nie bardzo wiem od której strony się do tego zabrać -- próbowałem coś szukać w sieci na ten temat, ale niestety nie udało mi się na razie.
Z tego, co napisałeś, składało by się na to parę osobnych kwestii:
1. Limitowanie czasu gry.
2. Ukrycie danych potrzebnych tylko w pełnej wersji.
3. System odblokowujący pełną wersję.

Niestety, bez dostępu do sieci i sprawdzania niektórych rzeczy na serwerze większość z powyższych może być złamana, więc poniżej podaję jedynie sensowne propozycje rozwiązań, czyli takie, które da się napisać w sensownym czasie i które dadzą w miarę sensowne zabezpieczenie, ale przed co bardziej znającymi się w temacie i tak się nie obronią.


Ad. 1. Większość gier wrzuca w kilku miejscach zakodowany pozostały czas działania gry. Mogą to być pliki z dziwnymi nazwami, czy wpisy do rejestru w kluczach programu lub bardziej nietypowych miejscach. Wada: przy odrobinie zapału da się to wszystko poznajdować używając process monitora, pousuwać i gra będzie się czuła jak nowa. Nie wiem na ile też to możliwe, ale nietypowe działania na systemie plików, czy rejestrze mają szansę zirytować niektóre nadgorliwe antywirusy. Pomimo wad, masa gier komercyjnych blokuje się właśnie w ten sposób.

Ad. 2. Dane możesz bezpiecznie schować używając algorytmu "one-time pad", czyli po prostu XORując wszystko z ciągiem bitów otrzymanym z kryptograficznie bezpiecznego generatora liczb losowych (a nie pierwszego lepszego randa oczywiście). Żeby odczytać dane klient musi znać seeda generatora, który najczęściej jest sensownej wielkości rozmiarów. Ten sposób zapewnia, że dane nie będą do odzyskania w sensownym czasie bez znajomości stanu początkowego generatora.

Ad. 3. Jako że nie jestem specjalistą w systemach płatności zakładam, że klient po zapłaceniu otrzymuje jakiś kod (jako tekst do wklepania, lub automatycznie po sieci). Tutaj jest dużo możliwości kombinacji, ale koniec końców przy zastosowaniu systemu powyżej klient musi na podstawie informacji z tego klucza odzyskać seeda.

Założenia:
- autor programu (i tylko on) może generować dowolnie dużo kluczy programu,
- nikt inny nie jest w stanie wygenerować nowych kluczy, nawet mając dowolną ilość oryginalnych kluczy,
- bez poprawnego klucza nikt nie jest w stanie odtworzyć seeda,

Moja propozycja: klucz programu jest parą liczb [ a, b ], każda długości porównywalnej z seedem.
- generowanie: wybieramy dowolnie 'x', wtedy: [ a, b ] = [ x xor S, E_kpriv( x ) ]
- wyznaczenie seeda z klucza: S = a xor D_kpub( b )

gdzie:
S - seed generatora liczb losowych ukrywającego dane programu,
E_kpriv - kryptograficzna funkcja kodująca z użyciem klucza prywatnego,
E_kpub - kryptograficzna funkcja dekodująca z kluczem publicznym (klucz publiczny jest zapisany w programie),

Można sprawdzić, że wszystkie założenia są spełnione (czego tutaj nie będę udowadniał). Oczywiście dla użytkownika klucz można zakodować do jakiejś literkowo-cyferkowej postaci. Jeżeli klucz ma być wpisywany, to najprawdopodobniej będzie musiał być dużo krótszy od całego stanu generatora - wtedy stan generatora musimy stworzyć na podstawie tylu bitów, iloma dysponujemy. Poprawność klucza gra jest w stanie sprawdzić na przykład dekodując dane i sprawdzając ich sumę kontrolną.


Niestety, jak wszystkie metody z wpisywanym kluczem, powyższa jest nieodporna na zwykłe podzielenie się kluczem z innymi. Do uniknięcia tego potrzebne już są metody korzystające z sieci (coś w stylu tego, co robi MS w Windowsach). Jeżeli przy rejestracji i wprowadzaniu klucza będziemy wymagali połączenia internetowego, możemy po prostu zapisać fakt aktywacji gry z podanym kodem i według naszej decyzji wysłać seeda odblokowującego, lub nie. Przykładowo, 5 instalacji z tym samym kodem w ciągu tygodnia może być jeszcze OK (albo i więcej, jeżeli sprawdzamy np. ID procesora lub dysku), ale większe ilości instalacji z tym samym kodem będziemy już w stanie wykryć, a kod tymczasowo zablokować. :)

Offline misioslaw

  • Użytkownik
    • www.asmforce.eu

# Styczeń 29, 2009, 03:15:16
Krzyśku, tylko że mając chociaż jeden działający klucz można odszyfrować cała zawartość a następnie pominąć proces dekrypcji/sprawdzania.
« Ostatnia zmiana: Styczeń 29, 2009, 03:21:31 wysłana przez misioslaw »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Styczeń 29, 2009, 03:39:28
Krzyśku, tylko że mając chociaż jeden działający klucz można odszyfrować cała zawartość a następnie pominąć proces dekrypcji/sprawdzania.
Przecież to właśnie napisałem: :)
"Niestety, jak wszystkie metody z wpisywanym kluczem, powyższa jest nieodporna na zwykłe podzielenie się kluczem z innymi."

Offline misioslaw

  • Użytkownik
    • www.asmforce.eu

# Styczeń 29, 2009, 03:58:53
Krzyśku, tylko że mając chociaż jeden działający klucz można odszyfrować cała zawartość a następnie pominąć proces dekrypcji/sprawdzania.
Przecież to właśnie napisałem: :)
"Niestety, jak wszystkie metody z wpisywanym kluczem, powyższa jest nieodporna na zwykłe podzielenie się kluczem z innymi."
Akurat nie miałem na myśli dzielenia się kluczami,tylko użycie łoma i następnie rozbrojenie, tak by już nigdy nie wymagało podawania czegokolwiek.
Generalnie założenie i tak jest dobre. Bo jak wiadomo "Jeżeli tylko coś jest w stanie się uruchomić, to można to złamać".

wg. mnie najbezpieczniej jest nie rozprowadzać dema z możliwością rozszerzenia do pełnej wersji.
Wersję pełną, indywidualnie oznakowaną, umieścić na serwerze i przesłać użytkownikowi login i hasło (także indywidualne) żeby mógł pobrać.
Wtedy będzie też wiadomo dzięki komu pojawiły się nielegalne kopie.


Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Styczeń 29, 2009, 04:33:29
Cytuj
Akurat nie miałem na myśli dzielenia się kluczami,tylko użycie łoma i następnie rozbrojenie, tak by już nigdy nie wymagało podawania czegokolwiek.
Ale komu się będzie chciało, skoro można podać klucz w pliku txt. ;)

Cytuj
wg. mnie najbezpieczniej jest nie rozprowadzać dema z możliwością rozszerzenia do pełnej wersji.
W przypadku podanej przeze mnie metody to akurat nic nie zmienia. Bez seeda i tak nic nie odczytasz. :)

Cytuj
Wersję pełną, indywidualnie oznakowaną, umieścić na serwerze i przesłać użytkownikowi login i hasło (także indywidualne) żeby mógł pobrać.
Wtedy będzie też wiadomo dzięki komu pojawiły się nielegalne kopie.
Też tak można, ale co da taka informacja? Dowodów na to, że to akurat ta osoba rozprowadzała kopie nie masz, poza tym komu będzie się chciało po sądach ciągać.

Offline misioslaw

  • Użytkownik
    • www.asmforce.eu

# Styczeń 29, 2009, 04:43:14
Cytuj
W przypadku podanej przeze mnie metody to akurat nic nie zmienia. Bez seeda i tak nic nie odczytasz. :)
Skąd go wziąć było napisane akapit wyżej.

Cytuj
Też tak można, ale co da taka informacja? Dowodów na to, że to akurat ta osoba rozprowadzała kopie nie masz, poza tym komu będzie się chciało po sądach ciągać.
Taka informacja jest dowodem samym w sobie.
Chyba jeszcze nie spotkano wirusów/trojanów które kradły by użytkownikom gry i umieszczały w p2p.
Taką kopię będzie można na przykład dezaktywować, i odciąć przy okazji nabywcę od aktualizacji, bonusów itd.
Tak poza tym to sama świadomość tego że gra jest indywidualnie oznakowana może powstrzymać niejednego przed podzieleniem się z innymi.

« Ostatnia zmiana: Styczeń 29, 2009, 04:50:48 wysłana przez misioslaw »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Styczeń 29, 2009, 05:13:02
Cytuj
Taka informacja jest dowodem samym w sobie.
Wątpię, żeby w sądzie to kupili. Zawsze się można bronić, że haker wykradł, kolega podpatrzył, zresztą w ogóle pytanie, czy udostępnianie kodów podejdzie pod definicję rozpowszechniania, jeżeli nie rozpowszechnia się samej kopii gry.

Cytuj
Taką kopię będzie można na przykład dezaktywować, i odciąć przy okazji nabywcę od aktualizacji, bonusów itd.
Tak poza tym to sama świadomość tego że gra jest indywidualnie oznakowana może powstrzymać niejednego przed podzieleniem się z innymi.
No to to wiadomo. :)

Offline Kos

  • Użytkownik
    • kos.gd

# Styczeń 29, 2009, 10:50:58
Zgadzam się - Jedyne, co jest w miarę bezpieczne, to po prostu nie dołączanie resourców pełnej wersji gry do triala.

Jeśli ktoś kupuje pełną wersję, to wysyłamy / udostępniamy na skończony czas do downloadu pełną wersję - z indywidualnym niewidocznym fingerprintem zakodowanym gdzieś w kodzie lub w którejś z tekstur. Jeśli wersja się rozejdzie na torrentach, to ściągamy ją sobie, sprawdzamy czyj to fingerprint i już mamy winowajcę.

Offline revo

  • Użytkownik

# Styczeń 29, 2009, 11:08:19
Dzięki za odpowiedzi, wyszła z tego na razie ciekawa dyskusja ;) Zdaję sobie sprawę, że to jest trochę walka z wiatrakami, ale czasami tak trzeba  8)

Zgadzam się - Jedyne, co jest w miarę bezpieczne, to po prostu nie dołączanie resourców pełnej wersji gry do triala.

Trzeba jeszcze pamiętać o jednej rzeczy -- exe z dema, z ograniczonymi zasobami, musi być inny niż exe z pełnej wersji. W przeciwnym przypadku, jeżeli okaże się, że pojawi się jednak wersja ograniczona czasowo (co robi część dystrybutorów), prawdopodobnie wystarczy podmienić pliki i całość zacznie działać ;)

Co do fingerprintów, to wydaje się to sensowne rozwiązanie, ale wystarczy w teorii 'odjąć' od siebie dwie wersje gry, żeby zaleźć w którym miejscu fingerprint się znajduje. Dzięki temu bardzo łatwo będzie namierzyć dokładne miejsce sprawdzania zabezpieczeń w pliku wykonywalnym i się go po prstu pozbyć, na dodatek zaburzając fingerprinta.

Pewnym sposobem mogłoby być umieszczanie go w pewnym losowo wybranym pliku i możliwość odczytania go tylko przez nas (robiąc diff z nieoznakowaną wersją). Ale wydaje się, że powyższą metodą da się to i tak raczej obejść. Można by było dodawać do plików jakieś sumy kontrolne, ale jako, że musimy mieć możliwość ich obliczania, to kod za to odpowiedzialny i tak zostanie udostępniony razem z naszą grą, więc w teorii to tylko kwestia czasu.

Na dodatek, generowanie wersji z fingerprintem byłoby raczej mocno obciążające dla serwera, co jest sprawą dość kłopotliwą.

Offline Hadrian W.

  • Użytkownik
    • Homepage

# Styczeń 29, 2009, 12:40:18
Fakt jest taki, że jeżeli gra jest choć trochę popularna to ten DRM nie ma najmniejszego sensu (przykład World of Goo), a jak gra ma minimalną popularność to tym bardziej DRM nie ma sensu. Wielu ludzi też docenia fakt braku DRM, spójrzcie też na GoG.com (GoG m.in. za brak DRM dostał solidną reklamę na RPS), albo na Apple i iTunes.
« Ostatnia zmiana: Styczeń 29, 2009, 13:35:07 wysłana przez Hadrian W. »

Offline Asmodeusz

  • Użytkownik
    • Bogumił Wiatrowski: Blog

# Styczeń 29, 2009, 12:44:12
Może zastosować coś podobnego do Games for Windows Live Security? Z tego, co kojarzę, jest to dostępne w którymś API od MS, a działanie jest bardzo proste (i dzięki temu bardzo skuteczne). Plugin GfWL [obecny w Xp SP2, 2003 SP1, Vista, 2008, Win7] w momencie tworzenia EXEka szyfruje wszystkie funkcje, które nie są niezbędne do zalogowania się do usługi. Dystrybuując grę, dystrybuujesz klucze, na podstawie których użytkownik może zarejestrować się lub dopisać grę do istniejącego już konta. Uruchamiając grę, musi się zalogować [może też działać logowanie automatyczne; ID i hasło generowane na podstawie klucza - tak czy inaczej, gra nie zezwoli na uruchomienie się bez dostępu do Sieci oraz na danym kluczu uruchomisz tylko jedną jej instancję gdziekolwiek], serwer przesyła do gry (zwykle korzystając z SSLa czy innego ustrojstwa) klucz deszyfrujący resztę kodu gry i kod programu jest dalej na bieżąco deszyfrowany. Jedyną wadą GfWL jako takiego jest koszt dla wydawcy - płaci od każdego zarejestrowanego egzemplarza.

Może własne rozwiązanie bazować na tym? Szyfrowany content, oznaczenie procesu pod WinVista jako DRM-secure (API dla Visty gdzieś ma funkcję pozwalającą na stałe oznaczenie EXEka w ten sposób; wszędzie poza cache procesora pamięć programu jest zaszyfrowana, dodatkowo nie ma prawa trafić do pagefile), pobieranie klucza na podstawie jakiejś identyfikacji użytkownika (numer licencyjny, login/hasło itp.) i na jego podstawie deszyfrowanie contentu i kodu? Rozwiązanie ma tylko jedną wadę: wymaga połączenia z Siecią, natomiast zaletą jest całkowita przeźroczystość dla użytkownika oraz (w przypadku Visty - do szyfrowania pamięci wykorzystywany jest BitLocker, więc koszt obliczeniowy spada praktycznie do zera) praktycznie niemożliwe dobranie się do tych danych (do aplikacji oznaczonej jako DRM-secure system uniemożliwia podpięcie debuggera, mapowanie pamięci itd.).