jar aus RAM heraus starten

[UweA]

Hallo,

ich würde gern ein Java-Programm direkt aus dem Speicher heraus starten.
Also so etwas wie:
Process proc =Runtime.getRuntime().exec("java -jar A.jar");

nur das "A.jar" nicht auf einem Filesystem liegt sondern direkt im Speicher.

Hat jemand eine Idee?

Grüße,
Uwe

 

[Thallius]

Sorry aber das macht überhaupt keinen Sinn.

 

[UweA]

Doch.
Das eigentliche jar file liegt verschlüsselt auf dem Dateisystem. Es wird über ein C-Programm entschlüsselt und in den Speicher kopiert und von da aus gestartet.

 

[Thallius]

Dann must du halt das C-Programm starten. Wo ist denn da das Problem?

 

[UweA]

Das Problem liegt darin, dass das Starten das Java-Programms aus dem Speicher heraus bisher nur eine "Wunsch-Funktion" ist und noch nicht existiert. Und da ich das unter C bisher nicht hinbekommen habe, versuche ich nun einen Ansatz bei Java zu bekommen.

 

[black swan]

Schau Dir mal die ProcessBuilder-Klasse an, damit könntest Du einen BS-Aufruf ("java -jar <jarfile>") machen.

Edit: Sorry, hab das mit dem "Programm liegt im RAM" übersehen. Das würde - wenn es gehen würde - das "Sandbox-Prinzip" aushebeln.

 

[Dompteur]

Der Aufruf von java erwartet das Jar-File im Filesystem. Ich glaube nicht, dass du da auf einen Speicherblock verweisen kannst. Außer eine RAM-Disk wäre erlaubt.

Als Alternative könntest du ein Java-Programm schreiben, dass das Jar-File entschlüsselt und über einen eigenen Class-Loader in deiner virtuelle Maschine nachlädt.
Hier ein Link als Anregung: http://kalanir.blogspot.co.at/2010/01/how-to-write-custom-class-loader-to.html

Der Link ist keine fertige Lösung, sondern zeigt dir nur, wie du Klassen selbst nachladen kannst.

 

[Thallius]

Verstehe dein problem immer noch nicht. Warum nicht einfach ein exec("cprogramm.exe" ?

 

[UweA]

@Thallius: Weil auch das C-Programm den Java-Code nicht aus dem Speicher laden kann. Diese Funktionalität fehlt noch.

 

[Thallius]

Ok, fangen wir mal ganz vorne an. Was soll das Ziel der ganzen Aktion sein ? Irgendwie scheint mir das ganze Konzept nicht schlüssig. Du kannst nicht einfach einen Code in den Speicher laden und dann starten. Das geht in keiner Sprache so wirklich einfach. Das verlangt extreme Kenntnisse des Betriebssystems. Plattform übergreifend wird es dann richtig lustig.
Wenn du da irgendwas verschlüsseln willst, dann solltest du das komplett anders angehen.

 

[UweA]

Das Ziel ist: Das Dekompilieren meines jar files verhindern.

Meine bisher untersuchten Möglichkeiten:
a) Obfuscator(ProGuard, Stringer): Unbrauchbar, weil erzeugtes jar entweder fehlerhaft oder nicht ausreichend verschleiert
b) USB-Donlge(WIBU): brauchbar aber teuer
c) jar-Datei verschlüsseln und über C-Loader entschlüsseln und starten: Problem mit dem Java-Launcher (s.o.)

Die Lösung muss nur unter Windows funktionieren.

 

[Thallius]

Jar2Exe mal probiert?

Ein Dongle bringt ja auch nichts. Den kan ich in Java ja auch problemlos aushebeln wenn ich den Code decompiliere und dann ändere.

Java bekommst du nunmal nicht wirklich sicher.

 

[Tom299]

In einer alten Firma von mir hatten wir auch ein "Geheimhaltungsproblem". Da wurde der "geheime Algorithmus" in C geschrieben und über JNI in Java eingebunden. Vielleicht wäre das eine Alternative für dich?

Inwieweit man aber dann die C-Object-Dateien decompilieren kann, weiß ich nicht.

 

[UweA]

@Thallius:
Jar2Exe sieht sehr gut aus! Vielen Dank für den Tip!

Wenn ich das mit dem Dongle richtig verstanden habe, dann ist der jar-Code verschlüsselt und wird erst beim Laden entschlüsselt (ähnlich dem, was ich mit dem C-Loader machen wollte). D.h. decompilieren und Dongle ausheblen dürfte nicht so einfach sein.

 

[UweA]

@Tom299:
Wenn es nur um einen Algorithmus ginge, wäre das durchaus eine Lösung (einige Teile laufen ohnehin schon in DLLs, die über JNA eingebunden sind), aber es geht um tonnenweise Code...
Wenn ich die alle nach C portiere, dann kann ich gleich das ganze Projekt nach C portieren.

 

[Dompteur]

Jar2Exe sieht sehr gut aus! Vielen Dank für den Tip!

Google liefert mir bei der Suche nach "Jar2Exe decompile" folgenden Link : http://reverseengineeringtips.blogspot.co.at/2014/12/unpacking-jar2exe-21-extracting-jar.html
Das ist eine Step-by-Step-Anleitung, wie man die Jars aus dem Exe-File extrahiert.

Wäre es eine Alternative den Code zu splitten und einen Teil der Berechnungen auf einem Server zu machen ?
Damit kannst du verhindern, dass dieser Teil der Anwendung decompiliert werden kann.
Solange deine ganze Anwendung auf einem privaten Rechner ausgeführt wird, kann man mit entsprechenden Aufwand eine Menge reverse-engeneeren.

Die andere Frage ist natürlich, ob dein Programm wirklich so wertvoll ist, dass sich der Aufwand für den Cracker lohnt...
Gerade, wenn du "tonnenweise Code" hast, ist der Einarbeitungsaufwand ja auch nicht soo klein. Das wird dir jeder bestätigen, der sich schon einmal in ein großes Projekt, das schlecht strukturiert / dokumentiert ist, einarbeiten musste.

 

[cafebabe]

Das Ziel ist: Das Dekompilieren meines jar files verhindern.

Lösung: verschlüsseltes jar-Archiv mit einem weiteren Java programm einlesen -> entschlüsseln -> Per ClassLoader nachladen!

Das ganze "entschlüsselung mit C programm da kompilierter Maschinencode..." ist keine seriöse Lösung, zumindest nicht so wie ich das hier verstehe!
Nur mal ein Beispiel (einer std. Lösung mit C) C-programm entschlüsselt das jar mit (z.b.) AES - key als String ist fest im code hinterlegt.
Einfachster Angriff: Filtern aller Strings aus der .exe Datei - testen aller Strings (viele können es nicht sein)

Die andere Frage ist natürlich, ob dein Programm wirklich so wertvoll ist, dass sich der Aufwand für den Cracker lohnt...

Ich würde sogar sagen: DAS ist die Frage!!!

 

[Dompteur]

Lösung: verschlüsseltes jar-Archiv mit einem weiteren Java programm einlesen -> entschlüsseln -> Per ClassLoader nachladen!

Damit verlagerst du nur den Angriffspunkt. Der Cracker muss hier also das "weitere Java Programm" decompilieren und das entschlüsselte Jar File danach speichern.

 

[cafebabe]

Damit verlagerst du nur den Angriffspunkt. Der Cracker muss hier also das "weitere Java Programm" decompilieren und das entschlüsselte Jar File danach speichern.

Jein, für so eine Aktion, braucht man eine "License"-Server o.ä.
Der Schlüssel darf natürlich(!!) nicht in den Java-Code (gleiches problem wie C,go,rust,php,asm... Code).
Ungefährer Ablauf:

• jar_1 kontaktiert License-Server (pub-Key auth o.ä.)
• jar_1 erhält sym. Schlüssel
• jar_1 entschlüsselt jar_2 (dein "geschütztes programm)
• jar_1 lädt jar_2 per ClassLoader nach

Ein motivierter angreifer fischt dir den übertragen sym. Schlüssel aber auch aus dem RAM
Eine wirklich sichere Lösung für dieses Problem gibt es (meines Wissens nach nicht)!
Selbst ein TPM hindert niemanden, den ByteCode der "jar_2" aus dem RAM zu lesen.

 

[UweA]

Auch nach meiner Auffassung gibt es keine 100% sichere Methode. Mit enstprechendem Aufwand läßt sich alles aushebeln. Ich möchte es einem potentiellen Cracker nur nicht unnötig leicht machen(was es bei einem einfachen jar-file nun mal ist).

 

[cafebabe]

Dann empfehle ich dir ein kleines JavaProgramm zu schreiben, das dein eigentliches Jar entschlüsselt und per ClassLoader nachlädt.
Am besten werden besonders "geheime" Programmteile auf einen Server ausgelagert.
Aber das kommt sehr auf die Anwendung an (Stand-alone , Buisness oder Privat etc.)

 

[UweA]

Möglicherweise gibt es noch einen weiteren Weg.
1. Mit Hilfe von Jar2Exe ein exe erzeugen.
2. exe verschlüsseln
3. C-Loader schreiben, der exe entschlüsselt und nachlädt (Stichwörter: Memory Execution & PE File Header)