Knihovna dynamických odkazů - Dynamic-link library

Tento článek je o implementaci OS/2 a Windows. Dynamické propojení knihoven obecně viz Dynamický linker .
Nesmí být zaměňována s dynamicky načtenou knihovnou .
Knihovna dynamických odkazů
Dll png.png
Přípona názvu souboru
.dll
Typ internetového média
application/vnd.microsoft.portable-spustitelný soubor
Jednotný identifikátor typu (UTI) com.microsoft.windows-dynamic-link-library
Kouzelné číslo MZ
Vyvinuto Microsoft
Kontejner pro Sdílená knihovna

Dynamická knihovna ( DLL ) je Microsoft je realizace sdílené knihovny koncepce v Microsoft Windows a OS / 2 operační systémy . Tyto knihovny mají obvykle příponu souboru DLL , OCX(pro knihovny, které obsahují prvky ActiveX ovládací prvky), nebo DRV(pro starší řidiče systému ). Formáty souborů pro knihovny DLL jsou stejné jako pro soubory EXE systému Windows -tj. Přenosný spustitelný soubor (PE) pro 32bitová a 64bitová okna a nový spustitelný soubor (NE) pro 16bitové systémy Windows. Stejně jako u EXE mohou DLL obsahovat kód , data a prostředky v jakékoli kombinaci.

Datové soubory se stejným formátem souboru jako knihovna DLL, ale s různými příponami souborů a případně obsahující pouze oddíly prostředků, lze nazvat prostředky DLL . Mezi příklady takových knihoven DLL patří knihovny ikon , někdy s příponou ICL, a soubory písem s příponami FONa FOT.

Pozadí

První verze systému Microsoft Windows provozovaly programy společně v jednom adresním prostoru . Každý program měl spolupracovat poskytnutím CPU jiným programům, aby grafické uživatelské rozhraní (GUI) mohlo provádět více úkolů a bylo maximálně responzivní. Všechny operace na úrovni operačního systému zajišťoval základní operační systém: MS-DOS . Všechny služby vyšší úrovně poskytovala knihovna Windows „Dynamic Link Library“. Drawing API , Graphics Device Interface (GDI), bylo implementováno do knihovny DLL s názvem GDI.EXEuživatelské rozhraní v USER.EXE. Tyto další vrstvy na DOSu musely být sdíleny ve všech běžících programech Windows, a to nejen proto, aby systém Windows mohl pracovat v počítači s méně než megabajtem RAM, ale také umožnit vzájemnou spolupráci programů. Kód v GDI potřebný k překladu výkresových příkazů do operací na konkrétních zařízeních. Na displeji muselo manipulovat s pixely ve vyrovnávací paměti snímků. Při kreslení na tiskárnu bylo nutné volání API převést na požadavky na tiskárnu. Ačkoli bylo možné poskytnout pevně zakódovanou podporu omezené sadě zařízení (například displej s barevným grafickým adaptérem , příkazový jazyk tiskárny HP LaserJet ), společnost Microsoft zvolila jiný přístup. GDI bude fungovat tak, že načte různé části kódu, nazývané „ ovladače zařízení “, aby fungovalo s různými výstupními zařízeními.

Stejný architektonický koncept, který umožňoval GDI načítat různé ovladače zařízení, je ten, který umožňoval prostředí Windows načítat různé programy Windows a pro tyto programy vyvolávat volání API ze sdílených knihoven USER a GDI. Tou koncepcí bylo „dynamické propojení“.

V konvenční nesdílené statické knihovně jsou části kódu jednoduše přidány do volajícího programu, když je jeho spustitelný soubor vytvořen ve fázi „propojení“; pokud dva programy volají stejnou rutinu, rutina je zahrnuta v obou programech během fáze propojení těchto dvou. S dynamickým propojováním je sdílený kód umístěn do jednoho samostatného souboru. Programy, které tento soubor nazývají, jsou k němu připojeny za běhu, přičemž vazbu provádí operační systém (nebo v případě dřívějších verzí systému Windows rozšíření OS).

U těchto raných verzí systému Windows (1.0 až 3.11) byly knihovny DLL základem celého grafického uživatelského rozhraní. Jako takové byly ovladače zobrazení pouze knihovnami DLL s příponou .DRV, která poskytovala vlastní implementace stejného rozhraní API pro kreslení prostřednictvím jednotného rozhraní ovladače zařízení (DDI), a rozhraní API pro kreslení (GDI) a GUI (USER) byla pouze exportem volání funkcí od GDI a USER, systémové knihovny DLL s příponou .EXE.

Tato představa o vybudování operačního systému ze sbírky dynamicky načtených knihoven je základním konceptem systému Windows, který přetrvává od roku 2015. Knihovny DLL poskytují standardní výhody sdílených knihoven , například modularitu . Modularita umožňuje provádět změny v kódu a datech v jedné samostatné knihovně DLL sdílené několika aplikacemi bez jakékoli změny samotných aplikací.

Další výhodou modularity je použití obecných rozhraní pro moduly plug-in. Může být vyvinuto jediné rozhraní, které umožňuje bezproblémovou integraci starých i nových modulů za běhu do již existujících aplikací bez jakékoli úpravy samotné aplikace. Tento koncept dynamické rozšiřitelnosti je s komponentním objektovým modelem , základem ActiveX, dotažen do extrému .

Ve Windows 1.x, 2.xa 3.x sdílely všechny aplikace Windows stejný adresní prostor a stejnou paměť. DLL byla do tohoto adresního prostoru načtena pouze jednou; od té doby k němu přistupovaly všechny programy využívající knihovnu. Data knihovny byla sdílena ve všech programech. To by mohlo být použito jako nepřímá forma meziprocesové komunikace , nebo by to mohlo omylem poškodit různé programy. Se zavedením 32bitových knihoven v systému Windows 95 běžel každý proces ve svém vlastním adresním prostoru. Zatímco kód DLL může být sdílen, data jsou soukromá s výjimkou případů, kdy jsou sdílená data výslovně požadována knihovnou. To znamená, že velké řady Windows 95 , Windows 98 a Windows Me byly postaveny ze 16bitových knihoven, které při spuštění omezovaly výkon mikroprocesoru Pentium Pro a nakonec omezovaly stabilitu a škálovatelnost verzí Windows založených na DOSu.

Ačkoli jsou knihovny DLL jádrem architektury systému Windows, mají několik nedostatků, souhrnně nazývaných „ DLL peklo “. Od roku 2015 společnost Microsoft propaguje .NET Framework jako jedno řešení problémů DLL pekla, ačkoli nyní propaguje řešení založená na virtualizaci, jako je Microsoft Virtual PC a Microsoft Application Virtualization , protože nabízejí vynikající izolaci mezi aplikacemi. Alternativním zmírňujícím řešením DLL pekla byla implementace sestavení vedle sebe .

Funkce

Vzhledem k tomu, že knihovny DLL jsou v zásadě stejné jako soubory EXE, výběr, který se má vytvářet jako součást procesu propojení, je z důvodu přehlednosti, protože je možné exportovat funkce a data z obou.

Není možné přímo spustit knihovnu DLL, protože vyžaduje, aby ji operační systém EXE načítal přes vstupní bod , a proto existence nástrojů jako RUNDLL.EXE nebo RUNDLL32.EXE, které poskytují vstupní bod a minimální rámec pro knihovny DLL které obsahují dostatek funkcí ke spuštění bez velké podpory.

Knihovny DLL poskytují mechanismus pro sdílený kód a data, což umožňuje vývojáři sdíleného kódu/dat upgradovat funkce, aniž by bylo nutné aplikace znovu propojovat nebo překládat. Z hlediska vývoje aplikací lze Windows a OS/2 považovat za kolekci knihoven DLL, které jsou upgradovány, což umožňuje aplikacím pro jednu verzi operačního systému pracovat v novějších za předpokladu, že dodavatel operačního systému zajistil, že rozhraní a funkce jsou kompatibilní.

Knihovny DLL se spouští v paměťovém prostoru procesu volání a se stejnými přístupovými oprávněními, což znamená, že při jejich použití je malá režie, ale také že neexistuje žádná ochrana pro volající EXE, pokud má knihovna DLL jakýkoli druh chyby.

Správa paměti

V rozhraní Windows API jsou soubory DLL uspořádány do sekcí . Každá sekce má svou vlastní sadu atributů, jako je zapisovatelný nebo jen pro čtení, spustitelný (pro kód) nebo nespustitelný (pro data) atd.

Kód v knihovně DLL je obvykle sdílen mezi všemi procesy, které používají knihovnu DLL; to znamená, že zabírají jedno místo ve fyzické paměti a nezabírají místo v souboru stránky . Windows pro své knihovny DLL nepoužívá kód nezávislý na poloze ; místo toho kód prochází při načítání přemístěním a opravuje adresy pro všechny jeho vstupní body v místech, která jsou volná v paměťovém prostoru prvního procesu načítání knihovny DLL. Ve starších verzích systému Windows, ve kterých všechny spuštěné procesy zabíraly jeden společný adresní prostor, by pro všechny procesy vždy stačila jedna kopie kódu DLL. V novějších verzích systému Windows, které pro každý program používají oddělené adresní prostory, je však možné použít stejnou přemístěnou kopii knihovny DLL ve více programech pouze v případě, že každý program má stejné virtuální adresy, které mohou obsahovat kód DLL. Pokud některé programy (nebo jejich kombinace již načtených knihoven DLL) nemají tyto adresy volné, bude nutné vytvořit další fyzickou kopii kódu knihovny DLL pomocí jiné sady přemístěných vstupních bodů. Pokud má být obnovena fyzická paměť obsazená sekcí kódu, její obsah bude zahozen a později podle potřeby znovu načten přímo ze souboru DLL.

Na rozdíl od sekcí kódu jsou datové sekce knihovny DLL obvykle soukromé; to znamená, že každý proces používající knihovnu DLL má vlastní kopii všech dat knihovny DLL. Volitelně lze datové sekce sdílet, což umožňuje meziprocesovou komunikaci prostřednictvím této oblasti sdílené paměti. Protože se však na používání sdílené paměti DLL nevztahují uživatelská omezení, vytváří to díru v zabezpečení ; totiž jeden proces může poškodit sdílená data, což pravděpodobně způsobí, že se všechny ostatní procesy sdílení budou chovat nežádoucím způsobem. Například proces spuštěný pod účtem hosta může tímto způsobem poškodit jiný proces spuštěný pod privilegovaným účtem. To je důležitý důvod, proč se vyvarovat používání sdílených sekcí v knihovnách DLL.

Pokud je knihovna DLL komprimována určitými spustitelnými balíky (např. UPX ), všechny její sekce kódu jsou označeny jako čtení a zápis a budou sdíleny. Sekce kódu pro čtení a zápis, podobně jako sekce soukromých dat, jsou pro každý proces soukromé. Knihovny DLL se sdílenými datovými sekcemi by tedy neměly být komprimovány, pokud jsou určeny k použití současně více programy, protože každá instance programu by musela nést vlastní kopii knihovny DLL, což by vedlo ke zvýšené spotřebě paměti.

Importovat knihovny

Podobně jako statické knihovny jsou importní knihovny pro knihovny DLL označeny příponou souboru .lib. Například kernel32.dll , primární dynamická knihovna pro základní funkce systému Windows, jako je vytváření souborů a správa paměti, je propojen pomocí souboru kernel32.lib. Obvyklý způsob, jak rozpoznat importní knihovnu ze správné statické knihovny, je podle velikosti: importní knihovna je mnohem menší, protože obsahuje pouze symboly odkazující na skutečnou knihovnu DLL, která má být zpracována v době propojení. Oba jsou nicméně soubory formátu Unix ar .

Propojení s dynamickými knihovnami se obvykle provádí propojením s importovanou knihovnou při vytváření nebo propojením za účelem vytvoření spustitelného souboru. Vytvořený spustitelný soubor pak obsahuje tabulku adres importu (IAT), pomocí které jsou odkazována všechna volání funkcí DLL (každá odkazovaná funkce DLL obsahuje vlastní položku v IAT). Za běhu je IAT naplněn příslušnými adresami, které směřují přímo na funkci v samostatně načtené knihovně DLL.

V Cygwin/MSYS a MinGW jsou importním knihovnám obvykle přidělena přípona .dll.a, která kombinuje příponu Windows DLL a příponu Unix ar. Formát souboru je podobný, ale symboly používané k označení importu jsou různé (_head_foo_dll vs __IMPORT_DESCRIPTOR_foo). Ačkoli jeho nástrojový řetězec GNU Binutils dokáže generovat importní knihovny a propojovat je, je rychlejší se přímo propojit s knihovnou DLL. K vygenerování importních libs pomocí symbolů ve stylu MSVC lze použít experimentální nástroj v MinGW nazvaný genlib.

Rozlišení symbolu a vazba

Každá funkce exportovaná knihovnou DLL je označena číselným pořadovým číslem a volitelně názvem. Podobně lze funkce importovat z knihovny DLL buď podle pořadového čísla, nebo podle názvu. Pořadové číslo představuje pozici ukazatele adresy funkce v tabulce exportní adresy DLL. Je běžné, že interní funkce jsou exportovány pouze pořadovým číslem. U většiny funkcí Windows API jsou v různých verzích Windows zachovány pouze názvy; pořadové číslo se může změnit. Nelze tedy spolehlivě importovat funkce Windows API podle jejich pořadových čísel.

Import funkcí podle pořadového čísla poskytuje jen o něco lepší výkon než import podle názvu: tabulky exportu knihoven DLL jsou seřazeny podle názvu, takže k nalezení funkce lze použít binární vyhledávání . Rejstřík nalezeného jména se pak použije k vyhledání pořadového čísla v tabulce Exportovat pořadové číslo. V 16bitových Windows nebyla tabulka názvů tříděna, takže režie při hledání názvu byla mnohem nápadnější.

Je také možné svázat spustitelný soubor s konkrétní verzí knihovny DLL, tj. Vyřešit adresy importovaných funkcí v době kompilace. U vázaných importů linker uloží časové razítko a kontrolní součet knihovny DLL, ke které je import vázán. Během běhu Windows kontroluje, zda se používá stejná verze knihovny, a pokud ano, Windows obchází zpracování importů. V opačném případě, pokud se knihovna liší od knihovny, ke které byla vázána, Windows zpracovává importy běžným způsobem.

Vázané spustitelné soubory se načítají o něco rychleji, pokud jsou spuštěny ve stejném prostředí, pro které byly kompilovány, a přesně ve stejnou dobu, pokud jsou spuštěny v jiném prostředí, takže neexistuje vazba pro vazbu importů. Například všechny standardní aplikace pro Windows jsou vázány na systémové knihovny DLL příslušné verze systému Windows. Dobrá příležitost svázat importy aplikace s jejím cílovým prostředím je během instalace aplikace. To udržuje knihovny „svázané“ až do příští aktualizace operačního systému. Změní však kontrolní součet spustitelného souboru, takže to nelze provést pomocí podepsaných programů nebo programů, které jsou spravovány nástrojem pro správu konfigurace, který ke správě verzí souborů používá kontrolní součty (například kontrolní součty MD5 ). Vzhledem k tomu, že novější verze systému Windows přestaly mít pevné adresy pro každou načtenou knihovnu (z bezpečnostních důvodů), příležitost a hodnota vazby spustitelného souboru klesá.

Explicitní propojení za běhu

Soubory DLL lze explicitně načíst za běhu, což je proces, kterému společnost Microsoft jednoduše říká dynamické propojení za běhu , pomocí funkce API LoadLibrary(nebo LoadLibraryEx). Funkce GetProcAddressAPI se používá k vyhledávání exportovaných symbolů podle názvu a FreeLibrary- k uvolnění knihovny DLL. Tyto funkce jsou analogické s dlopen, dlsyma dlcloseve standardním API POSIX .

Postup pro explicitní propojení za běhu je stejný v jakémkoli jazyce, který podporuje ukazatele na funkce , protože závisí spíše na jazykovém konstruktu než Windows API .

Zpožděné načítání

Normálně se aplikace, která je propojena s importní knihovnou DLL, nespustí, pokud nelze najít knihovnu DLL, protože systém Windows aplikaci nespustí, pokud nenajde všechny knihovny DLL, které aplikace může potřebovat. Aplikaci však lze propojit s knihovnou importu, aby bylo možné zpožděné načítání dynamické knihovny. V tomto případě se operační systém nepokusí najít nebo načíst knihovnu DLL při spuštění aplikace; místo toho je v aplikaci zahrnut stub linkerem, který se pokusí najít a načíst knihovnu DLL prostřednictvím LoadLibrary a GetProcAddress, když je volána jedna z jejích funkcí. Pokud nelze najít nebo načíst knihovnu DLL nebo volaná funkce neexistuje, aplikace vygeneruje výjimku , která může být zachycena a zpracována odpovídajícím způsobem. Pokud aplikace výjimku nezpracuje, zachytí ji operační systém, který ukončí program s chybovou zprávou.

Zpoždění, zatěžovací mechanismus poskytuje upozornění háčky , což umožňuje aplikaci provádět dodatečné zpracování nebo zpracování chyb , když je vložen DLL a / nebo jakékoliv funkce DLL je volána.

Aspekty kompilátoru a jazyka

Delphi

Ve zdrojovém souboru se použije klíčové slovo librarymísto program. Na konci souboru jsou funkce, které mají být exportovány, uvedeny v exportsklauzuli.

Delphi nepotřebuje LIBsoubory k importu funkcí z knihoven DLL; Chcete -li propojit knihovnu DLL, použije se externalklíčové slovo v deklaraci funkce k signalizaci názvu knihovny DLL a poté namek pojmenování symbolu (je -li jiný) nebo indexk identifikaci indexu.

Microsoft Visual Basic

V jazyce Visual Basic (VB) je podporováno pouze propojení za běhu; ale kromě použití LoadLibrarya GetProcAddressfunkcí API jsou povoleny deklarace importovaných funkcí.

Při importu funkcí DLL prostřednictvím deklarací vygeneruje VB chybu běhu, pokud DLLsoubor nelze najít. Vývojář může chybu zachytit a vhodně ji zpracovat.

Při vytváření knihoven DLL ve VB bude IDE povoleno pouze vytváření knihoven ActiveX DLL, byly však vytvořeny metody, které uživateli umožňují výslovně sdělit linkeru, aby zahrnoval soubor .DEF, který definuje pořadové umístění a název každé exportované funkce. To umožňuje uživateli vytvořit standardní knihovnu DLL systému Windows pomocí jazyka Visual Basic (verze 6 nebo nižší), na který lze odkazovat pomocí příkazu „Declare“.

C a C ++

Microsoft Visual C ++ (MSVC) poskytuje několik rozšíření standardního C ++, které umožňují zadávat funkce jako importované nebo exportované přímo v kódu C ++; tyto byly přijaty jinými kompilátory Windows C a C ++, včetně verzí GCC pro Windows . Tato rozšíření používají atribut __declspecpřed deklarací funkce. Všimněte si, že když jsou funkce C přístupné z C ++, musí být také deklarovány jako extern "C"v kódu C ++, aby kompilátor informoval, že by měla být použita vazba C.

Kromě zadávání importovaných nebo exportovaných funkcí pomocí __declspecatributů mohou být uvedeny v části IMPORT nebo VÝVOZ DEFsouboru používaného projektem. DEFSoubor je zpracováván linker, spíše než překladač, a proto je není specifický pro C ++.

DLL kompilace bude produkovat jak DLLa LIBsoubory. LIBSouboru (import knihovny) se používá k odkazu proti DLL při kompilaci; není nutné pro propojení za běhu. Pokud není knihovna DLL serverem Component Object Model (COM), DLLmusí být soubor umístěn do jednoho z adresářů uvedených v proměnné prostředí PATH, ve výchozím systémovém adresáři nebo ve stejném adresáři jako program, který jej používá. Knihovny DLL serveru COM jsou registrovány pomocí regsvr32.exe, který do registru umístí umístění knihovny DLL a její globálně jedinečné ID ( GUID ). Programy pak mohou použít knihovnu DLL vyhledáním jejího identifikátoru GUID v registru a vyhledáním jejího umístění nebo vytvořením instance objektu COM nepřímo pomocí jeho identifikátoru třídy a identifikátoru rozhraní.

Příklady programování

Pomocí importů DLL

Následující příklady ukazují, jak použít vazby specifické pro jazyk k importu symbolů pro propojení s knihovnou DLL při kompilaci.

Delphi 

{$APPTYPE CONSOLE}

program Example;

// import function that adds two numbers
function AddNumbers(a, b : Double): Double; StdCall; external 'Example.dll';

// main program
var
   R: Double;

begin
  R := AddNumbers(1, 2);
  Writeln('The result was: ', R);
end.

C

Před statickým propojením musí být soubor Example.lib zahrnut (za předpokladu, že je generován Example.dll) do projektu (možnost Přidat existující položku pro Project!). Soubor Example.lib je automaticky generován kompilátorem při kompilaci knihovny DLL. Neprovedení výše uvedeného příkazu by způsobilo chybu propojení, protože linker by nevěděl, kde najít definici AddNumbers. DLL Example.dll může být také nutné zkopírovat do umístění, kde by byl soubor .exe generován následujícím kódem. 

#include <windows.h>
#include <stdio.h>

// Import function that adds two numbers
extern "C" __declspec(dllimport) double AddNumbers(double a, double b);

int main(int argc, char *argv[])
{
    double result = AddNumbers(1, 2);
    printf("The result was: %f\n", result);
    return 0;
}

Použití explicitního propojení za běhu

Následující příklady ukazují, jak používat zařízení pro načítání a propojování za běhu pomocí jazykově specifických vazeb Windows API.

Všimněte si, že všechny čtyři ukázky jsou náchylné k útokům předběžného načítání DLL , protože example.dll lze přeložit na místo, které autor nezamýšlel (aktuální pracovní adresář předchází umístění systémové knihovny), a tedy na škodlivou verzi knihovny. Viz odkaz na pokyny od Microsoftu pro bezpečné nakládání knihovny: je třeba používat SetDllDirectoryWv kernel32odstranit vyhledávání proud adresáře před jsou načteny nějaké knihovny.

Microsoft Visual Basic

Option Explicit
Declare Function AddNumbers Lib "Example.dll" _
(ByVal a As Double, ByVal b As Double) As Double

Sub Main()
	Dim Result As Double
	Result = AddNumbers(1, 2)
	Debug.Print "The result was: " & Result
End Sub

Delphi

program Example;
  {$APPTYPE CONSOLE}
  uses Windows;
  var
  AddNumbers:function (a, b: integer): Double; StdCall;
  LibHandle:HMODULE;
begin
  LibHandle := LoadLibrary('example.dll');
  if LibHandle <> 0 then
    AddNumbers := GetProcAddress(LibHandle, 'AddNumbers');
  if Assigned(AddNumbers) then
    Writeln( '1 + 2 = ', AddNumbers( 1, 2 ) );
  Readln;
end.

C

#include <windows.h>
#include <stdio.h>

// DLL function signature
typedef double (*importFunction)(double, double);

int main(int argc, char **argv)
{
	importFunction addNumbers;
	double result;
	HINSTANCE hinstLib;

	// Load DLL file
	hinstLib = LoadLibrary(TEXT("Example.dll"));
	if (hinstLib == NULL) {
		printf("ERROR: unable to load DLL\n");
		return 1;
	}

	// Get function pointer
	addNumbers = (importFunction) GetProcAddress(hinstLib, "AddNumbers");
	if (addNumbers == NULL) {
		printf("ERROR: unable to find DLL function\n");
		FreeLibrary(hinstLib);
		return 1;
	}

	// Call function.
	result = addNumbers(1, 3);

	// Unload DLL file
	FreeLibrary(hinstLib);

	// Display result
	printf("The result was: %f\n", result);

	return 0;
}

Krajta

Vazba Python ctypes bude v systémech POSIX používat POSIX API. 

import ctypes

my_dll = ctypes.cdll.LoadLibrary("Example.dll")

# The following "restype" method specification is needed to make
# Python understand what type is returned by the function.
my_dll.AddNumbers.restype = ctypes.c_double

p = my_dll.AddNumbers(ctypes.c_double(1.0), ctypes.c_double(2.0))

print("The result was:", p)

Komponentní objektový model

Component Object Model (COM) definuje binární standardu hostit realizaci objektů v DLL a EXE souborů. Poskytuje mechanismy k vyhledání a verzi těchto souborů a také jazykově nezávislý a strojově čitelný popis rozhraní. Hostování objektů COM v knihovně DLL je jednodušší a umožňuje jim sdílet prostředky s klientským procesem. To umožňuje objektům COM implementovat výkonné back-endy do jednoduchých front-endů GUI, jako jsou Visual Basic a ASP. Lze je také programovat ze skriptovacích jazyků.

Únos DLL

Kvůli zranitelnosti, běžně známé jako únos DLL, spoofing DLL, předběžné načítání DLL nebo binární ukládání, mnoho programů načte a spustí škodlivou knihovnu DLL obsaženou ve stejné složce jako datový soubor otevřený těmito programy. Tuto zranitelnost objevil Georgi Guninski v roce 2000. V srpnu 2010 získala celosvětovou publicitu poté, co ji ACROS Security znovu objevila a mnoho stovek programů bylo shledáno zranitelnými. Programy, které jsou spuštěny z nebezpečných umístění, tj. Uživatelsky zapisovatelných složek, jako jsou soubory ke stažení nebo adresář Temp , jsou na tuto chybu zabezpečení téměř vždy citlivé.

Viz také

Reference

  • Hart, Johnson. Programování systému Windows, třetí vydání . Addison-Wesley, 2005. ISBN  0-321-25619-0 .
  • Rektor, Brent a kol. Programování Win32 . Addison-Wesley Developers Press, 1997. ISBN  0-201-63492-9 .

externí odkazy