Hallo alle Java freaks!

Ich habe im Moment die Aufgabe für meine Firma einen Java Client zu schreiben. Die Aufgaben des Clients sind dabei erstmal nebensächlich. Für mein Problem ist folgendes von Bedeutung.

1. Ich muss eine Dll von unserem Webserver in eine Art Bytearray laden. In C++ gäbe es da die Möglichkeit über UrlOpenBlockingStream. Aber in Java?

2. Als nächstes muss diese Dll encrypted werden. Deswegen ist es von nöten ein Bytearray an der Hand zu haben. Die Verschlüsselung beruht auf eine simple Xor Verknüpfung anhand eines Keys der der Länge der Dll entspricht. Die Dll soll dabei niemals hart auf dem Rechner des Benutzers liegen!

3. Als finalen Schritt, muss dieses Bytearray nun in einen anderen Prozess gemappt werden und dessen DllMain aufgerufen werden. Ich glaube das wird in Java nicht gehen. Eventuell über JNI und einer C-Library? Dort treffe ich dann sicherlich auf Probleme die DllMain auszuführen. Müssen doch "Relocations" durchgeführt werden oder nicht? Eventuell sollte man die Dll erst im Stub encrypten?

Wie ihr schon seht. Die Sicherheit der C++-Dll hat oberste Priorität. Eventuell fallen auch andere Möglichkeiten ein, diese ohne Manual Mapping sicher in den Hostprozess zu laden.


Gruß an alle Tüftler. Ich hoffe ich stoße auf einige kreative Ideen, da mir das Gesamtkonzept nocht nicht ganz klar ist.
Frank

Die sicherhei

1) Wo ist das Problem ? Du baust eine Socket Verbindung zum Server auf , fragst die entsprechende Datei an und speicherst den Response in einem Bytearray. Zur Not mach den Umweg über einen ByteArray-Stream.

2) Naja ... mit ner for()-Schleife einfach den "Schlüssel" über die DLL XOR und fertig.

3) In Java ist es meines Wissens nicht ohne weiteres möglich ein File im RAM zu halten. Ich gehe zwar davon aus das irgendwer schon mal eine entsprechende Klasse geschrieben hat und dazu passende Streams ... aber das auch noch als DLL laden wird unmöglich da der entsprechende C-Code in dem die JVM implementiert ist einen physischen Dateinamen / -pfad braucht und du diesem kein Byte-Array eines im RAM existierenden TempFiles übergeben kannst. Also müsstest du um sowas zu realisieren eine C-Lib schreiben die es ermöglicht eine DLL als Byte-Array aus dem RAM zu laden. Auch brauchst du dafür passende Java-Klassen die ein RAM-File repräsentieren , seine Daten halten und Read- / Write-Streams bereitstellen.

Alles in allem wird es also schwierig Zugriff auf die DLL zu bekommen ohne diese zumindest als Temp-File auf die Platte des Ziel-Systems zu speichern. In wie weit da C / C++ weiter sind oder ob es bereits von dem was ich mir da so vorstelle fertige Implementierungen gibt müsste man mal Google fragen.

Also erst mal zu 3.: Dafür gibt es JNA, eine API mit der du dir das Cross-compilen sparst: https://secure.wikimedia.org/wikiped..._Native_Access
Dass du eine verschlüsselte DLL ausführen kannst, will ich stark bezweifeln. Geht das in C/C++?

Zur Netzwerkprogrammierung gibts einige Grundlagen unter http://openbook.galileocomputing.de/...sel_21_002.htm

Gibts noch andere Ideen eine Art DLL-Injection durchzuführen?

Hat keiner Ideen um eine Art Dll zu streamen und in einen Host Prozess zu injezieren und das ganze etwas sicher gestaltet?

Wie gesagt : ohne die DLL zumindest als TMP-File auf die Platte zu cachen wird das in Java nicht möglich sein. Wie es in C *und dessen Abarten* ist weis ich nicht , aber da du diese in der regel eh auf den Rechner laden und von dort ausführen musst *wegen static-link gegen die DLL's* wird es da eh keine Rolle spielen.

Warte mal, wie sieht es denn mit RMI aus?
Wäre es eine Option (erlaubt), die DLL niemals lokal auszuführen, sondern nur auf einem Server?
So dass dein Client-Programm sich mit dem Server verbindet anstatt die DLL herunterzuladen?

Hi

in C ist es möglich, aber ein total sinnloser Riesenaufwand.
Zumindest lohnt es sich in keiner Weise. Vergiss es.

Windows will seine Execs am Dateisystem haben.

Man könnte ja einen Dateisystemtreiber machen, der vorspielt, dass die DLL im RAM eine Datei ist und diese Datei dann einbinden...

oder wenns noch eine Stufe mehr sein darf: Den Lademechanismus aus dem Kernel nachbauen und um die RAM-Möglichkeit erweitern...
Das muss man natürlich auch für jede Windowsversion/Servicepack und ein paar größere Updates extra machen

Spikees Vorschlag ist das einzig Sinnvolle, wenns lokal ist.
Netzwerk ist natürlich auch eine Möglichkeit. Ist dann ungefähr die Dateitreibervariante, nur schon fertig.
RAM-Dateitreiber kenn ich leider keinen, zumindest nicht für Windowskernel

Gruß