Discussion :

[benoit70]

J'ai 2 dlls qui ataquent une troisième dll.
Comment savoir dans le code de la 3ème dll(au sein d'une méthode appellé par une des 2 premieres) quelle est la dll qui appelle la méthode?
Merci

[benoit70]

Merci de m'aider les gars, j'ai vraiment besoin de cette infos pour mes developpements

[BertrandA]

Je ne comprends pas pourquoi tu as besoin de cette information dans ta DLL.
Néanmoins, est-ce que c'est difficile de passer un paramètre à la fameuse méthode qui doit connaître l'appelant : un enum ou un identifiant quelconque, même un handle... ?

[benoit70]

justement c'est pour ne pas rompre l'interface.

[farscape]

salut,
pourquoi pas une variable d'environnement alors ,réglée avant l'appel et lue dans la dll pour savoir qui appel.

[benoit70]

le probleme est que je ne peux pas changer le code des 2 dlls ni de l'interface.
Je dois tout connaitre depuis la 3 ème dll.
Est-ce possible???

[farscape]

ben alors je ne pense pas que ça soit possible ...

[benoit70]

comment le debugger fait il alors?

[farscape]

et bien il est deja en debug donc il genere les informations necessaires pour debugger ....

[moldavi]

Quand tu débugges, tu as bien la pile des appels non?

[sapphire]

En dernier recours essaie de mettre la main sur vtune d'intel.

[benoit70]

En fait mon code doit savoir quelle dll est l'objet d'un appel de methode.
Ex. : Si je suis dans la fonction MyFunction de dll3, je veux savoir quell dll a appellé MyFunction, sachant que Mynfunction peut etre appellée par plusieurs clients.

MyFunction
{

Who had called me?? dll1 or dll2??
}
Je ne peux rien changer aux interfaces, sinon j'aurais transmis un paramètre.

C'est quoi le vtune d'intel??

[sapphire]

c'est un debugger capable de cartographier sous forme de graphe l'exécution d'un binaire et de ses dll. normalement on utilise ca pour detecter quelles fonctions dans un prog consomme le plus de ressources pour trouver des optimisations. Moi jmen sers essentiellement pour comprendre comment fonctionne un soft.

Soft commercial par contre..

Ce que tu cherches a faire j'ai cherché la meme chose ces dernier temps, et pas trouvé.. dsl.

[Neitsa]

Bonjour,

C'est techniquement possible bien qu'un peu compliqué...

Lors d'un appel à une fonction l'adresse de retour est mise sur la pile (stack), ainsi lors de la sortie de cette fonction le programme sait où retourner (donc vers la fonction appelante).

l'initialisation d'une fonction se fait quasiment toujours par (en Asm) :

Code :

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

1
2
3
 
PUSH EBP // pousse le pointeur de base (EBP)
MOV EBP,ESP // met le pointeur de pile (ESP : stack pointer) dans le pointeur de base

Ainsi quand vous entrez dans la fonction vous pouvez retrouver quelle est l'adresse de la fonction appelante en 'fouinant' sur la pile. Cela requiert un peu d'asm inline, a mettre impérativement au debut de la fonction dans la DLL n°3 :

Code :

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

1
2
3
4
5
6
 
DWORD lpAdresseRetour ;
__asm{
mov eax, dword ptr [ebp+4]
mov lpAdresseRetour,eax
}

lpAddressRetour contient à ce moment là l'adresse de retour de la fonction appelante.

Maintenant, comment savoir quel est la DLL ?

Lorsqu'un processus se crée, les DLL sont 'mappées' (c'est le terme technique) dans son espace d'adresse. La plupart du temps (95%) un exécutable se loge en 0x400000 en mémoire. Les DLL linkées statiquement ou apelée dynamiquement se loge plus loin dans l'espace d'adressage du processus.

L'adresse de base d'une DLL (le début de son mapping donc) s'obtient aisément avec l'API win32 GetmoduleHandle, en passant comme argument le nom de la DLL.

Une petite vue de l'espace d'adressage d'un processus (toutes les adresses sont des exemples) :

Code :

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

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
45
 
0x400000 Monexécutable.exe
- PE header
- section code
- import
- section données
- ressources
[etc.]
0x450000 fin de l'exe (exemple)
 
...
 
0x10000000 DLL n°1
- PE header
- section code
- import
- export
- section données
- ressources
[etc.]
0x1050000 fin de DLL 1 (exemple)
 
...
 
0x1200000 DLL n°2
- PE header
- section code
- section données
-import
-export
- ressources
[etc.]
0x12500000 fin de DLL n°2 (exemple)
 
0x13000000 DLL n°3
- PE header
- section code
- import
- export
- section données
- ressources
[etc.]
0x13000000 fin de DLL n°3 (exemple)
 
...

En résumer pour trouver la DLL de la fonction appelante :

1) Obtenez l'adresse lpAdresseRetour
2) Faites un GetModuleHandle sur vos trois DLL
3) comparez l'adresse de lpAdressRetour avec les adresse de base de mapping obtenu avec 2)

Exemple :

lpAdresseRetour = 0x12300000
DLL 1 : 0x10000000
DLL 2 : 0x12000000
DLL 3 : 0x13000000

lpAdressRetour est plus haut que DLL1 mais aussi plus haut que DLL2 (ca n'est donc pas DLL 1). C'est donc DLL2 qui apelle DLL3

Notez que les DLL ne se mappent pas forcément dans l'ordre 1 puis 2 puis 3, c'est pourquoi il faut récupérer les bases des 3 DLLs et faire toutes les comparaisons nécessaires

Notez finalement que ceci fonctionne pour les procédures d'appel standard type __stdcall (pour la DLL n°3), cela devient plus difficle avec d'autres convention d'appel (nécessite un débugage de la fonction...).

J'espère n'avoir pas été trop ennuyeux avec ces explications...

[Aurelien.Regat-Barrel]

On pourrait pousser le vice plus loin en listant les modules du process via EnumProcessModules et en déduire celui qui appelle la fonction, mais bon je m'interroge quand même sur un tel besoin. Techniquement c'est sympa, mais c'est très bancal malgré tout. Au moindre changement de nom dans une autre dll / utilisation depuis une 4° dll tout se casse la gueule.
Sous VC++ >= 7, attention au cookie qui est pushé en plus avec l'option /GS. Cela dit je ne crois pas que cela affecte (la brillante) explication de Neitsa.

[Neitsa]

Effectivement la solution par EnumProcessModules est envisageable aussi.

Comme le souligne Aurélien, cette solution reste très tirée par les cheveux puisque l'on touche plus au Reverse Engineering qu'à la programmation en tant que telle dès qu'on ne peut passer un argument supplémentaire à la fonction... Donc toute modification du nombre de DLL, ou des paramètres de fonction entrainera un gros plantage de l'appli

J'oublais de souligner (c'est le cookie de sécurité dont Aurélien parlait qui m'y fait penser...) que le +4 dans l'asm inline ne vaut que pour un seul parmamètre passé en argument à la fonction. Il faudra ajouter 4 à chaque parmamètre passé en sus.

en admettant que la fonction de la DLL n°3 prenne 5 paramètres :

Code :

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

1
2
3
4
5
6
 
DWORD lpAdresseRetour ;
__asm{
mov eax, dword ptr [ebp+4*5]
mov lpAdresseRetour,eax
}

En effet la pile se comporte ainsi lors de son init. :

- params de fonctions
- adresse de retour <= ce qu'on cherche
- pointeur de frame
- cookie de sécu.
- handler d'exception
- etc...

Donc plus il y a de paramètres plus il faudra aller chercher loin...
(le cookie étant situé après il est donc négligeable dans la recherche de l'adresse de retour)