Bildschirmschoner o. ä. nach einer bestimmten Zeit des "nichts tuns"

[Matthias Lechtenberg]

Hi ihr da draußen
Ich folgendes Problem:
Sagen wir ich will einen Bildschirmschoner nach einer bestimmten Zeit aufrufen,
allerdings nur,wenn in dieser Zeit nichts passiert (der Benutzer keine Eingaben macht/
wie bei Windows selbst). Weiß jemand wie das geht?

mfg Matze

[Andreas Kosch]

Hallo,

welchen Sinn soll das Ganze machen? Windows bietet doch bereits diese Funktionalität.

Um die Maus- und Tastatuseingaben in fremden Anwendungen (separate Prozesse) überwachen zu können, kann ein <b>Hook</b> aktiviert werden. Dazu sind die folgenden Schritt notwendig: <br>
a) Hook-DLL schreiben, die die von Win32 vorgeschriebene Hook-Funktion (Callback-Funktion) implementiert. <br>
b) Hook-DLL scharfmachen, indem die Win32-API-Funktion <b>SetWindowsHookEx</b> aufgerufen wird. Das folgende Beispiel demonstriert dies für einen Keyboard-Hook:
<pre>
hDLL := LoadLibrary(PChar(sDLLPath));
pDLLProc := GetProcAddress(hDLL, PChar('KeyboardProc'));
hHook := SetWindowsHookEx(WH_KEYBOARD, pDLLProc, hDLL, 0);
</pre>
Da Hooks sehr systemnah arbeiten und somit die Stabilität des Rechners ersthaft gefährden können, sollte man so etwas nur dann in Angriff nehmen, wenn man die entsprechenden Abschnitte der Hilfe zum <b>Microsoft Platform SDK</b> genau durchgelesen hat

Hallo,
Das mit dem Bildschirmschoner war ja nur ein Beispiel, um das
Problem deutlicher zu machen! Es geht eigentlich um ein anderes
Programm.
Gibt es nicht noch ne einfachere Möglichkeit? Ich bin noch ein
Anfänger in Sachen Delphi und möchte die Warnung ernst nehmen.
Wenn ich das richtig verstanden habe, gibt es ja die Möglichkeit
die Mauscursorposition festzustellen. Wenn ich das zur Laufzeit vergleichen würde, hätte ich das Problem für die Maus gelöst.
Gibt es vielleicht etwas ähnliches für die Tastatur?

mfg
Matz

[Andreas Kosch]

Hallo,

da man mit Hooks eine Menge Unsinn anstellen kann und diese Techniken oftmals auch von "unfreundlichen" Programmen (Trojaner, die Passwörter suchen etc.) verwendet werden, werde ich ein Beispiel für einen Tastatur-Hook hier nicht veröffentlichen (daher ist auch kein Beispiel in meinem Win32-Lösungsbuch). Für die Teilnehmer der <i>Entwickler-Tage 2001</i> gibt es allerdings ein Beispiel in der Win32-API-Session ;-

*grmbl* ... und da dachte ich schon ich hätte was gefunden =(
Ne, ich wollte eigentlich nen Buyscript für nen vorhandenes PC-Spiel schreiben, welches die commands in das Spiel zurückschickt (WM_SENDMESSAGE ?!?),
ich zeichne ein menü mit dem DC auf das Bild des Spiels drauf (was schon funktioniert) muss aber noch die Antworten des Users abfangen =(

War das so ziemlich das einzigste Tabuthema hier ? =)

Entwicklertage klingt gut, leider mit knapp 3.500 DM nen bischel zu teuer für mich (17) =

[Andreas Kosch]

Hallo,

Borland hat auf seiner Community-Webseite einen Bereich mit <b>Technical Information</b> (TI). Dort wird in einer TI die Entwicklung eines Hooks mit Delphi beschrieben, so dass man dort die technischen Grundlagen findet. Da ein Tastatur-Hook bei jedem eintreffenen Zeichen aufgerufen wird, muss man dann nur noch das Zwischenspeichern/Auswerten implementieren. Beim Zusammensuchen der restlichen Infos im Platform SDK liest man automatisch die Abschnitte über die Gefahren und Stolperstellen - so dass dieser Weg immer besser ist als das direkte Nachbauen einer fertigen (unverstandenen?) Lösung eines anderen. Wie gesagt - ein Hook kann sogar Windows 2000 ins Nirvana schicken...

[Hagen Reddmann]

Hi Jörg

NEIN, es gibt hier keine Tabuthemen, was wäre das für ein Forum.
Ich gebe Andreas aber in allen Punkten recht. Vor dem Erfolg kommt der Schweiß. Andreas und ich haben schon öfters fertige Hooklösungen aufgezeigt. Leider stellte sich jedesmal herraus das der Gegenüber es eben NICHT versteht. Hooks sind und bleiben ein Systemfeature das eigentlich nur für Debuggingzwecke verwendet werden sollte. Wie Du sagt bist Du mit 17 Jahren noch Anfänger. Ich selber programmiere seit 15 Jahren, und dennoch stolpere ich bei Hooks. Das ist auch logisch, da jeder Hook entsprechend seiner endgültigen Nutzung immer was individuelles ist. Eine kleine Änderung und schon schmiert das System ab (JEDES System !), oder es entstehen neue Seiteneffekte (Explorer registriert seine COMs nicht mehr, etc ).

Andreas stellt aber an SICH den Anspruch gute, saubere Lösungen zu presentieren, da sozusagen die Computerwelt von morgen durch Euch entwickelt wird.

Gruß Hagen

PS: Du hast Dir aber auch ein schwieriges Ziel gesetzt

[Hagen Reddmann]

Hi Jörg

Als Ansatzpunkt schau Dir SetWindowsHookEx(), CreateProcess(), DebugActiveProcess() etc an. Falls Deine Zielanwendung KEINE Antidebuggingtricks nutzt könntest Du eine Startanwendnung schreiben die das Spiel startet. Mit Createprocess() wäre es möglich das Dein Elternprocess auch Zugriff auf den Kindprocess erlangt. Zusätzlich kannst Du dann den SetWindowHook() nutzen um NUR den Kindprocess zu überwachen. Eine andere Möglichkeit besteht im direkten injektzieren von Code in den Zielprocess, also das "dynamische" Erweitern der geladenen Zielanwendung mit Deinem Codepices.

Gruß Hage

[Nico Bendlin]

Hallo,

So wie ich das sehe, muß nichteinmal ein richtiger Hook geschrieben werden, sondern dieser wird nur benutzt, um seinen Code in den Zielprozeß zu bekommen (sonst würde sicher der Anti-Debugger-Code des Spiels greifen). Da ist es mit einer "leeren" Hookfunktion bereits getan. Und ein systemweiter Hook muß gar nicht erst gesetzt werden. Also ist nur eine Anwendung betroffen/gefärdet.

Das Prinzip ist immer das gleiche:

(1) CreateProcess zum Starten des Programmes benutzen, um einfach an die für das gezielte Setzen des Hooks notwenige ThreadId zu kommen. Alternativ per FindWindow(Ex) und GetWindowThreadProcessId wenn das Programm schon laufen sollte - oder das Start-Programm erst die eigentliche Anwendung durch einen Kindprozeß erzeugt.

(2) SetWindowsHookEx nur auf diesen einen Thread ansetzen. Somit kommt die selbstgeschriebene DLL in den Zielprozeß.

(3) Beim Laden der DLL erzeugt diese einen Thread, in dem die ganze Funktionalität implementiert wird. Die Hook-Funktion selbst macht eigentlich nichts und reicht die Nachrichten nur per CallNextHookEx weiter.

(4) Beim Entfernen des Hooks zur Lebenszeit des Zielprozesses wird natürlich der Thread beendet, also generell.

Gruß Nico

PS: Das direkte Injezieren von Code ist zwar durch CreateRemoteThread auf Windows NT/2ooo relativ einfach; doch auf Windows 9x bedarf es solider Grundkenntnisse, um das sauber zu implementieren. Ich rate davon ab, da es für die Anforderung nicht notwenig ist.
&#10

[Hagen Reddmann]

Hi Nico.

SetWindowsHook() kann aber ein Problem darstellen wenn die zu hookende Anwendung schon läuft oder keinen Messagequeue nutzt.

Man kann aber nach einem CreateProcess() das "Debugging" API nutzen um noch BEVOR der MainThread gestartet wird eine DLL zu injezieren.

Nungut, ich habe mit dem dirtekten injezieren von code in laufende Anwendungen gute Erfahrungen gemacht, egal ob Win9x oder NT/2000. Interessant ist dabei das man dies nutzen kann um in den Main-Process aus Kernel32.dll eigenen Code zu laden. Da dieser Main-Process sozusagen immer Adminrights hat werden diese rechte an die InjectDLL "vererbt". Folge: NT-Sicherheit ade !!!!

Gruß Hage

[Nico Bendlin]

SetWindowsHook ist gerade dann geeignet, wenn der Prozeß schon läuft!<br>
Nungut, bei dem Programm handelt sich um einen Prozeß, der mindestens ein Fenster hat, also eine Message-Queue.<br>Man kann ja schließlich erzwingen, das der Thread arbeitet, indem man ihm eine WM_NULL sendet, damit wird dann die DLL geladen.<p>
Der Zielprozeß kontrolliert unter Umständen, ob er im Kontext eines Debuggers ausgeführt wird - damit fällt die Lösung, den Prozeß gleich zu Beginn zu debuggen unter Umständen aus. Nebenbei bemerkt gibt es das Problem, das wenn der Debugger eines Prozesses beendet wird auch der Debuggee beendet wird - unter Umständen nicht erwünscht. Nachträgliches Debuggen ist wesentlich komplexer.<p>
Welchen "Main-Prozeß" meinst Du ? Die NT-Sicherheitsprüfungen werden mit Sicherheit nicht umgangen, zu einem bestimmten Zeitpunkt mußten die Rechte vorhanden sein, um zu tun, was auch immer das Programm / Inject-Code tun will.<br>
Der Parent-Prozeß hat immer vollen Zugriff auf alle Kind-Prozesse, die er erzeugt, keine Frage, damit auch das Recht den Code vor dem Start des Hauptthreads zu manipulieren. Der injezierte Code hat natürlich auch vollen Zugriff auf den Prozeß in dem er läuft. Aber was hat das mit der NT-Sicherheit zu tun?<p>

Gruß Nic

[Nico Bendlin]

Hallo Hagen,<p>
ist Deine eMail eigentlich noch gültig, ich wollte Dir was (kleines) schicken?<p>
Gruß Nico
<br>
PS: auf die letzte bekam ich kein Antwort, deswegen die Frag

[Hagen Reddmann]

Hi Nico

Meine Mail ist mailto:[email protected]
Wieso keine Antwort ? Entweder ist es nicht angekommen, fahre momentan zweigleisig, oder ich muß sie übersehen haben, sorry.

Zur WM_NULL Message: Das klappt meistens, sollte aber eine PostMessage() o.ä. sein. Mit Sendmessage hängts wenn der Thread im Sleep(), Suspend() mode ist. Somit wird die SetWindowsHook() Methode IMMER eine asynchrone Methode sein, was eigentlich weniger erwünscht ist.

Der "Main-Process" ist Kernel32.exe. In der Kernel32.dll befindet sich eine "EXE" diese enthält den "Main-process" und lädt sich selbst, sprich Kernel32.dll nochmals als Process. Erst dieser Process lädt die Shell. Damit ergibt sich folgendes Bild der Processhierarchie: Kernel32.exe -> Kernel32.dll -> Shell -> Anwendung. Nun, der Clou ist dabei aber das dieser Main-Process NICHT sichtbar ist, z.B. mit EnumProcess() etc. API. ABER, das Desktop Window ist diesem Process zugeordnet

Gruß Hage

[Nico Bendlin]

Stimmt soweit, doch was hat das mit NT zu tun ?<br>
Unter NT wird die Shell vom Logon-Prozeß gestartet.<p>
Ich hatte auf den Namen geklickt, dort stand [email protected]<p>
Gruß Nic