HILFE! Noch einmal der Tastaturhook

[idefix2]

Naja, Loadlibrary macht schon Sinn, weil dann kannst Du die DLL als Resource ins exe-File packen und brauchst nur eine Datei zu installieren. Kommt dann dran, wenn die DLL selbst funktioniert.

Riesenfrust: Ich habe den SimpleTimer ausprobiert, an und für sich eine feine Komponente: Statt über 500KB mit TTimer wiegt meine DLL mit SimpleTimer nur mehr ca 120KB. Aber sie stürzt genauso ab, und nachdem ich mir die Implementierung angeschaut habe, brauche ich gar nicht erst selbst einen Timer zu basteln, das Problem dürfte der Timper-API Aufruf selbst sein, der das ganze zum Absturz bringt. Ich versteh nur nicht, woran es liegt, es muß doch im Prinzip in DLLs möglich sein, einen Timer zu setzen. Anscheinend geht es aber nicht von in einer globalen Hookroutine aus, verstehen tu ich das überhaupt nicht.

Werde mich jetzt also noch mit IPC beschäftigen müssen und meine zwei Timer ins Hauptprogramm übersiedeln. Zumindest erübrigt sich damit die (ohnehin schon negativ beantwortete) Frage, ob ich das Hauptprogramm entladen und die DLL trotzdem in Betrieb bleiben kann, weil so brauch ich das exe File auf jeden Fall weiter. Und fad wird mir dabei auch nicht.

AArgghh!!!


Edit: Ich habe jetzt doch eine einfachere Möglichkeit gefunden. Innerhalb der DLL kann man nämlich sehr wohl einen Timer verwenden, nur in der Hook Routine selbst darf ich offenbar keinen starten. Damit wird es nur wenig komplizierter als geplant, ich brauche zumindest keine IPC zwischen DLL und EXE zu bauen.

[Delphi-Laie]

Zitat von idefix2:

Naja, Loadlibrary macht schon Sinn, weil dann kannst Du die DLL als Resource ins exe-File packen und brauchst nur eine Datei zu installieren. Kommt dann dran, wenn die DLL selbst funktioniert.

Das ist ja interessant! Womit tust Du das? Als Ressource? Das sind doch *.res-Dateien?!

Nachdem ich meine DLL erfolgreich injizierte und die Hooks mithin erfolgreich installierte, wurde ich auf ein Programm aufmerksam, daß diese Vereinigung anbietet: PEBundle! Nun, tatsächlich läuft auch das Konglomerat beider (natürlich eine Exe), also es startet, doch die DLL kann sich aus diesem Korsett nicht lösen und mithin nicht woanders injiziert werden - die Hooks funktionieren nicht woanders, also global. Ob der Hook im eigenen Programm funktioniert, weiß ich jetzt nicht (ich probierte damals auch reichlich mit Pieptönen), zumal das eigene Programm mit dem Hook nichts anfangen kann. Aber in anderen Programmen funktionierte das definitiv nicht.

Nun schreibst Du aber, daß Du es global doch hinbekommen hättest. Wie vereinigst Du Exe-Datei und DLL erfolgreich?

Edit: Mir schwant gerade, warum der Hook doch nicht global ist: Die DLL wird doch nur vom Hostprogramm geladen, wie soll die sich denn in andere Prozesse injizieren?! Also, ich installierte den/die Hook(s) über die DLL (Aufruf der in der Hook-DLL enthaltenen Hookinstallationsfunktion natürlich über das Hostprogramm), und damit war die DLL automatisch injiziert, der Hook installiert. Aber so ganz schlau werde ich aus Deinen Ausführungen nicht: Ist der Hook nun global oder nicht? Es ist nicht schwer, beide Deiner Aussagen in dieser Diskussion zu finden.

[idefix2]

Also - Die DLL kann in die Exe als Ressource eingebunden werden. Zur Laufzeit entpackt die Exe erst einmal die DLL irgenwohin (z.B. nach \TEMP), und lädt sie von dort, als wär die DLL immer schon dort gelegen. Der Vorteil ist, dass man, wenn man das Programm unter die Leute bringen will, nur eine einzige Datei verteilen muss. Zu dem Thema, in Verbindung mit Keyboard Hooks, gibt es ein sehr klares Tutorial: http://www.delphi-treff.de/tutorials...-hooks/page/5/

Hab das jetzt zurückgestellt, weil ich meinen Hook erst einmal funktionsfähig haben muss, und dass ist extrem mühsam, weil lokal funktioniert er, als globaler Hook nur teilweise, d. h. er ist zwar jetzt in die globale KeyboardHook Kette eingebunden und piepst bei jedem Tastendruck, tut aber trotzdem nicht das, was er als lokaler Hook macht - wenn ich eine Eingabe in die EXE mache, tut er jetzt genau, was er soll, bei einer Eingabe in ein anderes Programm piepst er zwar auch, also ist er da, er macht aber Mist.

Und wie ich die DLL debugge, ist mir auch noch nicht klar, der Debugger der Delphi IDE wird mir da ja vermutlich nicht sehr viel helfen. Dazu ist das ganze zeitkritisch, d.h. das Programm verhält sich im Debugger, wenn es bei einem Breakpoint stehengeblieben ist, sowieso anders als wenn es in Echtzeit abläuft. Es wird mir wahrscheinlich nichts übrigbleiben, als doch eine IPC zwichen EXE und DLL einzurichten, damit ich Testausgaben in einem Fenster der EXE ausgeben kann.

[Delphi-Laie]

Zitat von idefix2:

Also - Die DLL kann in die Exe als Ressource eingebunden werden. Zur Laufzeit entpackt die Exe erst einmal die DLL irgenwohin (z.B. nach \TEMP), und lädt sie von dort, als wär die DLL immer schon dort gelegen. Der Vorteil ist, dass man, wenn man das Programm unter die Leute bringen will, nur eine einzige Datei verteilen muss.

Das kenne ich. Das Programm „PEBundle“ kann so etwas, soweit ich mich entsinne, auch. Allerdings war, wie schon gesagt, diese Vereinigung, sofern sie die DLL nicht kreißte/gebar, nicht in der Lage, sich in andere Prozesse zu injizieren bzw. dorthinein injiziert zu werden.

Zitat von idefix2:

Zu dem Thema, in Verbindung mit Keyboard Hooks, gibt es ein sehr klares Tutorial: http://www.delphi-treff.de/tutorials...-hooks/page/5/

Das kenne ich auch, es ist Assarbads Anleitung und geradezu Pflichtlektüre für alle Hookexperimente/-projekte unter Delphi. Allerdings ist es dort anders: Er ruft - egal, ob statisch oder dynamisch - auch für die Hookeinschaltung DLL-Funktionen auf. Probiere doch einmal, auch diese Funktionen in die DLL zu verbannen! Dann müßte die Chance, es global zu installieren, größer sein?!

[idefix2]

Ich habe gleich nach dem Lesen Deines ersten Posts die Hookinstallation SetWindowsHookEx in die DLL übersiedelt. Mein problem ist jetzt auch nicht mehr, dass mein Hook nicht global ist. Er ist global, und er meldet sich immer, egal in welches Programm ich eine tastatureingabe mache. Aber wenn mein Testprogramm den Focus hat, macht die Hookroutine alles wie sie soll, und sobald die Tastatureingaben in ein anderes programm gehen, macht sie manche Sachen nicht mehr, das ist aber ganz normaler Delphi Code - ich blicke da noch nicht ganz durch, vielleicht schauen die Tastaturnachrichten (= Parameter der HookProc) anders aus als wenn sie von der eigenen EXE kommen. Um das festzustellen, muss ich aber erst einmal eine IPC einrichten, damit ich sehe, was in der DLL genau passiert, und nachdem ich das auch noch nie gemacht habe, muss ich mich da erst einlesen.

Nebenbei: In einer globalen HookProc selbst kann man offenbar wirklich keinen Timer starten, wenn man das versucht, passieren die seltsamsten Dinge - und zwar nur, wenn die Tastaturereignisse an ein fremdes Fenster adressiert sind. Das war der eigentliche Grund, warum meine ersten Versuche völlig danebengegangen sind. Wenn man es weiss, ist es kein Problem, weil in der DLL funktionieren Timer - ausserhalb der HookProc - sehr wohl.

Zitat:

Allerdings war, wie schon gesagt, diese Vereinigung, sofern sie die DLL nicht kreißte/gebahr, nicht in der Lage, sich in andere Prozesse zu injizieren

Die DDL wird ja zur Laufzeit erst einmal aus der EXE in eine ganz normale DLL Datei extrahiert. Danach wird diese DLL Datei genauso geladen, als wäre sie nie Teil der EXE gewesen. Beim Laden der DLL kann für das Betriebssytem kein Unterschied mehr gegenüber einer DLL, die von vorneherein separat war, zu erkennen sein.

[Delphi-Laie]

So ganz verstehe ich Dich leider immer noch nicht.

Brachte mein Vorschlag, den Hook innerhalb der DLL zu starten, Dir nun einen spürbaren Fortschritt oder doch nicht?

Eines mußt Du auch bedenken (ich bezahlte diesbezüglich auch Lehrgeld): Bei DLL-Injektionen werden etliche Kopien dieser DLL an andere Prozesse erstellt. Globale Daten, die z.B. zum Injektionszeitraum vorlagen, existieren aber nur in der ursprünglichen DLL, in den Kopien sind diese Makulatur bzw. Schall und Rauch.

Es müssen also, um sicherzustellen, daß jede injizierte Kopie die richtigen Daten erhält, diese Daten zur Laufzeit dort hineingebracht werden, bzw. die DLL muß sich diese DLL beschaffen. Ich tat das mit externen Dateien. Nicht die eleganteste Lösung (im Vergleich mit der Interprozeßkommunikation), hat aber den Vorteil, daß man in der Menge der Daten flexibel bleibt.

Zusammengefaßt: Hookprogrammierung ist ekelhaft, aber eine durchaus bewältigbare Herausforderung. Wenn man es geschafft hat, freut man sich umso mehr.

Edit: Mir ist zudem immer noch nicht klar, wozu ein Timer der DLL gut sein soll, weil (Tastatur-)Hookprogrammierung genau wie vieles andere Außen(!)-Ereignisprogrammierung ist.

[idefix2]

Ich kann im Moment noch nicht sagen, ob die Übersiedlung der Hookinstallation in die DLL notwendig war, oder ob es anders auch geht. Ich werde das noch austesten, wenn meine DLL funktioniert. Der Status ist derzeit der: Mein Hook ist global, tut aber nur lokal genau was ich erwarte (d.h. wenn das Tastaturerignis an die EXE geht, die die DLL geladen hat), er tut nur teilweise das, was er tun soll, wenn das Tastaturereignis an ein anderes Programm geht. Warum das so ist, bin ich erst beim Erkunden.

Den Timer brauche ich (und er funktioniert sogar in der DLL, ich habe nur das Programm etwas umbauen müssen, weil ich in der Hookroutine selbst keinen Timer starten kann), weil ich sicherstellen will, dass ShiftLock wirkungslos bleibt, wenn 300 ms vorher bis 300ms nach dem Drücken der Shiftlock Taste eine andere Taste gedrückt wird - jetzt, während ich das schreibe, kommt mir gerade, dass ich das gleiche auch ohne Timer mit Hilfe von Timestamps überprüfen könnte (vorausgesetzt, die Funktion "now" liefert die aktuelle Zeit mit ausreichender Genauigkeit, das müsste ich mir noch anschauen).

Und gibt es dann nicht noch eine Systemfunktion, die die Anzahl der Ticks seit dem Starten des PC liefert? Ich glaube, dass ich da irgendwo am Rande einmal etwas gelesen haben. Irgendwie sollte man damit feststellen können, wie lange der PC schon in Betrieb ist.

Zitat:

Bei DLL-Injektionen werden etliche Kopien dieser DLL an andere Prozesse erstellt.

Ich verstehe nicht ganz, was Du meinst. Wenn mehrere Prozesse eine DLL laden und verwenden, dann gibt es im Speicher ein Exemplar der DLL, das mit separaten Datenbereichen für jede Instanz, die sie geladen hat, arbeitet. Aber in dem Fall eines globalen Hooks wird ja nur ein DLL Prozess gestartet, und der bekommt dann alle Ereignisse mit, egal an welchen Prozess das Ereignisse geschickt werden.

[Delphi-Laie]

Zitat von idefix2:

Zitat:

Bei DLL-Injektionen werden etliche Kopien dieser DLL an andere Prozesse erstellt.

Ich verstehe nicht ganz, was Du meinst. Wenn mehrere Prozesse eine DLL laden und verwenden, dann gibt es im Speicher ein Exemplar der DLL, das mit separaten Datenbereichen für jede Instanz, die sie geladen hat, arbeitet. Aber in dem Fall eines globalen Hooks wird ja nur ein DLL Prozess gestartet, und der bekommt dann alle Ereignisse mit, egal an welchen Prozess das Ereignisse geschickt werden.

So ganz genau weiß ich es leider nicht, die echten Experten (außer Dir?!) halten sich ja in dieser Diskussion auffällig zurück. Ob nun nur eine DLL „mit separaten Datenbereichen“ oder x-mal die Kopie derselben DLL verwendet wird, läuft letztlich - vom Speicherverbrauch abgesehen - auf dasselbe hinaus, weil der Programmcode ja identisch sein muß.

In meinem Programm „Prozesse“ (auch hier im Forum zu finden) läßt sich über die Spalte „Module“ (dahinter steckt ein Modulschnappschuß) recht gut verfolgen, daß eine Hook-DLL in mehr als einem Prozeß als Modul existiert und damit wohl insgesamt auch mehrere Male (?) im Speicher vorhanden ist. In welche Prozesse sich die DLL einklinkt und in welche nicht, konnte ich allerdings noch kein System erkennen.

[Delphi-Laie]

Hallo idefix2!

Kürzlich bemerkte ich ein Phänomen, das ich vorher noch nie hatte: Mein Hookprogramm (das leider nie den Charakter einer Studie bzw. eines Experimentes ganz verließ) stürzte in der 64-Bit-Version (mit Lazarus erstellt) ab. Dennoch bemerkte ich später noch die Wirkung der Hookauslösung, also waren immer die immer noch funktionierende Kopien der DLL immer noch in einzelne Prozesse injiziert. Die automatische DLL-Entladung versagte also in diesem Falle. Zudem war es das erste und bisher einzige Mal, daß eine DLL wirklich ohne Exe-Datei funktionierte, also als allein ausführbarer und auch ausführender Code im Speicher lag. Sicher, die Situation, die dahin führte, war irregulär....

[idefix2]

Ehrlich gesagt vertraue ich dem 64 Bit Windows nicht. Ich hatte bei mir kurz ein Windows7 64Bit in Betrieb, habe es nach diversen obskuren Problemen wieder rausgeworfen und wieder die 32 Bit Version aufgesetzt. Die läuft halbwegs stabil. 3/4 GB Speicher stecken jetzt eben ungenutzt in meinem Rechner, 32Bit Windows kann ja nur 3,25 GB adressieren, dafür funktioniert er jetzt einigermassen.

Im Grossen und Ganzen habe ich meinen Hook jetzt fertig, was leider nicht ordentlich funktioniert ist das Zusammenspiel mit der Dektopintegration einer virtullen XP Maschine. Da kommen gelegentlich keine Tasten an, dann muss ich das HookHauptprogramm beenden, damit in der VM die Tastatur überhaupt funktioniert. Sonst läuft es jetzt, die Probleme mit der VM werde ich wahrscheinlich nicht lösen können, da dürfte einiges bei der Desktopintegration unsauber programmiert sein.