Jak zablokować skompilowane klasy Javy, aby zapobiec dekompilacji?

Tak długo, jak mają dostęp zarówno do zaszyfrowanych danych, jak i oprogramowania, które je odszyfrowuje, w zasadzie nie ma możliwości, aby było to całkowicie bezpieczne. Sposoby, które zostały wcześniej rozwiązane, to użycie jakiejś formy zewnętrznej czarnej skrzynki do obsługi szyfrowania/deszyfrowania, takiej jak klucze sprzętowe, zdalne serwery uwierzytelniania itp. Ale nawet wtedy, biorąc pod uwagę, że użytkownik ma pełny dostęp do własnego systemu, to tylko utrudnia, a nie uniemożliwia-chyba że możesz powiązać swój produkt bezpośrednio z funkcjonalność przechowywana w "czarnej skrzynce", jak na przykład serwery gier online.

Zastrzeżenie: nie jestem ekspertem od bezpieczeństwa.

To brzmi jak zły pomysł: pozwalasz komuś szyfrować rzeczy za pomocą 'ukrytego' klucza, który mu dajesz. Nie sądzę, żeby można było to zabezpieczyć.

Może klawisze asymetryczne zadziałają:

• wdrażaj zaszyfrowaną licencję za pomocą klucza publicznego do odszyfrowania
• pozwól klientowi utworzyć nową licencję i wysłać ją do Ciebie w celu szyfrowania
• wyślij nową licencję z powrotem do klienta.

Nie jestem pewien, ale wierzę, że klient może faktycznie zaszyfrować klucz licencyjny za pomocą klucza publicznego, który mu dałeś. Następnie możesz odszyfrować go za pomocą klucza prywatnego i ponownie zaszyfrować.

Możesz zachować oddzielną parę kluczy publicznych/prywatnych dla każdego klienta, aby upewnić się, że rzeczywiście dostajesz rzeczy od właściwego klienta - teraz ty jesteś odpowiedzialny za klucze...

Bez względu na to, co robisz, może być "dekompilowany". Heck, można po prostu zdemontować. Lub spójrz na zrzut pamięci, aby znaleźć swoje stałe. Widzisz, komputer musi je znać, więc Twój kod też będzie musiał.

Co z tym zrobić?

Staraj się nie wysyłać klucza jako stałej zakodowanej na twardo w kodzie: zachowaj go jako ustawienie dla każdego użytkownika. Uczyń użytkownika odpowiedzialnym za opiekę nad tym kluczem.

Spójrz na Artykuł JavaWorld Cracking Java byte-code encryption autor: Vladimir Roubtsov. Wyjaśnia, dlaczego szyfrowanie plików klas jest w większości bezcelowe.

@jatanp: albo jeszcze lepiej, mogą dekompilować, usunąć kod licencji i przekompilować. W przypadku Javy nie sądzę, aby było odpowiednie, odporne na włamania rozwiązanie tego problemu. Nawet zły mały klucz sprzętowy nie mógłby temu zapobiec za pomocą Javy.

Moi menedżerowie biznesowi martwią się o to, a ja myślę za dużo. Ale z drugiej strony, sprzedajemy naszą aplikację dużym korporacjom, które mają tendencję do przestrzegania warunków licencyjnych-ogólnie bezpieczne środowisko dzięki licznikom i prawnikom. Na sama dekompilacja może być nielegalna, jeśli licencja jest napisana poprawnie.

Więc muszę zapytać, czy naprawdę potrzebujesz ochrony stwardniałej, tak jak szukasz swojej aplikacji? Jak wygląda twoja baza klientów? (Korporacje? Czy nastoletnie masy graczy, gdzie byłoby to bardziej problemem?)

Nie wydaje mi się, aby istniała jakakolwiek skuteczna metoda antypiracka. Przemysł gier wideo próbował znaleźć to wiele razy, a ich programy zawsze były pęknięte. Jedynym rozwiązaniem jest to, że program musi być uruchomiony online połączony z serwerami, tak aby można było zweryfikować klucz lincense i że istnieje tylko jedno aktywne połączenie przez Licencjobiorcę na raz. Tak działa World of Warcraft lub Diablo . Nawet trudne są prywatne serwery opracowane dla nich by ominąć ochronę.

Powiedziawszy to, nie wierzę, że średnie / duże korporacje używają nielegalnie kopiowanego oprogramowania, ponieważ koszt licencji dla nich jest minimalny (być może, nie wiem, ile jesteś goig pobierać za swój program) w porównaniu do kosztów wersji próbnej.

Jeśli szukasz rozwiązania licencyjnego, możesz sprawdzić TrueLicense API . Opiera się na wykorzystaniu klawiszy asymetrycznych. Nie oznacza to jednak, że aplikacja nie może zostać złamana. Każdą aplikację można złamać z wystarczającym wysiłkiem. Co naprawdę ważne, jak odpowiedział Stu, zastanawiając się, jak silną ochronę potrzebujesz.

Możesz używać szyfrowania bajtowego bez obaw.

Faktem jest, że cytowany powyżej artykuł "Cracking Java byte-code encryption" zawiera błąd logiczny. Głównym twierdzeniem artykułu jest przed uruchomieniem wszystkie klasy muszą zostać odszyfrowane i przekazane do metody ClassLoader.defineClass(...) . Ale to nieprawda.

Pominięto założenie pod warunkiem, że działają one w autentycznym lub standardowym środowisku Java run-time . Nic nie może zobowiązać chronionej aplikacji java nie tylko do Uruchom te klasy, ale nawet odszyfruj i przekaż je ClassLoader. Innymi słowy, jeśli jesteś w standardowym JRE nie możesz przechwycić metody defineClass(...), ponieważ standardowa java nie ma API do tego celu, a jeśli używasz zmodyfikowanego JRE z załatanym ClassLoader lub innej "hackerskiej sztuczki", nie możesz tego zrobić, ponieważ chroniona aplikacja java w ogóle nie będzie działać, a zatem nie będziesz miał nic do przechwycenia. I absolutnie nie ma znaczenia, który "patch finder" jest używany lub który trik jest używany przez hakerów. Te TECHNICZNE szczegóły to zupełnie inna historia.

P: Jeśli zaszyfruję mój .pliki klas i Użyj niestandardowego classloadera, aby załadować i odszyfrować je w locie, czy zapobiegnie to dekompilacji?

A: problem zapobiegania dekompilacji kodu bajtowego Javy jest prawie tak stary jak sam język. Pomimo szeregu dostępnych na rynku narzędzi maskujących, początkujący Programiści Javy wciąż myślą o nowych i sprytnych sposobach ochrony swojej własności intelektualnej. W tej odsłonie Java Q&A obalam kilka mitów wokół idei często na forach dyskusyjnych.

Ekstremalna łatwość z jaką Java .pliki klas mogą być rekonstruowane na źródła Javy, które bardzo przypominają oryginały, które mają wiele wspólnego z celami projektu bajtowego kodu Javy i kompromisami. Między innymi, kod bajtowy Javy został zaprojektowany z myślą o zwartości, niezależności platformy, mobilności sieci i łatwości analizy przez interpretery kodu bajtowego i kompilatory dynamiczne JIT (just-in-time)/HotSpot. / Align = "left" / pliki klas wyrażają intencje programisty tak oczywiście mogą być łatwiejsze do analizy niż oryginalny kod źródłowy.

Można zrobić kilka rzeczy, jeśli nie całkowicie zapobiec dekompilacji, przynajmniej aby ją utrudnić. Na przykład, jako krok po kompilacji można masować .dane klasy, aby kod bajtowy był trudniejszy do odczytania podczas dekompilacji lub trudniejszy do dekompilacji do poprawnego kodu Javy (lub obu). Techniki takie jak wykonywanie ekstremalnych nazwa metody przeciążenia działają dobrze dla tych pierwszych, i manipulowanie przepływ kontroli do tworzenie struktur sterujących, które nie są możliwe do reprezentowania przez składnię Javy, działa dobrze dla tych ostatnich. Bardziej udane komercyjne zaciemniacze wykorzystują mieszankę tych i innych technik.

Niestety, oba podejścia muszą faktycznie zmienić kod, który uruchomi JVM, a wielu użytkowników obawia się (słusznie), że ta transformacja może dodać nowe błędy do ich aplikacji. Ponadto zmiana nazwy metody i pola może spowodować, że wywołania reflection przestaną działać. Zmiana rzeczywistej klasy i pakietu nazwy mogą łamać kilka innych API Javy (JNDI (Java Naming and Directory Interface), dostawców adresów URL itp.). Oprócz zmienionych nazw, jeśli związek między offsetami kodu bajtowego klasy A numerami linii źródłowych zostanie zmieniony, odzyskanie oryginalnych śladów stosu wyjątków może stać się trudne.

Następnie istnieje opcja zaciemniania oryginalnego kodu źródłowego Javy. Ale zasadniczo powoduje to podobny zestaw problemów. Szyfrować, a nie zaciemniać?

Być może powyższe uczyniło myślisz: "Cóż, co jeśli zamiast manipulować kodem bajtowym zaszyfruję wszystkie moje klasy po kompilacji i odszyfrowuję je w locie wewnątrz JVM (co można zrobić za pomocą niestandardowego classloadera)? Następnie JVM wykonuje mój oryginalny kod bajtowy, a jednak nie ma nic do dekompilacji lub inżynierii wstecznej, prawda?"

Niestety, myliłbyś się, zarówno myśląc, że jesteś pierwszym, który wpadł na ten pomysł, jak i myśląc, że to naprawdę działa. A powód nie ma nic wspólnego z siła twojego schematu szyfrowania.