Discussion :

[acx01b]

Bonjour !

on parle souvent de l'injection de DLL dans un process mais sous la forme d'un thread indépendant (qui en gros exécute le code qu'on a écrit dans notre langage préféré et qu'on a mis dans une DLL). Sauf que perso je ne vois pas bien l'intérêt, souvent le reverse engineering et notre gentil debugger nous a permis de trouver LA FONCTION dans le programme cible qui prend en argument THE STRUCTURE ou THE OBJET qui contient ... ben ce qu'on veut récupérer/modifier...


Ma méthode pour récupérer cette donnée d'intérêt est un peu "hardcore" et difficilement applicable à grande échelle :
- j'ouvre HexEdit.
- Je trouve un endroit où mettre 2 (int) variables globales dans le programme cible + 16 octets d'instructions langage machine
- au début de la fonction d'intéret (après push ebp; mov ebp,esp) je mets un jmp vers la zone libre que j'ai trouvée. Je mets le code (compilé) pour ouvrir ma dll :

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
 
// fonction cible
push ebp
mov ebp,esp
// des instructions remplacées par :
jmp adress1
 
// mon code
adress1:
 
if (!var1) {
var1 = loadlibrary("ma_dll.dll");
if (var1) var2 = getprocaddress(var1,"ma_fonction");
}
if(var2) push [ebp+8]; call var2; // [ebp+8] car ce qui m'intéresse c'est de récupérer l'argument 1 de la fonction cible
ICI JE RECOPIE LES INSTRUCTIONS EFFACEES PAR MON jmp adress1
jmp retour_a_la_fonction_du_programme_cible_comme_si_de_rien_netait

- bien sûr j'ai recalculé tous les jmp et call et les références à mes deux variables gloables var1 et var2 pour que tout fonctionne
- petit détail : la plupart des programmes sont liés avec user32.dll, et loadlibrary et getprocaddress ont déjà une adresse dans la mémoire de l'exécutable, il suffit de les utiliser

J'ai vu qu'il existait une fonction VirtualAllocEx. Je pourrais mettre mon code dans un espace réservé avec VirtualAllocEx ?

Donc Je fais un programme qui exécute le programme cible. Je fais un appel de VirtualAllocEx, y mets le code pour exécuter loadlibrary+getprocadresss+call et mes 2 variables globales, modifie le code de la cible en y mettant un jmp vers ma zone allouée avec VirtualAllorxEx, et attends que la cible passe par ce jmp (moins de 3ms a priori) ?

Je n'ai pas trouvé d'exemple clair à ce sujet

Pour ceux que ça intéresse : en général on n'attaque le .exe de la cible, mais une des dll qu'il utilise. L'avantage c'est que les dll contiennent des noms de fonctions qui nous renseignent beaucoup sur l'activité du programme, et ces noms permettent souvent de repérer une fonction qui prend en argument quelque chose d'intéressant

[edfed]

ça ressemble plus à de la programmation windows que de l'assembleur, mais je peu peut etre t'indiquer des indices.

les dll sont des fichiers, nous sommes d'accords, que le système charge lorsqu'il rencontre une reference nommée import dans le code applicatif. l'import consiste en un nom de fonction, un nom de fichier (.dll) et une adresse RVA de chargement supposé de la fonction.
le problème avec RVA, c'est que seul le système sait comment les utiliser, ce sont des adresses virtuelles.

cette dll peut evidement être copiée, vu que c'est un fichier, en tant que fichier, dans une zone de mémoire, mais il faut être en mesure d'aller lire les octets issus de cette zone, afin de les copier dans une autre zone.


le problème avec windows, c'est que c'est un système avec des protections.
il interdit par exemple, l'execution de code issu de zones de données (même si ça reste possible) c'est fortement deconseillé, c'est d'ailleur un des indices utilisés par les antivirus et detecteurs de malwares.

il permet la création de zones de code, mais uniquement sous forme de thread justement.
ce qui rend assez ardu ton problème qui est:

self modifiable code sous windows.

donc, l'indice principal, que tu devrais googeuliser c'est:

self modifiable code win32.

je pense que tu trouveras ton bonheur sur le forum de fasm, section windows programing.

j'ai déjà vu des astuces permettant de faire ce que tu cherches à faire.

l'idéal, ça serait d'expliquer la raison qui te pousse à vouloir copier le code d'une DLL dans une zone allouée dynamiquement. est ce pour faire un logiciel anti reverse? ou pour faire un programme de hack? dans les deux cas, la demarche est contraire au code libre, mais est acceptable, car ça fait avancer la technique.

donc, n'hesites pas à poster le resultat de tes recherches.

voici le lien vers le forum qui devrait t'aider.

http://board.flatassembler.net/forum.php?f=3

désolé, c'est en anglais, sur un site polonais, hebergé en suède...

[acx01b]

ok merci pour les références !

je l'ai mis dans la section assembleur car il y est question justement de .text, .data ...

je tiens à préciser que la méthode "éditer le .exe/.dll à la main" je l'ai pratiqué déjà 3/4 fois, l'ennui c'est qu'il faut chercher soit même, à la main (dans IDA disassembler) des zones de .text (code)/.data (variables globales) libres et ensuite ne pas se planter avec les adresses des jmp et des call

je cherche donc à automatiser la démarche. Je pense que je vais plus simplement faire un petit programme qui prend en argument :
- le .exe/.dll
- le numéro d'octet du début de la fonction à "hacker"
- l'adresse dans la mémoire du process de loadlibrary (et getprocaddress, je n'aime pas la fonction dllMain je préfère appeler ma petite fonction à moi, qui prend les arguments que je veux)
- l'adresse du bout de .data libre
- et l'adresse du bout de .text libre

évidemment on modifie le .exe/.dll et donc le checksum ce qui rend facile pour un antivirus de me repérer, mais ce n'est pas le problème

une application courante de ce que je décris (et ce qui m'intéresse) ce sont les programmes pour tricher dans les jeux : on récupère la position des persos, et on fait un wall hack, un autoaim, un détecteur de danger, etc ...

En fait on pense souvent au cracking comme le fait d'attaquer le code de la cible, mais dans beaucoup de cas, et les jeux vidéos en font partie, qui sont programmés en C# ou C++ la cible est basée sur une hiérarchie d'objets très structurés, et ce qu'on attaque c'est plutôt la structure de donnée en mémoire. Et dans ce cas, le problème principal c'est : récupérer les pointeurs vers les objets intéressants