Code verschlüsseln

[zilti]

Ist es möglich, Code zu verschlüsseln nach dem Compilieren, damit er auch mit einem Decompiler nicht mehr einsehbar, aber trotzdem noch verwendbar ist?

 

[Guest]

Yepp, geht. Dazu brauchst du einen so genannten "Obfuscator".

 

[Tobias]

Dann ist er immer noch mit dem Decompiler einsehbar, aber deutlich schwerer zu lesen.

mpG
Tobias

 

[Backwardsman]

ein obfuscator ist nicht dafür gedacht, den code zu verschlüsseln. eigentlich wird er dazu benutzt, den code zu verkleinern, in dem variablen auf einzelne buchstaben abgebildet werden etc... ein vorteil dabei ist allerdings, dass menschen den code nach anwendung eines obfuscators wesentlich schwerer verstehen können, ... was aber keine verschlüsselung ist!

wenn du den code verschlüsseln willst, brauchst du einen schlüssel, und dann hat man das alte problem der schlüssel-verwaltung... wo soll denn der schlüssel aufbewahrt werden... so dass der code kurz vor der anwendung entschlüsselt werden kann??

 

[Bernd das Brot]

Sorry, Backwardsman. Das ist falsch.

s.a. Leo-Dict für "to obfuscate".

zum Topic:
Es ist in Java leider grundsätzlich nicht vorgesehen, Klassen zu verschlüsseln. Aber man könnte darüber nachdenken, einen eigenen Classloader zu schreiben, welcher die aus den JAR- oder .class-Dateien gelesenen Daten erst decoded und danach an den superclassloader zwecks Instantiierung weiter gibt.

Dazu muss man das Laden seiner Hauptklasse mit diesem Classloader erzwingen, denn Java verwendet immer den Classloader der aktuellen Klasse, wenn er weitere Klassen nachladen muss und delegiert bei Mißerfolg an den Parent-Classloader (in Application-Servern gilt das wg. Hot-Deployment nicht immer. S.a. parent delegation modell).
Allerdings habe ich das auch schon mal probiert und festgestellt, daß das ein mühseliges Geschäft ist. Da muss man sehr genau über die Art, wie Java Classes nachläd, bescheid wissen!

Eine andere Möglichkeit sind die angesprochenen Obfuscater, die allerdings bei Reflection-Code versagen können und auch sonst nicht in allen Situationen funktionieren müssen und mit Vorsicht anzuwenden sind! Immerhin erzeugen sie neuen Quellcode, bei dem z.B. die Klassennamen je Paket mit A, B, C durchnummeriert werden - gleiches mit Variablen und Methoden.

So in etwa:

package x.y.w;

import x.y.z.A;

Class A
{
   public int a;
   public void a()
   {
      a=5;
      x.y.z.A.a(a);
   }
}

Dann noch ein Compile ohne Debug-Information und hinterher kann das keiner mehr so richtig lesen. Aber wer sich viel Mühe gibt, kann auch da noch was ausrichten - also nicht wirklich ein Schutz vor Hackern - außer vor "Algorithmus-Dieben"...

 

[Backwardsman]

Sorry, Backwardsman. Das ist falsch.

s.a. Leo-Dict für "to obfuscate".

wenn du schon behauptest, dass meine aussage falsch ist, dann erkläre gefälligst auch warum!!

"to obfuscate" heißt "verbergen"/"trüben" und genau, dass macht der obfuscator ja auch... mit einer verschlüsselung möchte man allerdings erreichen, dass der code nicht mehr lesbar ist! und das schafft der obfuscator nicht... es gibt ja wohl einen gewaltigen unterschied, zwischen "getrübt" und "nicht lesebar"... aus etwas getrübten kann man durchaus information erlangen... aus etwas veschlüsseltem nicht!!! (zumindest wenn es nach dem prinzip der verschlüsselung geht)

das fängt ja schon damit an, dass alle hartcodierten Strings im code vom obfuscator unberührt bleiben... ich kann also den code schon in soweit manipulieren, dass ich ihn decompile, die strings ändere und wieder kompiliere! bei verschlüsseltem code geht das nicht!

 

[NTB]

Davon ganz abgesehen sagt doch die wörtliche englisch-deutsche Übersetzung nichts darüber aus, was ein Obfuscator nun tatsächlich macht. Dennoch hat Backwardsman das sehr trefflich beschrieben.

 

[Guest]

Aber man könnte darüber nachdenken, einen eigenen Classloader zu schreiben, welcher die aus den JAR- oder .class-Dateien gelesenen Daten erst decoded und danach an den superclassloader zwecks Instantiierung weiter gibt.

Da ist dann allerdings auch recht leicht einzusetzen und die entschlüsselte Klasse zubekommen.

 

[Straightflush]

open-source is doch au was feines oder?

 

[zilti]

Nun ja, das paradoxe ist ja, dass ich das genau dazu bräuchte.
Ich hab ne Lobby geschrieben, nun hätte ich die OpenSource machen wollen.
Da die Lobby jedoch auf einen MySQL-Server connected, stehen die MySQL-Logindaten im Quelltext. Nun dachte ich, ich könnte das verschlüsseln.

 

[Wildcard]

Login Daten haben nichts im Quelltext zu suchen.

 

[zilti]

Naja, prinzipiell schon, aaber...
wie soll ichs denn sonst machen?

 

[Wildcard]

Wenn du ein Programm auslieferst, das alle benötigten Daten zum Verbinden besitzt, dann darf dich nicht stören, das User diese Daten einsehen können.

 

[zilti]

Gibt es denn Alternativen dazu, sich mit ner MySQL-Datenbank zu verbinden?
EDIT: Sorry, da ist wohl beim Posten was schiefgelaufen...

 

[Gast]

du verbindest dich zu einem programm auf deinem server und das verbindet sich zu der DB.

Also z.B. ein kleines php script.

 

[AlArenal]

Gibt es denn Alternativen dazu, sich mit ner MySQL-Datenbank zu verbinden?
EDIT: Sorry, da ist wohl beim Posten was schiefgelaufen...

XML-RPC, SOAP, JSON, ..

 

[zilti]

Ich hab ja eigentlich gemeint, Alternativen, sich zu verbinden.

 

[Rock Lobster]

Ich glaube, was Bernd bzgl. Backwardsmans Posting meinte, ist dieses hier:

eigentlich wird er dazu benutzt, den code zu verkleinern

Das ist nämlich nicht das gewünschte Ziel des Obfuscators. Sondern es geht um das, wie er später gesagt hat, "trüben" des Codes. Und nicht um das Kleinermachen (auch wenn das effektiv vielleicht passiert).