de-compilieren von class-dateien?

[bummerland]

hat sich schon mal jemand mit dem de-compilieren von class-dateien beschäftigt? wie lesbar ist der code, der dabei herauskommt?

 

[DTR]

So viel ich weiß bekommst du die Signaturen der Klasse heraus, aber nicht den Code. Kann mich aber auch irren. Am besten mal selbst ausprobieren.

 

[bummerland]

Hab nen decompiler gefunden, der scheint nicht schlecht zu sein.

http://members.fortunecity.com/neshkov/dj.html

Der stellt anscheinend fast den kompletten Quellcode wiederher, nur dass die variablennamen nicht mehr original sind, die erfindet er selbst.

vielleicht kann man beim compilieren irgendwelche parameter angeben, die das decompilieren erschweren?

 

[stev.glasow]

hast du mal den decompilierten code wieder compiliert - ob der läuft.

 

[Nobody]

also ich teste das nacher mal, den ich hätte manchmal schon ganz gerne mal den quelltext von daten angesehen, ging aber leider nicht.

ich denke jeder programmiere sollte so fair sein und keinen quelltext von anderen nutzen, solange ihm dies nicht gestattet wurde. aber das nachlesen um anregungen für eigene problematikas zu finden, finde ich in ordnung daher werde ich das mal testen obs funzt

 

[Stefan1200]

Bei mir zuhause habe ich ein Java Decompiler, vor dem ist jeder Java Byte Code lesbar, der nicht verschlüsselt wurde. Ich habe meine eigenen Programme damit decompiliert, und durfte mit erstaunen feststellen, das nicht nur der Source komplett lesbar ist, sondern sogar die Variablen Namen richtig sind.

Leider kann man diesen Decompiler nicht mehr runterladen, da die Seite down ist. Und aus dem Kopf heraus kenne ich auch den Namen nicht mehr auswendig. Wenn interesse besteht, poste ich das mal nächste Woche.

 

[bummerland]

also wie gesagt, der hier ist echt gut. der stellt den kompletten quelltext wieder her. wenn die class-datei nicht mit entsprechenden parametern kompiliert wurde, werden sogar die originalen variablennamen erkannt.

 

[Stefan1200]

also wie gesagt, der hier ist echt gut. der stellt den kompletten quelltext wieder her. wenn die class-datei nicht mit entsprechenden parametern kompiliert wurde, werden sogar die originalen variablennamen erkannt.

Den DJ Java Decompiler habe ich mir auch mal angeschaut. Der rockt ja.
Mal so nebenbei: Der DJ Decompiler basiert zufällig auf den Decompiler, den ich meinte
Den, den ich meinte, heisst "jad". Und im Ordner von DJ liegt zufällig eine jad.exe (ist auch wirklich der Gleiche)

Danke für den Tipp, dieser Decompiler kann sogar direkt JAR Dateien öffnen und so. Gefällt mir.

 

[aquanox]

Moin,

da beteilige ich mich auch mal an der Diskussion:

Der Decompiler, der mir derzeit am besten zusagt ist wie oben JAD. Für alle Windows Benutzer gibts davon sogar eine bequeme Oberfläche zum herumklicken (FrontEnd Plus).

http://kpdus.tripod.com/jad.html

Der Code, den er produziert ist mit dem Original gleich, fehlen tun nur Kommentare, aber die werden vom Compiler auch nicht in die Klassendateien gepackt.

Das decompilieren kann man erschweren und sogar soweit bekommen, dass es nicht mehr wieder compilierbar wird. Dazu benötigt man sogenannte Obfuscator. Diese löschen alles aus den Klassendateien, das nicht unbedingt für das Programm zum laufen nötig ist. Darunter sind Zeilennummern (Werden nur eingefügt, damit bei einem Fehler die Zeile ausgegeben werden kann) oder Ähnliches. Außerdem stellt er noch paar Sachen um und der decompilierte code glänzt dann an gotos (Existieren in Java nicht als gülige Benutzung), wo vorher schleifen und if's waren.

 

[stev.glasow]

das ist doch mist . gibt es da eine möglichkeit dem compiler zu sagen, dass er so compiliert, dass der code nicht mehr decompilierbar ist ?

 

[mariopetr]

jain. es gibt imho keinen javacompiler, der ein decompilieren verhindert. aber es gibt obfuscator, welche das decompilieren relativ erfolgreich verhindern. allerdings ist java (und alle anderen sprachen) prinzipbedingt nicht vor reverse engineering sicher. aber man kann den aufwand fuer den "cracker" fast beliebig in die hoehe treiben. wozu das gut sein soll, weiss ich aber auch nicht. zum einen gibt es ja das urheberrecht, zum andern kann mann zwar das decompilieren erschweren, aber nicht verhindern. oft macht man sich aber das leben selbst durch obfuscator das leben schwer. wenn man (relativ) sicher gehen will, kann man die klassen auch verschluesseln, ein tool dafuer kann man zb unter mailto:securepackager@itemic.<com | de> erhalten

 

[stev.glasow]

aber man kann den aufwand fuer den "cracker" fast beliebig in die hoehe treiben. wozu das gut sein soll, weiss ich aber auch nicht. zum einen gibt es ja das urheberrecht, zum andern kann mann zwar das decompilieren erschweren, aber nicht verhindern. oft macht man sich aber das leben selbst durch obfuscator das leben schwer.

damit, dass jemand den code sieht, kann mann ja leben, aber bei passwörtern, etc siehts schon anders aus

wenn man (relativ) sicher gehen will, kann man die klassen auch verschluesseln, ein tool dafuer kann man zb unter mailto:securepackager@itemic.<com | de> erhalten

ist itemic.com nicht deine seite ?
kostet das tool was ?

 

[mariopetr]

www.itemic.com ist die site meines arbeitgebers (fuer das design wuerde ich mich schaemen). das tool an sich hat ein mitarbeiter erstellt, als urheber ist er auch frei in seiner lizenzgebung (die firma darf das tool nutzen, er darf dafuer in seiner arbeitszeit daran arbeiten). frag ihn einfach, ob er dafuer geld haben will oder nicht, ich weiss es nicht.

fuer passwoerter wuerde ich eher richtige verschluesselung empehlen, oder, wenn man nicht das passwort braucht, sondern nur authentifizieren will, java.security.* (also den digest speichern).

 

[DTR]

Mit Passwörtern in Klassen ist das so eine Sache. Wenn ich sie nicht übers Decompilieren herausbekomme kann ich immernoch über Vererbung versuchen sie zumindest zu nutzen. deshalb sollte man sie auserhalb der Klassen aufbewahren. Da kann man sie dann auch nach belieben verschlüsseln.

 

[Nobody]

für passwort verschlüsselung eignet sich assembler meiner meinung nach am besten. durch verschiebungen der bit reihenfolge und ähnliches kann man die meisten zur weisglut treiben, da die entschlüsselung im quelltext kaum erkennbar ist und der kreis der sich mit assembler auskennt ist doch deutlich geringer als mit den hochsprachen

 

[DTR]

der kreis der sich mit assembler auskennt ist doch deutlich geringer als mit den hochsprachen

Womit die Nutzbarkeit des ganzen wieder stark eingeschränkt ist

 

[Nobody]

dem user solls doch egal sein, wie das ganze funktioniert und am assa tool solls nicht scheitern:
http://www.kryptocrew.de/archiv/coding/asm/Asmtut.html

wird das mit dem ringsystem sogar erklärt.

ach und wegen sicherung der quelltexte: .htaccess bietet zumindest serverseitig sehr guten schutz der rest liegt dann an euch. aber wenn jemand den quelltext haben will wird ihn bekommen, wobei wohl das erlernen und entwickeln da besser wäre

 

[RoyArtelo]

Do you think that Obama is going to win because the Republicans have such a bad candidate?
Why did John McCain make his final argument against Obama... coal?
That's his closing argument? William Ayers, Rev. Wright, spreading the wealth, Born Alive, meeting dictators without preconditions, etc. all have to take a back seat so that McCain can go to Colorado and New Mexico to talk about coal? Does this more or less explain why he's going to get his clock cleaned Tuesday?

 

[ARadauer]

falls jetzt hier jemand in den alten thread rein schaut, weil ihn der spam nach oben gepusht hat und fragen über das decompilieren von class files auftauchen...

www.kpdus.com/jad.html jad ist da ganz sinnvoll