Cześć, powiedzmy że jakiś portal no np dev.bukkit.org stale dekompiluję mój kod. Sytuacja ta strasznie mnie denerwuje. Czy jest jakis sposób na zabezpieczenie kodu przed dekompilacją? A jeśli tak to jaki. Chodzi by utrudnić tym ludziom życie jeśli będą chcieli dekompilować mój kod.
0
0
Poczytaj o obfuskacji i znajdź jakiegoś obfuskatora do kodu Javy. Utrudni im zabawę, jednak jeżeli chcesz mieć prawdziwe zabezpieczenie przed dekompilacją, to będziesz musiał przestać dokonywać kompilacji ;<
G-RoM [17-12-1999]
"If it runs, it can be defeated."
0
W 1999 roku nie było wirtualizerów, G-Rom był z innej epoki i jedyne co widział to W32Dsm :)
0
ProGuard - obfuskator do Javy.
http://proguard.sourceforge.net
Zaciemni kod ale dekompilacja i tak będzie możliwa.
Ewentualnie możesz przekształcić je do EXE-ka np. za pomocą tego programu (typu AOT compilers kodu natywnego):
http://launch4j.sourceforge.net/
Wtedy pewnie z EXE by się nie dało dekompilować (co najwyżej jak wszystko do ASMa).
Zna ktoś coś lepszego?
0
http://zenofx.com/classguard/ Czyli java traktowana AESem z randomowym kluczem. Do tego własny classloader który podobno jest pisany w C. Teoretycznie można pojedyncze klasy powyciągać gdzieś z ramu, ale to już naprawdę sporo roboty, a i z obfuskacją można to połączyć.
0
Moja propozycja to: nie pisać w Java. ;P
0
@mk321: launch4j nie jest AOT, to tylko launcher.
@mcoder: myślisz że do natywnych nie ma dekompilerów? Jak ktoś uparty, to mu to nie przeszkodzi. Poza tym, jeśli on pisze plugin do Bukkita, to go raczej nie ma wyboru.
Kod pośredni języków wysokopoziomowych (jak Java, C#, czy jakieś skryptówki typu js,as) ma być niezależny od platformy, przez co jest w dość abstrakcyjnej formie. Niestety sprawia to, że taki bajtkod jest dość.. czytelny i łatwo go odwrócić. Możesz co prawda usunąć z niego wszelkie nazwy zmiennych i klas, co utrudni zrozumienie jego działania, wciąż jest to dużo łatwiejsze niż w przypadku kodu natywnego.
Możesz użyć obfuskatora (najlepszym jest chyba ProGuard) do usunięcia większości informacji i nazw. Pisząc pod bukkita będziesz jednak musiał zostawić nazwę głównej klasy pluginu oraz zostawić wszystkie metody obsługujące eventy (można im zobfuskować nazwy, ale zostawić trzeba adnotacje) - to ważna uwaga, gdyż ProGuard, jeśli mu się tego wyraźnie nie zabroni, będzie usuwał metody, które uzna za nie-używane.
Inna możliość to użycie kodu natywnego, by zaszyfrować klasy i odszyfrować je w runtime, tak jak to robi classguard. Wciąż jest taki problem, że kod natywny też nie jest niepokonany, jak się znajdzie uparty, to i z tym sobie poradzi. Powinno to jednak odstraszyć większość script-kiddie.
Pamiętaj jednak, że wtedy musisz skompilować natywki dla wszystkich platform, na których chcesz, żeby działały. (Spod Linuksa to nie powinien być problem, gcc ma dobre cross compilery pod windę i maca, a i na androida też się da, żeby nie było)
Pisząc pod Bukkita nie możesz jednak użyć kodu natywnego do takich rzeczy... poza tym, dlaczego chcesz ukrywać kod pluginu? I tak wydajesz go pewnie za darmo, więc jak, wstydzisz się kodu?
0
Skoro pisze dla dev.bukkit.org exe nie jest rozwiązaniem, bo trzeba wrzucać .jar
Nie zabezpieczysz się całkowicie przed dekompilacją, bo klasy Bukkita do których będziesz się odwoływał nadal będą widoczne. A jeżeli dokonasz obfuskacji, to najpewniej plugin przestanie działać.
0
Kiedyś dostałem biblioteki do KIR- podpis kwalifikowany. Klas nie dało się dekompilować DJ java decompiler. Nigdy nie miałem czasu się tym zając i stwierdzić czym to było zrobione. Że kod był zaciemniony to OK, ale ni cholery nie szło tego połamać.
0
Byłem ostatnio na ciekawym wykładzie na ten temat. Ogólnie zakończył się on w ten sposób, że nie ma sposobu na 100% zabezpieczenie kodu i zaleca się unikanie przekazywania kodu do klientów (Java web start i inne cuda). Jeśli chcesz zabezpieczenia mniej pewnie to jak najbardziej zaciemnianie kodu i szyfrowane klasy. Tyle tylko, że w Twoim przypadku chyba tylko zaciemnianie da się zastosować. Jeśli ma to analizować człowiek, to to wystarczy. Jeśli maszyna - szkoda Twojego zachodu.