Apileech: décompilateur d'appels aux apis dans un assembly .net
Description
Ce programme permet d'ouvrir n'importe quel programme .NET, de lister l'ensemble des types (classes, interfaces, délégués...) qu'il contient et de générer du code VB ou C# pour tous les appels à P/Invoke (appels à Windows) et les constantes, énums et structures utilisés dans ces appels.
Pour décompiler les APIs d'un assembly:
1) Sélectionner le fichier dans la barre de texte, puis Réflexion
2) Filtrer les appels P/Invoke (c'est important: sinon, du code pour tout l'assembly va être généré, et c'est plutôt long :)
3) Sélectionner le langage, les options (par exemple, décocher 'colorer les mots-clefs dans le code' quand on ne sait pas la quantité de code généré, ça peut être long)
4) Générer le code
5) Attendre quelques minutes (suivant la taille de l'assembly et les options utilisées)
6) Utiliser le code :)
Bon je garantis pas un code avec 0% d'erreurs, il peut rester quelques erreurs (ou beaucoup parfois: "vbc : error BC30041: Le nombre maximal d'erreurs est dépassé."), mais ça devrait aller pour la plupart des assemblys .NET, pour mscorlib.dll avec les options par défaut j'ai zéro erreur.
Une des options indispensables quand on génère du code VB c'est de sélectionner un namespace par défaut qui est le même que cleui du projet VB, sinon le compilateur ne va pas trouver les bons namespaces.
Sinon pourquoi on peut générer du code C#?
1) Je programme en VB et en C# (comme on peut le constater dans APILeech)
2) Tous les appels P/Invoke ne sont pas codables en VB à cause des pointeurs
3) Ca m'a permi d'adapter la structure de mon programme de telle sorte qu'il est plus facile d'ajouter un autre langage à la liste des langages supportés, comme C++ Managé ou Delphi.NET
Pourquoi un niveau de 3!?!
Enfait, la partie Réflexion du framework .NET, qui s'occupe de charger un assembly, lister les informations sur les types, leurs membres... ne suffisait pas pour mes besoins dans API Leech: on ne pouvait pas connaître la DLL utilisée, la convention d'appel, les valeurs des constantes. Bref, tous ce qui est absolument nécessaire pour ce que je voulais faire.
Je me suis inspiré d'un articel de MSDN (http://www.msdn.microsoft.com/msdnmag/issues/1000/metadata/default.aspx) qui parle justement de métadonnées (informations sur la structure du programme, les types, leurs membres etc) et j'en suis servi pour faire une petite DLL (2800 lignes quand même) en C++ Managé qui appelle directement à travers COM (et c'est pas une partie de plaisir) mscoree.dll qui permet de lire ces métadonnées.
Voilà pourquoi, pour moi, ce code devrait avoir un niveau de 3, pour ces !*$à@% de 2800 lignes en C++ qui m'ont bien pris la tête.
Ce qui me reste à faire sur API Leech:
-un support des propriétés et des événements. Bon c'est pas capital pour les APIs mais comme ça j'aurais à peu près ma dll de réflexion perso et complète :)
-un support des attributs. Pareil c'est pas critique pour les APIs mais ca peut aider. (comme l'attribut SuppressUnmanagedCodeSecurity qui accélère l'acces aux APIs)
C'est pas vraiment facile à faire, les attributs sont stockés sous forme de blobs de données, c'est à dire un tableau d'octets qu'il faut intepréter (Par exemple 0100 07000000 04000000 41424344 05 546F646179 0000 qui est censé vouloir dire: un attribut dont le constructeur attend comme paramètres un entier de valeur 7, un tableau de 4 caractères A,B,C,D, et une chaîne "Today" - les types de données ne sont pas inclus dans ce blob, on les a en inspectant la signature du constructeur de l'attribut, un autre blob, c'est pas franchement évident).
-corriger tous les bugs qui restent. J'en ai éliminé déjà un bon paquet mais je suis SÛR qu'il en reste encore plein :)
Si ça interesse quelqu'un, toute la doc sur les métadonnes de .NET est dans <Dossier SDK .NET>\v1.1\Tool Developers Guide\docs\Metadata Unmanaged API.doc. C'est long et en anglais mais ça explique bien les arcanes de .NET.
J'attends commentaires, critiques et coups de gueule :)
Xya
Pour décompiler les APIs d'un assembly:
1) Sélectionner le fichier dans la barre de texte, puis Réflexion
2) Filtrer les appels P/Invoke (c'est important: sinon, du code pour tout l'assembly va être généré, et c'est plutôt long :)
3) Sélectionner le langage, les options (par exemple, décocher 'colorer les mots-clefs dans le code' quand on ne sait pas la quantité de code généré, ça peut être long)
4) Générer le code
5) Attendre quelques minutes (suivant la taille de l'assembly et les options utilisées)
6) Utiliser le code :)
Conclusion :
Bon je garantis pas un code avec 0% d'erreurs, il peut rester quelques erreurs (ou beaucoup parfois: "vbc : error BC30041: Le nombre maximal d'erreurs est dépassé."), mais ça devrait aller pour la plupart des assemblys .NET, pour mscorlib.dll avec les options par défaut j'ai zéro erreur.
Une des options indispensables quand on génère du code VB c'est de sélectionner un namespace par défaut qui est le même que cleui du projet VB, sinon le compilateur ne va pas trouver les bons namespaces.
Sinon pourquoi on peut générer du code C#?
1) Je programme en VB et en C# (comme on peut le constater dans APILeech)
2) Tous les appels P/Invoke ne sont pas codables en VB à cause des pointeurs
3) Ca m'a permi d'adapter la structure de mon programme de telle sorte qu'il est plus facile d'ajouter un autre langage à la liste des langages supportés, comme C++ Managé ou Delphi.NET
Pourquoi un niveau de 3!?!
Enfait, la partie Réflexion du framework .NET, qui s'occupe de charger un assembly, lister les informations sur les types, leurs membres... ne suffisait pas pour mes besoins dans API Leech: on ne pouvait pas connaître la DLL utilisée, la convention d'appel, les valeurs des constantes. Bref, tous ce qui est absolument nécessaire pour ce que je voulais faire.
Je me suis inspiré d'un articel de MSDN (http://www.msdn.microsoft.com/msdnmag/issues/1000/metadata/default.aspx) qui parle justement de métadonnées (informations sur la structure du programme, les types, leurs membres etc) et j'en suis servi pour faire une petite DLL (2800 lignes quand même) en C++ Managé qui appelle directement à travers COM (et c'est pas une partie de plaisir) mscoree.dll qui permet de lire ces métadonnées.
Voilà pourquoi, pour moi, ce code devrait avoir un niveau de 3, pour ces !*$à@% de 2800 lignes en C++ qui m'ont bien pris la tête.
Ce qui me reste à faire sur API Leech:
-un support des propriétés et des événements. Bon c'est pas capital pour les APIs mais comme ça j'aurais à peu près ma dll de réflexion perso et complète :)
-un support des attributs. Pareil c'est pas critique pour les APIs mais ca peut aider. (comme l'attribut SuppressUnmanagedCodeSecurity qui accélère l'acces aux APIs)
C'est pas vraiment facile à faire, les attributs sont stockés sous forme de blobs de données, c'est à dire un tableau d'octets qu'il faut intepréter (Par exemple 0100 07000000 04000000 41424344 05 546F646179 0000 qui est censé vouloir dire: un attribut dont le constructeur attend comme paramètres un entier de valeur 7, un tableau de 4 caractères A,B,C,D, et une chaîne "Today" - les types de données ne sont pas inclus dans ce blob, on les a en inspectant la signature du constructeur de l'attribut, un autre blob, c'est pas franchement évident).
-corriger tous les bugs qui restent. J'en ai éliminé déjà un bon paquet mais je suis SÛR qu'il en reste encore plein :)
Si ça interesse quelqu'un, toute la doc sur les métadonnes de .NET est dans <Dossier SDK .NET>\v1.1\Tool Developers Guide\docs\Metadata Unmanaged API.doc. C'est long et en anglais mais ça explique bien les arcanes de .NET.
J'attends commentaires, critiques et coups de gueule :)
Xya
Vous n'êtes pas encore membre ?
inscrivez-vous, c'est gratuit et ça prend moins d'une minute !
Les membres obtiennent plus de réponses que les utilisateurs anonymes.
Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.
Le fait d'être membre vous permet d'avoir des options supplémentaires.