DLL in fremden Prozess laden...

[Tim Henford]

Hallo,

...und wieder versuche ich eine DLL in einen fremden Prozess unter Windows 98 zu implementieren, dabei ist mir aufgefallen, dass eine ShellExecuteHook über ShellExtension etwas ähnliches tut nämlich, die besagt DLL in den laufenden Explorer.exe Prozess zu laden.

Wie funktioniert das?

Tschüss Tim

[Elmar Herzog]

Hallo Tim,<p>
was hast Du den genau vor? Um eine DLL in einen fremden Prozess zu inijizieren gibt es verschiedene Möglichkeiten. Was willst Du im laufenden Prozess vom Explorer? Wenn Du wirklich gute Informationen über dieses Thema wissen möchtest, kann ich Dir nur das C-Buch Windows Programmierung für Experten ans Herz legen

[Tim Henford]

Hallo Elmar,

danke für den Buch-Tipp, mal schauen was sich machen lässt.

Eigentlich geht es mehr oder weniger wieder um das alt bekannte Problem: Meine DLL wird in Form eines Login-Dialogs mit Windows gestartet; nun muss diese aber beendet werden bevor es weiter gehen kann - das ist vielleicht auch ganz gut so.<br>
Aber als nächstes sollen zum Beispiel alle gestarteten Programme überwacht werden, somit muss ich eine Anwendung starten, die aber ziemlich einfach mit Dllview (od.s.) beendet werden kann.

Meine Idee war es den ShellExecuteHook vielleicht gleich mit den Überwachungs-Tool zu kombinieren, so ganz klappt das aber noch nicht.

Mich würden die verschiedenen Möglichkeiten des Injizierens interessieren - ist es eigentlich in diesem Sinne auch möglich DLL's statisch zu laden?

Tschüss..

[Elmar Herzog]

Hallo Tim,<p>
<i>Aber als nächstes sollen zum Beispiel alle gestarteten Programme überwacht werden, somit muss ich eine Anwendung starten, die aber ziemlich einfach mit Dllview (od.s.) beendet werden kann. </i><p>
Was soll den Überwacht werden, da musst Du schon etwas genauer sein?<p>
Folgende Möglichkeiten zum Injizieren einer DLL bestehen:
<li>Injizieren einer DLL mittels Registrierung
<li>Injizieren einer DLL mittels Windows-Hook
<li>Injizieren einer DLL mittels Remote-Threads
<li>Injizieren einer DLL mittels trojanischer DLL
<li>Injizieren einer DLL mittels Debuger
<li>Injizieren von Code mit CreateProcess
<li>Injizieren von Code durch Überschreiben
<p>Jetzt kommt es drauf an, was Du machen willst und unter welchem System

[Tim Henford]

Hallo Elmar,

sorry, ich habe mich vielleichet etwas schlecht ausgedrückt:<br>
Unter <b>Windows 98</b> will ich zum Beispiel nur Word 2000 als Programm, dass gestartet werden kann, zulassen.<br>
Eigentlich auch nicht unbedingt ein Problem:

<pre>
with ShellExecuteInfo do
begin
// kein einziges Programm darf gestartet werden...
Result:= S_OK;
// Keine Windows-Fehlermeldung anzeigen -> Wert >= 32 zurückliefern
hInstApp:= 32;

// ...höchstens folgende:
// 'C:\Programme\MS Office\Office\Winword.exe',
DateiName:= UpperCase(ExtractFileName(lpFile));
if DateiEntSperren(DateiName)=true then
begin
//Programm darf gestartet werden, wenn das Icon, die Größe und der
//Pfad stimmen:
Result:= S_FALSE;
end
else
begin
//wenn es nicht diese sind:
MessageBox(Wnd, 'Dieser Vorgang wurde gesperrt!'+#13#10+
'Wenden Sie sich an den System-Administrator.',
'Vorgang verboten',
MB_OK or MB_ICONINFORMATION);
end;
end;
</pre>

Dieser Code steht in einer DLL, aber ich kann diese DLL nicht von einem Programm aus starten, da dieses wieder beendet werden könnte, sodass der Schutz unwirksam werden würde.

Fazit: die oben beschrieben DLL in einen schon laufenden Prozess injizieren, der <i>nicht beendet</i> werden kann.
(
<li>Windows Hook - wäre brauchbar
<li>Registrierung - zu unsicher; kann gelöscht werden
<li>Remote-Threads - funktioniert nur unter NT?
<li>trojanischer DLL - ?
<li>Debuger - nicht auf anderen Computer vefügbar?
<li>CreateProcess - wäre auch möglich!
<li>Überschreiben - wahrscheinlich zu heikel ?!
)

Tschüss Ti

[Elmar Herzog]

Hallo Tim,<p>
1. Du kannst den oben beschrieben Code zwar ohne weiters in den Prozess des Explorers injizieren, aber dafür musst Du eine Anwendung programmieren, die die DLL in den Prozessbereich läd. Auserdem musst Du natürlich sicherstellen, dass der Code wieder ordungsgemäss entfernt wird, ansonsten bekommt man die Fehlermeldung: <i>Die Anwendung verusacht eine allgemeine Schreibschutzverletzung...</i>.<p>
2. Injizieren kommt nur dann immer in Betracht, wenn man in der entsprechendem Prozess etwas ändern möchte. Z.B.: Funktionsteile ändern.<p>
3. Angenommen der Code ist im Prozessbereich vom Explorer geladen. Wie bitte möchtest Du dann den Code ausführen? In irgendeine Funktion bzw. einem Ablauf musst Du ja eingreifen bzw. einhacken

[Tim Henford]

Hallo Elmar,

es ist eigentlich kein größeres Problem ein Programm kurz starten zu lassen, um die DLL in den Prozess zu injizieren und gleich wieder zu beenden, denke ich - bloß wie man Injiziert weiß ich nicht so genau.

Vor einiger Zeit hatte ich auch schonmal einen Quelltext der ursprünglich vom BO-Server stammt, versucht in Delphi zu konvertieren, so recht ist es mir aber nicht gelungen. Dort scheint dass ganze doch recht gut zu funktionieren (Aufruf und Ablauf); aber wie?

Ich dachte sobald die DLL in den fremden Prozess injiziert wurde, wird diese auch geladen, d.h. gestartet (ähnlich wie LoadLibrary)?<br>
Ist es denn dann nicht mehr möglich die DLL zu steuern, d.h. Funktion aufzurufen?

Tschüss..

[Elmar Herzog]

Hallo Tim,<p>
<i>Ich dachte sobald die DLL in den fremden Prozess injiziert wurde, wird diese auch geladen, d.h. gestartet (ähnlich wie LoadLibrary)?
Ist es denn dann nicht mehr möglich die DLL zu steuern, d.h. Funktion aufzurufen?</i><p>
Du kannst zwar die DLL in einem fremden Prozess injizieren, sie wird aber noch lange nicht von selbst ausgeführt. Dafür musst Du schon selbst sorgen. Z.B. LoadLibray oder statischer Import. Und ganz wichtig: Du musst auch dafür sorgen, dass die injizierte DLL wieder aus dem Prozessbereich "entladen" wird. Injizieren kommt eigentlich nur in Betracht, wenn man etwas im Prozessbereich des entsprechenden Prozesses etwas ändern möchte oder Informationen benötigt die nicht über Prozessgrenzen hinausarbeiten. Wenn es nur darum geht, eine DLL zu laden, die nicht während der laufenden Windowssitzung beendet werden sollte, würde ich eine nicht-sichtbare-Anwendung programmieren die diese Aufgabe übernimmt.<p>
Ich habe hier ein C-Beispiel liegen, das zeigt wie man eine DLL in den Prozessbereich des Explorers läd und entläd. Bin noch nicht dazugekommen, das ganze in Delphi umzusetzten

[Tim Henford]

Hallo Elmar,

inwieweit ist es möglich die Anwendung "nicht-sichtbar" zu programmieren?

"Injizieren kommt eigentlich nur in Betracht, wenn man etwas im Prozessbereich des entsprechenden Prozesses etwas ändern möchte[...]" -> dann verstehe ich aber das Prinzip vom BackOrifice Server nicht. Wie funktioniert dieser? Wenn die "Server.exe" gestartet wird, ist noch lange kein Programm (in ATM zum Beispiel) sichtbar. Das einzig aufällige sind die neu geladenen DLL's im Explorer zum Beispiel. Im Run-Schlüssel steht auch wieder die "Server.exe", die, wie ich dachte, die DLL's in den Prozess injiziert. Kurioserweise wird aber scheinbar keine neue DLL irgendwo hinkopiert...

Der C source würde mich interessieren, meine E-Mail-Adresse sollte ja ersichtlich sein ;-)

Tschüss Ti

[Andreas Kosch]

Hallo,

wenn es nur darum geht, den Start eine Anwendung zu verhindern, würde ich nur auf die von Win32 vorgesehnen Veto-Wege zurückgreifen. Windows stellt für die API-Funktionen ShellExecute und ShellExecuteEx in Form von <b>IShellExecuteHook</b> eine eigene Erweiterung zur Verfügung. Gedacht ist diese Erweiterung dafür, unter Windows über <i>Start | Ausführen</i> eigene Programme über spezielle Namen starten zu können, ohne dass der vollständige Pfad der EXE vom Anwender eingetragen werden muss. Allerdings ist das IShellExecuteHook-Interface auch so flexibel, den Start einer Anwendung über das Startmenü zu verhindern. Der Vorteil des Ganzen liegt darin, dass man mit Delphi ein COM-Objekt als In-Process-Server (DLL) schreibt, sich aber das Betriebssystem automatisch um den Aufruf dieses COM-Objekts kümmert (man muss also diese DLL nicht selbst einen anderen Prozess unterschieben).

Das folgende Beispiel demonstriert, wird der Start des Spiels Solitaire verhindert werden kann:
<pre>
{ ************************************************** *******************
Autor : Andreas Kosch
Compiler : Delphi 5 UpdatePack#1
Betriebssystem : Windows 2000 SP 1
Datum : 01.01.2001
Beschreibung : IShellExecuteHook - Veto beim Betriebssystem
gegen das Starten einer Anwendung einlegen
************************************************** ******************** }

unit ShellExecuteHook_Impl;

interface

uses
Windows, ActiveX, ComObj,
ShlObj, // IShellExecuteHook
ShellAPI; // TShellExecuteInfo

type
TShellExecuteHook = class(TComObject, IShellExecuteHook)
protected
// Interface-Methode von IShellExecuteHook implementieren
function Execute(var ShellExecuteInfo: TShellExecuteInfo): HResult; stdcall;
end;

const
Class_TShellExecuteHook: TGUID = '{5CE3CB2B-AD56-4E41-8AA2-522F21DF77F9}';

implementation

uses ComServ, SysUtils, Registry;

type
TShellExecuteHookFactory = class(TComObjectFactory)
public
// Class Factory erweitern -> Hook wird aktiviert
procedure UpdateRegistry(Register: Boolean); override;
end;

{ TShellExecuteHook }

function TShellExecuteHook.Execute(var ShellExecuteInfo: TShellExecuteInfo): HResult;
var
sFile : String;
begin
// Default: Windows darf Programm starten
Result := S_FALSE;
with ShellExecuteInfo do
begin
sFile := UpperCase(ExtractFileName(lpFile));
if Pos('SOL', sFile) = 1 then
begin
// Programm soll nicht gestartet werden -> S_OK zurückliefern
Result := S_OK;
// Keine Windows-Fehlermeldung anzeigen -> Wert >= 32 zurückliefern
hInstApp := 32;
MessageBox(Wnd, 'Nicht schon wieder Solitaire!',
'Das störrische Windows 2000',
MB_OK or MB_ICONINFORMATION);
end;
end;
end;

{ TShellExecuteHookFactory }

procedure TShellExecuteHookFactory.UpdateRegistry(Register: Boolean);
resourcestring
ShellExecuteHooksKey = 'SOFTWARE\Microsoft\Windows\CurrentVersion\' +
'Explorer\ShellExecuteHooks';
var
aTReg : TRegistry;
begin
inherited;
if Register then
begin
aTReg := TRegistry.Create;
try
aTReg.RootKey := HKEY_LOCAL_MACHINE;
aTReg.OpenKey(ShellExecuteHooksKey, True);
aTReg.WriteString(GUIDToString(Class_TShellExecute Hook), Description);
finally
aTReg.Free;
end;
end
else
begin
aTReg := TRegistry.Create;
try
aTReg.RootKey := HKEY_LOCAL_MACHINE;
aTReg.OpenKey(ShellExecuteHooksKey, True);
aTReg.DeleteValue(GUIDToString(Class_TShellExecute Hook));
finally
aTReg.Free;
end;
end;
end;

initialization
TShellExecuteHookFactory.Create(ComServer, TShellExecuteHook,
Class_TShellExecuteHook, 'TShellExecuteHook',
'ShellExecute-Hook SOL.EXE', ciMultiInstance, tmApartment);

end.
</pre>
Wenn der In-Process-Server als COM-Objekt im System registriert wird, kann die "gesperrte" EXE nicht mehr gestartet werden.

P.S. IShellExecuteHook steht ab Windows 95 und Windows NT 4 zur Verfügung

[Hagen Reddmann]

Es sei denn, man startet aus der DOS-BOX oder nutzt z.B. PowerDesk Explorer o.ä., da IShellExecuteHook nur aus dem Explorer aufgerufen wird :

[Tim Henford]

Hallo,

ich danke Andreas erst einmal für den source, den meinte ich auch, als ich sagte ShellExecute zu verwenden. Das Problem ist aber, dass ich nicht nur Programme sperren, sondern auch noch Ornder verstecken, Timer ausführen usw. lassen möchte.<br>
Meine Idee war es den obigen Code zu erweitern, aber scheinbar klappt das mit Timer zum Beispiel nicht.

Des Weiteren würde mich das Thema doch interessieren "[...]DLL nicht selbst einen anderen Prozess unterschieben[...]". Wie macht dass Windows; man muss es doch auch "nachbasteln" können.

Das nächste Problem hat Hagen schon angesprochen, wie kann ich "DOS-Box-Aufrufe" verhindern?

Tschüss Ti

[Andreas Kosch]

Hallo,

wenn ein Programm aus dem Fenster der Eingabeaufforderung aufgerufen wird, greift Win32 intern nicht auf ShellExeucte(Ex) zu, so dass IShellExecuteHook sein Veto nicht einlegen kann. Für Power-User muss man sich also was anderes einfallen lassen

[Tim Henford]

Hallo Andreas,

hättest du dazu einen alternativen Vorschlag (ich nehme an ->VxD)

[Andreas Kosch]

Hallo,

nein - diese Low-Level-Sachen sind nicht mein Ding. Ich hatte vor einiger Zeit auf der DVD der MSDN Library einen Microsoft-Artikel gelesen, bei dem MS diese Aufgabe völlig objektorientiert gelöst hat. Wenn ich mich richtig erinnere, wurde dort auf WMI (Windows Managment Instrumentation) zurückgegriffen, d.h. es wurde ein vorhandenes COM-Objekt des Betriebssystems beauftragt, das eigene Programm bei jedem neuen Start eines Prozesses zu informieren, um ein Veto einlegen zu können.

Unter der URL http://msdn.microsoft.com/downloads/sdks/wmi/download.asp sind Infos zu WMI zu finden