Dynamische Link Bibliothek

In diesem Artikel geht es um die Implementierung von Betriebssystemen/2 und Windows. Für die dynamische Verknüpfung von Bibliotheken im Allgemeinen siehe Dynamischer Linker.
Nicht zu verwechseln mit Dynamisch geladene Bibliothek.
Dynamische Link Bibliothek
DLL Icon (PNG).png
Dateiname Erweiterung
.dll
Internet -Medientyp
Anwendung/vnd.microsoft.Portable-Execable
Uniform Typ Identifier (UTI) com.microsoft.windows-dynamic-link-library
magische Zahl MZ
Entwickelt von Microsoft
Container für Gemeinsame Bibliothek

Dynamische Link Bibliothek (DLL) ist MicrosoftImplementierung der gemeinsame Bibliothek Konzept in der Microsoft Windows und OS/2 Betriebssysteme. Diese Bibliotheken haben normalerweise die Dateierweiterung DLL, OCX (für Bibliotheken, die enthalten ActiveX Kontrollen) oder DRV (für Erbe Systemtreiber). Die Dateiformate für DLLs sind die gleichen wie für Windows Exe Dateien - das heißt, Tragbare ausführbare Datei (Pe) für 32-Bit und 64-Bit Fenster und Neue ausführbare Datei (Ne) für 16-Bit Fenster. Wie bei Exen können DLLs enthalten Code, Daten, und Ressourcen, in jeder Kombination.

Daten Dateien mit dem gleichen Datei Format Als DLL können jedoch mit unterschiedlichen Dateierweiterungen und möglicherweise nur Ressourcenabschnitte aufgerufen werden Ressourcen -DLLs. Beispiele für solche DLLs umfassen Symbol Bibliotheken, manchmal die Erweiterung haben ICL, und Schriftart Dateien mit den Erweiterungen Fon und Fot.[1]

Hintergrund

Die ersten Versionen von Microsoft Windows lief Programme in einer einzigen zusammen Adressraum. Jedes Programm sollte zusammenarbeiten, indem sie die CPU anderen Programmen so liefern, damit die grafische Benutzeroberfläche (GUI) könnte Multitasking und maximal reagieren. Alle Operationen auf Betriebssystemebene wurden vom zugrunde liegenden Betriebssystem bereitgestellt: MS-DOS. Alle Dienste auf höherer Ebene wurden von Windows Libraries "Dynamic Link Library" bereitgestellt. Die Zeichnung API, Grafikgerätschnittstelle (GDI), wurde in einer DLL genannten DLL implementiert Gdi.exe, die Benutzeroberfläche in User.exe. Diese zusätzlichen Schichten über DOS mussten alle laufenden Windows-Programme geteilt werden, nicht nur, um Windows in einer Maschine mit weniger als einem Megabyte RAM zu ermöglichen, sondern die Programme zu ermöglichen, miteinander zusammenzuarbeiten. Der Code in GDI musste die Zeichnungsbefehle in Operationen auf bestimmten Geräten übersetzen. Auf dem Display musste es Pixel im Rahmenpuffer manipulieren. Beim Zeichnen eines Druckers musste die API -Anrufe in Anfragen an einen Drucker umgewandelt werden. Obwohl es möglich gewesen sein könnte, eine begrenzte Geräte fest codiert zu unterstützen (wie die Farbgrafikadapter Anzeige, HP LaserJet Druckerbefehlssprache) Microsoft wählte einen anderen Ansatz. GDI würde funktionieren, indem sie verschiedene Codesteile laden, die genannt werden ""Gerätetreiber", um mit verschiedenen Ausgabegeräten zu arbeiten.

Das gleiche architektonische Konzept, das es GDI ermöglichte, verschiedene Gerätetreiber zu laden Windows Shell So laden Sie verschiedene Windows -Programme und für diese Programme, um API -Aufrufe von der gemeinsam genutzten Benutzer- und GDI -Bibliotheken aufzurufen. Dieses Konzept war "dynamisches Verknüpfen".

In einem konventionellen Nicht-Stamm Statische BibliothekCodeabschnitte werden einfach zum aufrufenden Programm hinzugefügt, wenn seine ausführbare Datei in der "Verknüpfung" -Phase erstellt wird. Wenn zwei Programme dieselbe Routine nennen, ist die Routine während der Verknüpfungsphase der beiden in beiden Programmen enthalten. Mit der dynamischen Verknüpfung wird der gemeinsame Code in eine einzelne, separate Datei gegeben. Die Programme, die diese Datei aufrufen, sind zum Laufzeit mit dem Betriebssystem (oder im Fall von frühen Windows-Versionen der OS-Extension) die Bindung durchführen.

Für diese frühen Versionen von Windows (1.0 bis 3.11) waren die DLLs die Grundlage für die gesamte GUI. Daher waren die Display -Treiber lediglich DLLs mit einer .DRV -Erweiterung, die benutzerdefinierte Implementierungen derselben Zeichnungs -API über eine einheitliche lieferte Gerätetreiber Die Schnittstelle (DDI) und die APIs von Drawing (GDI) und GUI (Benutzer) waren lediglich die von GDI und Benutzer exportierten Funktionsaufrufe, System -DLLs mit .exe -Erweiterung.

Dieser Begriff, das Betriebssystem aus einer Sammlung dynamisch belasteter Bibliotheken aufzubauen, ist ein Kernkonzept von Windows, das bis 2015 anhält. DLLs bieten die Standardvorteile von gemeinsame Bibliotheken, wie zum Beispiel Modularität. Mit der Modularität können Änderungen an Code und Daten in einer einzigen in sich geschlossenen DLL vorgenommen werden, die von mehreren Anwendungen ohne Änderung der Anwendungen selbst geteilt wird.

Ein weiterer Vorteil der Modularität ist die Verwendung generischer Schnittstellen für Plug-Ins. Es kann eine einzelne Schnittstelle entwickelt werden, mit der sowohl alte als auch neue Module zur Laufzeit nahtlos in bereits bestehende Anwendungen integriert werden können, ohne dass die Anwendung selbst geändert wird. Dieses Konzept der dynamischen Erweiterbarkeit wird mit dem extrem geführt Komponentenobjektmodelldie Grundlagen von ActiveX.

In Windows 1.x, 2.x und 3.x haben alle Windows -Anwendungen denselben Adressraum sowie denselben Speicher geteilt. Eine DLL wurde nur einmal in diesen Adressraum geladen; Von da an haben alle Programme mit der Bibliothek darauf zugegriffen. Die Daten der Bibliothek wurden in allen Programmen übertragen. Dies könnte als indirekte Form von verwendet werden Interprozesskommunikationoder es könnte versehentlich die verschiedenen Programme korrumpieren. Mit der Einführung von 32-Bit Bibliotheken in Windows 95Jeder Prozess lief in seinem eigenen Adressraum. Während der DLL -Code möglicherweise geteilt werden kann, sind die Daten privat, außer wenn gemeinsam genutzte Daten von der Bibliothek explizit angefordert werden. Das heißt, große Teile von Windows 95, Windows 98 und Fenster mich wurden aus 16-Bit-Bibliotheken gebaut, was die Leistung der Pentium Pro Der Mikroprozessor wurde beim Start und letztendlich die Stabilität und Skalierbarkeit der DOS-basierten Versionen von Windows eingeschränkt.

Obwohl DLLs der Kern der Windows -Architektur sind, haben sie mehrere Nachteile, die gemeinsam genannt werden. "Dll Hölle".[2] Ab 2015 Microsoft fördert .NET Framework Als eine Lösung für die Probleme der DLL-Hölle, obwohl sie jetzt virtualisierungsbasierte Lösungen wie z. Microsoft Virtual PC und Microsoft Application Virtualisierung, weil sie eine überlegene Isolation zwischen Anwendungen bieten. Eine alternative Minderungslösung für DLL Hell war die Implementierung Seite an Seite Montage.

Merkmale

Da DLLs im Wesentlichen die gleichen wie EXES sind, ist die Wahl, deren Wahl als Teil des Verknüpfungsprozesses erzeugt werden kann, um Klarheit zu erzeugen, da es möglich ist, Funktionen und Daten von beiden zu exportieren.

Es ist nicht möglich, eine DLL direkt auszuführen, da ein EXE für das Betriebssystem erforderlich ist, um sie durch eine zu laden EinstiegspunktDaher das Vorhandensein von Dienstprogrammen wie Rundll.exe oder Rundll32.exe, die den Einstiegspunkt und das minimale Rahmen für DLLs bieten, die genügend Funktionen enthalten, um ohne viel Unterstützung auszuführen.

DLLs bieten einen Mechanismus für gemeinsam genutzten Code und Daten, sodass ein Entwickler gemeinsamer Codes/Daten die Funktionalität aufrüsten kann, ohne dass Anwendungen erneut verknüpft oder neu kompiliert werden müssen. Aus Sicht der Anwendungsentwicklung können Windows und OS/2 als eine Sammlung von DLLs angesehen werden, die aktualisiert werden, sodass Anwendungen für eine Version des Betriebssystems in einem späteren funktionieren, vorausgesetzt, der Betriebssystemanbieter hat sichergestellt, Schnittstellen und Funktionen sind kompatibel.

DLLs werden im Speicherraum des Anrufprozesses und mit den gleichen Zugriffsberechtigungen ausgeführt, was bedeutet, dass deren Nutzung wenig Overhead enthält, aber auch, dass es keinen Schutz für das Anrufprogramm gibt, wenn die DLL irgendeine Art von Fehler hat.

Speicherverwaltung

Im Windows -API, DLL -Dateien sind in organisiert in Abschnitte. Jeder Abschnitt verfügt über eigene Attribute, z.

Der Code in einer DLL wird normalerweise unter allen Prozessen geteilt, die die DLL verwenden. Das heißt, sie nehmen einen einzelnen Ort im physischen Gedächtnis ein und nehmen keinen Platz in der Datei Datei. Windows verwendet nicht Positionsunabhängiger Code für seine DLLs; Stattdessen wird der Code unterzogen Verlegung Wenn es geladen ist, werden Adressen für alle seine Einstiegspunkte an Stellen festgelegt, die im Speicherraum des ersten Vorgangs frei sind, um die DLL zu laden. In älteren Versionen von Windows, bei denen alle laufenden Prozesse einen einzelnen gemeinsamen Adressraum belegten, würde eine einzige Kopie des DLL -Codes für alle Prozesse immer ausreichen. In neueren Versionen von Windows, die für jedes Programm separate Adressräume verwenden, ist es jedoch nur möglich, dasselbe umgestaltete Kopie der DLL in mehreren Programmen zu verwenden, wenn jedes Programm über die gleichen virtuellen Adressen verfügt, die kostenlos für den Code des DLL kosten. Wenn einige Programme (oder ihre Kombination aus bereits beladenen DLLs) diese Adressen nicht kostenlos haben, muss eine zusätzliche physische Kopie des DLL-Codes erstellt werden, wobei eine andere Reihe von Umstiegspunkten verwendet werden. Wenn der physische Speicher, der durch einen Codeabschnitt besetzt ist, zurückerobert werden soll, werden seine Inhalte verworfen und später nach Bedarf direkt aus der DLL -Datei neu geladen.

Im Gegensatz zu Codeabschnitten sind die Datenabschnitte einer DLL normalerweise privat; Das heißt, jeder Prozess, der die DLL unter Verwendung der DLL -Kopie aller Daten der DLL hat. Optional können Datenabschnitte gemeinsam genutzt werden, was zulässt Interprozesskommunikation über diesen gemeinsamen Speicherbereich. Da Benutzerbeschränkungen jedoch nicht für die Verwendung des gemeinsam genutzten DLL -Speichers gelten, wird ein a erstellt. Sicherheitsloch; Ein Prozess kann nämlich die gemeinsam genutzten Daten beschädigen, die wahrscheinlich dazu führen, dass alle anderen Freigabes -Prozesse sich unerwünscht verhalten. Ein Prozess, der unter einem Gastkonto ausgeführt wird, kann beispielsweise auf diese Weise einen weiteren Prozess verderben, der unter einem privilegierten Konto ausgeführt wird. Dies ist ein wichtiger Grund, um die Verwendung gemeinsamer Abschnitte in DLLs zu vermeiden.

Wenn eine DLL von sicher komprimiert wird Ausführbare Packer (z.B. Upx) alle ihre Codeabschnitte werden als Lesen und Schreiben markiert und werden ungeschherzt sein. Lese- und Schreibcode-Abschnitte, ähnlich wie private Datenabschnitte, sind für jeden Prozess privat. Daher sollten DLLs mit gemeinsam genutzten Datenabschnitten nicht komprimiert werden, wenn sie gleichzeitig von mehreren Programmen verwendet werden sollen, da jede Programminstanz eine eigene Kopie der DLL tragen müsste, was zu einem erhöhten Speicherverbrauch führt.

Bibliotheken importieren

Wie statische Bibliotheken werden Importbibliotheken für DLLs von der festgestellt .lib Dateierweiterung. Zum Beispiel, kernel32.dllDie primäre dynamische Bibliothek für Windows -Basisfunktionen wie Dateierstellung und Speicherverwaltung ist über die Überwachung der Basisfunktionen von Windows übernommen Kernel32.lib. Die übliche Möglichkeit, eine Importbibliothek aus einer ordnungsgemäßen statischen Bibliothek zu unterscheiden, ist nach Größe: Die Importbibliothek ist viel kleiner, da sie nur Symbole enthält, die sich auf die tatsächliche DLL beziehen, die zur Verknüpfungszeit verarbeitet werden sollen. Beide sind dennoch Unix ar Formatdateien.

Die Verknüpfung mit dynamischen Bibliotheken wird normalerweise durch Verknüpfung mit einer Importbibliothek beim Erstellen oder Verknüpfen, um eine ausführbare Datei zu erstellen, durch Verknüpfen behandelt. Die erstellte ausführbare Datei enthält dann eine Importadressetabelle (IAT), auf die alle DLL -Funktionsaufrufe referenziert werden (jede Referenz -DLL -Funktion enthält einen eigenen Eintrag im IAT). Zur Laufzeit ist das IAT mit geeigneten Adressen gefüllt, die direkt auf eine Funktion in der separat geladenen DLL verweisen.[3]

In Cygwin/MSYs und Mingw werden Importbibliotheken herkömmlicherweise das Suffix gegeben .dll.aKombinieren Sie sowohl das Windows DLL -Suffix als auch das UNIX AR -Suffix. Das Dateiformat ist ähnlich, die zum Markierung der Importe verwendeten Symbole sind jedoch unterschiedlich (_head_foo_dll vs __Import_descriptor_foo).[4] Obwohl es ist Gnu binutils Toolchain kann Importbibliotheken generieren und mit ihnen verknüpfen. Es ist schneller, direkt mit der DLL zu verknüpfen.[5] Ein experimentelles Werkzeug in Mingw namens Genlib kann verwendet werden, um Import-LIBs mit Symbolen im MSVC-Stil zu erzeugen.

Symbolauflösung und Bindung

Jede von einer DLL exportierte Funktion wird durch einen numerischen Ordinal und optional ein Name identifiziert. Ebenso können Funktionen entweder nach Ordinal oder mit Namen aus einer DLL importiert werden. Die Ordinal repräsentiert die Position des Adresszeigers der Funktion in der DLL -Exportadresse. Es ist üblich, dass interne Funktionen nur durch Ordinal exportiert werden. Für die meisten Windows -API -Funktionen sind nur die Namen über verschiedene Windows -Releases erhalten. Die Verordnungen können sich ändern. Somit kann man Windows -API -Funktionen nach ihren Ordnern nicht zuverlässig importieren.

Das Importieren von Funktionen nach Ordinal bietet nur geringfügig bessere Leistung als das Importieren mit Namen: Exporttabellen von DLLs werden mit Namen bestellt, also a binäre Suche Kann verwendet werden, um eine Funktion zu finden. Der Index des gefundenen Namens wird dann verwendet, um die Ordinal in der Export -Ordinal -Tabelle nachzuschlagen. In 16-Bit-Fenstern wurde die Namenstabelle nicht sortiert, sodass der Name der Namensuche viel spürbarer war.

Es ist auch möglich binden Eine ausführbare Datei in eine bestimmte Version einer DLL, dh die Lösung der Adressen der importierten Funktionen zur Kompilierungszeit. Für gebundene Importe die Linker Speichert den Zeitstempel und die Prüfsumme der DLL, an die der Import gebunden ist. Zur Laufzeit prüft Windows, um festzustellen, ob dieselbe Version der Bibliothek verwendet wird, und wenn ja, umgeht Windows die Verarbeitung der Importe. Andernfalls verarbeitet Windows die Importe auf normale Weise, wenn sich die Bibliothek von derjenigen unterscheidet.

Bound Executables laden etwas schneller, wenn sie in derselben Umgebung ausgetragen werden, für die sie zusammengestellt wurden, und genau zur gleichen Zeit, wenn sie in einer anderen Umgebung ausgeführt werden. Daher gibt es keinen Nachteil für die Bindung der Importe. Beispielsweise sind alle Standard -Windows -Anwendungen an die System -DLLs ihrer jeweiligen Windows -Version gebunden. Eine gute Gelegenheit, die Importe einer Anwendung an seine Zielumgebung zu binden, besteht in der Installation der Anwendung. Dies hält die Bibliotheken bis zum nächsten Betriebssystem -Update "gebunden". Es ändert jedoch die Prüfsumme der ausführbaren Datei, sodass nicht mit signierten Programmen oder Programmen durchgeführt werden kann, die von einem Konfigurationsmanagement -Tool verwaltet werden, das Prüfsummen verwendet (wie z. MD5 Überprüfungen) zum Verwalten von Dateiversionen. Da neuere Windows -Versionen sich von festen Adressen für jede geladene Bibliothek abgeschlossen haben (aus Sicherheitsgründen), nimmt die Möglichkeit und der Wert der Bindung einer ausführbaren Datei ab.

Explizite Laufzeitverknüpfung

DLL-Dateien können zur Laufzeit explizit geladen werden, ein Prozess, der einfach als als bezeichnet wird Laufzeitdynamikverknüpfung von Microsoft mit der Verwendung der Lastlibrary (oder Lastlibraryex) API -Funktion. Das GetProcaddress Die API -Funktion wird verwendet, um exportierte Symbole nach Namen zu suchen, und Freiberufler - Um die DLL zu entladen. Diese Funktionen sind analog zu DLOPEN, dlsym, und dlclose in dem Posix Standard -API.

Das Verfahren für eine explizite Laufzeitverknüpfung ist in jeder Sprache gleich, die unterstützt Zeiger auf Funktionen, da es von der abhängt Windows -API eher als Sprachkonstrukte.

Verzögerte Belastung

Normalerweise wird eine Anwendung, die mit der Importbibliothek einer DLL verknüpft ist, nicht starten, wenn die DLL nicht gefunden werden kann, da Windows die Anwendung nicht ausführt, es sei denn, sie kann alle DLLs finden, die die Anwendung benötigt. Eine Anwendung kann jedoch mit einer Importbibliothek verknüpft werden, um eine verzögerte Belastung der dynamischen Bibliothek zu ermöglichen.[6] In diesem Fall versucht das Betriebssystem nicht, die DLL zu finden oder zu laden, wenn die Anwendung startet. Stattdessen wird vom Linker ein Stub in der Anwendung enthalten, mit der versucht wird, die DLL durchzuführen und zu laden Lastlibrary und GetProcaddress Wenn eine seiner Funktionen aufgerufen wird. Wenn die DLL nicht gefunden oder geladen oder die aufgerufene Funktion nicht vorhanden ist, generiert die Anwendung eine Ausnahme, die angemessen gefangen und gehandhabt werden kann. Wenn die Anwendung die Ausnahme nicht behandelt, wird sie vom Betriebssystem erfasst, wodurch das Programm mit einer Fehlermeldung beendet wird.

Der verzögerte Belastungsmechanismus liefert auch Benachrichtigung Haken, sodass die Anwendung eine zusätzliche Verarbeitung durchführen kann oder Fehlerbehandlung Wenn die DLL geladen wird und/oder eine DLL -Funktion aufgerufen wird.

Compiler- und Sprachüberlegungen

Delphi

In einer Quelldatei das Schlüsselwort Bibliothek wird anstelle von verwendet Programm. Am Ende der Datei sind die zu exportierenden Funktionen in aufgeführt Exporte Klausel.

Delphi braucht nicht Lib Dateien zum Importieren von Funktionen aus DLLs; um zu einer DLL zu verlinken, die extern Das Schlüsselwort wird in der Funktionserklärung verwendet, um den DLL -Namen zu signalisieren, gefolgt von Name um das Symbol zu nennen (falls anders) oder Index Um den Index zu identifizieren.

Microsoft Visual Basic

Im Visual Basic (VB) wird nur eine Laufzeitverknüpfung unterstützt. aber zusätzlich zur Verwendung Lastlibrary und GetProcaddress API -Funktionen, Erklärungen von importierten Funktionen sind erlaubt.

Beim Importieren von DLL-Funktionen durch Deklarationen generiert VB einen Laufzeitfehler, wenn der DLL Datei kann nicht gefunden werden. Der Entwickler kann den Fehler fangen und angemessen umgehen.

Beim Erstellen von DLLs in VB ermöglicht die IDE nur die Erstellung von ActiveX -DLLs, es wurden jedoch Methoden erstellt[7] Damit der Benutzer dem Linker explizit anweisen kann, eine .DEF -Datei einzuschließen, die die Ordnungsposition und den Namen jeder exportierten Funktion definiert. Auf diese Weise kann der Benutzer eine Standard -Windows -DLL unter Verwendung von Visual Basic (Version 6 oder niedriger) erstellen, auf die über eine "Declare" -Anweisung verwiesen werden kann.

C und C ++

Microsoft Visuell c ++ (MSVC) liefert mehrere Erweiterungen für Standard C ++ Dadurch können Funktionen als importiert oder direkt im C ++ - Code importiert oder exportiert werden; Diese wurden von anderen Fenstern übernommen C und C ++ - Compiler, einschließlich Windows -Versionen von GCC. Diese Erweiterungen verwenden das Attribut __declspec vor einer Funktionserklärung. Beachten EXTERN "C" In C ++ - Code, um den Compiler darüber zu informieren, dass die C -Verknüpfung verwendet werden sollte.[8]

Neben der Angabe importierter oder exportierter Funktionen verwendet __declspec Attribute können sie im Abschnitt importieren oder exportieren Def Datei verwendet vom Projekt. Das Def Die Datei wird eher vom Linker als vom Compiler verarbeitet und ist daher nicht spezifisch für C ++.

Die DLL -Zusammenstellung produziert beide DLL und Lib Dateien. Das Lib Datei (Importbibliothek) wird verwendet, um bei der Kompilierung mit einer DLL zu verknüpfen. Es ist für die Laufzeitverbindung nicht erforderlich. Es sei denn, die DLL ist a Komponentenobjektmodell (Com) Server, der DLL Die Datei muss in einem der in der Pfadumgebungsvariablen aufgeführten Verzeichnisse im Standardsystemverzeichnis oder im selben Verzeichnis wie das Programm verwendet werden. COM Server -DLLs werden mit regsvr32.exe registriert, wodurch der Standort des DLL und seine global eindeutige ID (ID (Guid) in der Registrierung. Programme können dann die DLL verwenden, indem sie ihre GUID in der nachschlagen Registrierung So finden Sie seinen Standort oder erstellen Sie eine Instanz des COM -Objekts indirekt anhand seiner Klassenkennung und der Schnittstellenkennung.

Programmierbeispiele

Verwenden von DLL -Importen

Die folgenden Beispiele zeigen, wie sprachspezifische Bindungen verwendet werden, um Symbole für die Verknüpfung mit einer DLL bei der Kompilierungszeit zu importieren.

Delphi 

{$ AppType Console} Programm Beispiel; // Funktion importieren, die zwei Zahlen hinzufügt Funktion Addnumbers(a, b : Doppelt): Doppelt; Stdcall; extern 'Beispiel.dll'; // Hauptprogramm var  R: Doppelt; Start  R : = Addnumbers(1, 2);  Writeln('Das Ergebnis war: ', R); Ende.

C

Beispiel.LIB -Datei muss in das Projekt (vorhandene Element -Option für das Projekt hinzufügen!) Vor der statischen Verknüpfung enthalten sein (vorausgesetzt. Das Dateibeispiel.lib wird beim Kompilieren der DLL automatisch vom Compiler generiert. Die obige Erklärung nicht auszuführen würde verursachen Verknüpfungsfehler Da der Linker nicht weiß, wo er die Definition von Addnumbers finden soll. Das dll -Beispiel.dll muss möglicherweise auch an den Ort kopiert werden, an dem die .exe -Datei durch den folgenden Code generiert wird.

#enthalten  #enthalten  // Funktion importieren, die zwei Zahlen hinzufügt extern "C" __declspec(dllimport) doppelt Addnumbers(doppelt a, doppelt b); int hauptsächlich(int argc, verkohlen *argv[]) {   doppelt Ergebnis = Addnumbers(1, 2);   printf("Das Ergebnis war: %f\n", Ergebnis);   Rückkehr 0; }

Verwenden einer expliziten Laufzeitverknüpfung

Die folgenden Beispiele zeigen, wie die Lade- und Verknüpfungsmöglichkeiten für die Laufzeit mithilfe von sprachspezifischen Windows-API-Bindungen verwendet werden.

Beachten Sie, dass alle vier Proben anfällig für Dll VorspannungsangriffeDa Beispiel.dll an einen vom Autor nicht beabsichtigten Ort gelöst werden kann (das aktuelle Arbeitsverzeichnis geht Vor Systembibliotheksstandorte) und damit zu einer böswilligen Version der Bibliothek. In der Referenz finden Sie die Anleitung von Microsoft zum Laden der sicheren Bibliothek: Man sollte verwenden SetDllDirectoryW in kernel32 So entfernen Sie die aktuelle Verzeichnis-Lookup, bevor Bibliotheken geladen werden.[9]

Microsoft Visual Basic 

Möglichkeit Explizit Erklären Funktion Addnumbers Lib "Beispiel.dll" _(Byval a Wie Doppelt, Byval b Wie Doppelt) Wie Doppelt Sub Hauptsächlich() 	Schwach Ergebnis Wie Doppelt 	Ergebnis = Addnumbers(1, 2) 	Debuggen.Drucken "Das Ergebnis war: " & Ergebnis Ende Sub

Delphi 

Programm Beispiel;  {$ AppType Console}  Verwendet Fenster;  var  Addnumbers:Funktion (a, b: ganze Zahl): Doppelt; Stdcall;  Libhandle:Hmodule; Start  Libhandle : = Lastlibrary('Beispiel.dll');  wenn Libhandle <> 0 dann  Addnumbers : = GetProcaddress(Libhandle, "Addnumbers");  wenn Zugewiesen(Addnumbers) dann  Writeln( '1 + 2 =', Addnumbers( 1, 2 ) );  Readln; Ende.

C 

#enthalten  #enthalten  // DLL -Funktionssignatur Typedef doppelt (*Importfunktion) (doppelt, doppelt); int hauptsächlich(int argc, verkohlen **argv) { 	Importfunktion Addnumbers; 	doppelt Ergebnis; 	Hinstanz Hinstlib; 	// DLL -Datei laden 	Hinstlib = Lastlibrary(TEXT("Beispiel.dll")); 	wenn (Hinstlib == NULL) { 		printf("Fehler: DLL kann nicht geladen werden\n"); 		Rückkehr 1; 	} 	// Funktionszeiger abrufen 	Addnumbers = (Importfunktion) GetProcaddress(Hinstlib, "Addnumbers"); 	wenn (Addnumbers == NULL) { 		printf("Fehler: DLL -Funktion kann nicht gefunden werden\n"); 		Freiberufler(Hinstlib); 		Rückkehr 1; 	} 	// Aufruffunktion. 	Ergebnis = Addnumbers(1, 3); 	// DLL -Datei entladen 	Freiberufler(Hinstlib); 	// Ergebnis anzeigen 	printf("Das Ergebnis war: %f\n", Ergebnis); 	Rückkehr 0; }

Python

Die Python CTypes -Bindung verwendet POSIX -API auf POSIX -Systemen.

importieren Ctypes my_dll = Ctypes.CDLL.Lastlibrary("Beispiel.dll") # Die folgende "Restyp" -Methodespezifikation ist erforderlich, um vorzunehmen # Python verstehen, welcher Typ von der Funktion zurückgegeben wird. my_dll.Addnumbers.Restyp = Ctypes.c_double p = my_dll.Addnumbers(Ctypes.c_double(1.0), Ctypes.c_double(2.0)) drucken("Das Ergebnis war:", p)

Komponentenobjektmodell

Das Komponentenobjektmodell (Com) definiert einen binären Standard, um die Implementierung von zu hosten Objekte In DLL- und EXE -Dateien. Es bietet Mechanismen, um diese Dateien sowie eine sprachunabhängige und maschinenlesbare Beschreibung der Schnittstelle zu lokalisieren und zu verstellen. Das Hosting von COM -Objekten in einer DLL ist leichter und ermöglicht es ihnen, Ressourcen mit dem Kundenprozess zu teilen. Dies ermöglicht COM-Objekten, leistungsstarke Back-Ends für einfache GUI-Frontenden wie Visual Basic und ASP zu implementieren. Sie können auch aus Skriptsprachen programmiert werden.[10]

DLL Hijacking

Aufgrund eines Verletzlichkeit Viele Programme werden allgemein als DLL -Hijacking, DLL -Spoofing, DLL -Prelading oder Binäranlagen bezeichnet. Viele Programme laden und führen eine böswillige DLL aus, die im selben Ordner wie eine von diesen Programmen geöffnete Datendatei enthalten ist.[11][12][13][14] Die Verwundbarkeit wurde von Georgi Guninski im Jahr 2000 entdeckt.[15] Im August 2010 erlangte es weltweite Werbung, nachdem Acros Security es erneut entdeckt hatte und viele Hundertprogramme als verletzlich befunden wurden.[16] Programme, die von unsicheren Standorten ausgeführt werden, d. H. Benutzerverschreibbare Ordner wie die Downloads oder der Temperatur Verzeichnis sind fast immer anfällig für diese Sicherheitsanfälligkeit.[17][18][19][20][21][22][23]

Siehe auch

Verweise

  • Hart, Johnson. Windows -Systemprogrammierung dritte Ausgabe. Addison-Wesley, 2005. ISBN0-321-25619-0.
  • Rektor, Brent et al. Win32 -Programmierung. Addison-Wesley Developers Press, 1997. ISBN0-201-63492-9.

Externe Links

  1. ^ Microsoft Corporation. "Erstellen einer Ressourcen-DLL". Microsoft Developer Network Library.
  2. ^ "Das Ende der Hölle". Microsoft Corporation. Archiviert von das Original am 2008-05-06. Abgerufen 2009-07-11.
  3. ^ "Verständnis der Importadressetabelle".
  4. ^ "Aufbau und Verwendung von DLLs". Die Importbibliothek ist eine regelmäßige Unix-ähnliche .a-Bibliothek, enthält jedoch nur die winzigen Informationen, die erforderlich sind, um dem Betriebssystem zu sagen, wie das Programm mit ("Importe") der DLL interagiert. Diese Informationen sind mit .exe verknüpft.
  5. ^ "LD und Win32". LD -Dokumentation.
  6. ^ "Linker-Unterstützung für verzögerte DLLs". Microsoft Corporation. Abgerufen 2009-07-11.
  7. ^ Petrush, Ron (2005-04-26). "Erstellen einer Windows -DLL mit Visual Basic". O'Reilly Media. Abgerufen 2009-07-11.
  8. ^ MsdnVerwenden Sie extern, um die Verknüpfung anzugeben
  9. ^ "Sicheres Laden von Bibliotheken, um DLL -Vorspannungsangriffe zu verhindern". Microsoft -Unterstützung. Abgerufen 28. Oktober 2019.
  10. ^ Satran, Michael. "Komponentenobjektmodell (com)". msdn.microsoft.com.
  11. ^ DLL -Spoofing in Windows
  12. ^ "Dll Vorspannungsangriffe". msdn.com. Abgerufen 25. März 2018.
  13. ^ "Weitere Informationen über den DLL -Vorspannungs -Remote -Angriffsvektor". technet.com. Abgerufen 25. März 2018.
  14. ^ "Ein Update über den DLL-Preloading Remote Attack Vector". technet.com. Abgerufen 25. März 2018.
  15. ^ "Doppelklicken auf MS -Office -Dokumente von Windows Explorer kann in einigen Fällen beliebige Programme ausführen.". www.guninski.com. Abgerufen 25. März 2018.
  16. ^ "Binärer Pflanzen - Die offizielle Website einer vergessenen Verwundbarkeit. Acros Security". www.binaryplanting.com. Abgerufen 25. März 2018.
  17. ^ Teppichbomben- und Verzeichnisvergiftung
  18. ^ "Dev to Mozilla: Bitte entlasten Sie alte Fenster Installationsprozesse". dadurch.co.uk. Abgerufen 25. März 2018.
  19. ^ "GPG4Win-Sicherheitsberatung GPG4Win 2015-11-25". www.gpg4win.org. Abgerufen 25. März 2018.
  20. ^ "McAfee KB-McAfee Security Bulletin: Security Patch für mehrere McAfee-Installateure und -deinstallieren (CVE-2015-8991, CVE-2015-8992 und CVE-2015-8993) (TS102462)". service.mcafee.com. Abgerufen 25. März 2018.
  21. ^ "FSC-2015-4-F-Secure Labs". www.f-secure.com. Archiviert von das Original am 31. Juli 2017. Abgerufen 25. März 2018.
  22. ^ "Scannow DLL -Suchreihenfolge zur Verletzlichkeit und Abschaltung entführt". Rapid7.com. 21. Dezember 2015. Abgerufen 25. März 2018.
  23. ^ Team, Veracrypt. "OSS-SEC: CVE-2016-1281: TrueCrypt- und Veracrypt-Windows-Installateure ermöglichen eine willkürliche Codeausführung mit Anstieg der Privilegien". Seclists.org. Abgerufen 25. März 2018.