warum HookHandle global machen?

[Robert Marquardt]

Zitat von originalhanno:

- Es gibt die DLL einmal, kopiert wird nur der Datenteil, d.h. jeder Prozess besitzt einen Datenteil.

Hier ist der Denkfehler. Das Datensegment wird nicht kopiert.
Nur die DLL-Kopie die SetWindowsHookEx aufruft hat eine Hook-Variable ungleich 0.
Die anderen DLL-Kopien fuehren nur die Zuweisung "HHOOK hMouseHook =0;" durch.

[originalhanno]

??
In welchem Fall nun?
Wenn man's richtig macht, oder wenn man den Hook Handle nicht global macht?
Ist die Aussage von thkerkmann richtig, das die Handles lokal sein müssen?

Es tut mir leid, ich checks leider noch nicht.
Kann aber auch daran liegen, dass ich schon wieder seít 10:00 am Rechner sitze...
Muss halt fertig werden.
Ich werde also mal eine Nacht darüber schlafen, vielleicht sehe ich Morgen klarer...

Danke vielmals für Eure Hilfe

[Robert Marquardt]

Zitat von thkerkmann:

meiner Meinung nach müssen die Handles sogar lokal sein. Sie gehören dem Prozess, der den Hook (in der dll) installiert, damit er sich daraus wieder verabschieden kann. Global muss also nicht das Handle sein, sondern die HookProcedure muss global zur Verfügung gestellt werden - und das geht eben über die dll.

Meinung zaehlt nicht sondern nur die Realitaet.
Das Problem ist der Aufruf von NextHookEx. DLLs in verschiedenen Prozessen sind immer in Kopie geladen.
Die Datensegmente werden nie kopiert. Nur eine der Kopien hat daher eine von SetWindowsHookEx mit einem Wert versehene Hook-Variable und diese wird nun mal in allen Kopien fuer NextHookEx gebraucht.

Zitat von thkerkmann:

Die dll wird bei systemweiten Hooks nämlich nicht mit der Beendigung deines Programmes entladen, sondern erst, wenn keine Ereignisse mehr über sie laufen, d.h. ALLE Prozesse, die in die Hook-Kette eingeklinkt sind, beendet wurden. Im spätesten Fall erst beim Windows beenden.

Quatsch. Da die DLL pro Prozess separat geladen wird, wird sie einfach mit dem Prozess entladen und faellt aus der Verwaltung fuer die Hook-Chain.
Ruft man UnhookWindowsHookEx auf so wird die Hook-Chain sprich die Funktionsaufrufe aufgegeben. Ob die DLLs entladen werden oder ob Windows sie einfach als Zombies stehen laesst weiss ich nicht. Da sie nun funktionslos sind ist das ja theoretisch egal (praktisch sind Hooks Angriffsvektoren fuer allerlei Sauereien).

[thkerkmann]

Dann lies doch mal das hier genauer....

About Hooks

Also da lese ich nix von einem globalen HookHandle...

[originalhanno]

Hallo zusammen,

Zitat von Robert Marquardt:

Ob die DLLs entladen werden oder ob Windows sie einfach als Zombies stehen laesst weiss ich nicht. Da sie nun funktionslos sind ist das ja theoretisch egal (praktisch sind Hooks Angriffsvektoren fuer allerlei Sauereien).

Zitat:

You can release a global hook procedure by using UnhookWindowsHookEx, but this function does not free the DLL containing the hook procedure. This is because global hook procedures are called in the process context of every application in the desktop, causing an implicit call to the LoadLibrary function for all of those processes. Because a call to the FreeLibrary function cannot be made for another process, there is then no way to free the DLL. The system eventually frees the DLL after all processes explicitly linked to the DLL have either terminated or called FreeLibrary and all processes that called the hook procedure have resumed processing outside the DLL.

An alternative method for installing a global hook procedure is to provide an installation function in the DLL, along with the hook procedure. With this method, the installing application does not need the handle to the DLL module. By linking with the DLL, the application gains access to the installation function. The installation function can supply the DLL module handle and other details in the call to SetWindowsHookEx. The DLL can also contain a function that releases the global hook procedure; the application can call this hook-releasing function when terminating.

Ich hoffe das hilft

Nun aber noch mal zu den Kopien des Datenteils:
frisch ausgeschlafen habe ich dein posting noch mal gelesen.
Ich denke, das ich mich nicht 100% klar ausgedrückt habe, und wir deshalb aneinander vorbeigeredet haben.
Also:
Soweit ich das verstanden habe, ist es so:
- Die DLL wird injected -> sie wird 1 mal vom Betriebssystem (BS) geladen
- Prozess A wird gestartet -> A legt extra Speicher an, aber nur für den Datenteil der DLL
- Prozess B wird gestartet -> B legt extra Speicher an, aber nur für den Datenteil der DLL
- A + B greifen gemeinsam auf den Programmteil der DLL zu
- A + B haben einen getrennten Datenteil, jeder hat seinen eigenen

Wenn nun A + B Daten gemeinsam nutzen wollen, müssen die das z.B. über shared segments tun.

Ist das soweit richtig?

Nun kommt der zweite Teil:
- Die DLL wird durch Aufruf von InstallHooks (ich bleib mal bei meinem Beispiel oben) installiert, also injected.
- Nur hier wird hMouseHook initialisiert, also mit der Adresse von MouseHookProc belegt.
- Wenn nun diese Variable lokal gehalten wird, also im separaten Datenteil jedes Prozesses, woher soll dann Prozess A wissen, welche Adresse in hMouseHook steht?
Die Adresse übergibt A aber an "CallNextHookEx(hMouseHook, nCode, wParam, lParam)".
Genauso natürlich Prozess B.
Soweit also für mich einsichtig, dass man globale "Variablen" braucht.

ABER:
Wieso in aller Welt funktioniert mein Programm dann auch, wenn ich die Variable hMousHook nicht in ein shared segment lege?

Für eine Antwort auf besonders diese Frage währe ich sehr dankbar.

@ thkerkmann:
Ich habe auch in der MSDN nix von globalen Variablen gelesen. Mir erscheint es jedoch wie oben beschrieben am logischsten.


Danke nochmals für die grauen Zellen

[brechi]

Ich weiß echt nicht was an

callnexthookex

zo schwer zu verstehen ist. Oder bin ich einfach nur blöde?


hhk
Ignored.


Das wird Windows schon selbst regeln. Des weiß schon wen es gecalled hat und wer somit die Funktion weitergeben will. Da ist der Parameter doch aus Windows sicht überhaupt nicht mehr relevant.

Delphi-Quellcode:

-> neue Message -> 1 in der Liste callen -> kein callNextHook -> pech
                                         -> callNextHook -> Windows ruft nächsten in der Liste auf

Teste doch einfach mal und übergib irgend nen Müll als 1. Parameter.

[originalhanno]

Zitat von Robert Marquardt:

Nur eine der Kopien hat daher eine von SetWindowsHookEx mit einem Wert versehene Hook-Variable und diese wird nun mal in allen Kopien fuer NextHookEx gebraucht.

UIUI.
Also jetzt gehts aber rund. Irgendwer hat unrecht............

[sakura]

@originalhanno: Zur Info, ich habe überall mal [delphi] Tags nach [c] Tags gewandelt

......

[originalhanno]

Danke sehr !

[brechi]

Hanno, ich weiß nicht warum du nicht einfach mal den Wert von hMouseHook ausgibst?
Das würde wirklich ALLEN hier helfen, anstatt hier weiter Vermutungen zu äußern. Selbst wenn ich Unrecht habe (und somit was falsches in MSDN steht) oder ob Robert falsch liegt ist doch wohl mal nicht so schlimm.

Zu Data/Code Segmente:
Es ist (so viel ich weiß) total egal was die BaseOfCode / BaseOfData ist, nur die Flags in den _Sections_ interessieren.
Da gibt es halt Readable, Executable, Shareable und Writeable, wo bei Readable/Executable kein Unterschied auf Systemen ohne NXFlag gemacht wird. Und Shareable gibt es halt unter Delphi nicht (weiß nicht ib es reicht einfach als als Shareable zu markieren oder ob des spezielle Anforderungen braucht [eventl. gehts sogar ohne Probleme])
-> Jedenfalls kann auch die CodeSection Extra für jeden Prozess geladen werden, wenn man sie als Writeable markiert oder VirtualProtect drüberlaufen lässt.

Wie auch immer ist total egal und irrelevant für dein Problem. Da Keyhooks auch in Delphi machbar sind (und dort shareable nicht verwendet werden kann) reicht es für dich zu wissen, dass alles was du in einer DLL mit Variablen machst eben vom Prozess aus gesehen lokal ist.

Bleibt also nur noch zu klären ob die Variable 'hMouseHook' für SetWindowsHookEx egal ist. (laut MSDN schon) Laut der Betrachtung als Lokale Variable in einem Prozess ebenfalls. Mit 2 Minuten arbeit könntest du es ja leicht bestätigen oder eben auch nicht.
Da brauchst du die Forenuser nicht gegenseitig ausspielen, immerhin willst DU ja eine Lösung dafür haben.