Discussion :

[ilimo]

c++

bonjour,

comment trouver l'adresse mémoire d'un dll chargé en mémoire( dont on connait le nom)

merci pour votre aide

[hegros]

Tout ce que tu pourras obtenir est une adresse virtuelle qui doit varier d'un programme à un autre...

Hors si tu ne charges pas la dll dans ton programme il ne me paraît pas possible d'obtenir une telle adresse.

Que souhaites-tu faire exactement ?
Quel est ton système d'exploitation ?

Si tu connais le nom de la dll il suffirait de la charger ainsi tu aurais un objet qui ferait référence à cette dll...

[ilimo]

1- OS : windows xp pro
2- un programm XY charge une dll et remplit des cases mémoires des données relatives à cette dll
3- je voudrais avoir acces à ses données
4- à chaque fois qu'il est lancé, cette dll sera chargée à une place differente
5- mais je peux calculer les offsets des données à partir de cette dll
6- ce qui veut dire qu'il me suffit simplement de trouver l'emplacement de cette dll à chaque chargement
7- ayant les offsets, je pourrais avoir acces aux données

disons theoriquement

mais en programmation ??
:

[hegros]

C'est pas aussi évident. Il te faut déja avoir un droit en lecture dans l'espace des dits données.

Ce qu'on sait c'est que les dll sont toujours chargées dans la même plage d'adresse ( Ox??? à 0x???)

On sait lire ensuite avec ReadProcessMemory...Quand à faire ce que tu veux faire..

[Aurelien.Regat-Barrel]

LoadLibrary te renvoi l'adresse de la dll chargée. Si elle est déjà chargée, GetModuleHandle te permet de la retrouver à partir de son nom.
Tout ça c'est pour ton propre process.
Pour un autre process ça se complique, car chaque process possède son propre espace d'adressage. Mais pourquoi as-tu besoin de patcher un autre process ?

[hegros]

D'après ce que je comprends il ne pourrait pas faire un LoadLibrary puisque l'adresse qu'il récuperera sera propre à son process et donc il y a de forte chance qu'elle différe du process cible...

Il me semble avoir lu un article qui parlait de hooker certaines fonctions.Pourquoi ne pas hooker le LoadLibrary qu'effectue le processus cible ?

[Aurelien.Regat-Barrel]

Même si l'adresse est la même que le process cible, elle n'est valide que pour ton process. Tous les process ont l'adresse 0x40000, mais chaque case mémoire 0x40000 de chaque process est (généralement) différente.

[ilimo]

à chaque chose il y a une raison

1- imaginez les programmes A et B
2- A charge une dll
3- cette dll est propre à A
4- aucun autre programme ne s'en sert
5- cette dll met des données dans des cases mémoires

6- B connaît le nom de cette dll
7- B voudrais trouver l'adresse mémoire de cette dll où elle est chargée

8- car B connaît les adresses mémoires des données de cette dll
9- ainsi, B pourra trouver les offsets de ces données
10- les offsets trouvés, A ne pourra plus cacher ses données
11- ainsi je pourrai changer les données sans passer par A

mais tout ceci n'est réalisable que si j'ai l'adresse mémoire de cette dll

[Neitsa]

Bonjour,

C'est relativement simple. Il suffit de faire un snapshot des processus [ CreateToolhelp32Snapshot() ], de traverser cette liste [ Process32First() et Process32Next() ].

Pour chaque processus on traversera la liste de ses modules avec Module32First() et Module32Next().

La structure MODULEENTRY32 (utilisé par Module32xxxx) comprend notamment le nom de la DLL et son ImageBase (adresse où elle chargé dans le contexte du processus).

Il suffira de comparer le nom de la DLL recherchée avec celui retourné dans la structure précitée.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/perfmon/base/createtoolhelp32snapshot.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/perfmon/base/taking_a_snapshot_and_viewing_processes.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/perfmon/base/traversing_the_module_list.asp

[Aurelien.Regat-Barrel]

Une adresse n'a de signification que pour un process. Si B récupère l'adresse de la dll chargée par A, et qu'il écrit à cette adresse, il écrira dans la mémoire de B, et non de A. Sinon n'importe quel programme pourrait écrire n'importe où, et y'aurait aucune sécurité.
Pour une même adresse X, le programme A a sa propre case mémoire, et B la sienne, qui est différente.

[Neitsa]

Bonsoir,

Une adresse n'a de signification que pour un process.

Je suis tout à fait d'accord Aurélien, chaque processus a son propre espace d'adressage, c'est la base, notamment, d'un minimum de sécurité au cas où un processus "crasherait".

Si B récupère l'adresse de la dll chargée par A, et qu'il écrit à cette adresse, il écrira dans la mémoire de B, et non de A.

Toutefois il ne faut pas oublier que Windows propose des mécanismes d'écriture / lecture / injection sur d'autre processus ou threads, avec des APIs comme Read/WriteProcessMemory ou encore CreateRemoteThread, etc.

Je reste néanmoins circonspect quant à la méthode utilisée par ilimo. J'aurais choisi de passer par une boucle de débugging ce qui permet de pouvoir contrôler le processus débuggé et d'en avoir une plus grande maîtrise (breakpoint matériel sur les endrois recherchés, alerte lorsque les variables changent, arrêt / gèle du processus, etc.)

[Aurelien.Regat-Barrel]

Je me doute parfaitement que tu savais tout cela, ma réponse s'adressait à ilimo qui ne semble pas en être conscient.

[Médinoc]

Hump... Je dois avoir quelques fonctions utiles: Un programme qui cherche où se trouve la fonction ExitProcess() dans un autre processus en mémoire.

La seule condition est que les deux processus doivent utiliser la même version de la DLL concernée (ici, kernel32.dll).

http://www.isty-info.uvsq.fr/~fbenoit/Programmation/Killer.zip