Dynamic link library (or DLL ) is a Microsoft implementation of shared library concepts in Microsoft Windows and OS/2 operating systems. This library typically has a file extension DLL , OCX (for libraries containing ActiveX controls), or DRV (for old system drivers). The file format for the DLL is the same as the Windows EXE file - that is, Portable Executable (PE) for 32-bit and 64-bit Windows, and New Executable (NE) for Windows 16-bit. Like EXEs, DLLs can contain code, data, and resources, in any combination.
The data files are the same file format as the DLL, but with different file extensions and may only contain the resource portion, it can be called resource DLL . Examples of such DLLs include icon libraries , sometimes have ICL extensions, and font files, have FON and FOT extensions.
Video Dynamic-link library
Backgrounds for DLLs
The first version of Microsoft Windows runs a shared program in one address space. Each program is meant to work together by generating the CPU into another program so that the graphical user interface (GUI) can be multitask and become very responsive. All operating-level operating systems are provided by the underlying operating system: MS-DOS. All high-level services are provided by the Windows Library "Dynamic Link Library". The Drawing API, the Graphics Device Interface (GDI), is implemented in a DLL called GDI.EXE , the user interface in USER.EXE . This additional layer above DOS should be shared across all running Windows programs, not only to enable Windows to work on machines with less than one megabyte of RAM, but to allow programs to work with each other. Code in GDI is required to translate drawing commands to operations on certain devices. On the screen, it has to manipulate the pixels in the frame buffer. When drawing to a printer, the API call should be converted into a request to the printer. While it may be possible to provide hard-coded support for limited devices (such as the Color Graphics Adapter display, HP LaserJet Printer Command Language), Microsoft chose a different approach. GDI will work by loading different pieces of code, called "device drivers", to work with different output devices.
The same architectural concept that allows GDI to load different device drivers is that allows the Windows shell to load various Windows programs, and for these programs to call API calls from shared USER and GDI libraries. The concept is "dynamic linking".
In a conventional non-shared "static" library, code sections are only added to the calling program when the executable is built in the "connect" phase; if two programs call the same routine, routines are included in both programs during the linking stages of both. With dynamic linking, the shared code is placed into one separate file. The programs that call this file connect to it at run time, with the operating system (or, in the case of early versions of Windows, the OS-extension), commit binding.
For early versions of Windows (1.0 to 3.11), DLLs are the foundation for all GUIs. Thus, the driver display is just a DLL with an.DRV extension that provides custom implementations of the same image API through the integrated device driver interface (DDI), and Drawing (GDI) and GUI (USER) APIs are just the call functions that are exported by GDI and USER, DLL system with.EXE extension.
The idea of ​​building an operating system from a collection of dynamically loaded libraries is a core Windows concept that persists until 2015. DLLs provide the standard benefits of shared libraries, such as modularity. Modularity allows changes to code and data created in one standalone DLL shared by multiple applications without changes to the application itself.
Another benefit of modularity is the use of a common interface for plug-ins. A single interface can be developed that allows old and new modules to be seamlessly integrated at run-time into pre-existing applications, without any modification to the app itself. This dynamic extension concept is extracted with the Component Object Model, the basics of ActiveX.
In Windows 1.x, 2.x and 3.x, all Windows applications share the same address space with the same memory. The DLL is only loaded once into this address space; since then, all programs that use libraries have access to it. Library data shared to all programs. This can be used as an indirect form of inter-process communication, or may inadvertently undermine different programs. With the introduction of the 32-bit library on Windows 95 each process runs in its own address space. While DLL code can be shared, data is private unless explicitly shared data is requested by the library. It said most Windows 95, Windows 98 and Windows Me builds from a 16-bit library, which limits Pentium Pro microprocessor performance when launched, and ultimately limits the stability and scalability of Windows-based DOS versions.
Although DLLs are the core of the Windows architecture, they have several drawbacks, collectively called "DLL hell". In 2015 Microsoft promotes the.NET Framework as one solution to DLL problems, although they are now promoting virtualization-based solutions such as Microsoft Virtual PC and Microsoft Application Virtualization, as they offer superior isolation between applications. Alternative mitigation solutions for DLL hell have implemented side-by-side assembly.
Maps Dynamic-link library
DLL features
Since the DLL is essentially the same as the EXEs, the option that will be generated as part of the linking process is for clarity, since it is possible to export functions and data from both.
It is not possible to directly execute a DLL, since it requires an EXE for the operating system to load it through an entry point, then the presence of utilities such as RUNDLL.EXE or RUNDLL32.EXE provides a minimum entry point and framework for DLLs that contain sufficient functionality to run without much support.
DLLs provide a mechanism for shared code and data, allowing code/data shared developers to improve functionality without requiring the application to be re-linked or recompiled. From an application development perspective Windows and OS/2 can be regarded as an enhanced collection of DLLs, allowing applications for one OS version to work in later, as long as the OS vendor has ensured that the interface and functionality are compatible.
DLLs execute in the memory space of the call process and with the same access permissions which means there is little overhead in its use but also that there is no protection for EXE calls if the DLL has some sort of bug.
Memory management
In the Windows API, DLL files are set into sections . Each section has its own set of attributes, such as writable or read-only, executable (for code) or not executable (for data), and so on.
The code in the DLL is usually shared among all processes that use DLLs; that is, they occupy one place in physical memory, and do not take up space in the page file. If the physical memory occupied by the code section will be reclaimed, its contents are discarded, and then reloaded directly from DLL files as necessary.
Unlike the code section, the data portion of the DLL is usually private; that is, every process using a DLL has its own copy of all DLL data. Optionally, the data section can be created divided, enabling inter-process communication through this shared memory area. However, because user restrictions do not apply to shared DLL memory usage, this creates a security hole; that is, a process may damage shared data, which is likely to cause all other sharing processes to behave undesirably. For example, a process running under a guest account can in this way corrupt other processes running under a privileged account. This is an important reason to avoid using shared parts in DLLs.
If the DLL is compressed by an executable executable (eg UPX), all parts of the code are marked as read and written, and will be aborted. The read-and-write code section, such as the private data section, is private to each process. Thus, DLLs with shared data sections should not be compressed if they are intended to be used simultaneously by multiple programs, as each sample program must carry its own copy of the DLL, which results in an increase in memory consumption.
Import library
Like static libraries, the import libraries for DLLs are logged by the.lib file extension. For example, kernel32.dll, the main dynamic library for basic Windows functions such as file creation and memory management, is linked via kernel32.lib.
Connecting to dynamic libraries is usually handled by linking to an import library when creating or linking to create executable files. The executable created then contains the import address table (IAT) with which all the call DLL functions are referenced (each of the referenced DLL functions contains its own entries in the IAT). At run-time, the IAT is filled with the exact address that leads directly to a function in the DLL that is loaded separately.
Symbol and binding resolution
Each function exported by the DLL is identified by an ordinal number and an optional name. Likewise, functions can be imported from DLL either ordinal or by name. Ordinal represents the address pointer position of the function in the Export Address DLL table. It is common for internal functions for ordinal export only. For most Windows API functions only names are preserved in various Windows releases; ordinal may change. Thus, one can not reliably import Windows API functions through its ordinal.
Importing ordinal functions only gives a slightly better performance than importing them with the name: DLL export tables are sorted by name, so binary search can be used to search for functions. The index names found are then used to search the ordinal in the Ordinal Export table. In 16-bit Windows, table names are not sorted, so the overhead lookup of names is much more visible.
It is also possible to bind executable to a particular DLL version, that is, to resolve the address of the imported function at compile time. For bonded imports, the link holds a timestamp and checksum DLL where import is bound. In Windows running-time checking to see if the same version of the library is being used, and if so, Windows goes through the import process. Otherwise, if the library is different from bound, Windows will process import in the normal way.
Bound executions load faster if run in the same environment that is compiled, and at the same time if run in different environments, so there is no loss to bind imports. For example, all standard Windows applications are tied to DLL systems from their respective Windows releases. A good opportunity to bind app imports to the target environment is during application installation. This keeps the library 'tied' up to the next OS update. However, this changes the checksum from being executable, so it's not something that can be done with signed programs, or programs that are managed by a configuration management tool that uses checksums (like MD5 checksums) to manage file versions. Since newer versions of Windows have moved from having a fixed address for each loaded library (for security reasons), the opportunity and the value of the executable binding decreases.
Explicit run-time linkage
DLL files can be loaded explicitly at run-time, a process called just as run-time dynamic linking by Microsoft, using LoadLibrary (or LoadLibraryEx ) API function. The API function GetProcAddress is used to search for exported symbols by name, and FreeLibrary - to unpack DLLs. These functions are analogous to dlopen , dlsym , and dlclose in the POSIX standard API.
The procedure for explicit run-time linking is the same in any language that supports pointer functionality, since it depends on the Windows API rather than language constructs.
Pending loading
Typically, applications associated with DLL import libraries will fail to start if the DLL can not be found, because Windows will not run the application unless it can find all the DLLs required by the app. However the app can be associated with import libraries to allow pending loading of dynamic libraries. In this case the operating system will not try to find or load the DLL when the application starts; instead, the stub is included in the app by a link that will try to find and load the DLL through LoadLibrary and GetProcAddress when one of its functions is invoked. If the DLL can not be found or loaded, or the function being invoked does not exist, the application will generate an exception, which can be captured and handled appropriately. If the app does not handle exceptions, it will be caught by the operating system, which will stop the program with an error message.
The delay-loading mechanism also provides notification hooks, allowing the app to perform additional error processing or handling when DLLs are loaded and/or any DLL function is invoked.
Compiler and language considerations
Delphi
In the source file, the library keyword is used instead of program . At the end of the file, the function to be exported is listed in the export clause.
Delphi does not require LIB files to import functions from the DLL; to link to the DLL, the external keyword is used in the function declaration to signal the DLL name, followed by the name to name the symbol (if different) or index to identify the index.
Microsoft Visual Basic
In Visual Basic (VB), only run-time linking is supported; but in addition to using the LoadLibrary and GetProcAddress API functions, declarations imported functions are allowed.
When importing DLL functions via declaration, VB will generate run-time errors if the DLL file can not be found. Developers can catch errors and handle them appropriately.
When creating DLLs in VB, the IDE will only allow you to create ActiveX DLLs, but methods have been created to allow users to explicitly tell the linker to include.DEF files that define the ordinal position and the name of each exported function. This allows users to create standard Windows DLLs using Visual Basic (Version 6 or lower) that can be referenced via the "Declaration" statement.
C and C
Microsoft Visual C (MSVC) provides some extensions for the C standard that allow functions to be specified as imported or exported directly in C code; this has been adopted by other Windows C and C compilers, including Windows versions of GCC. This extension uses the __ declspec attribute before the function declaration. Note that when function C is accessed from C, they must also be declared as extern "C" in C code, to inform the compiler that the C relationship should be used.
In addition to specifying imported or exported functions using the __ declspec attribute, they can be listed in the IMPORT or EXPORTS section of the DEF file used by the project. The file DEF is processed by the linker, rather than the compiler, and therefore not specific to C.
Compiling the DLL will generate the DLL and LIB files. The LIB file is used to link to a DLL at compile time; no need to connect time. Unless your DLL is a Component Object Model (COM) server, the DLL file must be placed in one of the directories listed in the PATH environment variable, in the default system directory, or in the same directory as the program uses it. The COM DLL server is registered using regsvr32.exe, which locates the DLL and the global unique ID (GUID) in the registry. The program can then use DLLs by searching the GUID in the registry to find its location.
Examples of programming
Using import DLL
The following examples show how to use language-specific bindings to import symbols to connect against DLLs at compile time.
Delphi
C
Make sure you include the Example.lib file (assuming that Example.dll is generated) in the project (Add Existing Item for Projects!) Option before linking static. The Example.lib file is automatically generated by the compiler when compiling the DLL. Not executing the above statement will cause to associate the error because the linker will not know where to find the AddNumber definition. You also need to copy the Example.dll DLL to the location where the.exe file will be generated by the following code.
Using explicit run-time links
The following example shows how to use the loading and linking timescale facility using a language-specific Windows API binding.
Microsoft Visual Basic
Warning: The following code is vulnerable, not in accordance with Microsoft's guidelines for safe loading of libraries!
Delphi
Warning: The following code is vulnerable, not in accordance with Microsoft's guidelines for safe loading of libraries!
C
Warning: the following code is vulnerable; it does not comply with Microsoft's guide to load a secure library.
Python
Warning: the following code is vulnerable; it does not comply with the Microsoft guide for secure library loading!
Component Object Model
The Component Object Model (COM) defines the binary standard for hosting object implementations in DLL and EXE files. It provides a mechanism to locate and create versions of those files as well as interface descriptions that are independent and machine-readable. Hosting COM objects in a DLL is lighter and allows them to share resources with the client process. This allows the COM object to implement a powerful back end to a simple GUI front end like Visual Basic and ASP. They can also be programmed from scripting languages.
Hijack DLL
Due to vulnerabilities commonly known as DLL hijacking, DLL spoofing, preloading DLLs or binary planting, many programs will load and execute malicious DLLs contained in the same folder as data files opened by the program. The vulnerability was discovered by Georgi Guninski in 2000. In August 2010, it gained publicity worldwide after the ACROS security found it again and hundreds of programs found vulnerable. Programs running from unsafe locations, which are user-writable folders such as Downloads or the Temp directory, are almost always vulnerable to this vulnerability.
See also
- Walker Dependencies, a utility that displays exported and imported DLL and EXE file functions
- Dynamic library
- Library (computing)
- Linker (computing)
- Loader (computation)
- Moricons.dll
- Object file
- Shared library
- Static library
- Hell DLL
External links
- dllexport, dllimport on MSDN
- Dynamic-Link Library on MSDN
- Dynamic-Link Library Security on MSDN
- Dynamic-Link Library Search Order on MSDN
- Microsoft Security Advisor: Insecure library loading can allow remote code execution
- What is a DLL? on the Microsoft support site
- Dynamic-Link Library Functions on MSDN
- Microsoft Portable Executable and Common Object File Format Specifications
- Microsoft specifications for dll files
- Carpet bombing and Poisoning Directory
- MS09-014: Overcoming Safari Carpet Safari vulnerability
- More information about DLL Preloading remote attack vector
- An update on the DLL-preloading remote attack vector
- Load Library Safely
References
- Hart, Johnson. Windows System Programming Third Edition . Addison-Wesley, 2005. ISBNÃ, 0-321-25619-0
- The Rector, Brent et al. Win32 Programming . Addison-Wesley Developers Press, 1997. ISBNÃ, 0-201-63492-9.
Source of the article : Wikipedia
0 Comments