# Welchen Obfuscator nehmen?



## JanHH (7. Jun 2011)

Siehe Betreff.. hab früher mal mit JODE gearbeitet, aber der kommt mir nun langsam veraltet vor, mal abgesehen davon dass der Download-Link gerade nicht funktioniert. Welche Programme sind kostenlos, empfehlenswert und NICHT GPL (sondern lieber LGPL oder sowas)?


----------



## Wildcard (7. Jun 2011)

Warum spielt GPL eine Rolle? Sollte doch ziemlich egal sein da du das Tool nicht zur Laufzeit brauchst.
Der GNU Compiler ist auch GPL, dadurch fallen aber nicht alle mit GCC kompilierten Programme automatisch unter die GPL.
Mir fällt da spontan yGuard und ProGuard ein. Welches davon nun das bessere ist, keine Ahnung, ich halte nicht viel von Obfuscating. Macht letztlich eh nur die Stacktraces und das Logging kaputt und erschwert damit den Support.


----------



## JanHH (7. Jun 2011)

Danke, dann werd ich mir die zwei mal anschauen. Wenn das mit GPL kein Problem ist, ist ja ok.

Meine Firma gibt halt ein jar-File zum Kunden raus, und zwar eine "Demo-Version", und es soll verhindert werden, dass der Kunde das per Dekompilierung wieder in eine Vollversion verwandelt.


----------



## Wildcard (7. Jun 2011)

Bei einer Demo Version ist das auch halb so wild, denn die muss man wohl nicht Supporten.
Aber mal ehrlich, was hilft obfuscating dabei? Wenn das per Schalter im Quellcode funktioniert würde ich fast wetten das man den dekompilierten Quellcode mit einem Debugger in wenigen Minuten zerlegt, egal ob obfuscated, oder nicht.
Normal arbeitet man da eher mit Lizenzschlüssel, Onlineaktivierung, Modularisierung (die Demo Version enthält nicht alle Module), oder dergleichen.


----------



## nrg (7. Jun 2011)

das können die genauso auch mit obfuscating hinbekommen. würd lieber ne zeitlich beschränkte lizenz machen oder so


----------



## Empire Phoenix (8. Jun 2011)

Obfuscating erschwert es aber etwas in dem sinne das man erstmal den switch finden muss wenn der irgetwo als boolean abcde in der classe zzzxy ist, statt isDemo zu heißen


----------



## JanHH (8. Jun 2011)

Naja man braucht schon eine gewisse kriminelle Energie und Fachkenntnis, um da bei obfuscatetem Code ans Ziel zu kommen. Beides hat der besagte Kunde nicht. An sich hab ich da keine Sorge, ich würds dem im Grunde auch ohne obfuscator geben, aber sicher ist sicher. In der Demo-Version fehlt auch ein wichtiges Modul, ohne das kann man die Software quasi normal benutzen, aber mit den gewonnenen Daten nix anfangen (bzw. diese nicht speichern). Man könnte diesen Teil natürlich nachprogrammieren, aber all das zusammen traue ich dem Kunden wirklich nicht zu.


----------



## tuttle64 (8. Jun 2011)

JanHH hat gesagt.:


> Man könnte diesen Teil natürlich nachprogrammieren, aber all das zusammen traue ich dem Kunden wirklich nicht zu.




Ich schon. Vielleicht hackt ja der Sohn des Filialleiters gerne Java Programme. Deshalb, mach es richtig oder lass es sein.


----------



## Wildcard (8. Jun 2011)

> Naja man braucht schon eine gewisse kriminelle Energie und Fachkenntnis, um da bei obfuscatetem Code ans Ziel zu kommen


Hängt ganz davon ab. Angenommen ein bestimmter Buttonklick löst aus das ein Dialog hochpoppt der dem User mitteilt das die Funktion in der Demo Version deaktiviert ist. Nehmen wir weiterhin an das es sich um eine Swing Anwendung handelt.
Ich würde im dekompilierten Code die main Methode raussuchen (die ja nicht obfuscated ist) einen AWT Event Listener platzieren und einen Conditional Breakpoint setzen der auf die Beschriftung oder den Tooltip des Buttons reagiert. In der Methode muss nun irgendwo der Schalter abgefragt werden (egal wie der Schalter oder die Methode nach der obfuskierung heißt). Wenn ich den Schalter habe, bin ich fertig und habe dafür keine 5 Minuten gebraucht. Bei euch mag das etwas anders aussehen und funktionieren, aber die meisten Tricks lassen sich schnell aushebeln.



> In der Demo-Version fehlt auch ein wichtiges Modul, ohne das kann man die Software quasi normal benutzen, aber mit den gewonnenen Daten nix anfangen (bzw. diese nicht speichern). Man könnte diesen Teil natürlich nachprogrammieren, aber all das zusammen traue ich dem Kunden wirklich nicht zu


Das ist IMO der bessere Schutz.


----------



## JanHH (9. Jun 2011)

Wie macht man es denn "richtig"?

Mir ist auch klar dass man da nicht 100%ig schützen kann, aber besser so als gar nicht.. Wie gesagt, eine wichtige Klasse komplett entfernt, den Rest per Obfuscator geschützt.


----------



## maki (9. Jun 2011)

JanHH hat gesagt.:


> Wie macht man es denn "richtig"?


IMHO gar nicht, egal welche Sprache, man kann alles dekompilieren, nur eine Frage des Aufwandes.



JanHH hat gesagt.:


> Mir ist auch klar dass man da nicht 100%ig schützen kann, aber besser so als gar nicht.. Wie gesagt, eine wichtige Klasse komplett entfernt, den Rest per Obfuscator geschützt.


Komplexität an sich ist auch schon ein sehr wirksamer Schutz, und wenn man Dummy Module ausliefert bzw. wichtige weglässt, muss man sich weniger sorgen machen.


----------



## Empire Phoenix (9. Jun 2011)

Wirklich sicher?
Hm als webapplication mit login beispielsweise (die auf einem eigenen Server läuft), da der kunde nur die Gui und exchangeobjects sieht kann er nie die logic daraus gewinnen. Aber das lohnt denke ich nur in ausnahmefällen, da massiver aufwand und die meisten Kunden deme her abgeneigt sind.


----------

