.class-Dateien bearbeiten?

[n00b]

Kann ich ".class" Dateien bearbeiten? Wenn ja mit welchem Programm

L-ectron-X hat den Titel angepasst.

 

[Beni]

Mit irgendeinem Hexeditor (siehe google) kannst du eine class-Datei sicherlich bearbeiten.

Ob das allerdings Sinn macht... (ich bezweifle es).

Es gibt auch sog. "Decompiler" die class-Dateien zurück in java-Dateien verwandeln, siehe hier.

 

[Vril]

Der JBuilder von Borland decompilet, soweit ich weiss, eine *.class auch zurück in eine *.java so das man den Inhalt wieder lesen kann!

Wobei ich das eher als Nachteil empfinde, da ja dann jeder Nutzer im Stande ist den Source zu lesen und jede Java Anwendung gezwungenermaßen eine OpenSource Anwendung ist.

Gibt es da eigentlich eine Möglichkeit dem entgegenzuwirken, wenn man eine *.exe erzeugt werden ja i.d.R. auch die einzelnen *.class benötigt?

 

[Roar]

Der JBuilder von Borland decompilet, soweit ich weiss, eine *.class auch zurück in eine *.java so das man den Inhalt wieder lesen kann!

Wobei ich das eher als Nachteil empfinde, da ja dann jeder Nutzer im Stande ist den Source zu lesen und jede Java Anwendung gezwungenermaßen eine OpenSource Anwendung ist.

quark, lies dir mal die definition von open source durch. desweiteren kansnt du exe dateien ebenso dekompilieren und lesbaren sorucecode zu bekommen

Gibt es da eigentlich eine Möglichkeit dem entgegenzuwirken, wenn man eine *.exe erzeugt werden ja i.d.R. auch die einzelnen *.class benötigt?

such im forum zu obfusactor etc. gabs schon oft genug.

@n00b: schau dir mal jclasslib an, damit kansnt du class files anschauen. ob man die auch bearbeiten kann weiß ich nicht.

 

[0xdeadbeef]

Es gibt im übrigen - wie ich kürzlich zu meiner Verwunderung feststellen mußte - Obfuscators, die auf Bytecode-Ebene Gemeinheiten einbauen, die herkömmliche Decompiler wie JAD zum Absturz bringen bzw. unsinnigen Quellcode erstellen lassen. Da braucht es dann schon größere Kaliber, um an den - relativ unlesbaren - Quellcode zu kommen.

Man muß aber ganz allgemein sagen, daß ein "ofuscated" Quellcode nicht wirklich viel mehr Einsicht in den Quelltext bietet als ein aufbereitetes (Runtime-Aufrufe usw.) Bytecode-Listing. Und das wiederum ist auch nicht mehr oder weniger lesbar als die Ausgabe eines guten Disassemblers für herkömmliche Exe-Dateien.

Der einzige Unterschied zum Schutz von Exe-Dateien ist die Tatsache, daß man dort Debugger-Traps usw. einbauen kann, die das Erreichen des unverschlüsselten/entpackten Machinencodes sehr erschweren bzw. für den Laien beinahe unmöglich machen. Derlei Hardcore-Schutz kommt aber IMHO nur beim Kopierschutz von Spielen, bei Trojanern oder ganz selten bei sehr teueren Anwendungen zum Einsatz. Inbesondere das große Feld an Trojanern/Dialern, die sich derart gegen die Analyse durch Virenscanner schützen, verdeutlicht aber auch, daß diese Möglichkeit zum Schutz von Exe-Dateien aber in der Tat auch große Risiken birgt. Und letztendlich kann man ohehin IMMER an den Machinencode bzw. Bytecode gelangen, weil der halt irgendwann mal unverschlüsselt im Speicher vorliegen muß.

Eigentlich empfinde ich die gesamte Thematik persönlich ohehin eher als Vorteil von Java. Wer unbedingt seinen Quellcode schützen will, kann einen Obfuscator benutzen, was zumindest direkten Codeklau erschwert/verhindert.
Ansonsten heißt es "Geben und Nehmen". Oft interessiert man sich ja, wie jemand prinzipiell an ein Problem herangegangen ist, ohne daß man wirklich Quellcode "entwenden" will. So Marke: wie haben die das Scrolling so schnell hinbekommen?

Aus diesem Grund benutze ich für meinen Kram auch absichtlich keinen Obfuscator. Damit lasse ich Einblicke auf den Quellcode zu, ohne den Quellcode offenlegen zu müssen. Das ist nämlich mit einem Haufen Arbeit verbunden, wenn man es ordentlich machen will. Da ist es doch angenehmer, für Interessierte den "Hintereingang" offen zu lassen. Wenn die sich beschweren, daß der Quellcode unverständlich oder das Programm schlecht designed ist, kann man immer noch sagen: "deshalb habe ich den Quellcode ja auch nicht veröffentlicht".