Bonjour,

Dans le cadre de mon entreprise, je dois réaliser un logiciel qui va écouter les événements d'un logiciel tiers et réalisera des actions spécifiques suivant le bouton cliqué. (Changer ce qui est envoyé, ne pas envoyer etc.)

J'avais commencé mes recherches par UI Automation (par rapport à ce que pouvais faire avec Spy++ et Inspect) mais mon Directeur Technique m'a dit qu'il y avait des moments où ça ne marchera pas à tous les coups.

Et Hier j'ai appris l'existence des Hooks qui me semble plus approprié pour ce que je compte faire. Malheureusement, je pédale dans la semoule.

J'ai recherché sur le forum avant d'ouvrir un sujet. Le sujet qui s'approche le plus de ma question est celui de totalok : https://openclassrooms.com/forum/sujet/c-hook-clavier-et-souris-82184

Là j'essaye donc de faire fonctionner mon hook (en reprennant ses classes car ce sont celles de développez. Sauf le Start() qu'il a changé pour faire géré le KeyBoard et le Mouse).

Actuellement, je charge mon Hook dans le load de mon application (Winform). 

L'objet se crée, mais il me manque :

- Lui dire qu'on écoute l'événément "Clique Souris"

- L'action a réalisé sur cet événement.

(Par la suite je voudrais focaliser sur un Thread Spécifique, et récupérer le contrôleur se trouvant au coordonnée du curseur lorsque la personne a cliqué).

Voilà ce que j'ai actuellement (pompé du sujet linké au-dessus)

        MouseControler m_MouseHook = new MouseControler();
        public Form1()
        {
            InitializeComponent();
        }

        private void Form1_Load(object sender, EventArgs e)
        {
            m_MouseHook.LocalHook.OnMouseClick += OnMouseClicked;
            m_MouseHook.LocalHook.Start();
        }

        private void Form1_FormClosing(object sender, FormClosingEventArgs e)
        {
            m_MouseHook.LocalHook.Stop();
        }

Le OnmouseClicked n'existe pas dans ma solution car je ne l'ai pas créé et elle n'existe pas dans les classes de Totalok donc je suppose que c'est quelque chose spécifique à son code. Je voudrai reproduire sa démarche. En mettant mes propres actions.

Des idées pour m'orienter dans la manoeuvre ? Ou du moins pour récupérer tous les cliques fait en global ?

Merci,

Bonne journée

Hello,

On va commencer par se mettre d'accord sur un point. C'est quand même bien dégueulasse comme méthode. Faire ce genre de trucs en production c'est ouvrir la porte à une tripotée de bugs et de mauvais fonctionnements, galères à debug qui plus est, pour un débutant en plus c'est une belle façon de lui dire "Démerde toi Loulou !".  
Donc, comme ce forum est rempli de gars sadique mais sympa, on va te dire de trouver une autre solution, une API, un WebService, fouiller la base de données derrière ton programme, les fichiers qu'elle écrit, etc. Mais non, personne ne va te conseiller d'attraper les événements d'un autre programme à la volée.

Ce que tu veux, c'est pas vraiment un hook, un hook va te permettre de choper l'événement souris/clavier mais pas exactement ce qu'il se passe derrière comme tu t'en es rendu compte. À ta place, si j'avais envie de m'asseoir sur les genoux de Satan pour Noël, je me tournerai plutôt vers l'injection de DLL pour essayer de faire tout ça.

Bon gros courage !

Hey !

Je pensais qu'avec le Hook on pourrait chopper le bouton cibler par le clique et donc si je connais le bouton je sais ce je dois envoyer (si c'est le bon bouton).

Mon Directeur m'a parlé des API Windows. Je me trompe surêment mais le Hook n'a pas de rapport avec l'API windows ?  Je ne connais rien à ce domaine. Et j'ai regardé les cours sur OCR mais ce n'est pas ce que je cherche. 

Mais via SetWindowsHookEx, le logiciel n'injecte-t-il pas le DLL ?

Pour injecter un DLL, n'ai-je pas besoin d'avoir accès à la machine de l'utilisateur ? 

Imagine simplement une caisse enregistreuse, la caissière appuyant sur le bouton "espèces". Mon but est de savoir quand elle appuie sur ce bouton.

Merci pour ta réponse en tout cas.

Hello,

Si tu peux injecter des DLL via SetWindowsHookEx mais dans l'exemple du dessus il s'en sert pour injecter une dll de Windows et pouvoir détourner les appels Clavier/Souris avant de les rediriger au bon endroit. Ce qu'il capture ce sont les touches, les clics, pas la destination.

En gros lui capture le clic entre la souris et le bouton. Toi tu veux le capturer entre le bouton et la méthode derrière le bouton et ça c'est un peu plus chiant.

Pour injecter une DLL proprement il te faut évidemment accès à la machine et sûrement les droits d'admin je pense.

>mais mon Directeur Technique m'a dit qu'il y avait des moments où ça ne marchera pas à tous les coups.

Vous pouvez être plus précis ?

Car, il me semble que votre cas est assez borné, et que si cela fonctionne une fois, cela fonctionnera tout le temps, jusqu'à la prochaine refonte complète de l'application à espionner, non ?

> Hook on pourrait chopper le bouton cibler

Non, mais vous avez accès aux coordonnées écran du pointeur de souris.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms633558(v=vs.85).aspx

Mais bon, comme le dit @Pyrobolser, ça engendre des cas à la con (fenêtre cachée, pas de fenêtre si IHM directement en DirectX ou en WPF, etc...).

Spy++ utilise de Dll Injection, alors, si votre CTO dit que ça marche pas tout le temps, les Dll Injection non-plus.

>Mon Directeur m'a parlé des API Windows.

Lesquelles ? Il y a plusieurs dizaines d'API Windows et plusieurs dizaines de milliers de fonctions associées.

>Je me trompe surêment mais le Hook n'a pas de rapport avec l'API windows ?

Si, comme une dizaines d'autre API : GDI, ODBC, Kernel32, les drivers WDM, DirectX, etc...

>Mon but est de savoir quand elle appuie sur ce bouton.

Heu, et pourquoi pas un simple mouchard en hardware ?

ça ne marchait pas suivant le langage. Il n'y avait pas d'AutomationID est je me basé là dessus pour chopper le bouton. Donc pas d'AutomationID = pas de bouton même si il est visible.

Pour le hook qui récupère le bouton je pensais en effet à utiliser la position de la souris. 

Il ne m'a pas parlé précisément des API que je devais utiliser ! C'est pour ça que je fais mes recherches de mon côté (et là je viens de tomber sur EnumWindows)

Le mouchard en Hardware ne pourra pas envoyer le code que l'on souhaite une fois qu'elle a appuyé sur le bouton (?) Sauf si tu connais un logiciel capable de ça. Mais je n'en ai pas trouvé.

PS: Merci pour ta réponse, elle va quand même me servir

-
Edité par Ezazhel 13 octobre 2017 à 9:13:31

>ça ne marchait pas suivant le langage.

AutomationID, c'est pas un problème de langage, c'est un problème de librairie graphiques utilisé et de rigueur dans son utilisation.

Votre applicatif à espionner, c'est pas un serveur de la NSA, donc, vérifiez si cette technologie est utilisable avec.

Si oui, utilisez là. Sinon, faut utiliser une technologie compatible avec l'applicatif à espionner.

Utilisez une méthode compatible avec le logiciel à espionner.

Pas besoin de faire une bombe atomique pour écraser une mouche.

>Il ne m'a pas parlé précisément des API que je devais utiliser !

Contre quoi doit-on se prémunir ???

>(et là je viens de tomber sur EnumWindows)

Super, en sachant que des technologies comme DirectX ou WPF n'utilisent pas les fenêtres de l'OS, c'est aussi casse-gueule qu'AutomationID.

>Le mouchard en Hardware ne pourra pas envoyer le code que l'on souhaite

Quel code ?

Un mouchard peut contenir le code que l'on veut.

Vous voulez interagir avec l'applicatif ?

Oulah... 17 jours sont passé et j'ai été pris par les cours...

Alors pour répondre à Bacelar :
On peut oublier pour le moment la parti "code à envoyer". 

Finalement je ne passe pas non plus par EnumWindows mais par Windows Informations. Il me renvoie une liste d'informations concernant les fenêtres ouvertes ou seulement celle que je décide d'inspecter en passant son nom en paramètre.

Du coup j'obtiens en filtrant la liste des contrôleurs de type : Button.

Mon réel problème c'est de savoir comment réaliser une écoute sur ce bouton spécifique. Enfaite non ce n'est pas vraiment mon problème (en sélectionnant l'item dans ma ListeBox il me suffit de faire un bouton me permettant de mettre en écoute celui là.), sans passer par un hook comment puis-je écouter les événements émis par le bouton de l'application tierce ? 

Merci

Oulah ! A  nouveau une semaine... Désolé ! 

Ce sont des applications marchandes (gestion de caisse enregistreuse type Carrefour / Auchan etc).

J'ai oublié de mettre mon problème en résolu ! 

Finalement, je récupère toutes les fenêtres ouvertes sur l'ordinateur. Via une classe WindowInformation. Je récupère seulement les applications ayant des boutons ou des textbox, je les ajoute à une ListBox.

Je liste dans une autre ListBox les controleurs présent dans l'application.

A la suite de quoi, via deux boutons je choisis le bouton qui déclenchera mon événement Clique gauche et le TextBox dont je veux récupérer la valeur. 

ça marche très bien mais mon nouveau problème est de réussir à créer un cadre rouge pour montrer quel bouton on focus sur l'application (car je me retrouve avec des textbox vide et l'utilisateur ne peut pas différencier lequel choisir). 

Mes rectangles restent sur l'affichage et ne s'effacent pas, ce qui porte encore plus à la confusion.

-
Edité par Ezazhel 9 novembre 2017 à 15:59:48

Vous n'êtes pas très claire sur la "solution" que vous proposez.

Et je ne vous toujours pas les cas ou votre technique semble plus fiable que "UI Automation", bien au contraire.

>Ce sont des applications marchandes (gestion de caisse enregistreuse type Carrefour / Auchan etc).

Ça, c'est à quoi ça sert pas comment c'est fait.

Les réponses que j'attends sont plus du type "MFC", une bibliothèque graphique JAVA comme AWT SWIG etc, DirectX, Navigateur Web embarqué, etc...

Si votre application qui utilise "UI Automation" fonctionne avec, pourquoi vous enquiquinez avec une usine à gaz super peu fiable ???

>Via une classe WindowInformation

Ça, c'est OK, mais ça marche que sur du Win32 et les technologies qui l'utilise, donc pas de DirectX, de WPF, de Java SWIG, et bon nombre de Navigateur Web "Moderne", etc...

C'est très très moyen comme truc "fiable".

>Je liste dans une autre ListBox les controleurs présent dans l'application.

C'est quoi les "controleurs" ici ????

> via deux boutons je choisis le bouton qui déclenchera mon événement Clique gauche

Heu, vous ne faites que sélectionner deux handles de fenêtre en fait, non ?

Je croyais que votre application n'avait pas d'API, vu que c'est censé être une application "espion", non ???

>nouveau problème est de réussir à créer un cadre rouge

On retombe sur la problématique du hooking "bas niveau" avec injection de Dll et tout le toutim.

https://stackoverflow.com/questions/8411958/how-to-change-borders-color-of-any-window

Bon, j'ai l'impression que vous avez choisi une "solution" random et que vous lisez le cahier des charges en serrant les fesses pour que ça marchouille jusqu'à la recette.

C'est pas comme ça qu'on trouve une bonne solution de développement.

Faut mettre le cahier des charges à plat (IHM ou pas, technologies "espionables" avec l'outil, etc...

Parce qu'à chaque réponse de votre part, il y a des lapins blancs qui sortent du "chapeau des contraintes orales".

>Mes rectangles restent sur l'affichage et ne s'effacent pas, ce qui porte encore plus à la confusion.

Houais, moi, j'ai l'impression que vous créez des fenêtres par-dessus les fenêtres cibles et que vous ne faites pas le ménage "après".

Montrez un peu le code qui fait le job, SVP.

J'ai trouvé une solution à mon problème : https://stackoverflow.com/questions/47219277/how-to-change-border-property-of-controler-in-other-application/47220812#47220812 

Je n'ai pas de cahier des charges concernant l'application, et je suis débutant dans le domaine. Je ne saurai répondre à vos questions. Du moins, je ne pourrais pas y apporter plus d'informations.

Pour UI Automation, j'ai proposé l'idée à mon CIT qui m'a dit : ça ne marchera pas tout le temps.

Pour les Windows API, je n'en avais jamais entendu parler et je comprend à peine ce que c'est.

Pour l'outil d'espionnage, il me sert en effet à hook et je ne peux l'essayer qu'avec un winform que je crée de mon côté. Je n'ai pas possibilité de le tester sur les logiciels qui sont la cible. Donc je ne me suis pas posé plus de questions sur le : Est-ce que ça ne marchera qu'en Win32 ?

Je n'ai pas réalisé d'injection SQL, et j'utilise la position des contrôleurs sur l'écran principale. J'aurai pu récupéré le handle mais si celui-ci change à cause de l'application qui redémarre ça tombe à l'eau. Et de même avec ma solution passant par la position, si la fenêtre bouge ça ne fonctionnera pas.

Pour le moment je suis arrivé à ce que je voulais faire, je verrais si j'ai de nouvelles contraintes plus tard. 

Désolé de commencer dans ce domaine là. Je n'ai pas 10 ans d'expérience, ou bien 5. Je n'ai pas la même expérience que vous et vous semblez me prendre de haut à cause / grâce à l'expérience que vous avez accumulé. C'est toujours intéressant de se rendre compte que la communauté des développeurs n'est pas aussi accueillante.

Certes je n'ai pas été assez clair car je n'ai pas toutes les réponses à vos questions mais est-ce là une raison pour agir ainsi ? 

Ce que vous présentez de votre CIT a le don de m'énerver.

Ce n'est pas vos questions qui m'énerve, mais votre situation.

Et quand on est énervé, "le scorpion qui pique la grenouille, ... tout ça tout ça".

Votre question sur SO peut induire en erreurs ceux qui y répondent, car vous n'êtes pas très clair sur le fait que les contrôles ne sont pas dans votre application et que l'application à espionner n'est pas obligatoirement développer avec Winform.

Ces 2 assertions sont faites soit dans les réponses soit dans les références données en réponses.

Références très intéressantes au demeurant.

Je ne voudrais pas qu'après avoir dépensé tant de temps et d'énergie pour une solution, vous retrouviez le bec dans l'eau car votre solution ne fonctionne correctement que sur les vieilles technologies (JAVA AWT, MFC, Winforms, VBA, Access) mais très probablement pas sur les "nouvelles" (JAVA SWIG, WPF, DirectX, Cordova, tous les navigateurs Web "modernes", etc...).

>Je n'ai pas possibilité de le tester sur les logiciels qui sont la cible.

Là, vous êtes clairement en train de mettre la charrue avant les bœufs.

Il vous faut au moins les caractéristiques techniques de ces applications. Sinon, vous avez une très très grosse probabilité de vous retrouver avec une solution qui ne fonctionnera pas. Il suffira qu'elles utilisent une technologie d'affichage "moderne" et vous êtes complètement cuit.

Le scope de fonctionnement de votre approche à base de handler de fenêtre du GDI Win32 (pour les technologies "old-school" comme WinForms) n'est pas plus étendu que l'utilisation de l"UI Automation" car elle est utilisable même avec les nouvelles technologies (bien que aussi peu utilisé).

Faudrait vraiment que vous mettiez les points sur les i avec votre CIT, pour qu'il donne des contraintes techniques CLAIRES. A l'impossible nul n'est tenu.

>Je n'ai pas réalisé d'injection SQL,

L'injection d'une Dll dans un processus (nécessaire pour du hooking bas-niveau) n'a rien à voir avec "l'injection SQL", qui est un type d'attaque informatique.

L'injection d'une Dll dans un processus permettant d'exécuter du code dans ce processus, dont les routines de "hooking".

>et j'utilise la position des contrôleurs sur l'écran principale.

OK, vous avez donc pris l'approche du formulaire invisible, qui est très adapté pour l’implémentation d'un Designer graphique. Cadre pour lequel cette solution vous a été proposée. C'est beaucoup moins adapté pour un programme espion qui n'aura aucune garantie d'être "par-dessus les autres" pour de l'interception directe les Input et qui n'aura pas forcement le droit de "capturer" ces Input via le hooking de haut niveau de votre premier post.

> J'aurai pu récupéré le handle

Oui, et, avec cette technique, vous avez toujours besoin d'handles, parce que vous utilisez indirectement que du GDI qui ne fonctionne qu'à base de handle.

>mais si celui-ci change à cause de l'application qui redémarre ça tombe à l'eau.

Oui, c'est pour cela qu'il faut toujours retrouver l'handle au moment de l'évènement et pas le stocker.

> Et de même avec ma solution passant par la position, si la fenêtre bouge ça ne fonctionnera pas.

Oui, ok, mais si vous récupérez le layout des contrôles à chaque "click" vous aurez toujours des valeurs à jour.

C'est pour le rafraichissement de vos listBox que vous avez besoin de ces informations ???

>Pour le moment je suis arrivé à ce que je voulais faire, je verrais si j'ai de nouvelles contraintes plus tard.

Là, vous êtes très loin d'avoir fait du hooking, ni même d'avoir fiabilisé votre solution.

Il faut bien comprendre que dans ce domaine, le moindre changement dans les contraintes peut complètement invalider tout le travail qui a été fait.

Vous appris plein de chose, très bien, mais soyez conscient qu'il est très probable que vous devrait tout reprendre une fois les programme à espionner dans les mains.

N'ayez pas une grande aversion à la perte, votre code a de très grande chance de se retrouver dans la corbeille.