Jak chronić skompilowane klasy Java?

Wiem, wiele podobnych pytań zostało tu zadanych. Nie pytam, Czy mogę chronić swoją skompilowaną klasę Javy - bo oczywiście powiesz "nie możesz". Mam pytanie Jaka jest najbardziej znana metoda ochrony klas Java przed de-kompilacją? Jeśli znasz jakieś badania lub prace naukowe w tej dziedzinie, proszę dać mi znać. Również jeśli korzystałeś z niektórych metod lub oprogramowania, podziel się swoim doświadczeniem? Wszelkie informacje będą bardzo przydatne. Dziękuję.

Author: JasonMArcher, 2010-03-14
Source

5 answers

Po pierwsze, jeśli kierujesz " tylko "na rynek Windows, bardzo łatwo jest zapobiec".Klasa do .java " dekompilacja: użyj narzędzia takiego jak Excelsior Jet, które przekształci .słoik w .exe .

Jest to niezawodne: jest to niemożliwe , aby uzyskać .java file back jeśli używasz Excelsior Jet (tak długo dla wszystkich ludzi mówiących " nie da się zapobiec dekompilacji .class file"). Oczywiście, atakujący może uruchomić SoftIce i spróbować trace your .exe ale okaże się to nieco trudniejsze niż użycie JAD do dekompilacji .klasa do a .java {[2] } i na pewno nie pozwoli znaleźć .java file back.

Teraz może ty też celujesz w OS X i Linuksa albo nie masz $$$ żeby odpalić Excelsior Jet.

Piszę komercyjny program napisany w Javie. To oprogramowanie ma sens tylko wtedy, gdy jest połączenie z Internetem. Stąd "chronimy" nasze oprogramowanie m.in. poprzez część obliczeń dzieje się po stronie serwera: mamy kilka .klasy , które nie będą działać, jeśli nie zostaną wygenerowane od strony serwera i wyślemy je w dół przewodu (a to, co jest wysyłane na przewód, jest Zawsze inne: generujemy unikalne, jednorazowe .pliki klasy Po stronie serwera).

Wymaga to połączenia z Internetem, ale jeśli Użytkownikowi nie podoba się to, jak działa nasze oprogramowanie, może kupić gorszy produkt naszego konkurenta ;)

Dekompilacja nie przyniesie wiele dobrego: musisz aktywnie złamać oprogramowanie (tj. odtworzyć to, co dzieje się po stronie serwera) lub nie będziesz mógł z niego korzystać.

Używamy własnego "string obfuscation" Przed używamy Proguard. Wykonujemy również instrumentację kodu źródłowego (mogliśmy również instrumentację kodu bajtowego), gdzie usuwamy wiele rzeczy z kodu (jak" assert", które komentujemy) i wprowadzamy przypadkową "maskację przepływu kodu" [oprogramowanie może przyjmować różne ścieżki, ale uzyskać ten sam wynik, to jest coś, co naprawdę sprawia, że oprogramowanie jest trudne do śledzenia]).

Następnie używamy Proguard (który jest wolny), aby spłaścić całą naszą hierarchię OO i zaciemnić już-code-flow-and-string-zaciemniony kod.

Więc nasz przepływ to:

  • zaciemnienie strun
  • losowe zaciemnienie przepływu kodu
  • Proguard
  • Finał .jar to zależy od .klasy , które są (inaczej) dynamicznie generowane po stronie serwera.

Oprócz tego wydajemy bardzo regularną (i zautomatyzowaną) aktualizację, która zawsze stara się zmodyfikować nieco nasz schemat ochrony klienta / serwera (tak, że z każdym wydaniem atakujący hipotetycznie musi zacząć głównie od zera).

Oczywiście łatwiej jest rzucić ręcznik i pomyśleć: "nic nie mogę zrobić, aby utrudnić atakującemu życie, ponieważ jad może znaleźć z powrotem .java file anyway " (co jest bardziej niż bardzo dyskusyjne i rażąco błędne w przypadku, gdy używaszKlasa do .exe konwerter do ochrony .klasy z dekompilacji).

 15
Author: SyntaxT3rr0r,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-03-14 22:03:26

Obfuscator (zobacz http://java-source.net/open-source/obfuscators ) "szyfruje" kod tak, że nie będzie miał żadnego sensu, gdy zostanie skompilowany.

 6
Author: Itay Maman,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-03-14 20:38:42

Istnieje kilka metod:

Wszystkie omówione szczegółowo w moim artykule Chroń swój kod Java - za pomocą Maskatorów i nie tylko

 6
Author: Dmitry Leskov,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-01-10 12:17:28

Więc jak możesz chronić swoje klasy przed dekompilacją? Jedna odpowiedź to Crema. Crema szyfruje symboliczną informację w Twoim .pliki klas, dzięki czemu staną się mniej podatne na dekompilację. Symboliczne informacje, które Crema Scramble zawiera nazwę klasy, jej klasę nadrzędną, interfejsy, nazwy zmiennych, metody i tak dalej. Te symboliczne nazwy są potrzebne maszynie wirtualnej Javy (JVM) do połączenia klas z pakietami bibliotek. Crema szyfruje te symboliczne nazwy i odwołuje się do nich w ten sam sposób, aby JVM nadal mógł osiągnąć poprawne powiązanie między klasami i pakietami.

Jak działa Crema? Zasadniczo, przed rozpowszechnieniem plików klas w Internecie, Uruchom Crema na nich. Crema będzie szyfrować zawarte w nich symboliczne informacje i umieści każdą nową klasę w pliku 1.crema. Twoim zadaniem jest zmiana nazwy 1.crema do czegoś takiego jak nazwa pliku.klasy przed dystrybucją na Internet.

JAK PROJEKTOWAĆ KLASY JAVA

 0
Author: Ravindra Shekhawat,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-04-18 06:56:40

Możesz spróbować Java Protector. Jest to lepszy sposób niż obfuscation.It tworzy natywny ClassLoader modyfikując źródło OpenJDK, może szyfrować klasy, które chcesz chronić za pomocą AES i parsować je w ich custom-JRE.Możesz publikować swoje oprogramowanie w JRE i rozpowszechniać swoje bezpieczeństwo oprogramowania.

 0
Author: Yongfa Lin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-10-09 02:39:13