Una biblioteca de vínculo dinámico ( DLL ) es una biblioteca compartida en el sistema operativo Microsoft Windows o OS/2 .
Una DLL puede contener código ejecutable (funciones), datos y recursos , en cualquier combinación.
Un archivo DLL suele tener la extensión de archivo .dll , pero puede tener cualquier extensión de archivo. Los desarrolladores pueden optar por utilizar una extensión de archivo que describa el contenido del archivo, como en el caso .ocxde los controles ActiveX y de un controlador de dispositivo.drv heredado (16 bits) .
Una DLL que contiene solo recursos se puede llamar DLL de recursos . Algunos ejemplos son la biblioteca de iconos , que a veces tiene la extensión .icl, y la biblioteca de fuentes , que tiene las extensiones .fony .fot. [1]
El formato de archivo de una DLL es el mismo que el de un ejecutable (también conocido como EXE ), pero las diferentes versiones de Windows usan formatos diferentes. Las versiones de Windows de 32 y 64 bits usan Portable Executable (PE), y las versiones de Windows de 16 bits usan New Executable (NE).
La principal diferencia entre DLL y EXE es que una DLL no se puede ejecutar directamente, ya que el sistema operativo requiere un punto de entrada para iniciar la ejecución. Windows proporciona un programa de utilidad (RUNDLL.EXE/RUNDLL32.EXE) para ejecutar una función expuesta por una DLL.
Dado que tienen el mismo formato, un EXE se puede utilizar como DLL. El código que se consume puede cargar un EXE mediante el mismo mecanismo que se utiliza para cargar un DLL.
Las primeras versiones de Microsoft Windows ejecutaban programas juntos en un único espacio de direcciones . Cada programa estaba pensado para cooperar cediendo la CPU a otros programas para que la interfaz gráfica de usuario (GUI) pudiera realizar múltiples tareas y ser lo más receptiva posible. Todas las operaciones a nivel de sistema operativo eran proporcionadas por el sistema operativo subyacente: MS-DOS . Todos los servicios de nivel superior eran proporcionados por las bibliotecas de Windows "Dynamic Link Library". La API de dibujo , Interfaz de dispositivo gráfico (GDI), se implementó en una DLL llamada GDI.EXE, la interfaz de usuario en USER.EXE. Estas capas adicionales sobre DOS tenían que ser compartidas entre todos los programas de Windows en ejecución, no solo para permitir que Windows funcionara en una máquina con menos de un megabyte de RAM, sino para permitir que los programas cooperaran entre sí. El código en GDI necesitaba traducir los comandos de dibujo a operaciones en dispositivos específicos. En la pantalla, tenía que manipular píxeles en el búfer de cuadros. Al dibujar en una impresora, las llamadas a la API tenían que transformarse en solicitudes a una impresora. Aunque podría haber sido posible proporcionar soporte codificado para un conjunto limitado de dispositivos (como la pantalla del adaptador de gráficos en color o el lenguaje de comandos de impresora HP LaserJet ), Microsoft eligió un enfoque diferente. GDI funcionaría cargando diferentes fragmentos de código, llamados " controladores de dispositivos ", para trabajar con diferentes dispositivos de salida.
El mismo concepto arquitectónico que permitió a GDI cargar distintos controladores de dispositivos también permitió que el shell de Windows cargara distintos programas de Windows y que estos programas invocaran llamadas API desde las bibliotecas compartidas USER y GDI. Ese concepto era el "enlace dinámico".
En una biblioteca estática convencional no compartida , las secciones de código simplemente se agregan al programa que realiza la llamada cuando se crea su ejecutable en la fase de "enlace"; si dos programas llaman a la misma rutina, la rutina se incluye en ambos programas durante la etapa de enlace de los dos. Con el enlace dinámico, el código compartido se coloca en un solo archivo separado. Los programas que llaman a este archivo se conectan a él en tiempo de ejecución, y el sistema operativo (o, en el caso de las primeras versiones de Windows, la extensión del sistema operativo) realiza la vinculación.
En las primeras versiones de Windows (de la 1.0 a la 3.11), las DLL eran la base de toda la interfaz gráfica de usuario. Por tanto, los controladores de pantalla eran simplemente DLL con una extensión .DRV que proporcionaban implementaciones personalizadas de la misma API de dibujo a través de una interfaz de controlador de dispositivo (DDI) unificada, y las API de dibujo (GDI) y GUI (USER) eran simplemente las llamadas de función exportadas por GDI y USER, DLL del sistema con extensión .EXE.
Esta noción de construir el sistema operativo a partir de una colección de bibliotecas cargadas dinámicamente es un concepto central de Windows que persiste a partir de 2015. [actualizar]Las DLL brindan los beneficios estándar de las bibliotecas compartidas , como la modularidad . La modularidad permite realizar cambios en el código y los datos en una única DLL autónoma compartida por varias aplicaciones sin ningún cambio en las aplicaciones mismas.
Otro beneficio de la modularidad es el uso de interfaces genéricas para los complementos. Se puede desarrollar una única interfaz que permita que tanto los módulos antiguos como los nuevos se integren sin problemas en tiempo de ejecución en aplicaciones preexistentes, sin ninguna modificación en la propia aplicación. Este concepto de extensibilidad dinámica se lleva al extremo con el Modelo de objetos componentes , la base de ActiveX .
En Windows 1.x, 2.x y 3.x, todas las aplicaciones de Windows compartían el mismo espacio de direcciones y la misma memoria. Una DLL se cargaba una sola vez en este espacio de direcciones; a partir de entonces, todos los programas que utilizaban la biblioteca accedían a ella. Los datos de la biblioteca se compartían entre todos los programas. Esto podía utilizarse como una forma indirecta de comunicación entre procesos o podía dañar accidentalmente los diferentes programas. Con la introducción de las bibliotecas de 32 bits en Windows 95 , cada proceso se ejecutaba en su propio espacio de direcciones. Si bien el código de la DLL puede compartirse, los datos son privados, excepto cuando la biblioteca solicita explícitamente los datos compartidos. Dicho esto, grandes porciones de Windows 95 , Windows 98 y Windows Me se crearon a partir de bibliotecas de 16 bits, lo que limitaba el rendimiento del microprocesador Pentium Pro cuando se iniciaba y, en última instancia, limitaba la estabilidad y la escalabilidad de las versiones de Windows basadas en DOS.
Aunque la tecnología DLL es fundamental para la arquitectura de Windows, tiene desventajas.
El infierno de DLL describe el mal comportamiento de una aplicación cuando se consume la versión incorrecta de una DLL. [2] Las estrategias de mitigación incluyen:
El código ejecutable de una DLL se ejecuta en el espacio de memoria del proceso que lo llama y con los mismos permisos de acceso, lo que significa que hay poca sobrecarga en su uso, pero también que no hay protección para el programa que lo llama si la DLL tiene algún tipo de error.
La tecnología DLL permite modificar una aplicación sin necesidad de volver a compilar o vincular los componentes que la consumen. Se puede reemplazar una DLL para que la próxima vez que se ejecute la aplicación utilice la nueva versión de la DLL. Para que funcione correctamente, los cambios en la DLL deben mantener la compatibilidad con versiones anteriores .
Incluso el sistema operativo se puede actualizar, ya que está expuesto a las aplicaciones a través de archivos DLL. Los archivos DLL del sistema se pueden reemplazar para que la próxima vez que se ejecuten las aplicaciones, utilicen los nuevos archivos DLL del sistema.
En la API de Windows , los archivos DLL se organizan en secciones . Cada sección tiene su propio conjunto de atributos, como por ejemplo, si es de solo lectura o de escritura, ejecutable (para código) o no ejecutable (para datos), etc.
El código de una DLL suele compartirse entre todos los procesos que la utilizan; es decir, ocupan un único lugar en la memoria física y no ocupan espacio en el archivo de paginación . Windows no utiliza código independiente de la posición para sus DLL; en su lugar, el código sufre una reubicación a medida que se carga, fijando direcciones para todos sus puntos de entrada en ubicaciones que están libres en el espacio de memoria del primer proceso que carga la DLL. En versiones anteriores de Windows, en las que todos los procesos en ejecución ocupaban un único espacio de direcciones común, una única copia del código de la DLL siempre sería suficiente para todos los procesos. Sin embargo, en versiones más nuevas de Windows que utilizan espacios de direcciones separados para cada programa, solo es posible utilizar la misma copia reubicada de la DLL en varios programas si cada programa tiene las mismas direcciones virtuales libres para alojar el código de la DLL. Si algunos programas (o su combinación de DLL ya cargadas) no tienen esas direcciones libres, será necesario crear una copia física adicional del código de la DLL, utilizando un conjunto diferente de puntos de entrada reubicados. Si se desea recuperar la memoria física ocupada por una sección de código, se descarta su contenido y luego se vuelve a cargar directamente desde el archivo DLL según sea necesario.
A diferencia de las secciones de código, las secciones de datos de una DLL suelen ser privadas; es decir, cada proceso que utiliza la DLL tiene su propia copia de todos los datos de la DLL. Opcionalmente, las secciones de datos se pueden compartir, lo que permite la comunicación entre procesos a través de esta área de memoria compartida. Sin embargo, debido a que las restricciones de usuario no se aplican al uso de la memoria compartida de la DLL, esto crea un agujero de seguridad ; es decir, un proceso puede corromper los datos compartidos, lo que probablemente hará que todos los demás procesos que comparten se comporten de forma indeseable. Por ejemplo, un proceso que se ejecuta bajo una cuenta de invitado puede de esta manera corromper otro proceso que se ejecuta bajo una cuenta privilegiada. Esta es una razón importante para evitar el uso de secciones compartidas en las DLL.
Si una DLL se comprime mediante ciertos empaquetadores ejecutables (por ejemplo, UPX ), todas sus secciones de código se marcan como de lectura y escritura y no se compartirán. Las secciones de código de lectura y escritura, al igual que las secciones de datos privados, son privadas para cada proceso. Por lo tanto, las DLL con secciones de datos compartidos no se deben comprimir si se pretende que sean utilizadas simultáneamente por varios programas, ya que cada instancia de programa tendría que llevar su propia copia de la DLL, lo que daría como resultado un mayor consumo de memoria.
Al igual que las bibliotecas estáticas, las bibliotecas de importación para DLL se identifican por la .libextensión del archivo. Por ejemplo, kernel32.dll , la biblioteca dinámica principal para las funciones básicas de Windows, como la creación de archivos y la gestión de memoria, está vinculada mediante kernel32.lib. La forma habitual de distinguir una biblioteca de importación de una biblioteca estática adecuada es por el tamaño: la biblioteca de importación es mucho más pequeña, ya que solo contiene símbolos que hacen referencia a la DLL real, que se procesará en el momento del enlace. Sin embargo, ambas son archivos de formato ar de Unix.
La vinculación a bibliotecas dinámicas se suele gestionar mediante la vinculación a una biblioteca de importación al crear un archivo ejecutable o mediante la vinculación para crearlo. El ejecutable creado contiene una tabla de direcciones de importación (IAT) mediante la cual se hace referencia a todas las llamadas a funciones de la DLL (cada función de la DLL a la que se hace referencia contiene su propia entrada en la IAT). En tiempo de ejecución, la IAT se llena con las direcciones adecuadas que apuntan directamente a una función en la DLL cargada por separado. [3]
En Cygwin/MSYS y MinGW, las bibliotecas de importación reciben convencionalmente el sufijo .dll.a, combinando tanto el sufijo DLL de Windows como el sufijo ar de Unix. El formato de archivo es similar, pero los símbolos utilizados para marcar las importaciones son diferentes ( _head_foo_dllvs __IMPORT_DESCRIPTOR_foo). [4] Aunque su cadena de herramientas GNU Binutils puede generar bibliotecas de importación y vincularlas, es más rápido vincularse directamente a la DLL. [5] Se puede utilizar una herramienta experimental en MinGW llamada genlib para generar bibliotecas de importación con símbolos de estilo MSVC.
Cada función exportada por una DLL se identifica mediante un ordinal numérico y, opcionalmente, un nombre. Del mismo modo, las funciones se pueden importar desde una DLL por ordinal o por nombre. El ordinal representa la posición del puntero de dirección de la función en la tabla de direcciones de exportación de la DLL. Es habitual que las funciones internas se exporten solo por ordinal. Para la mayoría de las funciones de la API de Windows, solo se conservan los nombres en las distintas versiones de Windows; los ordinales están sujetos a cambios. Por lo tanto, no se pueden importar de forma fiable funciones de la API de Windows por sus ordinales.
La importación de funciones por ordinal ofrece un rendimiento apenas mejor que la importación por nombre: las tablas de exportación de las DLL se ordenan por nombre, por lo que se puede utilizar una búsqueda binaria para encontrar una función. El índice del nombre encontrado se utiliza entonces para buscar el ordinal en la tabla de ordinales de exportación. En Windows de 16 bits, la tabla de nombres no estaba ordenada, por lo que la sobrecarga de la búsqueda de nombres era mucho más notoria.
También es posible vincular un ejecutable a una versión específica de una DLL, es decir, resolver las direcciones de las funciones importadas en tiempo de compilación. Para las importaciones vinculadas, el enlazador guarda la marca de tiempo y la suma de comprobación de la DLL a la que está vinculada la importación. En tiempo de ejecución, Windows comprueba si se está utilizando la misma versión de la biblioteca y, en caso afirmativo, omite el procesamiento de las importaciones. De lo contrario, si la biblioteca es diferente de la que estaba vinculada, Windows procesa las importaciones de forma normal.
Los ejecutables enlazados se cargan algo más rápido si se ejecutan en el mismo entorno para el que fueron compilados, y exactamente al mismo tiempo si se ejecutan en un entorno diferente, por lo que no hay inconvenientes en enlazar las importaciones. Por ejemplo, todas las aplicaciones estándar de Windows están enlazadas a las DLL del sistema de su respectiva versión de Windows. Una buena oportunidad para enlazar las importaciones de una aplicación a su entorno de destino es durante la instalación de la aplicación. Esto mantiene las bibliotecas "enlazadas" hasta la próxima actualización del sistema operativo. Sin embargo, cambia la suma de comprobación del ejecutable, por lo que no es algo que se pueda hacer con programas firmados o programas que se administran mediante una herramienta de administración de configuración que utiliza sumas de comprobación (como las sumas de comprobación MD5 ) para administrar las versiones de archivo. A medida que las versiones más recientes de Windows han dejado de tener direcciones fijas para cada biblioteca cargada (por razones de seguridad), la oportunidad y el valor de enlazar un ejecutable están disminuyendo.
Los archivos DLL se pueden cargar explícitamente en tiempo de ejecución, un proceso al que Microsoft denomina simplemente vinculación dinámica en tiempo de ejecución , mediante la función API LoadLibrary(o LoadLibraryEx). La GetProcAddressfunción API se utiliza para buscar símbolos exportados por nombre y FreeLibrary– para descargar la DLL. Estas funciones son análogas a dlopen, dlsym, y dlcloseen la API estándar POSIX .
El procedimiento para la vinculación explícita en tiempo de ejecución es el mismo en cualquier lenguaje que admita punteros a funciones , ya que depende de la API de Windows en lugar de construcciones del lenguaje.
Normalmente, una aplicación que está vinculada a una biblioteca de importación de una DLL no se iniciará si no se puede encontrar la DLL, porque Windows no ejecutará la aplicación a menos que pueda encontrar todas las DLL que la aplicación pueda necesitar. Sin embargo, una aplicación puede estar vinculada a una biblioteca de importación para permitir la carga retrasada de la biblioteca dinámica. [6]
En este caso, el sistema operativo no intentará encontrar o cargar la DLL cuando se inicie la aplicación; en su lugar, el enlazador incluye un fragmento en la aplicación que intentará encontrar y cargar la DLL a través de LoadLibraryy GetProcAddresscuando se llame a una de sus funciones. Si no se puede encontrar o cargar la DLL, o la función llamada no existe, la aplicación generará una excepción , que puede detectarse y manejarse adecuadamente. Si la aplicación no maneja la excepción, el sistema operativo la detectará y terminará el programa con un mensaje de error.
El mecanismo de carga retrasada también proporciona ganchos de notificación , lo que permite que la aplicación realice un procesamiento adicional o manejo de errores cuando se carga la DLL y/o se llama a cualquier función de la DLL.
En un archivo fuente, libraryse utiliza la palabra clave en lugar de program. Al final del archivo, las funciones que se exportarán se enumeran en exportsla cláusula.
Delphi no necesita LIBarchivos para importar funciones desde DLL; para vincular a una DLL, externalse utiliza la palabra clave en la declaración de la función para señalar el nombre de la DLL, seguido de namepara nombrar el símbolo (si es diferente) o indexpara identificar el índice.
En Visual Basic (VB), solo se admite la vinculación en tiempo de ejecución; pero además de utilizar funciones LoadLibraryde GetProcAddressAPI, se permiten declaraciones de funciones importadas.
Al importar funciones DLL mediante declaraciones, VB generará un error en tiempo de ejecución si DLLno se puede encontrar el archivo. El desarrollador puede detectar el error y manejarlo adecuadamente.
Al crear archivos DLL en VB, el IDE solo permite la creación de archivos DLL ActiveX, sin embargo, se han creado métodos [7] para permitir que el usuario le indique explícitamente al enlazador que incluya un archivo .DEF que defina la posición ordinal y el nombre de cada función exportada. Esto permite al usuario crear un archivo DLL estándar de Windows utilizando Visual Basic (versión 6 o anterior) al que se puede hacer referencia mediante una declaración "Declare".
Microsoft Visual C++ (MSVC) ofrece varias extensiones al estándar C++ que permiten especificar funciones como importadas o exportadas directamente en el código C++; estas han sido adoptadas por otros compiladores de C y C++ de Windows, incluidas las versiones de Windows de GCC . Estas extensiones utilizan el atributo __declspecantes de una declaración de función. Tenga en cuenta que cuando se accede a funciones de C desde C++, también deben declararse como extern "C"en el código C++, para informar al compilador que se debe utilizar el enlace C. [8]
Además de especificar funciones importadas o exportadas mediante __declspecatributos, se pueden incluir en la sección IMPORT o EXPORTS del DEFarchivo utilizado por el proyecto. El DEFarchivo lo procesa el enlazador, no el compilador, y por lo tanto no es específico de C++.
La compilación de DLL producirá archivos DLLy LIB. El LIBarchivo (biblioteca de importación) se utiliza para vincular con una DLL en tiempo de compilación; no es necesario para la vinculación en tiempo de ejecución. A menos que la DLL sea un servidor de Modelo de objetos componentes (COM), el DLLarchivo debe colocarse en uno de los directorios enumerados en la variable de entorno PATH, en el directorio de sistema predeterminado o en el mismo directorio que el programa que lo usa. Las DLL de servidor COM se registran utilizando regsvr32.exe, que coloca la ubicación de la DLL y su ID único global ( GUID ) en el registro. Luego, los programas pueden usar la DLL buscando su GUID en el registro para encontrar su ubicación o crear una instancia del objeto COM indirectamente utilizando su identificador de clase e identificador de interfaz.
Los siguientes ejemplos muestran cómo utilizar enlaces específicos del lenguaje para importar símbolos para vincular con una DLL en tiempo de compilación.
Delfos
{$CONSOLA APPTYPE}programa Ejemplo ; // función de importación que suma dos números function AddNumbers ( a , b : Double ) : Double ; StdCall ; external 'Example.dll' ; // programa principal var R : Double ; begin R := AddNumbers ( 1 , 2 ) ; Writeln ( 'El resultado fue: ' , R ) ; end . do
El archivo 'Example.lib' debe incluirse (suponiendo que se genera Example.dll) en el proyecto antes de la vinculación estática. El compilador genera automáticamente el archivo 'Example.lib' al compilar la DLL. No ejecutar la declaración anterior provocaría un error de vinculación, ya que el enlazador no sabría dónde encontrar la definición de AddNumbers. Es posible que también haya que copiar el archivo DLL 'Example.dll' a la ubicación donde se generaría el archivo .exe mediante el siguiente código:
#include <windows.h> #include <stdio.h> // Función de importación que suma dos números extern "C" __declspec ( dllimport ) double AddNumbers ( double a , double b ); int main ( int argc , char * argv []) { double resultado = AddNumbers ( 1 , 2 ); printf ( "El resultado fue: %f \n " , resultado ); return 0 ; } Los siguientes ejemplos muestran cómo utilizar las funciones de carga y vinculación en tiempo de ejecución mediante enlaces de API de Windows específicos del lenguaje.
Tenga en cuenta que las cuatro muestras son vulnerables a ataques de precarga de DLL, ya que example.dll se puede resolver en un lugar no previsto por el autor (a menos que se excluya explícitamente que el directorio de la aplicación vaya antes que las ubicaciones de las bibliotecas del sistema, y sin HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode[9] o HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\CWDIllegalInDLLSearch[10] el directorio de trabajo actual se busque antes que los directorios de las bibliotecas del sistema), y por lo tanto en una versión maliciosa de la biblioteca. Consulte la referencia para obtener la guía de Microsoft sobre la carga segura de bibliotecas: se debe usar SetDefaultDllDirectoriesin kernel32para eliminar tanto el directorio de la aplicación como el directorio de trabajo actual de la ruta de búsqueda de DLL, o usar SetDllDirectoryWin kernel32para eliminar el directorio de trabajo actual de la ruta de búsqueda de DLL. [11]
Opción Declarar explícitamente Función AddNumbers Lib "Example.dll" _ ( PorVal a como Double , PorVal b como Double ) Como Double Sub Main () Dim Result As Double Result = AddNumbers ( 1 , 2 ) Debug . Imprimir "El resultado fue: " & Result End Sub programa Ejemplo ; {$APPTYPE CONSOLE} usa Windows ; var AddNumbers : function ( a , b : entero ) : 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 . #include <windows.h> #include <stdio.h> // Firma de función DLL typedef double ( * importFunction )( double , double ); int main ( int argc , char ** argv ) { importFunction addNumbers ; doble resultado ; HINSTANCE hinstLib ; // Cargar archivo DLL hinstLib = LoadLibrary ( TEXT ( "Example.dll" )); if ( hinstLib == NULL ) { printf ( "ERROR: no se puede cargar la DLL \n " ); return 1 ; } // Obtener el puntero de función addNumbers = ( importFunction ) GetProcAddress ( hinstLib , "AddNumbers" ); if ( addNumbers == NULL ) { printf ( "ERROR: no se puede encontrar la función DLL \n " ); FreeLibrary ( hinstLib ); return 1 ; } // Función de llamada. result = addNumbers ( 1 , 3 ); // Descargar archivo DLL FreeLibrary ( hinstLib );// Mostrar resultado printf ( "El resultado fue: %f \n " , resultado ); devuelve 0 ; } El enlace ctypes de Python utilizará la API POSIX en sistemas POSIX.
importar ctypesmy_dll = ctipos . cdll . LoadLibrary ( "Ejemplo.dll" )# La siguiente especificación del método "restype" es necesaria para que Python comprenda qué tipo devuelve la función. my_dll . AddNumbers . restype = ctypes . c_doublep = mi_dll .AddNumbers ( ctypes .c_double ( 1.0 ) , ctypes .c_double ( 2.0 ) ) imprimir ( "El resultado fue:" , p )El modelo de objetos componentes (COM) define un estándar binario para alojar la implementación de objetos en archivos DLL y EXE. Proporciona mecanismos para localizar y versionar esos archivos, así como una descripción de la interfaz legible por máquina e independiente del lenguaje. Alojar objetos COM en una DLL es más liviano y les permite compartir recursos con el proceso cliente. Esto permite que los objetos COM implementen back-ends potentes en front-ends GUI simples como Visual Basic y ASP. También se pueden programar desde lenguajes de scripting. [12]
Debido a una vulnerabilidad conocida comúnmente como secuestro de DLL, suplantación de DLL, precarga de DLL o plantación binaria, muchos programas cargarán y ejecutarán una DLL maliciosa contenida en la misma carpeta que un archivo de datos abierto por estos programas. [13] [14] [15] [16] La vulnerabilidad fue descubierta por Georgi Guninski en 2000. [17] En agosto de 2010 ganó publicidad mundial después de que ACROS Security la redescubriera y se encontraran cientos de programas vulnerables. [18] Los programas que se ejecutan desde ubicaciones no seguras, es decir, carpetas escribibles por el usuario como Descargas o el directorio Temp , casi siempre son susceptibles a esta vulnerabilidad. [19] [20] [21] [22] [23] [24] [25]
La biblioteca de importación es una biblioteca .a normal, similar a la de UNIX, pero sólo contiene la pequeña cantidad de información necesaria para indicarle al sistema operativo cómo interactúa el programa con ("importa") la DLL. Esta información está vinculada a .exe.