Converter EXE para DLL

Um aplicativo host do Windows ou um SDK de dispositivo pode aceitar somente uma DLL quando precisa de código reutilizável em vez de um programa autônomo. Portanto, converter um EXE existente geralmente significa extrair ou recriar funcionalidades selecionadas como uma biblioteca, e não alterar a extensão do nome do arquivo.

O que é o formato EXE

Um EXE é um arquivo Windows Portable Executable destinado a iniciar um aplicativo. Ele pode conter código de máquina nativo ou código .NET gerenciado, um ponto de entrada como main, WinMain ou um método de inicialização .NET, metadados do aplicativo, recursos e referências a outras bibliotecas.

Visual Studio, GCC, Clang, Delphi e ferramentas do .NET SDK produzem arquivos EXE. Eles são usados em aplicativos para desktop, utilitários de linha de comando, instaladores, serviços e aplicativos .NET autocontidos.

O que é o formato DLL

Uma DLL também é um arquivo Windows Portable Executable, mas é criada para ser carregada por um processo host. Uma DLL nativa normalmente expõe funções exportadas, componentes COM ou outros pontos de entrada definidos por ABI; uma DLL gerenciada é um assembly .NET que contém classes, métodos, recursos e metadados aos quais outro programa .NET pode fazer referência.

As DLLs permitem que vários aplicativos compartilhem código e que um host carregue funcionalidades opcionais em tempo de execução. O host precisa conhecer a API da biblioteca, as convenções de chamada, o framework de destino e as dependências. Uma DLL não é automaticamente uma versão reutilizável do aplicativo que produziu um EXE.

Quando o código-fonte está disponível

1. Crie um projeto Class Library separado no Visual Studio ou crie o projeto Dynamic-Link Library apropriado para código nativo em C ou C++. Use o mesmo framework e a mesma arquitetura de CPU do aplicativo.
2. Mova as classes reutilizáveis, os recursos e o código de implementação para o projeto da biblioteca. Mantenha o projeto executável se ele ainda precisar de uma interface de usuário, processamento de linha de comando, configuração ou static void Main().
3. Torne as classes e os métodos gerenciados pretendidos public. Para C ou C++ nativo, defina uma API exportada estável com __declspec(dllexport) ou um arquivo de definição de módulo, e documente a convenção de chamada e os tipos de dados.
4. Compile com Build → Build Solution. O Visual Studio coloca a saída em um diretório do projeto, como bin\Debug ou bin\Release, dependendo da configuração.

Para uma nova biblioteca .NET, os comandos equivalentes são:

dotnet new classlib -n MyLibrary
dotnet build MyLibrary

A compilação cria uma DLL, mas somente o código incluído no projeto da biblioteca fica disponível por meio de sua API; o comportamento completo do EXE não é transferido automaticamente.

Quando apenas um EXE .NET está disponível

Os arquivos EXE e DLL .NET gerenciados usam o mesmo formato geral de assembly, portanto as ferramentas geralmente podem inspecionar e reconstruir seu código. Quando a licença e a legislação aplicável permitirem, abra o EXE com ILSpy ou dnSpyEx, inspecione seus namespaces e dependências e use a função File → Save Code do ILSpy para exportar o C# reconstruído.

Crie um novo projeto Class Library, importe o código recuperado, restaure as referências, corrija os modificadores de acesso e os caminhos dos recursos e, em seguida, compile e teste a DLL. A saída decompilada não tem garantia de corresponder ao código-fonte original: ofuscação, transformações do compilador, símbolos ausentes, dependências nativas e código gerado podem impedir uma recompilação limpa.

Às vezes, um EXE gerenciado existente pode ser referenciado como um assembly, mas isso não remove seu ponto de entrada executável nem transforma o design do aplicativo em uma API de biblioteca. Uma DLL de dependência referenciada encontrada ao lado do EXE também já é uma biblioteca existente, e não uma conversão do EXE.

Quando apenas um EXE nativo está disponível

Não existe uma conversão confiável com um clique para um EXE nativo em C, C++, Delphi ou similar. Ghidra, IDA e Binary Ninja podem desmontar e analisar código de máquina, mas não restauram o código-fonte original nem produzem automaticamente uma DLL sustentável com exports documentados.

Reimplemente o comportamento necessário a partir do código-fonte, da documentação ou dos resultados da engenharia reversa e, em seguida, compile a implementação como uma DLL. Criar um projeto DLL a partir do mesmo código-fonte nativo pode ajudar, mas funções, estado global, inicialização, tratamento de recursos e exports ainda exigem alterações no código.

Limitações de compatibilidade

Renomear program.exe para program.dll não o converte. O arquivo renomeado mantém suas características executáveis e normalmente não possui os exports ou tipos de biblioteca gerenciados esperados por um host.

Para bibliotecas nativas, o host e a DLL precisam usar arquiteturas de CPU compatíveis: um processo de 64 bits não pode carregar uma DLL nativa de 32 bits, e um processo de 32 bits não pode carregar uma DLL nativa de 64 bits. Compatibilize a ABI do compilador, as convenções de chamada, o layout das estruturas, a codificação de caracteres, as bibliotecas de runtime, os nomes exportados e as versões das DLLs dependentes. Uma DLL carregada em um processo também compartilha o espaço de endereçamento desse processo, portanto a inicialização e a propriedade da memória exigem cuidado.

Para bibliotecas .NET, compatibilize o framework de destino, a versão do runtime, as dependências específicas do processador, os requisitos de strong name e as versões dos pacotes. Uma biblioteca criada para um runtime mais recente ou incompatível pode falhar antes que qualquer método seja chamado.

A recompilação pode alterar o estado global, a ordem de inicialização, a busca de configurações, as suposições sobre o diretório de trabalho, o comportamento da interface do usuário e os caminhos dos recursos. Teste a DLL por meio do aplicativo host ou SDK exato que a carregará.

Conversores online

Conversores de arquivos online confiáveis são úteis para alterações de formato, como imagens ou documentos, mas não para transformar executáveis arbitrários do Windows em DLLs funcionais. Um servidor não consegue inferir de forma confiável, a partir do binário, os exports pretendidos e a interface de biblioteca de um programa nativo, e o envio de arquivos proprietários ou executáveis cria riscos de confidencialidade e de verificação contra malware. Em vez disso, use um toolchain de desenvolvimento local ou ferramentas locais de engenharia reversa.