Konwertuj EXE na DLL

Aplikacja hosta Windows lub device SDK może akceptować wyłącznie DLL, gdy potrzebuje kodu wielokrotnego użytku, a nie samodzielnego programu. Konwersja istniejącego EXE zwykle oznacza więc wyodrębnienie lub ponowne zbudowanie wybranej funkcjonalności jako biblioteki, a nie zmianę rozszerzenia pliku.

Czym jest format EXE

EXE to plik Windows Portable Executable przeznaczony do uruchamiania aplikacji. Może zawierać natywny kod maszynowy lub zarządzany kod .NET, punkt wejścia, taki jak main, WinMain lub metoda startowa .NET, metadane aplikacji, zasoby oraz odwołania do innych bibliotek.

Visual Studio, GCC, Clang, Delphi i narzędzia .NET SDK tworzą pliki EXE. Są one używane w aplikacjach desktopowych, narzędziach wiersza poleceń, instalatorach, usługach oraz samodzielnych aplikacjach .NET.

Czym jest format DLL

DLL to również plik Windows Portable Executable, ale jest tworzony w celu załadowania przez proces hosta. Natywna DLL zwykle udostępnia eksportowane funkcje, komponenty COM lub inne punkty wejścia zdefiniowane przez ABI; zarządzana DLL to zestaw .NET zawierający klasy, metody, zasoby i metadane, do których może odwoływać się inny program .NET.

DLL umożliwiają wielu aplikacjom współdzielenie kodu oraz pozwalają hostowi ładować opcjonalną funkcjonalność w czasie wykonywania. Host musi znać API biblioteki, konwencje wywołań, docelowy framework i zależności. DLL nie jest automatycznie wielokrotnego użytku wersją aplikacji, która utworzyła EXE.

Gdy dostępny jest kod źródłowy

1. Utwórz osobny projekt Class Library w Visual Studio albo utwórz odpowiedni projekt Dynamic-Link Library dla natywnego kodu C lub C++. Ustaw ten sam framework i architekturę CPU co w aplikacji.
2. Przenieś klasy wielokrotnego użytku, zasoby i kod implementacji do projektu biblioteki. Zachowaj projekt pliku wykonywalnego, jeśli nadal wymaga interfejsu użytkownika, obsługi wiersza poleceń, konfiguracji lub static void Main().
3. Oznacz przeznaczone do udostępnienia zarządzane klasy i metody jako public. W przypadku natywnego C lub C++ zdefiniuj stabilne API eksportowane za pomocą __declspec(dllexport) lub pliku definicji modułu oraz udokumentuj konwencję wywołań i typy danych.
4. Zbuduj projekt za pomocą Build → Build Solution. Visual Studio umieszcza dane wyjściowe w katalogu projektu, takim jak bin\Debug lub bin\Release, zależnie od konfiguracji.

W przypadku nowej biblioteki .NET odpowiednie polecenia to:

dotnet new classlib -n MyLibrary
dotnet build MyLibrary

Kompilacja tworzy DLL, ale za pośrednictwem jej API dostępny jest wyłącznie kod uwzględniony w projekcie biblioteki; pełne działanie EXE nie jest automatycznie przenoszone.

Gdy dostępny jest wyłącznie EXE .NET

Zarządzane pliki EXE i DLL .NET używają tego samego ogólnego formatu zestawu, dlatego narzędzia często mogą je analizować i odtwarzać ich kod. Jeśli zezwala na to licencja i obowiązujące prawo, otwórz EXE za pomocą ILSpy lub dnSpyEx, przeanalizuj jego przestrzenie nazw i zależności, a następnie użyj funkcji File → Save Code w ILSpy, aby wyeksportować odtworzony kod C#.

Utwórz nowy projekt Class Library, zaimportuj odzyskany kod, przywróć odwołania, popraw modyfikatory dostępu i ścieżki zasobów, a następnie zbuduj i przetestuj DLL. Zdekompilowane dane wyjściowe nie muszą odpowiadać oryginalnemu kodowi źródłowemu: zaciemnianie kodu, transformacje kompilatora, brakujące symbole, natywne zależności i wygenerowany kod mogą uniemożliwić poprawne ponowne zbudowanie projektu.

Istniejący zarządzany EXE może czasami być używany jako zestaw, ale nie usuwa to jego wykonywalnego punktu wejścia ani nie przekształca projektu aplikacji w API biblioteki. Zależna DLL znaleziona obok EXE jest również istniejącą biblioteką, a nie konwersją EXE.

Gdy dostępny jest wyłącznie natywny EXE

Nie istnieje niezawodna konwersja jednym kliknięciem natywnego EXE napisanego w C, C++, Delphi lub podobnym języku. Ghidra, IDA i Binary Ninja mogą dezasemblować i analizować kod maszynowy, ale nie odtwarzają oryginalnego kodu źródłowego ani automatycznie nie tworzą możliwej do utrzymania DLL z udokumentowanymi eksportami.

Zaimplementuj wymagane działanie na podstawie kodu źródłowego, dokumentacji lub wyników inżynierii wstecznej, a następnie skompiluj implementację jako DLL. Utworzenie projektu DLL na podstawie tego samego kodu natywnego może pomóc, ale funkcje, stan globalny, inicjalizacja, obsługa zasobów i eksporty nadal wymagają zmian w kodzie.

Ograniczenia zgodności

Zmiana nazwy program.exe na program.dll nie konwertuje pliku. Zmieniony plik zachowuje cechy pliku wykonywalnego i zwykle nie zawiera eksportów ani zarządzanych typów biblioteki oczekiwanych przez hosta.

W przypadku bibliotek natywnych host i DLL muszą używać zgodnych architektur CPU: proces 64-bitowy nie może załadować 32-bitowej natywnej DLL, a proces 32-bitowy nie może załadować 64-bitowej natywnej DLL. Dopasuj ABI kompilatora, konwencje wywołań, układ struktur, kodowanie znaków, biblioteki runtime, eksportowane nazwy oraz wersje zależnych DLL. DLL załadowana do procesu współdzieli również przestrzeń adresową tego procesu, dlatego inicjalizacja i zarządzanie własnością pamięci wymagają ostrożności.

W przypadku bibliotek .NET dopasuj docelowy framework, wersję runtime, zależności specyficzne dla procesora, wymagania dotyczące strong name oraz wersje pakietów. Biblioteka zbudowana dla nowszego lub niezgodnego runtime może zakończyć działanie, zanim zostanie wywołana jakakolwiek metoda.

Ponowne zbudowanie może zmienić stan globalny, kolejność uruchamiania, wyszukiwanie konfiguracji, założenia dotyczące katalogu roboczego, działanie interfejsu użytkownika i ścieżki zasobów. Przetestuj DLL za pomocą dokładnej aplikacji hosta lub SDK, która będzie ją ładować.

Konwertery online

Renomowane internetowe konwertery plików są przydatne do zmiany formatów, takich jak obrazy lub dokumenty, ale nie do przekształcania dowolnych plików wykonywalnych Windows w funkcjonalne DLL. Serwer nie jest w stanie niezawodnie określić zamierzonych eksportów natywnego programu ani interfejsu biblioteki na podstawie jego pliku binarnego, a przesyłanie zastrzeżonych lub wykonywalnych plików stwarza ryzyko naruszenia poufności i kontroli pod kątem malware. Zamiast tego użyj lokalnego toolchaina programistycznego lub lokalnych narzędzi do inżynierii wstecznej.