DLL aus einer DLL heraus laden geht nicht

Martin Richter

Und warum linkst Du nicht einfach implizit. Warum der Umstand mit GetProcAddr?

Martin Richter schrieb:

Und warum linkst Du nicht einfach implizit. Warum der Umstand mit GetProcAddr?

Wie gesagt, es ist mir nicht möglicht, implizit einzubinden. Das GEHT mit den Möglichkeiten, die ich besitze, einfach nicht - es sei denn, ich arbeite mich wochenlang in Assembler ein.

Mein Problem ist, dass ich lediglich auf einzelne Funktionen des Maschinencodes eines Programms, dessen Quellcode ich nicht habe, zugreifen kann. Neue Funktionen könnte ich also entweder mit einem Assemblerstudium ODER mit dem Umweg über LoadLibrary, GetProcAddress usw. hinzufügen, und neue Funktionen brauche ich.

Das Projekt ist nicht pures C/C++, da spielen noch andere Sachen eine Rolle.

Zurück zu meiner Frage: wenn eine DLL Verweise auf Funktionen in anderen DLLs besitzt, wird dann lediglich der Code der Funktion oder die komplette DLL eingebunden?

Außerdem noch etwas: ist es möglich, die Kernel32.DLL von beispielsweise Windows 7 durch die Kernel32.DLL von Windows XP zu ersetzen? Wenn nicht (durch inkompatibilität, was weiß ich), gibt es eine Möglichkeit, die neuere, erweiterte DLL vor die DLL im Windows-Ordner zu linken?

Martin Richter

Für mich klingt das in keiner Weise mehr legal.
EOD für mich.

Martin Richter schrieb:

Für mich klingt das in keiner Weise mehr legal.
EOD für mich.

Tatsächlich ist es sehr legal, wird sogar durch eine Lizenz gedeckt. Solange es nicht kommerziell ist und ich dafür sorge, dass der Maschinencode gebraucht wird, ist und bleibt es legal, sonst hätte ich diesen Thread wohl kaum hier, sondern im Gully-Board oder sonst wo eröffnet ...

EDIT: Und ich verändere den Maschinencode nicht, ich rufe ihn auf. Aber ich will nicht zu viel verraten, sonst ... ach, ich weiß nicht. Jedenfalls ist es legal, sonst würde ich es nicht machen. Auch ich habe Prinzipien.

lol was soll da nicht legal sein?
Solange du nix verbreitest, darfst du mit deinen Bits im RAM/Flash machen, was du willst. EGAL WER was anderes sagt ZOMG!!!
Oder lasst ihr euch gerne pseudo-einschränken?

Nick Unbekannt

Vielleicht solltest du doch mal dein Problem näher erläutern. Soweit wie du du das bist jetzt geschildert hast, klingt das ganze nach übelsten Rumgehacke ohne wirklichen Sinn. Es ist problemlos möglich alle benötigten Funktionen in deinem Programm sauber zu kapseln und davon aus dann dein eigentliches Problem zu lösen.
Btw. ist es tatsächlich nicht legal oder von einer Lizenz gedeckt Teile von Windows ohne Erlaubnis zu verbreiten. Wobei ich noch weniger verstehe, warum du spezielle Windows-Funktionen benötigst?

Nick Unbekannt schrieb:

Vielleicht solltest du doch mal dein Problem näher erläutern. Soweit wie du du das bist jetzt geschildert hast, klingt das ganze nach übelsten Rumgehacke ohne wirklichen Sinn. Es ist problemlos möglich alle benötigten Funktionen in deinem Programm sauber zu kapseln und davon aus dann dein eigentliches Problem zu lösen.

Na gut, probiere ich es mal so:

Stellt euch ein Programm vor, dass zur Laufzeit (beim Start des Programms, um genauer zu sein) eine Datei einliesst, in der es möglich ist, eigene C-Funktionen zu schreiben, um sie im Programm zu verwenden. Diese C-Funktionen haben jedoch den Nachteil, dass sie dem Standart entsprechen - kein "declspec(dllimport)", kein "#pragma comment (lib,"MyLib.LIB")", und die Speicherreservierung ist ein bisschen hackelig. Zudem habe ich keine Laufzeitbibliotheken-Header, man könnte es also ein bisschen wie eine Scriptsprache sehen.

Diese C-Funktionen kann ich jetzt anweisen, Zeiger auf Funktion und Prozeduren im Maschinencode zu erstellen und diese aufzurufen. Damit kann ich fehlende Bibliotheken wie "windows.h" oder "stdlib.h" kompensieren, denn die Verweise liefern mir einiges an Macht - wie bereits das Einladen meiner eigenen DLL bewiesen hat.

Da ich jedoch ein bisschen mehr brauche, habe ich mir gedacht, dass ich eine DLL schreibe, die kurz und bündig in der Lage ist, mehrere System-DLLs einzuladen und die dadurch enthaltenen Funktionen zu nutzen. Der Grund, warum ich eine eigene DLL dafür schreibe? Nun, mit dem C-Code der Datei verfüge ich (noch) nicht über andere wichtige Funktionen, die ich brauche, um die DLL zu initialisieren.

Nick Unbekannt schrieb:

Btw. ist es tatsächlich nicht legal oder von einer Lizenz gedeckt Teile von Windows ohne Erlaubnis zu verbreiten. Wobei ich noch weniger verstehe, warum du spezielle Windows-Funktionen benötigst?

1. Ich habe bloss gefragt, gemacht habe ich noch gar nichts. Und wenn du sagst, dass dies nicht legal ist, muss ich mir was anderes ausdenken - etwas, das legal ist.

2. Die Legalität bezog sich auf das Programm, welches mir erlaubt, dies mit ihm zu tun, solange ich kein Geld damit verdiene und bewerkstelligt ist, dass die Grundstruktur des Programms erhalten bleibt.

2. Ich benötige neuere Windows-Funktionen. Das Programm ist etwas älter, die Verweise auf Kernel-Funktionen etwas angestaubt. Und jetzt brauche ich modernere Funktionen.

Bitte ein Bit

Der aus dem Westen schrieb:

Außerdem noch etwas: ist es möglich, die Kernel32.DLL von beispielsweise Windows 7 durch die Kernel32.DLL von Windows XP zu ersetzen? Wenn nicht (durch inkompatibilität, was weiß ich), gibt es eine Möglichkeit, die neuere, erweiterte DLL vor die DLL im Windows-Ordner zu linken?

Alter Schwede. Auf die Idee muss man erst mal kommen. So als würde man sagen, ich baue mal ein Porsche Getriebe in einen Opel ein, oder ich montiere mal eine kleinere Brennstoffrakete an meinem Jeep und schaue mal was dabei hearuskommt, ...

Lass bitte die Finger komplett von dem Betriebssystem. Du wirst definitiv dein System durch das Ersetzen der Kernel32.DLL verschrotten. Solange du kein Entwickler von Windows bist oder Profi-Hacker für Stuxnet, macht eine Manipulation der System-DLL's null Sinn. Martin reagierte deswegen auch so weil Rootkits gerne die System-DLL's manipulieren. Und wenn du so mit den Windows-DLL's agierst ist Ärger mit Antivirensoftware vorprogrammiert.

Stellt euch ein Programm vor, dass zur Laufzeit (beim Start des Programms, um genauer zu sein) eine Datei einliesst, in der es möglich ist, eigene C-Funktionen zu schreiben, um sie im Programm zu verwenden. Diese C-Funktionen haben jedoch den Nachteil, dass sie dem stan**** entsprechen - kein "declspec(dllimport)", kein "#pragma comment (lib,"MyLib.LIB")", und die Speicherreservierung ist ein bisschen hackelig. Zudem habe ich keine Laufzeitbibliotheken-Header, man könnte es also ein bisschen wie eine Scriptsprache sehen.

Was benötigst du hier eine eigentlich ? Eine eigene Skriptsprache, ein eigenes Mini-OS oder eine Trennung der Schnittstelle einer Funktionalität von der Implementierung (Stichwort: Component Object Model) ?

Der aus dem Westen ...

Bitte ein Bit schrieb:

Alter Schwede. Auf die Idee muss man erst mal kommen. So als würde man sagen, ich baue mal eine Porsch Getriebe in einen Opel ein, oder ich montiere mal eine kleinere Brennstoffrakete an meinem Jeep und schaue mal was dabei hearuskommt, ...

Lass bitte die Finger komplett von dem Betriebssystem. Du wirst definitiv dein System durch das Ersetzen der Kernel32.DLL verschrotten. Solange du kein Entwickler von Windows bist oder Profi-Hacker für Stuxnet macht eine Manipulation der System-DLL's null Sinn. Martin reagierte deswegen auch so weil Rootkits gerne die System-DLL's manipulieren. Und wenn du so mit den Windows-DLL's agierst ist Ärger mit Antivirensoftware vorprogrammiert.

Gut zu wissen. Dann lass ich komplett die Finger davon.

Bitte ein Bit schrieb:

Was benötigst du hier eine eigentlich ? Eine eigene Skriptsprache, ein eigenes Mini-OS oder eine Trennung der Schnittstelle einer Funktionalität von der Implementierung (Stichwort: Component Object Model) ?

Eigentlich suche ich einen Weg, in diesem Mini-C, das ich verwende, Funktionen, die keinen statischen Verweis in dem Maschinencode haben, einzubinden, damit neuere Funktionen, die ich brauche, in ebendiesem Mini-C aufrufen kann. Wie beschrieben, an den Linker kann ich nix schicken.

Aber Martin hat mich bereits auf etwas gebracht ... mit GetModuleHandle, wieso bin ich nicht darauf gekommen? Natürlich wird immer die vorhandene Kernel32.DLL und die Sub-DLLs eingebunden, was habe ich mir dabei eigentlich gedacht?

Vielen Dank für die Hilfe und die Geduld, Leute.

Kleiner Edit: Noch etwas. Ich habe in den Linkereinstellungen eines meiner Projekte eine Reihe von Bibliotheken gefunden, die standartmässig in das Programm eingebunden werden. Meine Frage: werden noch zusätzlich und implizit andere DLLs als die unten angeführten bei Programmstart standartmässig eingebunden? Diese kann ich dann mit meinem Mini-C und GetModuleHandle abfragen ...

ADVAPI32.DLL
GDI32.DLL
KERNEL32.DLL
OLE32.DLL
OLEAUT32.DLL
SHELL32.DLL
USER32.DLL