Decompillieren

Kommt darauf an, wieviel Metadaten du mit eincompilierst. Standardmäßig ist das recht viel, so dass sich sogar das Layout des Codes rekonstruieren lässt. Aber man kann das schon sehr gut zurückstellen.

Allerdings verstehe ich nicht, was daran "unsicher" sein soll, außer nach dem Motto "niemand darf meinen Quellcode sehen".

Wenn du ohne Debug-Infos compilierst, erhältst du nicht viel mehr als Assembler-ähnlichen Bytecode und ein paar Metadaten zur Beschreibung der Klassen. Der einzige Unterschied ist, dass es der Assembler-Code für den Virtuellen Prozessor der VM ist. Viel anfangen kann man damit nicht mehr, irgendnen tollen innovativen Algorithmus kannst aber wahrscheinlich nicht verheimlichen, wenn entsprechender Aufwand betrieben wird um das zu rekonstruieren.

Aber wie kann ich nun meinen 1.5er bytcode durch den jad schleusen?

CengizS

Wenn der JAD 1.5er Code nicht kann dann gar nicht.

Spätestens seit 1.5 dürfte das decompilieren IMHO auch recht schwierig zu sein. Es gibt Sprachfeatures (Generics, enums), die es im Bytecode einfach nicht gibt. Ich würde als behaupten, dass es fast unmöglich ist, wieder den Quelltext herauszufinden. Vielleicht kriegst was funktionierendes, aber nicht den Quelltext.

Jester

afaik sieht doch der Bytecode genauso aus, wie wenn man keine Generics verwendet hätte und einfach immer gecastet. Das heißt theoretisch müßte eine Version mit casts dabei rausspringen.
Weiß jemand wie enums im Bytecode umgesetzt sind?

Aber warum schmiert dann der jad immer ab? Wenn ich das oben so lese, dann müsste er ja was "anderes" rausbekommen

Jester schrieb:

afaik sieht doch der Bytecode genauso aus, wie wenn man keine Generics verwendet hätte und einfach immer gecastet. Das heißt theoretisch müßte eine Version mit casts dabei rausspringen.
Weiß jemand wie enums im Bytecode umgesetzt sind?

enums sind Klassen, die statische Referenzen auf Singleton-Instanzen der einzelnen Werte haben. (deshalb geht auch Referenzvergleich mit == bei enums)

Hans0815 schrieb:

Aber warum schmiert dann der jad immer ab? Wenn ich das oben so lese, dann müsste er ja was "anderes" rausbekommen

In Java 1.5 sind lauter neue metadaten drin, auch wenn der eigentliche bytecode gleich ist. Metadaten sind z.B. Debug-Informationen, die der Decompiler sicherlich ausgiebig nutzt.

elise

bei mir mit 1.5 und ad v1.5.8e2 klappt alles wunderbar.

gib mal ein wenig quellcode, compilierbaren (abgespeckt), denn man testen kann, nach .class erstellung, der bei dir abspeckt. so grenzt du das problem auch ein.

also ich hab mit 1.5 ein mehr oder weniger leeres (immer der gleiche fehler) erzeugt und bekomme folgende ausgabe:

Parsing Test.class...The class file version is 49.0 (only 45.3, 46.0 and 47.0 are supported)

elise

This is the error; the important part is "(Unsupported major.minor version 49.0)". Each Java version has an internal major.minor version.. Version 49.0 is Java 1.5 (aka Java 5).

http://forum.java.sun.com/thread.jspa?threadID=562771&tstart=75

nutzt du nen alten jad? nimm mal nen neuen.
nutzt du ne alte ide?
update mal.

wie schon erwähnt: teste die ide "gel", der integrierte decompiler (einfach doppelklick aufs class file ) nimmt auch die 1.5 kompilierten sourcen.

jad:

Jad v1.5.8f. Copyright 2001 Pavel Kouznetsov (kpdus@softhome.net).

glaub der is vom alter her ok,

ide:
keine - javac in konsole

E:\Java>javac -version
javac 1.5.0-rc
javac: no source files

das war's dann wohl net...
Aber was isses dann?