gcj Compiler erweitern

Z

ziploader

Grünschnabel
Hallo,

ich möchte gerne den gcj-Compiler unter Linux dahingehend erweitern, dass er beim Kompilieren die .class Dateien verschlüsselt und beim Ausführen on-the-fly entschlüsselt.

Kann mir jemand mit Informationsquellen weiterhelfen bzw. hat jemand so etwas schon mal gemacht


Gruß
Toni
 
Hallo!

also gcj ist ein sogenannter Ahead of Time compiler der aus einem Java Quellcode Java Bytecode und daraus wiederum nativen Maschinencode erzeugen kann. Dieser ist dann ähnlich "verschluesselt"/codiert wie das ein entsprechendes C Programm wäre. Der Leistungsumfang des gcj bei der Umwandlung von Java bytecode in Maschinencode hat aber auch Grenzen... beispielsweise gibt es bisher noch keine Unterstützung für Grafische auf AWT/Swing basierende Anwendungen...

Falls du trotzdem noch eine Verschlüsselung brauchst würde ich so vorgehen, dass ich eine Art Launcher Anwendung um die "gcj Java Anwendung" herumstricken würde. Diese Launcher Anwendung würde dann den (in irgend einer Form) verschlüsselten Code in den Speicherladen, dort entschlüsseln und von dort aus dann ausführen.

Gruß Tom
 
Hallo zurück!

Ich möchte aber nur den Bytecode verschlüsseln und dann beim Ausführen wieder entschlüsseln. Normalerweise kann man sich dafür einen eigenen Classloader schreiben, der den Code vor dem Kompilieren verschlüsselt. Kann man das auch beim GCJ so machen?

Soweit ich es bisher verstanden habe, benutzt der GCJ die libgcj (ich glaube so ähnlich wie rt.jar bei SUN) und Libaries aus dem GNU Classpath Project. Auf der GCJ-Homepage kann man sich auch die Unterschiede zwischen beiden anschauen.

Könnte man es nicht so machen, sich einen eigenen Classloader mit encrypt-Methode zu schreiben?

Ich kenn mich mit diesen ganzen Libaries unter Linux nicht so gut aus. Hat jemand schonmal die Libaries für GCJ erweitert (egal mit was)?

Gruß
Toni
 
Hallo,

ich glaube ich muss meine letzte Aussage korrigieren. Natürlich möchte ich nicht eine .class-Datei mit dem Classloader verschlüseln, weil das völlig unsinnig wär!

Mein Vorhaben ist folgendes:

Ich habe die Aufgabe nach einer Möglichkeit zu suchen, .class Dateien zu verschlüsseln und zur Laufzeit wieder zu entschlüsseln, um den Bytecode zu schützen. Das Verschlüsseln kann ich nur in einem seperaten Schritt mit einem kleinen Tool machen.

Das Entschlüsseln der .class Dateien zur Laufzeit ist schon schwerer und deshalb brauche ich eure Hilfe. Man muss sich das vom Sicherheitsstandpunkt vorstellen! Bei Sun's JVM kann man eigene Classloader schreiben, mit denen man die .class Dateien entschlüsseln könnte. Leider ergibt sich daraus das Problem, dass jeder andere diesen Classloader überschreiben und so den Inhalt der .class Dateien z.B. in irgendeine Datei weiterleiten könnte.
Darum war meine Überlegung, den GCJ zu erweitern. Dort werden die entsprechenden Bibliotheken ja kompiliert. Ich habe die Info bekommen, dass man die Entschlüsselung in der Datei libjava/defineclass.cc vornehmen könnte.

Kennt jemand noch andere Möglichkeiten beim GCJ, um einen eigene Classloader zu schreiben bzw. weiß, wo man in diesem File die decrypt-Methode plazieren müsste?

Ich kann kein C++. Vielleicht gibt es hier Leute, die C++ und Java beherrschen und mir weiter helfen können.
 

Anhänge

Hallo!

Code: 
Leider ergibt sich daraus das Problem, dass jeder andere diesen Classloader überschreiben und so den Inhalt der .class Dateien z.B. in irgendeine Datei weiterleiten könnte.
Na ja, wenn die ClassFiles versschluesselt sind, koennen andere ClassLoader ja nichts damit anfangen,...

dann wuerde ich so vorgehen, dass ich einen eigenen ClassLoader schreiben wuerde der verschluesselte Klassen
laden kann. Dazu delegiert er beim Laden der Klasse vom FileSystem zunaechst an eine C Library welche das
Entschluesseln uebernimmt. Kehrt die Aufruf auf der C-Lib zurueck so gibt er die entschluesselten bytes des
ClassFiles weiter an die eigentliche defineClass Methode....
Du kannst deine Anwendung so entwerfen, dass die verschluesselten Klassen nur von deinem ClassLoader geladen werden...


Das Verschluesseln der Class-Files kann dann extern erfolgen.

Gruss Tom
 
Mit dem Weiterleiten ist es so gemeint, dass du meinetwegen ne Funktion zur Weiterleitung direkt hinter die decrypt-Methode knallst und somit den entschlüsselten bytecode herausbekommen würdest, der auch nach der Entschlüsselung an die JVM weitergereicht wird.

Und genau das versuche ich zu verhindern. Man soll es so schwer wie möglich haben, an den bytecode (z.B. für spätere Decomplierung) heranzukommen.


Tom: "Du kannst deine Anwendung so entwerfen, dass die verschluesselten Klassen nur von deinem ClassLoader geladen werden..."

Ok, da stimme ich mit dir überein.


In den libgcj Sourcen ist die Datei ClassLoader.java auch vorhanden. Würdest du hier eine Klasse für einen eigenen Classloader anlegen?
Mein Problem ist hauptsächlich, wo ich den Classloader anlegen bzw. hinschmeissen muss und wie ich es erreiche, dass nur die verschlüsselten Dateien an ihn weitergereicht werden.
 
Zuletzt bearbeitet:
Hallo!

Du koentest ja auch das defineClass innerhalb deiner C-Lib durchfuehren.
CustomClassLoader -> loadClass(...) -> C-Lib -> verschluesseltes ClassFile einlesen -> class bytes entschluesseln -> defineClass(...) von java.lang.ClassLoader mit den entschluesselten byte[] aufrufen (immer noch innerhalb der C-Lib!)-> Class Instanz zurueckliefern ... -> und weiter gehts in Java...

Gruss Tom
 
ist ja ein spannendes Thema, aber was hält Dich eigetnlich davon ab einen Obscurator zu verwenden (oder wie so'n Teil heißt)
dann kann man zwar decompilieren, hätte aber nicht wirklich was davon.

Takidoso
 
Hallo,

einen Obfuscator verwende ich zusätzlich.

Mein Primärziel ist die größtmögliche Sicherheit zu erreichen. Es wird sicherlich immer Leute geben, die auch sowas knacken können, aber ich versuche einen höchstmöglichen Arbeitsaufwand damit zu verbinden.
Außerdem ist die Aufgabe von meinem Betreuer und vom Thema so vorgeschrieben, diese Möglichkeiten zu evaluieren. Darum werde ich um dieses Thema leider nicht mit dem simplen Einsatz eines Obfuscators drumrum kommen... ;)
 
ahhh verstehe. Allerdings wie wird eigetnlich gewährleistet, dass dieser Code dann noch Plattformnabhängig läuft?
Müsste man dann vor Einsatz Deiner Anwendung eine entsprechende Bibliothek noch zusätzlich installieren, die dann für diverse Plattformen geschrieben wird.
Mhhh lässt mich Zweifeln ob man da nicht lieber was von vorneherien anderes Nimmt als Java. Aber das ist sicher wieder meine zu praxis und Aufwand/Kosten orientierte Sicht.

Takidoso
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück