[C#/Win32] Local Hook

[riezebosch]

Ik kan een systemwide hook zetten om toetsenbord- en muisinvoer uit te lezen. Ook lukt het me om alleen van de huidige thread informatie uit te lezen. Maar nu wil ik alleen de events van een bepaalde applicatie afvangen. Moet je hiervoor persé een DLL gebruiken (wat in eerste instantie ook van systemwide hooks gezegd werd), of kan ik 'm ook gewoon laten doorverwijzen naar een stukje (functie) uit m'n huidige applicatie?

Ik heb al van alles met de hInstance en threadId (3e en 4e parameter van SetWindowsHookEx) geprobeerd, maar in het beste geval gebeurde er niks, en in het ergste crashten alle openstaande applicaties...

edit:

SetSystemsHookEx = SetWindowsHookEx natuurlijk...

[ Voor 8% gewijzigd door riezebosch op 27-11-2004 21:58 ]

[.oisyn]

Je moet een stukje code hebben dat zich in de address space van de applicatie die je hookt bevindt. Als de hook in je huidige applicatie zit betekent dat dus dat je geen dll hoeft te gebruiken, voor een hook in een andere app heb je echter een dll nodig die je in de address space van de andere applicatie kunt laden.

Overigens vraag ik me af of je wel een local hook kunt zetten voor een andere app.

[riezebosch]

Een systemwide keyboard/mouse hook lukt me, door als parameter Marshal.GetHINSTNACE(System.Reflection.Assembly.GetExecutingAssembly().GetModules()[0]) mee te geven, en een delegate naar de functie waarin ik de messages afhandel. Maar met WH_CALLWNDPROC krijg je dan dikke errors.

En wat is anders het nut van dwThreadID en wat houd dan een hook in die een thread als scope heeft?

quote: http://msdn.microsoft.com...ions/setwindowshookex.asp

Hook	Scope
WH_CALLWNDPROC	Thread or global
WH_CALLWNDPROCRET	Thread or global
WH_CBT	Thread or global
WH_DEBUG	Thread or global
WH_FOREGROUNDIDLE	Thread or global
WH_GETMESSAGE	Thread or global
WH_JOURNALPLAYBACK	Global only
WH_JOURNALRECORD	Global only
WH_KEYBOARD	Thread or global
WH_KEYBOARD_LL	Global only
WH_MOUSE	Thread or global
WH_MOUSE_LL	Global only
WH_MSGFILTER	Thread or global
WH_SHELL	Thread or global
WH_SYSMSGFILTER	Global only

[ Voor 3% gewijzigd door riezebosch op 16-11-2004 15:07 ]

[curry684]

riezebosch schreef op dinsdag 16 november 2004 @ 15:00:
Een systemwide keyboard/mouse hook lukt me, door als parameter Marshal.GetHINSTNACE(System.Reflection.Assembly.GetExecutingAssembly().GetModules()[0]) mee te geven, en een delegate naar de functie waarin ik de messages afhandel. Maar met WH_CALLWNDPROC krijg je dan dikke errors.

Goh

De hook wordt uitgevoerd binnen de context van de aanroepende applicatie, en jij plaatst daar dus een pointer naar code uit jouw eigen assembly. Dat is zo ongeveer de klassiekste access violation die je kunt bedenken ja

De enige manier om op andere applicaties te hooken is om een DLL in de global hook chain te hangen en netjes de filteren in de callback zelf.

[riezebosch]

Mooi zo! Dan ben ik eindelijk overtuigd een DLL te gaan bouwen

Dank u.

Maar is het nu wel of niet mogelijk een hook in de chain van een bepaalde applicatie te hangen? Of moet ik, zoals jij impliciet aangeeft, dit ook zelf filteren in de callback?

[ Voor 59% gewijzigd door riezebosch op 16-11-2004 15:12 ]

[curry684]

Nee je kunt eigen threads hooken of globaal. Indien je wil filteren in een globale hook heb je een memorymappedfile nodig nodig waarin je 'config' data opslaat, en omdat iedere running app vervolgens aan je DLL connect moet je bij iedere 'connect' even die file openen. Vervolgens kun je simpelweg gewenst threadId matchen met GetCurrentThreadId

[riezebosch]

Maar wanneer ik dus één bepaalde app wil hooken (heeft die ook maar één ThreadID?), dan kan ik gewoon specifiek daar m'n hook aan knopen? En hoef ik dus ook niet de threadId's te matchen?

[.oisyn]

Uit de MSDN blijkt niet dat je geen threadid op mag geven die niet van jezelf is, dus je kunt imho gewoon een local hook zetten.

[curry684]

riezebosch schreef op dinsdag 16 november 2004 @ 15:15:
Maar wanneer ik dus één bepaalde app wil hooken (heeft die ook maar één ThreadID?), dan kan ik gewoon specifiek daar m'n hook aan knopen?

Nee een hook is global of threadspecific, maar dan moet het wel een thread van jezelf zijn

Een 'app' is overigens een proces, en bevat zelf 1 tot x threads. Niet iedere thread is een GUI-thread, de meeste applicaties doen alle GUI-activiteiten in 1 thread. Je kunt middels GetWindowThreadProcessId de thread- en process ID's achterhalen die bij een specifiek window horen.

En hoef ik dus ook niet de threadId's te matchen?

Wel dus

[curry684]

.oisyn schreef op dinsdag 16 november 2004 @ 15:22:
Uit de MSDN blijkt niet dat je geen threadid op mag geven die niet van jezelf is, dus je kunt imho gewoon een local hook zetten.

Hmmm nu je het zegt kan dat op zich wel werken, volgens de docs moet hMod expliciet alleen NULL zijn als je een lokale thread aangeeft. Proberen waard

[riezebosch]

.oisyn schreef op dinsdag 16 november 2004 @ 15:22:
Uit de MSDN blijkt niet dat je geen threadid op mag geven die niet van jezelf is, dus je kunt imho gewoon een local hook zetten.

Ik moest echt drie keer lezen voordat ik doorhad dat curry684 het wel goed gelezen had. Dacht dat je eerst bedoelde dat uit de MSDN bleek dat het niet mocht, maar zag toen pas dat je drie ontkenningen gebruikt (Had het eerste woordje 'niet' geskipt).

curry684 schreef op dinsdag 16 november 2004 @ 15:23:
Een 'app' is overigens een proces, en bevat zelf 1 tot x threads. Niet iedere thread is een GUI-thread, de meeste applicaties doen alle GUI-activiteiten in 1 thread. Je kunt middels GetWindowThreadProcessId de thread- en process ID's achterhalen die bij een specifiek window horen

Maar als niet per definitie alle GUI-activiteit in 1 thread zitten, is de methode dus ook niet waterdicht. Maar dat is een global hook icm het matchen van threadId's dan zeker ook niet?

En is het doorgeven van een 'functiepointer' vanuit m'n C# app naar de DLL om binnen m'n app wel de messages af te kunnen handelen net zo'n ranzige Access Violation? Je zal toch op een of andere manier de data binnen moeten krijgen...

Edit:
Dat is natuurlijk precies de manier waarop hooks werken. Het ging bij de Access Violation niet om de functiepointer, maar om het verwijzen naar de Assembly van een andere app...

[ Voor 63% gewijzigd door riezebosch op 16-11-2004 15:41 ]

[.oisyn]

curry684 schreef op dinsdag 16 november 2004 @ 15:25:
[...]

Hmmm nu je het zegt kan dat op zich wel werken, volgens de docs moet hMod expliciet alleen NULL zijn als je een lokale thread aangeeft. Proberen waard

Dat is idd precies het stukje wat ik bedoelde Als het niet zou mogen zou dat er ook niet bij staan (en zou er wel staan dat het niet mag)

[riezebosch]

Maar nu snap ik opeens het verschil niet meer. Wat maakt het nou uit of ik de functie van mijn applicatie doorgeef aan een DLL die geïnjecteerd is een ander proces, of dat ik een functie uit m'n eigen assembly laat verwijzen in de callback van een ander proces?

Waar zit 'm nu precies die Access Violation in?

Ik wil toch de data die ik in m'n DLL binnenkrijg weer terugkrijgen in m'n C# app. Zoals ik het nu voor me zie, bouw ik een functie in een DLL die SetWindowsHookEx aanroept. Vanuit m'n C# app roep ik die functie in de DLL aan, met als parater een pointer naar de functie in de C# app die wat met het bericht doet(, en de hinstance van m'n app (in het voorbeeld doen ze ook this.appIntance)?).

Waarom is zo'n DLL dan niet kant en klaar? Wat moet er nog meer in? Op die manier kan je toch elke gewenste hook zetten? Maar wat is het verschil dan met de eerder genoemde methode?

[.oisyn]

Je begrijpt het niet helemaal. Je wilt een hook zetten, zo'n hook is een stukje code die wordt aangeroepen op het moment dat datgene waar je de hook opzet triggert (bijvoorbeeld mouse en keyboard events), maar in de address space van het proces waarin het event afgehandeld wordt. Je code moet dus in die applicatie zitten, en de manier om dat te doen is om de code in een dll te zetten zodat ie in een applicatie geladen kan worden.

Je hook code moet weer communiceren met je main applicatie, en dus zul je iets met shared memory moeten doen oid. Maar in de dll komt dus de hook code zodat die in de context van de applicatie waarin de hoek gezet wordt gerund kan worden.

[riezebosch]

Kom er net achter dat Jeffrey Richter compleet hoofdstuk gewijd heeft aan DLL Injection and API Hooking _{Programming Applications for Microsoft Windows - Fourth Edition [Jeffrey Richter]}

Alleen nog ff uitzoeken of dit gaat werken met C# icm DLL. Anders moet ik maar voor het record-gedeelte een losse Win32 App schrijven.

[riezebosch]

Ik snap nu hoe ik:
• in een DLL een shared memory gedeelte aan moet maken;
• de DLL moet injecteren in een ander proces;
• een SendMessage naar mijn eigen applicatie moet sturen.

Maar mijn vraag is of dit ook icm een C# app kan. Ik zat eraan te denken in die DLL functies te implementer om de shared-data uit te lezen, zodat ik die kan importeren in C#. Wat ik me dan alleen afvraag is of ik ook een SendMessage naar die C# app kan doen om duidelijk te maken dat hij de data uit moet lezen.

Verder vroeg ik me af of de SetWindowsHookEx en UnHookWindowsHookEx ín de DLL moeten, of dat dit ook vanuit de C# applicatie kan, en misschien zelfs netter is. De meeste voorbeelden doen dit namelijk vanuit de DLL, en slaan dan voor een mij nog niet duidelijke reden de handle naar de hook op in het shared-mem gedeelte . Of het zou moeten zijn omdat je daar pas de hInstance van de DLL weet?

[ Voor 12% gewijzigd door riezebosch op 18-11-2004 15:30 ]

[curry684]

De handle van de DLL weet je zodra je LoadModule op het ding hebt gedaan Het is niet nodig om dit vanuit de DLL te doen, ik vind het persoonlijk zelfs onlogisch: het is je programma dat de hook zet, en refereert aan de DLL als callback.

[riezebosch]

Juist! Ik vond het zelf ook nogal onlogisch. Maar wat vind je van die andere oplossing: functies bouwen om het shared-memory beschikbaar te maken naar C#? Gewoon in het .shared memory segment een WPARAM g_wParam en LPARAM g_lParam en dan 2 functies getWParam en getLParam?

Alleen moet ik dan nog weten of ik een eigen gedefinieerde SendMessage naar mijn C# app kan doen en dit daarin dan ondervangen om de functies voor het uitlezen aan te roepen... Ik zat zelf te denken, als het anders niet mogelijk is, iets van een hidden button op te nemen, message erheen sturen vanuit de DLL (Callback) die 'm indrukt om vervolgens in de eventhandler ervan de data te verwerken.

Het setten van de windowshook moet je alleen zeker wel vanuit de DLL doen als je 'm niet dynamisch laadt met LoadLibrary/LoadModule? En dat is denk ik wel net zo makkelijk als je zelf ook nog functies uit die DLL aan wilt roepen (de get in mijn geval).

[ Voor 17% gewijzigd door riezebosch op 18-11-2004 15:46 ]

[curry684]

Hidden button heb je niet nodig, je kunt gewoon een Message Window definieren (kijk maar eens bij CreateWindowEx docs). Ik prefereer overigens Named Pipes om tussen processen te communiceren, maar als je weinig data op en neer stuurt werken messages idd eenvoudiger. Kwestie van handle naar msg window in het shared mem opnemen

[riezebosch]

Dat is inderdaad de manier, handle naar msg windows in shared mem opnemen. Maar je oplossing om een Message Window te definiëren snap ik niet. CreateWindowEx is toch Win32? Ik kan in .NET toch geen eigen callback-functie voor zo'n Window definiëren?

Wat ik ook maar niet helder krijg is de werking van de JournalPlaybackProc (is trouwens ook weinig over te vinden). Eerst zette ik gewoon 2 hooks: 1 voor de muis en 1 voor het toetsenbord, en las ik in de filterfunction uit of het op de betreffende applicatie was door extra functies. Bij het afspelen deed ik dan gewoon een SendInput met de data, en een SetCursorPos (met mooie beweging nav een oud topic van jou).
Nu begrijp ik dat met een JournalRecordProc muis en toetsenbord beide uitgelezen worden, plus dat er in de meegestuurde data ook informatie over het scherm zit. Maar hoe verbouw en filter ik deze info naar believen, en simuleer het weer met een JournalPlaybackProc?

[curry684]

Journalling hooks moet je alleen gebruiken als je echt journalling aan het doen bent. D'r staat in MSDN genoeg over hoe je dat doet

Je kunt de messages ook gewoon aan je dialoog sturen als je die een hebt, message windows zijn voornamelijk bedoeld voor als je geen window hebt.

_{gaaf trouwens dat posts van ruim 2 jaar oud nog gebruikt worden}

[riezebosch]

Ja, maar dat bedoel ik juist: als ik zo'n mesage naar m'n dialoog stuur, hoe vang ik die dan af? Want in mijn programma in C# beschik ik niet over een Callback-function waar ik persoonlijk de messages in kan afhandelen...

offtopic:
Is inderdaad supertof algoritme wat je daar geeft, omdat het de lijn die de muis moet gaan in gelijke stapjes deelt. Hierdoor is het niet afhankelijk van lengte of x/y coördinaten (richtingscoëfficient)!

[riezebosch]

curry684 schreef op donderdag 18 november 2004 @ 15:36:
De handle van de DLL weet je zodra je LoadModule op het ding hebt gedaan Het is niet nodig om dit vanuit de DLL te doen, ik vind het persoonlijk zelfs onlogisch: het is je programma dat de hook zet, en refereert aan de DLL als callback.

Maar hoe zit het dan met het laden van de DLL? Met LoadModule wordt hij in de huidige process-space geladen. Wordt met SetWindowsHookEx deze zelfde DLL dan naar de process-space van het andere process waarin je de hook wilt zetten gekopieerd? Of delen hetzelfde stukje geheugen?

[Verwijderd]

Waarom is er nog niemand om het idee gekomen te melden dat het een waanzinnig slecht idee is systemwide hooks in managed code te maken? Als het gaat werken (en dat is al een grote als) wordt in ieder process de CLR met al z'n dll's naar binnen gesleurd waardoor je hooks niet echt lightweight meer zijn en het geheugen gebruik waarschijnlijk ook niet misselijk.

ja C# is makkelijk programmeren voor heel veel dingen maar kies wel the right tool for the right job, en C# voor een system wide hook is verre van the right tool.

[riezebosch]

Daarom stop ik nu ook m'n hook in een DLL gemaakt met C++, en probeer dit extern te koppelen aan m'n managed code. Eventueel, wanneer dit onwerkbaar blijkt, zal ik het gedeelte voor de hook in een aparte applicatie zetten, met een eigen dll, die extern aangeroepen gaat worden door m'n C# applicatie.

In ieder geval bedantk voor je reactie

[riezebosch]

Dan kom ik nu weer met het volgende: welk hooktype moet ik kiezen?

Om toetsenbord en muisinvoer in een bepaalde applicatie uit te lezen, kan ik twee hooks zetten: een WH_MOUSE en WH_KEYBOARD. Hierbij krijg ik echter geen extra informatie over de handle van het Window waarop de actie is uitgevoerd, en moet ik dit dus nog zelf achterhalen.

Daarnaast kan ik ook een WH_JOURNALRECORD hook zetten, welke wel die aanvullende informatie geeft. Alleen is deze hook, als ik het goed begrijp, alleen bedoeld om in combinatie met WH_JOURNALPLAYBACK, ongewijzigd de opgenomen acties weer af te spelen.

Ook heb ik de WH_CALLWNDPROC en CALLWNDPROCRET uitgeprobeerd. Deze leek wel op het goede moment acties af te vuren, alleen kon ik deze maar niet verwerkt krijgen. De waarde van uMsg was niet die van standaard WM_MOUSEMOVE e.d. Zo ver ik kon zien gaf deze wel de handle van het subwindow waarop de actie werd uitgevoerd, zelfs als dit een menu was.

Ten vierde heb ik de WH_GETMESSAGE geprobeerd. Deze geeft de benodigde informatie, voor toetsenbord én muis, alleen geeft ie de handle van het hoofdscherm, ongeacht of er een popup actief is. Ook weet ik niet of dit type hook bedoeld is voor het uitlezen van gebruikersinvoer.

[Edit]
Nu heb ik nog een aanvullende vraag op de laatste mogelijkheid: wanneer ik een PostThreadMessage naar de thread van mijn eigen app stuur, met als parameters de message, wParam en lParam die ik binnenkrijg in de lParam (MSG) in m'n GetMsgProc, kopieert ie de waarde waar deze variabelen naar verwijzen (met name lParam) dan ook naar de process-space van de thread waar ik hem heenstuur? Want het wérkt wel, maar ik vraag me dus af of (omdat lParam (meestal) een verwijzing is) of deze dan niet in de process-space van de gehookte app zit te frutten...

[ Voor 20% gewijzigd door riezebosch op 23-11-2004 15:42 ]

[Verwijderd]

Voor als iemand deze ooit nog es opgraaft via de search wat aanvullende info

http://support.microsoft....aspx?scid=kb;EN-US;318804

[curry684]

riezebosch schreef op dinsdag 23 november 2004 @ 14:21:
Dan kom ik nu weer met het volgende: welk hooktype moet ik kiezen?

Om toetsenbord en muisinvoer in een bepaalde applicatie uit te lezen, kan ik twee hooks zetten: een WH_MOUSE en WH_KEYBOARD. Hierbij krijg ik echter geen extra informatie over de handle van het Window waarop de actie is uitgevoerd, en moet ik dit dus nog zelf achterhalen.

GetWindowAtPos en GetForegroundWindow zijn ook heel complexe functies

Daarnaast kan ik ook een WH_JOURNALRECORD hook zetten, welke wel die aanvullende informatie geeft. Alleen is deze hook, als ik het goed begrijp, alleen bedoeld om in combinatie met WH_JOURNALPLAYBACK, ongewijzigd de opgenomen acties weer af te spelen.

Ja, dat zijn echt combo-acties. Journaling is gewoon een rotzooi om uit te plukken anders, en teveel load voor de simpele taakjes imho.

Ook heb ik de WH_CALLWNDPROC en CALLWNDPROCRET uitgeprobeerd. Deze leek wel op het goede moment acties af te vuren, alleen kon ik deze maar niet verwerkt krijgen. De waarde van uMsg was niet die van standaard WM_MOUSEMOVE e.d. Zo ver ik kon zien gaf deze wel de handle van het subwindow waarop de actie werd uitgevoerd, zelfs als dit een menu was.

uMsg heeft wel degelijk de normale window messages hoor, je krijgt exact de messages zoals ze naar het window gaan namelijk.

Ten vierde heb ik de WH_GETMESSAGE geprobeerd. Deze geeft de benodigde informatie, voor toetsenbord én muis, alleen geeft ie de handle van het hoofdscherm, ongeacht of er een popup actief is. Ook weet ik niet of dit type hook bedoeld is voor het uitlezen van gebruikersinvoer.

GetMessage werkt idd op het niveau van het window waarin de afhandeling plaatsvindt, en is imho niet echt nuttig.

Ik heb altijd gewoon op CALLWNDPROC gewerkt, handigste, krachtigste en overzichtelijkste

[Edit]
Nu heb ik nog een aanvullende vraag op de laatste mogelijkheid: wanneer ik een PostThreadMessage naar de thread van mijn eigen app stuur, met als parameters de message, wParam en lParam die ik binnenkrijg in de lParam (MSG) in m'n GetMsgProc, kopieert ie de waarde waar deze variabelen naar verwijzen (met name lParam) dan ook naar de process-space van de thread waar ik hem heenstuur? Want het wérkt wel, maar ik vraag me dus af of (omdat lParam (meestal) een verwijzing is) of deze dan niet in de process-space van de gehookte app zit te frutten...

In principe zit je daar altijd veilig mee. Eventuele handles kun je middels DuplicateHandle naar je eigen processspace kopieren, en pointers naar geheugen via messages horen per definitie globally owned blocks te zijn anders kan het systeem er zelf ook niets mee