TerminateProcess geht nicht die Zweite

[mkinzler]

If not(b<>False) Then ist ja echt abenteuerlich

[CCRDude]

Als "LocalSystem" (nicht "LokalesSystem") kannst Du Dich nicht einfach so anmelden; Systemdienste etwa arbeiten unter diesem Account, manchmal auch LocalService, NetworkService sowie einige andere. Wenn Du im Windows Task Manager Dir die Prozesse aller User anzeigen lässt, wirst Du die (unter leicht anderem Namen) sehen. Das halt also nichts mit der Domäne zu tun.

Privileges betreffen Rechte, die sich ein Programm teilweise erst noch anfordern muss. Siehe auch MSDN: How to Use the SeDebugPrivilege - da wird sogar die OpenProcess/TerminateProcess-Thematik erwähnt.

Und nein, Privileges und auch Gruppenrichtlinien wurden nicht erfunden, um Programmierer zu ärgern, sondern in diesem Kontext auch, um Sicherheit zu schaffen - was zugegeben Programmierer manchmal zwingt, sich Gedanken über Sicherheit zu machen, was ich allerdings nicht als Ärgern einstufen würde

Ich glaube aber ehrlich gesagt, der Kindergarten ist die größere Baustelle Eigentlich würde ich ja empfehlen, euch ein bisschen in Tokens und Privileges einzulesen, aber ich glaube da täte erstmal ein Kommunikations und ggfls. Führungsseminar not, wenn jemand in einer kundenkritischen Situation einfach so Fehler in seinem Programm ignorieren darf

[QuickAndDirty]

Gelöst ---
Ursache Eine Quelloffene Treiber-DLL im System-Verzeichis wurde genutzt um per IP einen Hardware in der Virtuellen Maschine des Kunden verfügbar zu machen.

Wann immer der IP Server mit dem die DLL sich verband, aus welchen gründen auch immer, nicht rechtzeitig antwortete, meldete sie es mit "::MessageBox" aufrufen....

Leider kann man wohl ein Programm nicht abschießen wenn es in einer System DLL hängt und im dienst ist die MessageBox ja nicht sichtbar.


1.
Mal ne frage aus Neugierde: Dürfen System DLLs überhaupt Messageboxen aufmachen? Weil das ist ja mit hinblick auf einen gebrauch in einem Dienst ziemlich suboptimal.

2.
Kann ich von außen herausfinden ob ein Dienst gerade in einer Messagebox hängt und diese "drücken".


Wir haben es jetzt so geregelt das wir besagter mini dienst die Hardware selbst direkt benutzt....
und jetzt seit einigen Tagen keine Probleme mehr ^^

[CCRDude]

1. Hängt sicherlich etwas damit zusammen, was Du unter Treiber-DLL bzw. System-DLL meinst. Ist es ein richtiger Treiber, sicherlich nicht. Meinst Du aber nur die Funktionalität - kann ja sein, daß die auch in einer normalen Anwendung eingebunden werden kann/soll. Dann ist es nur noch schlechter Stil Zudem lassen sich System Services per Flag auf "interaktiv" setzen. In älteren Windows-Versionen (Windows 2000?) war dieses Flag evtl. nicht notwendig, später kam es aus Absicherungsgründen hinzu (Prozesse mit Systemrechten sollten nicht direkt über das UI mit dem Benutzer kommunizieren).

2. "Einfacher" wäre es vermutlich, die MessageBox-Funktion innerhalb des Prozesses zu hooken und so einfach zu ignorieren (oder, um's ganz fein zu machen, ins Eventlog umzuleiten). Dazu gibt's hier in der DP glaub ich auch Beispiele

[QuickAndDirty]

Ok, auch wenn es Offtopic in bezug auf den Threadtitel ist...es ist ja noch der selbe Fall...

Zitat von CCRDude:

1. Hängt sicherlich etwas damit zusammen, was Du unter Treiber-DLL bzw. System-DLL meinst.
Ist es ein richtiger Treiber, sicherlich nicht.

Ich meine ein Datei in C:\Windows\System32 es ist kein Treiber nur eine DLL die systemweit und von jeder X beliebigen Anwendung - oder auch Dienst - benutzt werden können sollte. Ist eben eine Capi2032.dll von Shamrock und dazu gibt es irgendwie zwischen 16Kb und 32Kb Opensource C++ Code... ich verwende die ja auch...aber ich muss mich nicht auf das dauerhafte Funktionieren dieser Geschichte verlassen...

CAPI ist für schon so die Schnittstelle zur ISDN-Karte...sollte eigentlich(wenn es verkauft werden würde und nicht umsonnst Opensourcezeug ist) mit der selben Sorgfallt und Misstrauen gegenüber den Randbedingungen programmiert sein wie ein Treiber.

Zitat von CCRDude:

Meinst Du aber nur die Funktionalität - kann ja sein, daß die auch in einer normalen Anwendung eingebunden werden kann/soll. Dann ist es nur noch schlechter Stil Zudem lassen sich System Services per Flag auf "interaktiv" setzen. In älteren Windows-Versionen (Windows 2000?) war dieses Flag evtl. nicht notwendig, später kam es aus Absicherungsgründen hinzu (Prozesse mit Systemrechten sollten nicht direkt über das UI mit dem Benutzer kommunizieren).

Das wäre leider keine lösung...aber da es Opensource ist...vielleicht werde ich mal in nem C++ board betteln das jemand mir den code ohne "::MessageBox" kompiliert...habe hier keine IDE dafür und betteln ist schneller als mich mit ner gnu C++ und Eclipse oder MS C++ und VS ... rumzuschlagen.
Es ist jetzt nicht WIRKLICH entscheidend, aber es wäre sicher von Vorteil für so manchen wenn es das Projekt so gäbe das es auch in Diensten funktioniert....
(Ich bereite morgen mal nen freundlich Text vor und Kommentiere die MessageBoxen aus)

Zitat von CCRDude:

2. "Einfacher" wäre es vermutlich, die MessageBox-Funktion innerhalb des Prozesses zu hooken und so einfach zu ignorieren (oder, um's ganz fein zu machen, ins Eventlog umzuleiten). Dazu gibt's hier in der DP glaub ich auch Beispiele

Vermutlich nicht "Einfacher", aber da ich ja im Prinzip immer damit rechnen muss das irgendwelche von meinen Diensten genutzten Treiber oder Bibliotheken oder sonnst etwas eine MessageBox werfen kann, würde es wohl der Stabilität des Produktes entgegenkommen, wenn ich den von dir vorgeschlagenen Weg einschlage.

Muss also was über Hooks lernen *nicht will*

[CCRDude]

Da es nur Hooks innerhalb Deiner Anweisung und nicht systemweit sein müssen, hält sich der Streß in Grenzen, denke ich

Schaue Dir mal die executehook.zip hier an. Davon brauchst Du quasi nur die HookUnit.pas, bzw. sogar nur einzelne Funktionen daraus (nämlich FinalFunctionAddress und PatchAddress).

Grob gesagt, machst Du ein:

Code:

type
   TMessageBoxA = function(hWnd: HWND; lpText, lpCaption: PAnsiChar; uType: UINT): Integer; stdcall;
   TMessageBoxW = function(hWnd: HWND; lpText, lpCaption: PWideChar; uType: UINT): Integer; stdcall;

var 
   OldMessageBox: TOldMessageBoxA; // unter DXE: *W
   OldMessageBoxA: TOldMessageBoxA; 
   OldMessageBoxW: TOldMessageBoxW; 

...

procedure NewMessageBoxA(hWnd: HWND; lpText, lpCaption: PAnsiChar; uType: UINT): Integer; stdcall;
begin
   // log message to some kind of log instead.
   // to display message box, call OldMessageBoxA here.
end;
procedure NewMessageBoxW(hWnd: HWND; lpText, lpCaption: PWideChar; uType: UINT): Integer; stdcall;
begin
   // log message to some kind of log instead.
   // to display message box, call OldMessageBoxA here.
end;

...

initialization
   @OldMessageBox := FinalFunctionAddress(MessageBox);
   @OldMessageBoxA := FinalFunctionAddress(MessageBoxA);
   @OldMessageBoxW := FinalFunctionAddress(MessageBoxW);
   PatchAddress(@OldMessageBox, @NewMessageBox);
   PatchAddress(@OldMessageBoxA, @NewMessageBoxA);
   PatchAddress(@OldMessageBoxW, @NewMessageBoxW);
finalization
   PatchAddress(@NewMessageBox, @OldMessageBox);
   PatchAddress(@NewMessageBoxA, @OldMessageBoxA);
   PatchAddress(@NewMessageBoxW, @OldMessageBoxW);
end;

Das ist jetzt kein getesteter Code, sondern nur per copy'n'paste an Deine Situation angepasst, damit Du das Schema versteht. Ich arbeite inzwischen mit madCodeHook, kann mich daher nur noch grob erinnern, wie diese Methode ging.

[QuickAndDirty]

cool danke .....Dude!