class-Datei

[Gast]

Hallo Leute,

wenn man die Javadatei compiliert entstehen ja diverse classDatei mit JavaBytecode. Sind solche Bytecodedateien wieder "decompilierbar"? Ich habe irgendwann mal gelesen, das man Java Quellcode nicht wirklich "verstecken" kann.

In C++ wird eine exe erstellt und diese kann man ja nicht wieder "decompilieren". Ich denke man würde sich doch wohler fühlen, wenn nicht jeder auf den eigentlichen Quellcode zugreifen bzw. sich diesen (durch decompilieren der Classdateien) wiederherstellen kann.

Danke + Gruß

 

[hupfdule]

wenn man die Javadatei compiliert entstehen ja diverse classDatei mit JavaBytecode. Sind solche Bytecodedateien wieder "decompilierbar"?

Ja, gibt es einige. Eine Google Suche wird dir schon mehrere bieten.

In C++ wird eine exe erstellt und diese kann man ja nicht wieder "decompilieren".

Doch, man kann alles dekompilieren. Ein dekompilierter Java-Code sollte nur besser lesbar sein, weil dabei die ganzen Variablennamen erhalten bleiben. Ich weiß nicht, ob das bei nativem Code auch so ist. Vermute eher nicht.

Ich denke man würde sich doch wohler fühlen, wenn nicht jeder auf den eigentlichen Quellcode zugreifen bzw. sich diesen (durch decompilieren der Classdateien) wiederherstellen kann.

In wie fern fühlst du dich dann wohler? Dass du weißt, dass niemand sieht, was für einen schlechten Code du schreibst? Dass du weißt, dass niemand deine genialen, hochkomplexen Algorithmen lesen kann, mit denen du bald tierisch viel Geld verdienen kannst, weil sie so toll sind?

 

[Gast]

richtig.

mit http://www.kpdus.com/jad.html kann man dekompilieren.

wenn du etwas dagegen tun willst, dass dein code leicht dekompiliert wird, dann lies mal das hier:
http://www.galileocomputing.de/open...sel26_005.htm#Rxx747java2600504000A061F0451E8

 

[Guest]

Es gibt einige möglichkeiten deinen java code zu verpacken, für den anfang ersetzt du einfach mal die variabeln, methoden und klassennamen durch buchstaben, da wird es schon sehr schwerer das zu verstehen und wenn dir das nicht reicht, gibts auch tools, die den bytecode durchmischen (mir fällt der naem gerade nicht ein), aber sowas gibts auf jeden fall, da werden dann sinnlose blöcke dazu gepackt. Verlangsamt allerdings deine applikation ein wenig.

 

[Anmeldeboykottierer]

Hi,
es gibt (wie schon gesagt wurde) zu jeder Sprache Möglichkeiten diese zu dekompilieren. Das liegt einfach daran, dass jede Datei, die ausgeführt werden soll vom einem System ausgeführt werden muss.
Je nach disassembler bekommst du auch bei C++ oder anderen nativen Sprachen einen schönen lesbaren Quellcode. Es gibt für native Programme nur mehr Auswahl, was die Sprache dahinter angeht. Wenn du mit MS und MFC arbeitest, wirst du anderen Code erzeugen als mit Borland und der VCL. Gute Disassembler kennen hier aber auch die großen und können dir dann Code liefern, der sich wie aus der IDE liest.
Sicherheit hast du an der Stelle also nicht wirklich.

Gruß Der Anmeldeboykottierer

 

[EOB]

heisann, also ich verwende als obfuscator
jshrink ...der ist guenstig zu haben und laesst sich prima einstellen fuer verschiedenen szenarien. auch klassmaster ist nicht uebel. allerdings muss man manchmal ziemlich fummerln, wenn man class.forname etc nutzt. was auch ganz gut sein soll, ist crema/mocha. allerdings wird das nicht mehr supported und kommt sicher mit neueren java 5 sachen nicht zurecht?

gruesse

 

[Guest]

So jetzt hab ich gefunden was ich eben meinte:

So wie das Dekompilieren von Werkzeugen unterstützt wird, so kann auch mithilfe von
Werkzeugen der Code vor Dekompilierung geschützt werden. Diese Werkzeuge, so genannte
Obfuskatoren, automatisieren im Wesentlichen die oben beschriebenen Verschleierungs- und
Verkleinerungs-Techniken. Werkzeuge wie
· RetroGuard,
· JShrink,
· CodeShield
· smokeScreen
· jCloak

wer mehr wissen will, hier das Vorlesungsskript dazu:


02_SchutzDesQuellcodes.pdf

 

[thE_29]

1. JBuilder bietet das feature auch (also obfuscaten)

2. bietet JBUilder dir auch eine Erstellung von nativen executeable Files für jedes gängige OS!

Und wenn du ne exe unter windows hast, kommst du net so schnell auf den java source!

Das wäre halt ne Überlegung werd. Nur musst du halt für jedes OS dann das native File haben (was mit JBuilder ja erzeugt werden kann)

 

[Guest]

Mag JBuilder nitt, hab mich da vor ewigkeiten mal registreiert, um den JBuilder 9 zu bekommen, seit dem nerven die für ihre tollen 5.000 € Produkte via Telefon und Post !!!

=> niemals da registrien !!!!!!!!!!!!!!!!!!!!!!!!!!!

 

[EOB]

hat nicht die witwe von dem programmierer von mocha/crema dessen 'engine' an borland verkauft?

gruesse

 

[Guest]

Gute Disassembler kennen hier aber auch die großen und können dir dann Code liefern, der sich wie aus der IDE liest.

naja nicht ganz, mehr als assembler code machen die auch nicht, es können dir bloss die funktionsaufrufe mit ihren parametern angezeigt werden, aber du kriegst da keinen c++ code raus.

 

[Anmeldeboykottierer]

Also wenn ich lesen kann, welche Komponenten verwendet werden und welche Methoden diese Komponenten verwendet werden, dann ist das schon deutlich mehr als reiner Assembler. Aus irgendeinem Grund (dürfte wohl der Compiler sein) wird für jede gleiche Komponente immer ein recht eindeutiger Assembler erzeugt. Verwendet man also Standardkomponenten, gibt es Anzeichen dafür und viele lassen sich dann auch wiedererkennen. Das heißt du bekommst C++ (auch wenn dies stark vom eingesetzen Dissassembler und dem C++ Compiler abhängt). Es ist jedenfalls teilweise recht gut möglich.