Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fran ois Picalausa
On Sep 27, 1:06 pm, pascal1967 wrote:
Bonjour, Est-il possible, partir d'une dll dont on a perdu les sources, de retrouver les fonctions et leurs param tres ? Merci Pascal
Hello,
Pour les DLL standards, Depends.exe (pr sent dans le platform SDK) pourra afficher correctement (probablement au travers de l'API MapDebugInformation) le nom des fonctions export es. Pour ce qui est de leurs param tres, MapDebugInformation donne aussi des informations sur le d but et la fin de la fonction dans l'image. A partir de cette information, il est possible de r cup rer le code compil correspondant la fonction export e, de le d sassembler... et (op ration non triviale, mais possible) de retrouver les param tres.
Fran ois
On Sep 27, 1:06 pm, pascal1967 <piqu...@2pInformatique.com> wrote:
Bonjour,
Est-il possible, partir d'une dll dont on a perdu les sources, de
retrouver les fonctions et leurs param tres ?
Merci
Pascal
Hello,
Pour les DLL standards, Depends.exe (pr sent dans le platform SDK)
pourra afficher correctement (probablement au travers de l'API
MapDebugInformation) le nom des fonctions export es.
Pour ce qui est de leurs param tres, MapDebugInformation donne aussi
des informations sur le d but et la fin de la fonction dans l'image. A
partir de cette information, il est possible de r cup rer le code
compil correspondant la fonction export e, de le d sassembler... et
(op ration non triviale, mais possible) de retrouver les param tres.
Bonjour, Est-il possible, partir d'une dll dont on a perdu les sources, de retrouver les fonctions et leurs param tres ? Merci Pascal
Hello,
Pour les DLL standards, Depends.exe (pr sent dans le platform SDK) pourra afficher correctement (probablement au travers de l'API MapDebugInformation) le nom des fonctions export es. Pour ce qui est de leurs param tres, MapDebugInformation donne aussi des informations sur le d but et la fin de la fonction dans l'image. A partir de cette information, il est possible de r cup rer le code compil correspondant la fonction export e, de le d sassembler... et (op ration non triviale, mais possible) de retrouver les param tres.
Fran ois
pascal1967
j'obtient effectivement assez facilement le nom de la fonction mais pour les paramètres le code assembleur est trop corriace...
pourquoi des outils comme PE Explorer n'y arrive pas non plus ? Cela dépend du compilateur ?
Merci
j'obtient effectivement assez facilement le nom de la fonction mais pour les
paramètres le code assembleur est trop corriace...
pourquoi des outils comme PE Explorer n'y arrive pas non plus ? Cela dépend
du compilateur ?
j'obtient effectivement assez facilement le nom de la fonction mais pour les paramètres le code assembleur est trop corriace...
pourquoi des outils comme PE Explorer n'y arrive pas non plus ? Cela dépend du compilateur ?
Merci
Jean-marc
pascal1967 wrote:
Hello,
j'obtient effectivement assez facilement le nom de la fonction mais pour les paramètres le code assembleur est trop corriace...
pourquoi des outils comme PE Explorer n'y arrive pas non plus ? Cela dépend du compilateur ?
Tu peux voir du code bien désassemblé et commenté avec un outil comme W32Dasm, téléchargeable gratuitement ici: http://www.angelfire.com/dc/vashala/hacks%20pages/hack_programs/Win32dasm.html
(Lors de la première utilisation, change de police depuis le Menu Font...)
Tu trouveras sans probleme les noms de fonctions et les adresses, puis le code assembleur qui va derrière. Si tu es un bon pro, tu pourras deviner que par exemple la fonction recoit 3 ou 4 parametres. Mais c'est tout.
Et ca ne dépend pas du compilateur, ca tient betement à la façon dont un compilateur fonctionne (tous les "vrais" compilateiurs, ceux qui produisent du code assembleur).
Le code assembleur d'une fonction ne contient plus ni noms, ni types, ni rien de ce genre. tu pourras simplement savoir que sur la pile d'appel, on a passé un "truc" sur 2 bytes, puis un "machin" sur 4 bytes, etc. Mais impossible de dire par exemple si c'est un "long" ou un "pointeur sur char".
Voici 2 fonctions en C, dans une dll:
void titi(char *p) { printf("%pn", p); }
void toto(long p) { printf("%ldn", p); }
Ces 2 fonctions produisent le même code source, à l'identique (à l'exception de la chaine pour printf):
_titi PROC NEAR ; COMDAT
; 5 : {
push ebp mov ebp, esp sub esp, 64 ; 00000040H push ebx push esi push edi lea edi, DWORD PTR [ebp-64] mov ecx, 16 ; 00000010H mov eax, -858993460 ; ccccccccH rep stosd
le code est à 100% identique pour toto, et c'est bien normal: un "long" est codé sur 4 bytes, comme un pointeur. Ils sont donc impossible à distinguer.
Moralité: en examinant l'assembleur généré, c'est IMPOSSIBLE (pour toujours et à jamais), quel que soit l'outil de deviner si la fonction originale attend un long, ou un pointeur sur char (ou sur quoique ce soit d'autre d'ailleurs, genre une structures, etc.)
En lisant le code source et en le comprenant, un expert pourrait faire du reverse ingeneering et par tatonnement finir par deviner que le premier parametre est sans doute une chaine, ou ceci, ou cela;
A force de tests, l'expert finirait peut etre par retrouver qq chose.
Voila. La réponse à ta question originale est donc:
Il est impossible, par des moyens mécaniques, de retrouver les parametres d'une fonction depuis le code assembleur généré.
Un Expert humain pourra (pourrait) dans une certaine mesure retrouver plus ou moins la nature des paramètres, mais avec bcp d'efforts et de temps, en plus de tests poussés.
j'obtient effectivement assez facilement le nom de la fonction mais
pour les paramètres le code assembleur est trop corriace...
pourquoi des outils comme PE Explorer n'y arrive pas non plus ? Cela
dépend du compilateur ?
Tu peux voir du code bien désassemblé et commenté avec un outil
comme W32Dasm, téléchargeable gratuitement ici:
http://www.angelfire.com/dc/vashala/hacks%20pages/hack_programs/Win32dasm.html
(Lors de la première utilisation, change de police depuis le Menu Font...)
Tu trouveras sans probleme les noms de fonctions et les adresses, puis le
code assembleur
qui va derrière. Si tu es un bon pro, tu pourras deviner que par exemple la
fonction recoit
3 ou 4 parametres. Mais c'est tout.
Et ca ne dépend pas du compilateur, ca tient betement à la façon dont un
compilateur
fonctionne (tous les "vrais" compilateiurs, ceux qui produisent du code
assembleur).
Le code assembleur d'une fonction ne contient plus ni noms, ni types, ni
rien de ce genre.
tu pourras simplement savoir que sur la pile d'appel, on a passé un "truc"
sur 2 bytes, puis un "machin"
sur 4 bytes, etc. Mais impossible de dire par exemple si c'est un "long" ou
un "pointeur sur char".
Voici 2 fonctions en C, dans une dll:
void titi(char *p)
{
printf("%pn", p);
}
void toto(long p)
{
printf("%ldn", p);
}
Ces 2 fonctions produisent le même code source,
à l'identique (à l'exception de la chaine pour printf):
_titi PROC NEAR ; COMDAT
; 5 : {
push ebp
mov ebp, esp
sub esp, 64 ; 00000040H
push ebx
push esi
push edi
lea edi, DWORD PTR [ebp-64]
mov ecx, 16 ; 00000010H
mov eax, -858993460 ; ccccccccH
rep stosd
le code est à 100% identique pour toto, et c'est bien normal:
un "long" est codé sur 4 bytes, comme un pointeur. Ils sont
donc impossible à distinguer.
Moralité: en examinant l'assembleur généré, c'est IMPOSSIBLE
(pour toujours et à jamais), quel que soit l'outil de deviner
si la fonction originale attend un long, ou un pointeur sur char
(ou sur quoique ce soit d'autre d'ailleurs, genre une structures, etc.)
En lisant le code source et en le comprenant, un expert pourrait faire
du reverse ingeneering et par tatonnement finir par deviner que le
premier parametre est sans doute une chaine, ou ceci, ou cela;
A force de tests, l'expert finirait peut etre par retrouver qq chose.
Voila. La réponse à ta question originale est donc:
Il est impossible, par des moyens mécaniques, de retrouver
les parametres d'une fonction depuis le code assembleur généré.
Un Expert humain pourra (pourrait) dans une certaine mesure
retrouver plus ou moins la nature des paramètres, mais avec bcp
d'efforts et de temps, en plus de tests poussés.
j'obtient effectivement assez facilement le nom de la fonction mais pour les paramètres le code assembleur est trop corriace...
pourquoi des outils comme PE Explorer n'y arrive pas non plus ? Cela dépend du compilateur ?
Tu peux voir du code bien désassemblé et commenté avec un outil comme W32Dasm, téléchargeable gratuitement ici: http://www.angelfire.com/dc/vashala/hacks%20pages/hack_programs/Win32dasm.html
(Lors de la première utilisation, change de police depuis le Menu Font...)
Tu trouveras sans probleme les noms de fonctions et les adresses, puis le code assembleur qui va derrière. Si tu es un bon pro, tu pourras deviner que par exemple la fonction recoit 3 ou 4 parametres. Mais c'est tout.
Et ca ne dépend pas du compilateur, ca tient betement à la façon dont un compilateur fonctionne (tous les "vrais" compilateiurs, ceux qui produisent du code assembleur).
Le code assembleur d'une fonction ne contient plus ni noms, ni types, ni rien de ce genre. tu pourras simplement savoir que sur la pile d'appel, on a passé un "truc" sur 2 bytes, puis un "machin" sur 4 bytes, etc. Mais impossible de dire par exemple si c'est un "long" ou un "pointeur sur char".
Voici 2 fonctions en C, dans une dll:
void titi(char *p) { printf("%pn", p); }
void toto(long p) { printf("%ldn", p); }
Ces 2 fonctions produisent le même code source, à l'identique (à l'exception de la chaine pour printf):
_titi PROC NEAR ; COMDAT
; 5 : {
push ebp mov ebp, esp sub esp, 64 ; 00000040H push ebx push esi push edi lea edi, DWORD PTR [ebp-64] mov ecx, 16 ; 00000010H mov eax, -858993460 ; ccccccccH rep stosd
le code est à 100% identique pour toto, et c'est bien normal: un "long" est codé sur 4 bytes, comme un pointeur. Ils sont donc impossible à distinguer.
Moralité: en examinant l'assembleur généré, c'est IMPOSSIBLE (pour toujours et à jamais), quel que soit l'outil de deviner si la fonction originale attend un long, ou un pointeur sur char (ou sur quoique ce soit d'autre d'ailleurs, genre une structures, etc.)
En lisant le code source et en le comprenant, un expert pourrait faire du reverse ingeneering et par tatonnement finir par deviner que le premier parametre est sans doute une chaine, ou ceci, ou cela;
A force de tests, l'expert finirait peut etre par retrouver qq chose.
Voila. La réponse à ta question originale est donc:
Il est impossible, par des moyens mécaniques, de retrouver les parametres d'une fonction depuis le code assembleur généré.
Un Expert humain pourra (pourrait) dans une certaine mesure retrouver plus ou moins la nature des paramètres, mais avec bcp d'efforts et de temps, en plus de tests poussés.
