Zaciemnianie kodu

Witam,

Mam do napisania półkomercyjny projekt (grę) , który będzie dostępny nieokreślonej liczbie osób (niezależnych ode mnie), w związku z tym istnieje ryzyko, że ktoś będzie próbował zaszaleć i poanalizować kod w celu szukania optymalnych rozwiązań. Chciałem wobec tego maksymalnie utrudnić im zadanie i zaciemnić kod w paczkach .jar

Znalazłem coś takiego: http://proguard.sourceforge.net/

Chciałem zapytać:

• czy ktoś z was robił coś takiego i czy program proguard jest wart polecenia?
• czy znacie jakieś inne metody na maksymalne ukrycie kodu programu, by utrudnić jego analizę?

Pozdrawiam,
Caballito

PS. Nie jestem żadnym javowym wymiataczem, więc być może istnieje jakieś banalne rozwiązanie, którego nie znam - Javą zajmuję się około trzech - czterech miesięcy.

W przypadku javy, to raczej na pełne obfuskowanie kodu nie ma co liczyć. Język i JVM jest tak zbudowany, że analiza kodu jest stosunkowo prosta. W dodatku dość łatwo zdekompilować kod, a następnie za pomocą IDE odtworzyć np. stos wywołań. Dzieciaki tym odstraszysz, a spec nawet tym się nie przejmie.

Co do programu to jest on jednym z lepszych niekomercyjnych. Na pewno warto go zastosować chociażby by trochę podkręcić jakość kodu. Jest tam opcja optymalizacji klas Javy6, czy wyszukiwania "martwego kodu". Pewno też i wynikowy kod będzie mniejszy niż oryginalny.

Obfuscatory maja ta zalete ze wynikowy bytecode jest z reguly mniejszy niz oryginalny, glownie sie to przydaje np do aplikacji Java ME.

Dzięki za info. Czyli wynika z tego, że tak naprawdę w javie jest sens tworzyć tylko aplikacje, które docelowo mają być open source, bo jeśli ktoś będzie chciał koniecznie dorwać się do mojego kodu, to nawet się nie napracuje. Dla mnie jest to dziwne w kontekście tego, że w miarę upływu czasu coraz bardziej kładzie sie nacisk na ukrycie rozwiązań i prawa autorskie, a tu proszę - wystarczy odrobina dobrej woli i kod stoi otworem.

Gdybym zatem chciał maksymalnie utrudnić znalezienie kodu nawet specom, to co mam zrobić - skierować się do C++, gdzie jest pełna kompilacja kodu programu do kodu maszynowego?

Caballito napisał(a)

Czyli wynika z tego, że tak naprawdę w javie jest sens tworzyć tylko aplikacje, które docelowo mają być open source, bo jeśli ktoś będzie chciał koniecznie dorwać się do mojego kodu, to nawet się nie napracuje.

no nie do końca... Jeżeli ktoś będzie chciał się dorwać to się dorwie niezależnie czy to jest w Javie, C++ czy COBOLu. Zresztą najlepszym dowodem jest to, że obecnie nie ma zabezpieczeń nie do złamania. Po prostu obfuskator służy w dzisiejszych czasach do minimalizacji objętości kodu, jego niewielkiej optymalizacji oraz do odstraszania scripting kids...

Caballito napisał(a)

Dla mnie jest to dziwne w kontekście tego, że w miarę upływu czasu coraz bardziej kładzie sie nacisk na ukrycie rozwiązań i prawa autorskie, a tu proszę - wystarczy odrobina dobrej woli i kod stoi otworem.

Bo czym innym jest prawo, a czym innym jego przestrzeganie. W idealnym stallmanowskim świecie praw autorskich każda firma czy programista udostępniała by swój kod jednocześnie wskazując kto z imienia i nazwiska napisał który kawałek, który kawałek od kogo jest pożyczony, a całość była by okraszona treścią GPL.
Rzecz w tym, że ty dając swój program użytkownikowi zawierasz umowę w ramach, której on nie będzie wpatrywał się w kod i próbował go rozgryźć.
Trochę inna drogą jest tzw. "clean room", czyli metoda inżynierii wstecznej polegająca na napisaniu testów i probie odtworzenia rezultatów jakie daje oryginalny kod za pomocą całkowicie nowego, pisanego od zera, kodu.

Caballito napisał(a)

Gdybym zatem chciał maksymalnie utrudnić znalezienie kodu nawet specom, to co mam zrobić - skierować się do C++, gdzie jest pełna kompilacja kodu programu do kodu maszynowego?

Nie, to nic nie da, a tylko podnosi koszty po twojej stronie. Możesz co najwyżej próbować opatentować swoje rozwiązanie o ile jest rzeczywiście innowacyjne i dotychczas nikt inny nie stworzył czegoś podobnego. Policz co bardziej ci się opłaca.

Aj, patentować mi się nie opłaca, po prostu chcę odciąć drogę wszelkim kombinatorom, którzy będą próbowali dorwać się do kodu gry, żeby edytować świat, zgłębiać mechanikę, czy co tam jeszcze by chcieli.

@Caballito, a tak w ogóle najważniejsza sprawa czy to jest gra która może chodzić bez neta? Bo jak wymagany jest net to zawsze można pokombinować...

@Caballito

Nie zgadzam się z Tobą by świat szedł w kierunku coraz to bardziej radykalnego zastrzegania kodu. Wręcz przeciwnie-zobacz ile open source'owych projektów powstało w porównaniu powiedzmy z rokiem 2000. A ich jakos jak wzrosła. Kiedyś darmowe oprogramowanie było często utożsamiane z czymś niekompletnym i zawodnym a teraz całe komercyjne projekty mają wspomaganie Open source'u. Przykład? Pierwszy z brzegu - Fabrication.

Co innego zastrzegać kod bo chce się być jedyną gwiazdką a co innego (w przypadku gier) utrudniać możliwość oszukiwania.Co do pierwszego to Ty jako autor wybierasz licencję i tyle-potem już jest tylko egzekwowanie prawa.

@Koziołek

W Polsce i chyba całej Europie nie ma prawa patentowego na oprogramowanie-możesz dać patent na jakieś rozwiązane programistyczne tylko po to by komuś łatwiej było implementować Twoje rozwiązanie. Nie mozesz przedstawić rozczeń osobie/firmie która wykorzystuje Twoje rozwiazanie patentowe. I całe szczęsćie:) Niech te durne prawo sobie zostanie w stanach.

Prawo autorskie to nie prawo patentowe.

@lipkerson
Mnie interesuje tylko utrudnienie gry, bo i tak, jeśli ktoś będzie chciał podebrać moje rozwiązanie, to w necie pewnie odszuka jakieś ciekawsze i lepsze :)

@Koziołek
Gra ma chodzić offline, bez neta.

@Caballito, no to jak to mówią zad... możesz kombinować z pisaniem jakiegoś swojego DSL'a w jakimś innym niż Java języku choćby w Scali, Groovy czy w JRuby i w nim zamknąć jakąś istotna funkcjonalność. Możesz też próbować dynamicznego generowania niektórych aspektów rozgrywki. W ostateczności zostaje JNI i napisanie czegoś w C.
Ja jednak nadal podtrzymam, że powinieneś najpierw podliczyć czy ci się to opłaca.

hehe Koziołek dobrze pisze - ten Twój rdzeń cenny, który mógłby służyć do oszukiwania po rozeznaniu się co i jak napisz w natywnym kodzie-bez finezji dwie pętle trzy ify i już kolo wymięknie bo nie rozwali C/C++ na drobne. Tzn jakby się naprawę uparł to da rade ale nadkład pracy byłby ogromny.
Oczywiście odpada wtedy java ME.
Zamiast JNI użyj JNA i tyle.

Możesz użyć jakiegoś mieszacza kodu który będzie Ci maglował go przed kompilacją ale wtedy uważaj na użyte refleksje. I tyle - chyba nic mądrzejszego nie ma.

@lipkerson, dzięki jeszcze mi się jedna rzecz nasunęła...

Użyj AspectJ i dynamicznego weaveringu Kod, który powstanie po uruchomieniu będzie nijak się miał do kodu źródłowego i tylko bezczelny dump pamięci JVM + analiza aspektów pozwoli na rozczajenie co i jak. tego raczej nie ruszy nie specjalista, a i spec będzie miał nielichą zagatkę jak zobfuskujesz aspekty :D

lipkerson napisał(a)

i już kolo wymięknie bo nie rozwali C/C++ na drobne.
Czyli faktycznie dekompilacja kodu maszynowego C/C++ jest istotnie trudniejsza od dekompilacji obfuskowanej javy?

@Caballito, dla speca tak, dla nie speca nie.

Kodu maszynowego się nie dekompiluje w praktyce. Czy analiza dla specjalisty jest trudniejsza? Nawet obfuskowany kod maszynowy można przeanalizować w relatywnie krótkim czasie (kilka lat temu na 4p było wyzwanie z obfuskowanym crackme, padło w kilka godzin). To wszystko kwestia doświadczenia i użytych narzędzi...

Jeżeli coś może zostać odpalone, może się wykonać, to może zostać odtworzone lub/i złamane - święte prawo tej branży.

Ok, w takim razie kwestia bezpieczeństwa rozwiązania jest załatwiona.
Dziękuję wszystkim za pomoc.

Do dekompilacji C/ C++ służy http://www.hex-rays.com/decompiler.shtml o którym deus już gadał w innych wątkach.

Poobserwuj zresztą jaki jest poślizg między wydaniem super kasowej gry (prawie wszystkie są w C++ robione), a wydaniem na nią cracka, trainerów i modyfikacji. Poczytaj ile twórcy tych gier wydali na zabezpieczenia i jakie problemy stwarzają użytkownikom.

Trudno hexraysa faktycznym dekompilatorem nazwać, dekompiluje do czegoś, co od biedy można uznać za ANSI C, w praktyce jest to pseudokod. Mechaniki obiektów C++, jak wywoływanie metod na rzecz obiektów, nadal nie rozumie, o metodach wirtualnych nawet nie wspominam.

Co do zabezpieczeń faktycznych komercyjnych gier - sporo z tego to zabezpieczenia z najwyżej półki, praktycznie wszystko, co branża protectorów ma obecnie do zaoferowania. W praktyce zawsze znajdzie się jakiś zainteresowany zawodnik/team co to połamie.

Statystycznie czas łamania zabezpieczenia jest czterokrotnie dłuższy od jego tworzenia.

Statystycznie czas łamania zabezpieczenia jest czterokrotnie dłuższy od jego tworzenia.

Skoro jakiś team rozwali gierkę w kilka dni, a pisanie zabezpieczenia jest 4 razy krótsze to czemu te zabezpieczenia tyle kosztują?

Koszt opracowania zabezpieczenia jest spory, to fakt. Z drugiej strony komercyjne pakiety są dobrze przebadane, jest sporo papierów opisujących różne aspekty ich mechaniki. Crackerzy rozwalający protectory z wyższej półki 'w kilka dni' robili to już wielokrotnie na innych tytułach, stąd mogą się zająć zmianami w mechanice pomiędzy aplikacjami protectora, wykorzystać wiedzę o jego słabych stronach itd.

Należy pamiętać, że obecnie protectory mają od cholery opcji, widziałem gry, gdzie autorzy poodznaczali dosłownie wszystko 'bo protector spowalnia' (a i bez zabezpieczeń optymalizacja była koszmarna) więc co się dziwić, że czasem łatwo to połamać? Jeżeli najbardziej oporne mechanizmy się wyłącza to trudno oczekiwać długiego statusu 'uncracked'...

Protector ma tylko opóźnić wypuszczenie cracka, utrudnić działanie wersji nielegalnej i aplikowanie patchy, nie całkowicie uchronić przed piractwem.

A więc stosowanie zabezpieczeń bardziej zaawansowanych niż kilka ifów mija się z celem.

No nie wiem, protectory inne niż totalnie ograne potrafią się utrzymać wiele miesięcy. Poza tym znacznie piracenie utrudnia wydawanie patchy do gry, każdego kolejnego patcha trzeba łamać, co też potrafi sporo czasu zająć - dobry protector przy każdej aplikacji daje znacznie różniącą się mechanikę. To tylko narzędzie, trzeba umieć je stosować z sensem, czytać dokumentację... jak wiemy 90% programistów nawet jednej strony dokumentacji nie przeczytało w całości.

Czyli jest sens o ile gra się szybko deaktualizuje albo ma wciągający tryb multi tylko na oficjalnych serwerach. Mimo wszystko nie słyszałem o gierce która by się długo opierała przed spiraceniem jej trybu offline.

@up: O ile dobrze pamietam half-life 2 dosc dlugo sie opieral, ale tez nie do konca mozna jego single player zaliczyc do, jak to ujales, "trybu offline". Orginalna wersja chyba nawet jak chciales pograc tylko w single player laczyla sie z netem, costam sprawdzala itp itd.

Dziękuję wszystkim za wypowiedzi, bardzo dużo się dowiedziałem :)
Podjąłem jednak decyzję pisania gry w C++ - gdy przypomniałem sobie język, okazało się, że nie tak znowu wiele z niego zapomniałem, poza tym wydaje mi się, że pod względem wydajności uda mi się zejść niżej.

@donkey
AC2 opieralo sie przez chyba 3 miesiace :)

ale warto było czekać :)

Jak to, ja miałem przed premierą.
<font size="1">whops</span>

Jeśli gra wywali sie u klienta to z logów ciezko bedzie wykminić co sie stalo, bo nazwy pakietow i klas tez sa obfuskowane. Sadzisz, ze komuś bedzie sie chcialo wyciagać z kodu Twoje super algorytmy ?

Fail... proguard pozwala na zmapowanie zobfuskowanego kodu, dzięki czemu ze stack trace'u można odczytać o które metody i klasy chodzi.