Dekompilacja plików *.class

czy jest jakaś sprawdzona metoda zabezpiecznia plików class przed dekompilacją?? w przypadku javy jest to zbyt proste, mozna to zrobic pierwszym lepszym narzedziem znalezionym na google :-/

Obfuskatory kodu. Innych metod, które pozwalają na zabezpieczenie się przez dekompilacją nie ma.

lipa troche, że tak powiem... obfuskator to jedynie "zaciemnienie" kodu a nie pełnowartościowe szyfrowanie... no cóż moze przynajmniej częsc ludzi zniecheci :-|

Ale o co Ci chodzi? Jakie szyfrowanie? Skoro ma się uruchomić u klienta, to jakoś się odszyfrować musi. Jakkolwiek byś to zaszyfrował, zawsze da się obejść.

Zresztą w C/C++/Delphi jest bardzo podobnie. Dekompilacja programu w C/C++ jest podobnie łatwa co dekompilacja obfuskowanego kodu w Javie. Jedyna różnica, że musisz mieć dekompilator pod konkretną platformę, a w Javie wystarczy się raz pomęczyć i jest na wszystkie.

Poza tym obfuskator nie tylko zaciemnia, ale usuwa pewne informacje z kodu jak np. nazwy funkcji, zmiennych i klas i zastępuje je nic nie znaczącymi zbitkami liter.

Sposoby są do pewnego stopnia skuteczne. Po prostu trzeba robić to tak jak zawodowcy. Otwierać zaszyfrowane połączenie do serwera, z którego ściąga się zserializowane klasy będące kluczowymi kawałkami kodu. Deserializuje się je w pamięci i od razu używa. Trzeba w tym celu napisać swoją ładowarkę klas i kilka innych drobiazgów potrzebnych do autoryzacji, tak aby jakiś spryciarz nie mógł prosto ich sobie sam ściągnąć. A jak nie ściągnie to i nie zdekompiluje. Ściągane z sieci klasy też mogą zawierać kolejnego niestandardowego ładowacza klas i w ten sposób ma się drugi poziom zabezpieczenia. Itd...
Kolejnym sposobem uzupełniającym jest ściąganie niektórych klas, których nazwy już lokalnie istnieją (ale jeszcze nie zostały uruchomione), ale tak aby uruchamiały się tylko te ściągnięte zamiast tych podstawionych. Równie dobrze ściągnięte dane mogą naprawiać śmiecie zawarte w lokalnych plikach klas. W ten sposób potencjalny szpiegunio będzie czytał klasy zupełnie inne niż powinien - i rozwali mu to całą koncepcję. Pod warunkiem, że klasy podstawione do czytania nie będą banalne - albo najlepiej jakby były wyjątkowo trudne. Nawet wręcz bez sensu lub zawierające błędy - typu nieskończone rekurencje odwołania cykliczne itp. Jednak dobrze by było jakby zawierały potrzebne nazwy metod. Jeżeli koleś czytający nie złapie okrutnego żartu, to być może osiwieje zanim wywącha co jest grane i dlaczego działa program, który nie powinien działać.

A moze PKI + classloader? Napisac DecodingClassLoader, ktory wczytuje klucz prywatny, zaszyfrowane bajty, nastepnie odszyfrowuje bajty kluczem i klasa jest zdefiniowana. Kod klasy bylby zaszyfrowany odpowiadajacym kluczem publicznym.
Plus: wysokie bezpiezcenstwo bym powiedzial, nie musisz sciagac nic przez neta - w przeciwienstwie do rozwiazania kolegi z gory (poza tym, co sie stanie po pierwszym uruchomieniu? klasy juz sa i taku klienta wiec moze zdekompilowac)
Minusy: dosc zlozone, musiz dostac klucz publiczny od klienta, zaszyfrowac klasy. Czyli dla kazdego klienta osobny release.
Hmm?

Jeżeli kod może coś lokalnie zdeszyfrować i to co deszyfruje jest składowane lokalnie, to zawsze można to prześledzić. Wystarczy "ręcznie" odpalić klasy, które mają coś zdeszyfrować i otrzymuje się ostateczny kod, który można zdekompilować. W wersji sieciowej, którą podałem, żeby uzyskać możliwość ściągnięcia i deszyfracji trzeba najpierw nawiązać połączenie z serwerem i "przekonać go", że uruchamia się cały program, a nie tylko jego kawałek i dopiero wtedy serwer może przekazać klucz, który umożliwi odszyfrowanie przekazanego przez serwer bajtowego śmiecia. Oczywiście technika taka jak każda jest do złamania i przeanalizowania, ale koszt (i czas) takiej roboty powinien po prostu znacznie przekroczyć wartość kodu, który chce się zabezpieczyć. No i jedyne co musi być unikalne dla każdej działającej sztuki to klucz do deszyfracji składowany na serwerze i używany tylko przez chwilę w pamięci lokalnej programu u klienta. Czyli realnie oznacza to konto klienckie na serwerze sieciowym. Nawet gdyby właściciel konta próbował kombinować, to w kodzie można ukryć sygnalizatory, które poinformują serwer, że ktoś próbuje grzebać w kodzie, co może powodować spalenie konta i zabicie możliwości autoryzacji. W ten sposób właściciel kodu ma dość dużą szansę na to, że kod będzie się uruchamiać tylko na maszynach, w których nikt nie próbuje się dobrać do niego.
Jak pokazuje życie zabezpieczenia oparte na sieci są takimi z którymi piraci jeszcze sobie nie radzą. Widać to po grach MMO - możliwości uruchamiania niektórych klientów na shakowanych serwerach istnieją, ale minusy i problemy są duże. Często za duże, żeby wielu opłacało się używać pirackich kopii.
Kod w całości dostępny lokalnie jest zawsze całkowicie do złamania.

Ja mialem na mysli ClassLoader ktory wczytuje zaszyfrowane bajty, i za pomcoa klucza prywatnego je odszyfrowuje, i wczytuje do pamieci. Po skonczeniu programu nie ma nigdzie rozszyfrowanych klas. Mozna je jedynie wyciagnac z pamieci jak sa juz zaladowane, prawde mowiac nie wiem jak to zrobic, na pewno sie da.. ale jest to jakis pomysl.