class-Datei modifizieren

[gast2]

Hallo Leute,

ich habe eine Anwendung wo es keine Sourcen mehr zu gibt. Ich habe nur die class-Files und es sollen an einer Stelle (ein String) Änderungen gemacht werden (nur einige Zeichen austauschen).

wie stehen die Chancen das folgendes läuft:

1) HexEditor (könnt ihr einen empfehlen?) die besagten Zeichen austauschen und wieder ab zu den anderen Klassen.

2) Ich habe einen Teil der Klassen decompiliert bekommen, aber stelle fest das vieles fehlt....nun hab ich deswegen nur die besagte Klasse decompiliert und die restlichen class-Dateien der Anwendung in ein jar gepackt. So das ich quasi nur meine eine Klasse neu übersetzen muß (ist das vom Prinzip her erstmal okay?). Problem ist das die ganze Anwendung unter Java 1.3.1_keine Ahnung geschieben wurde und lief. Ich hab mir jetzt die letzt Java 1.3.1_20 version runtergeladen und will die eine Klasse damit komilieren. Wie groß ist die Gefahr das die Anwendung nach einfügen/ersetzen meiner Klasse nicht meht funktioniert (woran kann es liegen? Bytecodeprobleme bzw. unterscheidet sich der Bytecode von 1.3.1_xx und 1.3.1.yy?)

Hoffe ihr könnt mir da ein wenig auf die Sprünge helfen...oder gibt es generell eine andere Möglichkeit mein Vorhaben zu realisieren?

Noch ne kurze Frage am Rande...hab jdk 1.5, sdk 1.4 und sdk 1.3 installiert. passe dann immer die Path, Java_Home und Java_JRE bei den Umgebungsvariablen an...wie kommt es das immer java 1.5 angezogen wird wenn ich mit "java -version" teste?

Gruß,
gast2

 

[JPKI]

1) Möglich wär's, ist aber sehr kompliziert.
2) Welchen Decompiler benutzt du denn? Ich kann dir JAD empfehlen, der dekompiliert so gut wie alles.

Ach ja, da ist nochwas: Ist das überhaupt legal was du da tust? Ich meine, wenn in der JAR keine Quelltexte drin sind, hat das warscheinlich durchaus seine Gründe :noe: :meld:

 

[Rock Lobster]

1) finde ich jetzt nicht großartig kompliziert. Solange nur Zeichen "ausgetauscht" werden müssen, ändert sich ja nix an der Größe usw. Also das ist eigentlich kein Problem.

Hex-Editor: Schau mal bei mirkes.de, das ist einer der besten (und kostenlos).

@ JPKI, zum Thema Legalität: Das ist eh so 'ne Sache... man kann wirklich einiges dabei lernen, wenn man mal in .class oder .exe-Dateien rumforstet und ein paar Bytes ändert. Und das finde ich ehrlich gesagt nicht problematisch. Wenn er tatsächlich was illegales vorhat, wird er das sowieso wissen und da kannst Du ihn auch nicht dran hindern.

 

[Murray]

2) Ich habe einen Teil der Klassen decompiliert bekommen, aber stelle fest das vieles fehlt....nun hab ich deswegen nur die besagte Klasse decompiliert und die restlichen class-Dateien der Anwendung in ein jar gepackt. So das ich quasi nur meine eine Klasse neu übersetzen muß (ist das vom Prinzip her erstmal okay?). Problem ist das die ganze Anwendung unter Java 1.3.1_keine Ahnung geschieben wurde und lief. Ich hab mir jetzt die letzt Java 1.3.1_20 version runtergeladen und will die eine Klasse damit komilieren. Wie groß ist die Gefahr das die Anwendung nach einfügen/ersetzen meiner Klasse nicht meht funktioniert (woran kann es liegen? Bytecodeprobleme bzw. unterscheidet sich der Bytecode von 1.3.1_xx und 1.3.1.yy?)

Das sollte so funktionieren. Die unterschiedlichen Version vom JDK 1.3 sollten untereinander kompatibel sein; insofern ist da wohl kein Problem zu befürchten. Theoretisch könntest du auch einen neueren Compiler verwenden und diesem mit -source 1.3 und -target 1.3 mitteilen, dass a) die Sourcen für das JDK 1.3 gemacht sind und b) Bytecode erzeugt werden soll, der mit dem JDK 1.3 laufen soll. Sicherer ist aber der alte Compiler (wenn du ihn noch hast; zum Download gibt es das alte JDK wohl nicht mehr).

Noch ne kurze Frage am Rande...hab jdk 1.5, sdk 1.4 und sdk 1.3 installiert. passe dann immer die Path, Java_Home und Java_JRE bei den Umgebungsvariablen an...wie kommt es das immer java 1.5 angezogen wird wenn ich mit "java -version" teste?

Das liegt wohl daran, dass das Installationsprogramm die java.exe in das Windows-Systemverzeichnis kopiert.

 

[gast2]

Hallo,

danke für die Antworten soweit.
Nein ich habe nichts illegales vor. Die Anwendung ist alt und der Programmierer nicht mehr da. Im CVS sind keine brauchbaren Sourcen und jetzt will der Kunde ne kleine Änderung.

Also es müssen wirklich nur 4 Zeichen in einem 10 Zeichen-langen String ausgetauscht werden. Deswegen dachte ich ich probiers als erstes mit nem HexEditor...Strings kann man ja relatic gut im Klartext sehen...

Ich lass von meinen Ergebnissen hören...

Gruß,
gast2

 

[gast2]

Hallo,

hab vergessen noch zu fragen, wegen der Path Geschichte...kann ich die entsprechende java.exe die im Windowsverzeicnis lungert einfach löschen? Denn ich will ja nicht das immer Java 1.5 angezogen wird...

In Netbeans kann ich ja einstellen mit welcher Java Version ich arbeiten will, aber mit Konsole kann ich das so nicht.

Gruß,
gast2

 

[JPKI]

Hm. Wenn du mit Windows arbeitest, schreib dir doch ein paar kleine Batchdateien, etwa so:

java3.bat

"PfadZurExeDerJRE3InAnführungszeichen" %1

java5.bat

"PfadZurExeDerJRE5InAnführungszeichen" %1

und speicher' sie im Windows-Installationsordner.
Dann kannst du die Programme über die Konsole mit

java3 Klasse

mit der 3er-JRE ausführen und mit

java5 Klasse

mit der 5er JRE.

 

[tuxedo]

Wie übel ist das denn. Hab JAD an einer Bibliothek ausprobiert zu der ich keine Sources hab:

Das Ding produziert ja, zumindest auf den er sten Blick, astreinen Quelltext. Und ich hab nichtmal 2min gebraucht.

Ist decompilieren generell so easy oder gibts da Einschränkungen? Wenn ersteres Zutrifft muss man sich ja sorgen um seine nicht-quell-offenen Programme machen ?!

- Alex

 

[gast2]

super, danke.

Darf ich fragen wofür das %1 steht? Sone Art Parameterübergabe?

Btw. für die die es interessiert: SUN hat ne Archive Page da kann man sich sogar noch SDK 1.2 runterladen lauter andern alten Krempel.

Gruß,
gast2

 

[tuxedo]

%1 ist das erste übergebene Argument der Batch-File, quasi wie in der Main-Methode das args[0] ...

 

[JPKI]

Das %1 steht für den ersten Parameter der Batchdatei. Wenn dieser Leerzeichen enthält, bitte in Anführungszeichen angeben.

 

[JPKI]

Wie übel ist das denn. Hab JAD an einer Bibliothek ausprobiert zu der ich keine Sources hab:

Das Ding produziert ja, zumindest auf den er sten Blick, astreinen Quelltext. Und ich hab nichtmal 2min gebraucht.

Ist decompilieren generell so easy oder gibts da Einschränkungen? Wenn ersteres Zutrifft muss man sich ja sorgen um seine nicht-quell-offenen Programme machen ?!

- Alex

Natürlich. Dekompilieren von Java-Programmen ist immer so einfach, da Java-Programme ja nur zu Bytecode kompiliert werden, welcher sehr einfach wieder zurückzuverwandeln ist.

Wenn du deine nicht-quelloffenen Programme schützen willst, bleibt dir nichts anderes übrig, als die Hemmschwelle des Täters mit massiven Urheberrechtsvermerken hochzusetzen. Das hilft vielleicht.

 

[tuxedo]

Hab dazu jetzt ein wenig gegoogelt und gelesen... Ich denke für's erste tun's bei mir obfuscatoren... Da dauert's dann wenigstens nichtmehr 2min um lesbaren und verständlichen code zu haben.
Und mit Passwörtern im Code etc. werde ich in Zukunft auch vorsichtiger sein... bzw. mir was einfallen lassen...

Dass es so einfach ist hätte ich mir im leben nicht träumen lassen.

 

[Rock Lobster]

Naja im Grunde kannst Du alles zurückbauen - Deine CPU kann es lesen, also kann auch ein Mensch es lesen. Natürlich ist es bei Java dann eben besonders einfach

Man sollte sich also generell NIE drauf verlassen, daß man irgendwie etwas sicheres machen kann. Man kann's den Leuten nur erschweren. Aber wenn einer Dein Programm unbedingt auseinandernehmen WILL, dann macht es auch keinen großen Unterschied mehr, ob er 5 min oder 5 Tage braucht. Im Gegenteil, eine Herausforderung könnte demjenigen sogar noch sehr gefallen

Daher ist es eigentlich prinzipiell auch wurscht, ob man jetzt Java benutzt oder mit C++ eine richtige Binary macht, zumindest wenn es um Sicherheit bzgl. Dekompilieren geht. Das einzige, was auch ich machen würde, wäre bestimmte Dateien wenigstens so zu verschlüsseln, daß nicht jeder Noob drin rumpfuschen kann (z.B. wenn Du ein Spiel machst und dann die Eigenschaften für bestimmte Objekte usw. verschlüsselst, weil Du z.B. Cheaten unterbinden willst), sodaß das nur denen vorbehalten ist, die sich damit auskennen. Damit grenzt man seinen Kreis etwas ein. Aber wie gesagt, wer's unbedingt hinbekommen will, der bekommt es auch hin, es ist letztendlich nur eine Frage der Zeit, und die kann verdammt kurz sein.

 

[tuxedo]

naja, die zeit würd ich halt gern von 2min auf ein paar stunden, besser Tage hochschrauben. Weil: Selbst ein Java-Noob schafft es, wenn man ihm den Namen "JAD" gibt, in 5min jede x-beliebige klasse zu decompilieren.

Klar, es gibt Cracks die sind da ziemlich fit drin und schaffen das "korrigieren" der verstümmelten Namen durch Obfuscatoren auch in absehbarer, für sie kurzer Zeit.

Es soll halt nicht zu einfach sein, finde ich.

Weiß jemand ob das bei C/C++ genau so einfach und schnell (2min) geht? Oder ist es da aufwendiger?

 

[Rock Lobster]

Bei C++ ist es aufwendiger, da hierbei einiges an Informationen wegfällt. Unter Java hast Du ja noch alle Klassennamen, Methoden, Variablen usw, und unter C++ wird eben alles durch feste Adressen ersetzt. Auch Vererbungen usw. dürften weniger stark nachzuvollziehen sein. Und natürlich gibt es unter C++ Templates, und die wieder zurückzubasteln ist ein Ding der Unmöglichkeit

Also als Assembler-Code kannst Du es natürlich problemlos anschauen, und es gibt auch Decompiler, die dann Schleifen und If-Abfragen durch C-Code ersetzen, aber es ist bei weitem nicht so lesbar wie dekompilierter Java-Code.

 

[tuxedo]

... also wär das nur was für cracks... und nicht für die breite Masse

Mir schwebt da gerade folgendes Konstrukt vor:

Alle Java-Klasse, bis auf eine art Starter-Klasse verschlüsseln. Entschlüsselt wird mittels eines Schlüssels der von einer Schlüssel-Library die in C++ implementiert ist und mittels JNI angebunden wird.

Nach dem decompilieren des Java-Programms hat man nur die Starterklasse und viele verschlüsselte Klassen. Um die noch zu entschlüsseln muss man erst die c++-library "knacken". Hmm, okay, auch doof. Die "Anleitung" zum bedienen der Schlüssel-Library steht ja in der Starterklasse... *am kopf kratz* *grübel*

Naja, obfuscator reicht ja mal für's erste LOL

- Alex

 

[Rock Lobster]

Jo, ich sag's ja, Du kannst es nicht sicher machen. Denn wenn Dein Programm das Teil entschlüsselt, dann kann das auch jemand verfolgen und sich genau anschauen, WIE das entschlüsselt wird. Oder noch einfacher, das Programm starten und dann die entschlüsselten Klassen aus dem Speicher rausfischen

Also einfach keine großen Mühen verschwenden. Obfuscator ist okay, dann hat - wie Du sagst - die breite Masse schonmal keinen Durchblick mehr. Aber den Rest wirst Du nicht beeindrucken können, egal wie viel Energie Du da reinsteckst.

 

[tuxedo]

Jo, meine Hirnwindungen entknoten sich langsam wieder. Solange das "entschlüsseln" auf Java-Seite getriggert wird, reicht es aus, der unverschlüsselten "Start"-Klasse die Anleitung mittels decompiler zu entlocken.

Richtig übel wirds wenn man den in vielen Thinkpads verbauten Kryptographie-Chipsatz ins Spiel bringt... Allerdings ist man dann auf nur ein Gerät beschränkt und kann die Software nicht weitergeben :-(

- Alex

 

[Rock Lobster]

Naja man muß es letztendlich aus 'ner anderen Richtung betrachten. Es gibt eigentlich zwei Gründe, warum man seinen Code schützen will:

a) man hat streng geheime Algorithmen
b) man will das Programm verkaufen und hat 'ne Freischaltung drin

Fall a) ist meist Blödsinn, da vermeintlich "eigene" Algorithmen oftmals doch schon bekannt sind oder es bereits bessere gibt. Und ansonsten kriegt's ein Profi eh raus, weil wenn die CPU es ausführt, kann man es auch nachvollziehen (mit entsprechendem Aufwand). Außerdem ist es eher ein Vorteil, wenn gute Algorithmen weitläufig bekannt sind, denn dadurch werden diese noch schneller und stärker optimiert, was letztendlich allen zugute kommt.

Fall b) wird auch oft überschätzt, denn derjenige, der das Programm crackt, würde die Vollversion meist eh nicht kaufen. Da ist es besser, mehr Zeit und Energie in das Programm zu stecken, dann kaufen es auch mehr ehrliche Leute, anstatt sich nur auf den Crack-Schutz zu konzentrieren, der eh in wenigen Stunden ausgehebelt ist und bei den Leuten, die das Programm ohnehin nicht kaufen wollen, sowieso keinen Vorteil bietet.

Daher habe ich auch aufgehört, mir darüber Gedanken zu machen. Es bringt einfach nix, da kann man noch so ausgeklügelte Systeme haben, oft ist es dann trotzdem sehr schnell rausgehebelt. Ein Kumpel von mir meinte neulich auch, sein Spiel sei sehr sicher... und 10 Minuten später konnte ich ihm beweisen, daß es alles andere als sicher war

Die einzige Ausnahme in Fall a) wäre, wenn Du etwas militärisches oder staatliches machst, da gibt es natürlich Gründe, warum man bestimmte Dinge geheimhalten will. Aber auch hier ist es besser, nicht auf den Algorithmus zu setzen, sondern auf einen großen Schlüsselraum. Denn den richtigen Schlüssel zu finden ist viel schwieriger, als den Algorithmus zu knacken. Vor allem, wenn die Software vorliegt

 

[tuxedo]

Klar, bei "normalen" Programmen stimm ich dir vollkommen zu... Und "normale" Programme decken ja schon fast alles ab was es gibt.

Ist jetzt vielleicht ein blödes Beispiel... Aber man stelle sich nur mal vor was es alles für Hacks gäbe wenn World of Warcraft (sollte bekannt sein) mit Java geschrieben wäre und man in wenigen Minuten einblick in den kompletten Quellcode hätte...

Blöd wird's immer dann wenns viele davon negativ betroffen wären... Und bei nem Onlinespiel mit so vielen Spielern weltweit wäre das doch verheerend.

Aber wie gesagt. Das ist dann wohl doch die Ausnahme ...

 

[Rock Lobster]

World of Warcraft ist auch ein gutes Beispiel, da ja der Online-Server überprüfen kann, ob Deine EXE sich noch im Auslieferungszustand befindet oder ob Du ein registrierter Benutzer bist etc. Und auf den Code auf dem Server hat natürlich auch keiner Zugriff. Daher ist das eben sicher.

Falls Du jetzt aber eher die Engine meintest, also daß z.B. keiner die 3D-Sachen rauslesen und für sich selbst benutzen kann, dann denke ich, daß auch das zunehmend an Bedeutung verliert, da ja heutzutage auch schon viele freie 3D-Engines mit erstaunlicher Qualität verfügbar sind. Somit ist es meist gar nicht nötig, sich da an anderen Engines zu bedienen.

Wenn man jetzt jedoch eine absolute High-End-Engine nachprogrammieren will, ist man damit wiederum so lange beschäftigt, daß sie schon wieder veraltet ist, bis man sie endlich fertig hat. Und direkt klauen und selbst verwenden geht eh nicht, da hierfür immer noch das Urheberrecht zieht und das eigentlich jeder mitkriegen müßte, wenn jetzt einer ein Spiel rausbringt, dasd unberechtigterweise eine aktuelle Spiele-Engine verwendet

 

[tuxedo]

Nene, ich mein eher das WoW-Protokoll das zwischen Client und Server gesprochen wird. Da setzen die meisten nicht zugelassenen Tools an. Wenn ich natürlich den Protokoll-Layer in akzeptabler zeit decompilieren kann, dann ist das wesentlich einfacher und inhaltlich korrekter, wie wenn ich den Traffic mitsniffen muss um rauszufinden welches byte was macht um nacher ein Tool zwischenzuschalten das mit nen Vorteil gegenüber anderen verschafft.

Es geht da vielmehr um das Reverse-Engineerung und Bug-Using als um das modifizieren des Clients.

 

[Rock Lobster]

Jo stimmt, da hast Du Recht. Wobei ich nicht weiß, inwiefern man da richtig krass abgehen kann, sobald man das Protokoll kennt. Ich denke, die Server-Software wird schon einige "Fehlanfragen" erkennen. Aber klar, Sicherheitslücken gibt's immer