Discussion :

[Omegnight]

Hello les gens,

Je me faisais une réflexion et me demandait si c'était possible de faire interagir une application vers une autre (unidirectionnel, donc) en appelant ses méthodes, d'une manière ou une autre.

Pour illustrer on aurait donc deux applications différentes A et B. A est développée et posséderait plusieurs méthodes publiques qu'on connait:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
class A {
    public void afficherMessage1() {
        [...]
    }

    public void afficherMessage2() {
        [...]
    }

    [...]
}

Ensuite, on développe une application B, aucun lien au niveau du code, ce sont bien deux entités différentes, pas forcément dans le même langage, et on souhaite faire une méthode qui appelle une des méthodes de l'application A.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
class B {
    public void interagir() {
        //Déclaration, ou autre chose qui marcherait, de A.
        //C'est juste pour montrer
        A.afficherMessage1();
    }

    [...]
}

Voilà, on a ça. Maintenant, disons que l'application A est entrain de tourner et on lance l'application B et on appelle B.

Qu'est ce qu'il faudrait faire concrètement, pour que l'application B puisse appeler avec succès la méthode de l'application A lorsque celle-ci tourne? J'imagine qu'il y a déjà eu des réflexion là dessus, mais je ne sais pas vraiment comment ça s'appelle..

Je sais qu'il existe des bibliothèques tierce qui permettent de simuler des clics eu autres à certains endroit d'une application et tout ça, mais ce n'est pas spécialement ce qui m'intéresse. Là je recherche vraiment quelque chose qui travaille au niveau du code.

Merci.

[Médinoc]

Pour commencer, il faudrait avoir accès aux infos de débogage de l'application pour avoir accès aux noms de fonctions et à l'emplacement des différentes variables.
Ensuite, en ayant les droits sur le processus (ce qui est facile si les deux appartiennent au même utilisateur):

• y injecter une des allocation mémoire pour les entrées/sorties (VirtualAllocEx()+ReadProcessMemory()+WriteProcessMemory()),
• y injecter le code voulu, le plus facile étant sous forme d'une DLL (CreateRemoteThread() sur LoadLibrary() avec le chemin dans la mémoire allouée ci-avant, en espérant qu'il n'y ait pas d'autres obstacles dus à l'Address Space Layout Randomization (ASLR) qui est faite exprès pour contrer cela; mais contournable en examinant le process avec Module32First())
• Trouver à quelle adresse la DLL a été injectée (Module32First())
• Appeler la fonction servant de "charge utile" à la DLL injectée

Ça, c'était la partie simple.

Ce que la fonction doit faire est plus compliqué: Elle doit se servir des infos de débogage pour trouver les addresses de l'objet voulu de la classe A, et de sa méthode afficherMessage1(), avant de faire l'appel, puis placer les retours éventuels dans une zone mémoire à laquelle le processus appelant peut accéder (soit via le procédé ci-dessus, soit via n'importe quelle autre méthode de communication inter-processus).

[Médinoc]

Après, si tu acceptes une application A faite pour être pilotée à distance au lieu d'une application quelconque, c'est beaucoup plus facile. Avec les bibliothèques et plate-formes qui vont bien (.Net Remoting, Distributed Component Object Model, Windows Communication Foundation) on peut créer des classes et interfaces faites pour l'appel de procédure distant, que l'application A "enregistre" lors de son lancement. L'application B peut alors se connecter aux objets de cette classe (généralement soit la classe a un objet unique, soit elle expose le moyen de créer des objets en s'y connectant) via les interfaces, et appeler les méthodes voulus; l'architecture sous-jacente se chargera de sérialiser les paramètres, les transmettre d'un processus à l'autre, les désérialiser, appeler la méthode et faire le procédé inverse pour les retours de la fonction.

[Omegnight]

D'accord, c'est donc possible pour, on va dire, "n'importe quel" programme, mais le mieux reste quand même d'avoir une application qui intègre un système pensé pour effectuer ce genre de choses.

Mais sans toucher au code de l'application A, ça m'a l'air plutôt compliqué quand même comme méthode de fonctionnement, après si c'était si simple j'imagine qu'on serait vite exposé à des failles comme une application néfaste qui manipule les autres programmes courants/habituels un peu à sa guise pour semer le chaos sur nos ordinateurs ou récolter des données (les mots de passe enregistrés des navigateurs, par exemple) en toute discrétion.

[Médinoc]

Beaucoup d'applications Microsoft sont programmés selon les normes DCOM (depuis remplacé en grande partie par .Net, mais comme il existe des "ponts" entre les deux...)

Microsoft Office, notamment: Cela permet à un programme de "piloter" Word, ou de créer des extensions pour Word. C'est également la même technologie (sous le nom "Objet Linking and Embedding") qui permet de mettre par exemple une feuille Excel dans un document Word.

Internet Explorer est également pilotable, et permet d'héberger un mini-IE dans un programme!