Verschleiern Sie Ihren kommerziellen Java-Code?[geschlossen]

Question

Ich frage mich, ob jemand kommerzielle/kostenlose Java-Obfuskatoren für sein eigenes kommerzielles Produkt verwendet.Ich kenne nur ein Projekt, das tatsächlich einen verschleierenden Schritt im Ant-Build-Schritt für Releases hatte.

Verschleiern Sie?Und wenn ja, warum verschleiern Sie?

Ist es wirklich eine Möglichkeit, den Code zu schützen, oder ist es nur ein besseres Gefühl für die Entwickler/Manager?

bearbeiten: Ok, um genau zu sein:Verschleiern Sie, um Ihr geistiges Eigentum (Ihre Algorithmen, die Arbeit, die Sie in Ihr Produkt gesteckt haben) zu schützen?Ich werde aus Sicherheitsgründen nicht verschleiern, das fühlt sich nicht richtig an.Ich spreche also nur davon, Ihren Anwendungscode vor der Konkurrenz zu schützen.

@staffan hat einen guten Punkt:

Der Grund, sich von der Verkettung des Codeflusses fernzuhalten, besteht darin, dass einige dieser Änderungen es der JVM unmöglich machen, den Code effizient zu optimieren.Tatsächlich wird dadurch die Leistung Ihrer Anwendung beeinträchtigt.

Answer 1

Wenn Sie verschleiern, halten Sie sich von Verschleierern fern, die den Code modifizieren, indem sie den Codefluss ändern und/oder Ausnahmeblöcke usw. hinzufügen, um die Disassemblierung zu erschweren.Um den Code unleserlich zu machen, reicht es normalerweise aus, alle Namen von Methoden, Feldern und Klassen zu ändern.

Der Grund, den Codefluss nicht zu ändern, besteht darin, dass einige dieser Änderungen es der JVM unmöglich machen, den Code effizient zu optimieren.Tatsächlich wird dadurch die Leistung Ihrer Anwendung beeinträchtigt.

Answer 2

Ich denke, dass die alte (klassische) Art der Verschleierung allmählich an Relevanz verliert.Denn in den meisten Fällen unterbrechen klassische Verschleierer einen Stack-Trace (das ist nicht gut für die Unterstützung Ihrer Kunden).

Heutzutage geht es vor allem darum, nicht einige Algorithmen zu schützen, sondern sensible Daten zu schützen:API-Anmeldungen/Passwörter/Schlüssel, Code, der für die Lizenzierung verantwortlich ist (hier gibt es meiner Meinung nach immer noch Piraterie, insbesondere Westeuropa, Russland, Asien), Werbekonto-IDs usw.

Interessante Tatsache:Wir haben all diese sensiblen Daten in Strings.Tatsächlich machen Strings etwa 50–80 % der Logik unserer Anwendungen aus.Mir scheint, dass die Zukunft der Verschleierung in „String-Verschlüsselungstools“ liegt.

Aber jetzt ist die Funktion „String-Verschlüsselung“ nur in kommerziellen Verschleierern verfügbar, wie zum Beispiel: Allatori, Zelix KlassMaster, Nebelwand, Stringer Java Obfuscation Toolkit, DashO.

Hinweis:Ich bin CEO bei Licel LLC.Entwickler von Stringer Java Obfuscator.

Answer 3

Ich verwende Proguard für die JavaME-Entwicklung.Es ist nicht nur sehr, sehr gut darin, JAR-Dateien zu verkleinern (wesentlich für Mobilgeräte), sondern es ist auch eine nützlichere Möglichkeit, gerätespezifischen Code zu erstellen, ohne auf IDE-unfreundliche Vorverarbeitungstools wie Antenna zurückgreifen zu müssen.

Z.B.

public void doSomething()
{
    /* Generated config class containing static finals: */
    if (Configuration.ISMOTOROLA)
    {
        System.out.println("This is a motorola phone");
    }
    else
    {
        System.out.println("This is not a motorola phone");
    }
}

Dies wird kompiliert, verschleiert und die Klassendatei sieht so aus, als hätten Sie Folgendes geschrieben:

public void doSomething()
{
    System.out.println("This is a motorola phone");
}

Sie können also über Codevarianten verfügen, um Herstellerfehler in JVM-/Bibliotheksimplementierungen zu umgehen, ohne die endgültigen ausführbaren Klassendateien zu überladen.

Ich glaube, dass einige kommerzielle Verschleierer in bestimmten Fällen auch Klassendateien zusammenführen können.Dies ist nützlich, denn je mehr Klassen Sie haben, desto größer ist der Größenaufwand für die ZIP-Datei (JAR).

Answer 4

Ich habe dieses Jahr einige Zeit damit verbracht, verschiedene Java-Obfuskatoren auszuprobieren, und ich habe festgestellt, dass einer den anderen meilenweit voraus ist: JBCO.Es ist leider etwas umständlich einzurichten und verfügt über keine grafische Benutzeroberfläche, aber was den Grad der Verschleierung angeht, den es erzeugt, ist es beispiellos.Sie versuchen, ihm eine einfache Schleife zuzuführen, und wenn Ihr Dekompiler beim Versuch, ihn zu laden, nicht abstürzt, sehen Sie etwa Folgendes:

    if(i < ll1) goto _L6; else goto _L5
_L5:
    char ac[] = run(stop(lI1l));
    l7 = (long)ac.length << 32 & 0xffffffff00000000L ^ l7 & 0xffffffffL;
    if((int)((l7 & 0xffffffff00000000L) >> 32) != $5$)
    {
        l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL;
    } else
    {
        for(l3 = (long)III & 0xffffffffL ^ l3 & 0xffffffff00000000L; (int)(l3 & 0xffffffffL) < ll1; l3 = (long)(S$$ + (int)(l3 & 0xffffffffL)) ^ l3 & 0xffffffff00000000L)
        {
            for(int j = III; j < ll1; j++)
            {
                l2 = (long)actionevent[j][(int)(l3 & 0xffffffffL)] & 65535L ^ l2 & 0xffffffffffff0000L;
                l6 = (long)(j << -351) & 0xffffffffL ^ l6 & 0xffffffff00000000L;
                l1 = (long)((int)(l6 & 0xffffffffL) + j) & 0xffffffffL ^ l1 & 0xffffffff00000000L;
                l = (long)((int)(l1 & 0xffffffffL) + (int)(l3 & 0xffffffffL)) << 16 & 0xffffffff0000L ^ l & 0xffff00000000ffffL;
                l = (long)ac[(int)((l & 0xffffffff0000L) >> 16)] & 65535L ^ l & 0xffffffffffff0000L;
                if((char)(int)(l2 & 65535L) != (char)(int)(l & 65535L))
                {
                    l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL;
                }
            }

        }

    }

Sie wussten nicht, dass Java gotos hat?Nun, die JVM unterstützt sie =)

Answer 5

ich benutze ProGuard und kann es wärmstens empfehlen.Während die Verschleierung Ihren Code vor zufälligen Angreifern schützt, liegt ihr Hauptvorteil in der minimalen Wirkung, die durch das Entfernen nicht verwendeter Klassen und Methoden und die Verkürzung aller Bezeichner auf ein oder zwei Zeichen entsteht.

Answer 6

Ich denke, dass Verschleierung größtenteils sinnlos ist:Selbst mit vollständigem Quellcode ist es im Allgemeinen schwer genug, herauszufinden, was die eigentliche Absicht war (vorausgesetzt, es gibt keine Kommentare und keine aussagekräftigen Namen für lokale Variablen – was der Fall ist, wenn Quellen aus Bytecode neu generiert werden).Verschleierung schmückt nur den Kuchen.

Ich denke, dass Entwickler und insbesondere ihre Manager dazu neigen, das Risiko, dass jemand den Quellcode sieht, stark zu überschätzen.Obwohl gute Dekompilierer gut aussehenden Quellcode erzeugen können, ist es nicht trivial, damit zu arbeiten, und die damit verbundenen Kosten (ganz zu schweigen von den rechtlichen Risiken) sind hoch genug, dass dieser Ansatz selten nützlich ist.Ich habe nur dekompiliert, um Probleme mit Produkten von Closed-Source-Anbietern zu beheben (Deadlocks in der DB-Abstraktionsschicht, ugh).Ich glaube, der Bytecode war tatsächlich verschleiert, aber wir haben trotzdem das zugrunde liegende Problem gefunden – es war ein tatsächliches Designproblem.

Answer 7

Ich denke, es kommt wirklich darauf an Was Ihr Java-Code ist für, wie er verteilt wird und wer Ihre Kunden sind.Wir verschleiern nichts, da wir noch nie eines gefunden haben, das besonders gut war und es tendenziell mehr Ärger macht, als es wert ist.Wenn jemand Zugriff auf unsere JAR-Dateien hat und über das Wissen verfügt, darin herumzuschnüffeln, kann er weitaus besorgniserregendere Dinge tun, als unseren Quellcode zu stehlen.