Problème exécutable : hook et fonctions exportées

Bonjour à tous,

Je vous explique mon problème:

J'ai un executable qui possède une fonction exportée. Nommons la exe_fn1.
J'ai une DLL qui possède une fonction exportée dll_fn1.

- exe_fn1 ne fait qu'ajouter bêtement un texte dans une listeBox de l'executable..
- dll_fn1 initialise un hook WH_CBT

Il n'y aucun problème au niveau du hook, je récupère bien les messages.

Par contre, je galère pour faire communiquer ma DLL et mon executable dans le sens DLL -> executable.

Pour cela, ma DLL, à l'initialisation du Hook, recupere l'adresse de exe_fn1.

Dans la fonction callback du hook WH_CBT, à chaque message recu, je veux appeler exe_fn1 pour qu'un texte s'affiche sur la listeBox.
Sauf que dès lors que exe_fn1 est appelée, cela fige direct le programme, plante mon explorer, ..., enfin bref la galère.
Ex:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

static LRESULT CALLBACK CBTCallback(int code, WPARAM wparam, LPARAM lparam) { if (code >= 0) { UINT msg = 0; if (code == HCBT_ACTIVATE) exe_fn1 (); // crash } return CallNextHookEx(hookCbt, code, wparam, lparam); }

---

Si vous avez une idée, faites moi signe :)

PS: Selon vous, quel est le meilleur moyen pour faire communiquer une DLL et un executable pour passer des structures par exemple. J'ai choisi les fonctions exportees, mais ce n'est peut etre pas la meilleur methode.

Merci.

Vince

http://vroy1.free.fr/wpfr/

Votre dll sera injectée dans tous les exécutables, le votre qui à la fonction exe_fn1 mais aussi les autres qui ne l'ont pas.

Déjà, réussir à linker statiquement une dll à un exe, c'est chercher un peu les emmerdes. Je ne savais pas que cela était facilement réalisable.

C'est toute à fais illogique d'avoir une dll qui dépend d'un exécutable.

Si votre dll doit communiquer avec votre exécutable, utilisez n'importe quel IPC (mémoire mappé, socket, pipe ....) pour qu'ils communiquent de manière sûre.

Bonjour,

Tout d'abord merci pour votre réponse.

Je veux préciser un point important quand même. La fonction exe_fn1 fonctionne très bien en dehors de la procédure callback CBTCallback.

Donc je ne vois pas pourquoi cela ne fonctionne pas dans la procédure CBTCallback.

Merci.

Vincent.

je recapépète, la procédure callback CBTCallback est appelée dans le contexte d'autres exécutables, via injection de dll dans les espaces mémoires de tous les exécutables. Oui le hooking est un peu intrusif, juste un peu/
Les autres fonctions de la dll sont aussi injectées mais pas appelées dans l'espace mémoire d'un autre programme, CBTCallback si.

Si vous appelez CBTCallback directement depuis votre programme, ça marchera aussi, puisque vous n'avez pas changé d'espace mémoire (c'est celui du programme appelant).

Il faudrait penser à vérifier ce qu'est un espace mémoire et de l'injection de dll.

Bonjour Bacelar,

Merci pour tes conseils. J'ai finalement opté pour l'API SendNotifyMessage qui fonctionne très bien.

Sinon j'aurais une autre question. Je voudrais détecter et récupérer chaque modification d'un champ de saisie (chaque fois que l'utilisateur saisi quelque chose). Je sais que je peux récupérer ca avec les messages keyboard, mais je me demandais s'il n'y avait pas un message windows spécifique.

Merci.

Vincent

Je tenterais le subclassing de la fenêtre.

http://msdn.microsoft.com/en-us/libr...69(VS.85).aspx

Attention, si vous êtes dans de l'injection de dll, les adresses dans le code (les pointeurs de fonction par exemple) peuvent varier d'un exécutable à l'autre. Il faut les calculer pour chaque programme.

Salut,

Ok, donc si je comprend bien, il faudrait que je subclass chaque objet de la fenetre (edit, bouton, etc ..) à l'aide de SetWindowLong dans des procédures que je coderais moi même.
Par contre, le seul hic est je peux hooker n'importe quel exécutable, je ne connais pas à l'avance le nombre de boutons, de menu, ...

Donc ma question: Si je subclass directement la procédure de gestion des messages windows avec le paramètre GWL_WNDPROC, est ce que j'aurais tous les évènements de la fenêtre (modification champ de saisie ...) dans ma nouvelle procedure ?

Merci.

Vincent.

Je croyais que c'était qu’un seul champ de saisie.

Si c'est pour tout récupérer, le plus simple est de hooker les événements keyboard.

Pour choisir la bonne méthode, il faut connaître ton besoin réel.

Bonjour,

Je veux checker les evénements de chaque objets de la fenetre (creation modification, suppression, ...).
Donc en suivant tes conseils, j'ai donc opté pour un hook sur WH_CALLWNDPROC.
Je récupère bien les evénements de création de champs. Maintenant, il faut que je fasse la même chose pour la modification.
Merci encore.
Vincent

Bonjour, me revoila.

Les hooks fonctionnent lorsque le process est déjà lancé.
Maintenant, je veux faire la même chose, mais avec un executable que je lance.
J'ai donc tester avec l'API CreateProcess en mode suspendu. Bien le hook ne fonctionne pas. J'ai donc fais des recherches.
1- Apparemment, il faut passer par CreateRemoteThread. C'est ce que j'ai fais, mais pareil, le hook ne se lance pas.
2- 2eme test: Passer par CreateProcess en debuggant l'exécutable à lancer. Au 1er breakpoint, les DLL systemes sont chargées, donc normalement CreateRemoteThread devrait fonctionner, mais non ... Ca ne charge pas la DLL injectée. (WaitForSingleObject me retourne un TimeOut).

Donc comment faut-il s'y prendre pour injecter une DLL dans un processus lancé par createProcess en mode suspendu ?

Merci.

Vincent

Là, on retombe sur mes remarques initiales.
Hooking dans un process qui n'est pas celui de l'appelant, c'est un hook global donc la fonction doit être dans une dll.

Voici un article précis sur le hooking et l'injection de thread (à ne pas mélanger).

http://www.codeguru.com/Cpp/W-P/syst...icle.php/c5767

Le fait de d'installer un hook système (threadId = NULL) met automatiquement la dll de la fonction dans la liste des dll à charger au démarage d'une application(AppInit_DLLs).
C'est même le principe d'un Hack sous Win95 qui n'a pas cette clé de registre.
http://support.microsoft.com/kb/134655/fr

Donc pourquoi vous embêter avec "createProcess en mode suspendu" et autres "CreateRemoteThread' ?

Si vous suivez correctement la méthode de hooking system de l'article, tout sera totomatique. :aie:

Bonjour Bacelar,

Je vais essayer d'être plus clair dans mes explications.

J'ai lu le très bon article que tu cites plus haut. C'est ce que je fais déjà. Je hook bien un autre process (déjà lancé) et récupère bien les messages. Par contre, comme le process est déjà lancé, je ne peux pas récupérer les messages de la création des champs de la fenêtre principale, vu qu'il est déjà lancé.

Donc, c'est la raison pour laquelle je me suis dit: si je lance le process avec CreateProcess en mode suspendu, je pourrais lancer le hook "avant" la création des champs. Sauf que, bien entendu, ce serait trop facile, ca ne fonctionne pas.

Donc autre solution que j'ai testé: lancer le process en mode debug:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

while(1) { waitfordebugevent(...) if(dEvent.dwDebugEventCode==EXCEPTION_DEBUG_EVENT) { if(dEvent.u.Exception.ExceptionRecord.ExceptionCode==EXCEPTION_BREAKPOINT) { if (firstBreakpoint) injectionDeMaDll (...); // je hook le process } } continuedebugevent (...) }

---

Bien entendu, ca ne fonctionne pas non plus.


Dans l'exemple de l'article, l'auteur récupère le threadID de SetWindowsHookEx via l'API GetWindowThreadProcessId (...).

Code:

---

1 2	g_hHook = SetWindowsHookEx( WH_CALLWNDPROC,(HOOKPROC)HookProc,hDll, GetWindowThreadProcessId(hWnd,NULL) );

---

De mon côté, je ne peux pas car la fenêtre n'est pas encore créée.

Donc la je tourne en rond.

J'espère avoir été le plus clair possible.

Merci encore.

Vincent

On va essayer d'être méthodique.

Votre problème est complètement différent si le programme à espionné est lancé ou s'il doit être lancé par votre application.

Avec un Hook système, votre dll sera automatiquement mappée dans tous les exécutables qui seront lancés.

Bonjour Bacelar,

Oui je comprends le principe. Justement, je ne suis pas intéressé par le mappage de ma DLL dans tous les exécutables qui seront lancés.

Il n'y a que l'exécutable que je veux lancer qui m'importe.

Merci

Vincent.

Pourquoi la méthode suivante ne convient pas ?

-CreateProcess avec le flag CREATE_SUSPENDED.
-Positionnement du Hook (SetWindowsHookEx) sur le thread principale retourné dans les paramètres retournés par CreateProcess
-Faire un ResumeThread sur le thread principale retourné dans les paramètres retournés par CreateProcess

En fait cette methode ne fonctionne pas:

Voila en gros mon code:

L'executable

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

typedef int(WINAPI *DLL_InstallHook)(DWORD threadID); DLL_InstallHook InstallHook; char* exeString = "C:\\hook\monExe.exe"; char* workingDir = "C:\\hook" STARTUPINFO si = {0}; PROCESS_INFORMATION pi = {0}; si.cb = sizeof(STARTUPINFO);   result = CreateProcess(NULL, exeString, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, workingDir, &si, &pi); if(!result) { MessageBox(0, "Erreur CreateProcess", "Error", MB_ICONERROR); return -1; }   HANDLE dllHandle = NULL; dllHandle = LoadLibrary("DllInjectHook.dll");   InstallHook = (DLL_InstallHook)GetProcAddress((HMODULE)dllHandle,"?InstallHook@@YAPAUHHOOK__@@K@Z");   InstallHook ((DWORD)pi.dwThreadId); // on appelle la fonction exportee de la DLL   ResumeThread(pi.hThread);   return 0;   }

---

Code la DLL

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

HHOOK g_hHook; HINSTANCE hInst = NULL;   LRESULT CALLBACK SetHook(int nCode,WPARAM wParam,LPARAM lParam);   BOOL APIENTRY DllMain( HMODULE hModule,DWORD ul_reason_for_call,LPVOID lpReserved) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: hInst = (HINSTANCE)hModule; case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: case DLL_PROCESS_DETACH: break; } return TRUE; }   // Install du hook __declspec(dllexport) HHOOK InstallHook (DWORD threadID=0) {   g_hHook = SetWindowsHookEx(WH_CALLWNDPROC,(HOOKPROC)SetHook,hInst,threadID);   // g_hHook est toujours NULL if (g_hHook == NULL) { // Ici j'ai un code erreur 87 qui correspond à un mauvais paramètre }   return g_hHook; }   // Messages Hook LRESULT CALLBACK SetHook(int nCode,WPARAM wParam,LPARAM lParam) { if (nCode==HC_ACTION) {   } return CallNextHookEx(g_hHook,nCode,wParam,lParam); }

---

Donc la je ne vois pas trop pourquoi ca ne fonctionne pas, à part peut etre que l'exécutable lancé n'a pas encore de DLL chargé en mémoire (user32, kernel32, ...)

Merci encore.

Vincent.

Il y a peut-être une limitation de SetWindowsHookEx sur les thread suspendus. :aie:

En créant un hook système avant la création du process et faire un "UnhookWindowsHookEx" au moment du DllMain de la dll de Hook, quand on détecte que le process parent n'est pas bon, est une solution.

Sinon, il faut se rabattre sur les méthodes plus complexe à base de
"CreateRemoteThread" présentées dans l'article.

Je suis bien d'accord qu'il y a surement une limitation entre un process suspendu et setwindowshookex.

Par contre, j'avais bien testé avec l'API CreateRemoteThread et sa fonctionne bien, ma DLL est chargée par le process lancé. Par contre, j'avais buté pour la suite. C'est à dire comment puis-je récupérer les messages windows de l'autre process sans SetWindowsHookEx. J'ai donc pensé à subclasser (dans le code de la DLL) la procédure Window principale via l'API SetWindowLong en lui passant le paramètre GWL_WNDPROC. Et donc la encore un truc qui ne va pas, comment puis- je connaître le HWND de la fenêtre principale vu que lorsque ma DLL est chargée avec CreateRemoteThread, cette fenêtre n'est pas encore créée. Je tourne encore en rond ...

EDIT: Le hook système global ne prenant que les messages windows de l'appli que j'ai lancé avec createProcess n'est pas con je trouve. Je vais me tester çà. Mais si tu as des idées pour le subclassing, je suis preneur :)

Encore merci.
Vincent.

Normalement, le DllMain de votre dll de hooking est appelé à la création de chacun des threads du nouvel exécutable.
Profitez-en pour positionner votre fonction de hooking dans chacun d'eux.
S'il passe dans le DllMain, le thread ne devrait pas être suspendu. :aie:

Si cela ne marche pas, il faut se tourner vers l'API Hooking, voici une vue générale, mais c'est encore plus compliqué pour certaines méthodes.
http://www.codeproject.com/KB/system/hooksys.aspx

Bonjour,

Tout d'abord, merci Bacelar pour tes conseils, mon hook fonctionne de manière correcte.

Mais Me revoila pour une question au sujet de l'interception des clics sur bouton.

Je reçois bien les messages lorsque j'entre / sors d'un champ de saisie, lorsque j'ai le focus, lorsque la fenêtre bouge, etc .... Mais pas le clic souris sur un bouton.

Voici ma procédure de callback (WH_CALLWNDPROC):

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

static LRESULT CALLBACK WndProcCallback(int code, WPARAM wparam, LPARAM lparam) { if (code >= 0) { CWPSTRUCT* myStruct = (CWPSTRUCT*)lparam; if (myStruct->message == WM_COMMAND) { if (HIWORD(myStruct->wparam) == BN_CLICKED) { // Je ne passe jamais ICI !! } } return CallNextHookEx(hookCallWndProc, code, wparam, lparam); }

---

Je ne passe jamais dans le message BN_CLICKED quand je clic sur un bouton. Mais, car il y a un mais, lorsque le process à hooker affiche une messagebox, je recois bien le message du clic sur le bouton de la messagebox, donc je passe dans le cas BN_CLICKED.

Donc pour recapituler:
- Aucun message reçu lorsque c'est un bouton de la fenêtre du process
- Message reçu lorsque le bouton "OK" d'une messagebox est cliquée.

Donc la j'avoue que je ne comprend pas trop pourquoi.
Très bonne journée.
Merci.
Vincent.

Ma réponse ne se base que sur des hypothèses qu'il faudrait vérifier. :aie:

Le message "WM_COMMAND" n'est pas généré par le système de fenêtrage de Windows.
Ce système génère un "WM_LBUTTONUP" qui est envoyé à la routine de fenêtre du bouton. La routine de fenêtre par défaut du bouton poste le message WM_COMMAND au parent de celui-ci.

Maintenant, prenons l'hypothèse que ce n'est pas la routine par défaut du bouton mais une autre, comme la routine de fenêtre MFC, qui est appelée.
Pour rappel, la routine de fenêtre des MFC permet de mettre ne oeuvre le modèle Document/Vue des MFC en routant les commandes depuis les Vues vers les Documents, entre autres choses.
Cette routine, comme celle des MFC, n'est pas obligé de poster un WM_COMMAND avec BN_CLICKED. Dans le cas des MFC, elle route la commande dans un dédale d'objets qui implémente un modèle bien plus complexe qu'une hiérarchie de fenêtre, rendant inutile voir dangereux l'envoyé d'un message WM_COMMAND.

Votre application espionnée peu utiliser les MFC ou tout autre framework graphique du même acabit.
Si vous voulez être prévenu quelque soit le framework graphique, il faut prendre un message bien plus en amont. Gérez le "WM_LBUTTONUP" par exemple.

P.S. : désolé pour le retard mais les vacances sont passées par là. :aie::oops:

Salut Bacelar,

J'espère que les vacances se sont bien passées.
Sinon, j'ai suivi ton conseil en passant par un check du message WM_LBUTTONUP. A chaque fois que je clic, je récupère le nom de la classe grâce à l'API GetClassName. Ainsi, si je trouve que c'est un bouton, je fais une action spécifique.
Encore une fois, merci pour ton aide qui m'est vraiment précieuse.
Vincent.