Convertir EXE en DLL

Une application hôte Windows ou un SDK d’appareil peut accepter uniquement une DLL lorsqu’elle a besoin de code réutilisable plutôt que d’un programme autonome. La conversion d’un EXE existant consiste donc généralement à extraire ou à reconstruire certaines fonctionnalités sous forme de bibliothèque, et non à modifier l’extension du nom de fichier.

Qu’est-ce que le format EXE ?

Un EXE est un fichier Windows Portable Executable destiné à démarrer une application. Il peut contenir du code machine natif ou du code .NET managé, un point d’entrée tel que main, WinMain ou une méthode de démarrage .NET, des métadonnées d’application, des ressources et des références à d’autres bibliothèques.

Visual Studio, GCC, Clang, Delphi et les outils du .NET SDK produisent des fichiers EXE. Ils sont utilisés pour les applications de bureau, les utilitaires en ligne de commande, les programmes d’installation, les services et les applications .NET autonomes.

Qu’est-ce que le format DLL ?

Une DLL est également un fichier Windows Portable Executable, mais elle est conçue pour être chargée par un processus hôte. Une DLL native expose normalement des fonctions exportées, des composants COM ou d’autres points d’entrée définis par un ABI ; une DLL managée est un assembly .NET contenant des classes, des méthodes, des ressources et des métadonnées auxquels un autre programme .NET peut faire référence.

Les DLL permettent à plusieurs applications de partager du code et à un hôte de charger des fonctionnalités facultatives au moment de l’exécution. L’hôte doit connaître l’API de la bibliothèque, les conventions d’appel, le framework cible et les dépendances. Une DLL ne constitue pas automatiquement une version réutilisable de l’application qui a produit un EXE.

Lorsque le code source est disponible

1. Créez un projet Class Library distinct dans Visual Studio, ou créez le projet Dynamic-Link Library approprié pour du code natif C ou C++. Ciblez le même framework et la même architecture CPU que l’application.
2. Déplacez les classes, ressources et codes d’implémentation réutilisables dans le projet de bibliothèque. Conservez le projet exécutable s’il a encore besoin d’une interface utilisateur, du traitement de la ligne de commande, de la configuration ou de static void Main().
3. Rendez les classes et méthodes managées prévues public. Pour le C ou le C++ natif, définissez une API exportée stable avec __declspec(dllexport) ou un fichier de définition de module, puis documentez la convention d’appel et les types de données.
4. Compilez avec Build → Build Solution. Visual Studio place la sortie dans un répertoire de projet tel que bin\Debug ou bin\Release, selon la configuration.

Pour une nouvelle bibliothèque .NET, les commandes équivalentes sont :

dotnet new classlib -n MyLibrary
dotnet build MyLibrary

La compilation crée une DLL, mais seul le code inclus dans le projet de bibliothèque est disponible via son API ; le comportement complet de l’EXE n’est pas transféré automatiquement.

Lorsqu’un EXE .NET est le seul élément disponible

Les fichiers EXE et DLL .NET managés utilisent globalement le même format d’assembly, de sorte que les outils peuvent souvent inspecter et reconstruire leur code. Lorsque la licence et le droit applicable l’autorisent, ouvrez l’EXE avec ILSpy ou dnSpyEx, inspectez ses espaces de noms et ses dépendances, puis utilisez la fonction File → Save Code d’ILSpy pour exporter le code C# reconstruit.

Créez un nouveau projet Class Library, importez le code récupéré, restaurez les références, corrigez les modificateurs d’accès et les chemins des ressources, puis compilez et testez la DLL. La sortie décompilée ne correspond pas nécessairement au code source d’origine : l’obfuscation, les transformations du compilateur, les symboles manquants, les dépendances natives et le code généré peuvent empêcher une reconstruction propre.

Un EXE managé existant peut parfois être référencé comme un assembly, mais cela ne supprime pas son point d’entrée exécutable et ne transforme pas la conception de son application en API de bibliothèque. Une DLL de dépendance référencée trouvée à côté de l’EXE est également une bibliothèque existante, et non une conversion de l’EXE.

Lorsqu’un EXE natif est le seul élément disponible

Il n’existe pas de conversion fiable en un clic pour un EXE natif C, C++, Delphi ou similaire. Ghidra, IDA et Binary Ninja peuvent désassembler et analyser le code machine, mais ils ne restaurent pas le code source d’origine et ne produisent pas automatiquement une DLL maintenable avec des exports documentés.

Réimplémentez le comportement requis à partir du code source, de la documentation ou des résultats de rétro-ingénierie, puis compilez l’implémentation sous forme de DLL. Créer un projet DLL à partir du même code natif peut être utile, mais les fonctions, l’état global, l’initialisation, la gestion des ressources et les exports nécessitent toujours des modifications du code.

Limites de compatibilité

Renommer program.exe en program.dll ne le convertit pas. Le fichier renommé conserve ses caractéristiques exécutables et ne possède normalement pas les exports ou les types de bibliothèque managés attendus par un hôte.

Pour les bibliothèques natives, l’hôte et la DLL doivent utiliser des architectures CPU compatibles : un processus 64 bits ne peut pas charger une DLL native 32 bits, et un processus 32 bits ne peut pas charger une DLL native 64 bits. Faites correspondre l’ABI du compilateur, les conventions d’appel, la disposition des structures, l’encodage des caractères, les bibliothèques d’exécution, les noms exportés et les versions des DLL dépendantes. Une DLL chargée dans un processus partage également l’espace d’adressage de ce processus ; l’initialisation et la gestion de la propriété de la mémoire exigent donc une attention particulière.

Pour les bibliothèques .NET, faites correspondre le framework cible, la version du runtime, les dépendances spécifiques au processeur, les exigences de strong name et les versions des packages. Une bibliothèque conçue pour un runtime plus récent ou incompatible peut échouer avant même l’appel d’une méthode.

La reconstruction peut modifier l’état global, l’ordre de démarrage, la recherche de la configuration, les hypothèses concernant le répertoire de travail, le comportement de l’interface utilisateur et les chemins des ressources. Testez la DLL avec l’application hôte ou le SDK exact qui la chargera.

Convertisseurs en ligne

Les convertisseurs de fichiers en ligne réputés sont utiles pour les changements de format tels que ceux des images ou des documents, mais pas pour transformer des exécutables Windows arbitraires en DLL fonctionnelles. Un serveur ne peut pas déduire de manière fiable les exports prévus et l’interface de bibliothèque d’un programme natif à partir de son binaire, et l’envoi de fichiers propriétaires ou exécutables crée des risques de confidentialité et d’analyse de malwares. Utilisez plutôt une chaîne d’outils de développement locale ou des outils locaux de rétro-ingénierie.