Una biblioteca de vínculos dinámicos (DLL) es una biblioteca compartida en el sistema operativo Microsoft Windows u 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 .ocxpara controles ActiveX y para un controlador de dispositivo.drv heredado .
Una DLL que contiene solo recursos se puede llamar DLL de recursos . Los ejemplos incluyen la biblioteca de iconos , que a veces tiene extensión .icl, y la biblioteca de fuentes que tiene 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 distintas versiones de Windows utilizan formatos diferentes. Las versiones de Windows de 32 y 64 bits utilizan Portable Executable (PE) y las versiones de Windows de 16 bits utilizan 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.
Como tienen el mismo formato, un EXE se puede utilizar como DLL. El consumo de código puede cargar un EXE mediante el mismo mecanismo que cargar una DLL.
Las primeras versiones de Microsoft Windows ejecutaban programas juntos en un único espacio de direcciones . Cada programa estaba destinado a cooperar cediendo la CPU a otros programas para que la interfaz gráfica de usuario (GUI) pudiera realizar múltiples tareas y tener la máxima capacidad de respuesta. Todas las operaciones a nivel del sistema operativo fueron proporcionadas por el sistema operativo subyacente: MS-DOS . Todos los servicios de nivel superior fueron proporcionados por las bibliotecas de Windows "Biblioteca de vínculos dinámicos". 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 tuvieron que compartirse entre todos los programas de Windows en ejecución, no sólo 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 comandos de dibujo en operaciones en dispositivos específicos. En la pantalla, tenía que manipular píxeles en el búfer de fotogramas. Al dibujar en una impresora, las llamadas a la API debían 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 , el lenguaje de comandos de la impresora HP LaserJet ), Microsoft eligió un enfoque diferente. GDI funcionaría cargando diferentes fragmentos de código, llamados " controladores de dispositivo ", para trabajar con diferentes dispositivos de salida.
El mismo concepto arquitectónico que permitió a GDI cargar diferentes controladores de dispositivos también permitió que el shell de Windows cargara diferentes programas de Windows y que estos programas invocaran llamadas API desde las bibliotecas USER y GDI compartidas. Ese concepto era el de "vínculo 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 su ejecutable se construye en la fase de "vinculación"; Si dos programas llaman a la misma rutina, la rutina se incluye en ambos programas durante la etapa de vinculación de los dos. Con los enlaces dinámicos, el código compartido se coloca en un archivo único e independiente. Los programas que llaman a este archivo están conectados a él en tiempo de ejecución, con el sistema operativo (o, en el caso de las primeras versiones de Windows, la extensión del sistema operativo), realizando el enlace.
Para esas primeras versiones de Windows (1.0 a 3.11), las DLL eran la base de toda la GUI. Como tal, los controladores de pantalla eran simplemente DLL con una extensión .DRV que proporcionaba implementaciones personalizadas de la misma API de dibujo a través de una interfaz de controlador de dispositivo unificada (DDI), y las API de Dibujo (GDI) y GUI (USER) eran simplemente las llamadas a funciones exportadas. por GDI y USUARIO, 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 proporcionan 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 complementos. Se puede desarrollar una interfaz única que permita integrar perfectamente módulos antiguos y nuevos en tiempo de ejecución en aplicaciones preexistentes, sin ninguna modificación en la aplicación misma. 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 solo se cargó una vez en este espacio de direcciones; a partir de ese momento, todos los programas que usaban la biblioteca accedieron a ella. Los datos de la biblioteca se compartieron entre todos los programas. Esto podría usarse como una forma indirecta de comunicación entre procesos , o podría dañar accidentalmente los diferentes programas. Con la introducción de bibliotecas de 32 bits en Windows 95 , cada proceso se ejecutó en su propio espacio de direcciones. Si bien el código DLL se puede compartir, los datos son privados, excepto cuando la biblioteca los solicita explícitamente. Dicho esto, grandes extensiones de Windows 95 , Windows 98 y Windows Me se construyeron a partir de bibliotecas de 16 bits, lo que limitó el rendimiento del microprocesador Pentium Pro cuando se lanzó y, en última instancia, limitó la estabilidad y escalabilidad de las versiones de Windows basadas en DOS.
Aunque la tecnología DLL es fundamental para la arquitectura de Windows, tiene desventajas.
DLL hell 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 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 llama si la DLL tiene algún tipo de bicho.
La tecnología DLL permite modificar una aplicación sin necesidad de volver a compilar o vincular componentes de consumo. Se puede reemplazar una DLL para que la próxima vez que se ejecute la aplicación utilice la nueva versión de DLL. Para funcionar correctamente, los cambios de 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. Las DLL del sistema se pueden reemplazar para que la próxima vez que se ejecuten las aplicaciones, utilicen las nuevas DLL del sistema.
En la API de Windows , los archivos DLL están organizados en secciones . Cada sección tiene su propio conjunto de atributos, como ser escribible o de solo lectura, ejecutable (para código) o no ejecutable (para datos), etc.
El código de una DLL suele compartirse entre todos los procesos que utilizan la DLL; 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 archivos DLL; en cambio, el código se reubica 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 para cargar 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 las versiones más recientes de Windows que utilizan espacios de direcciones separados para cada programa, sólo es posible utilizar la misma copia reubicada de la DLL en varios programas si cada programa tiene las mismas direcciones virtuales libres para acomodar el código de la DLL. Si algunos programas (o su combinación de DLL ya cargadas) no tienen esas direcciones libres, entonces 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 va a recuperar la memoria física ocupada por una sección de código, su contenido se descarta y luego se recarga 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 DLL compartida, esto crea un agujero de seguridad ; es decir, un proceso puede corromper los datos compartidos, lo que probablemente provocará que todos los demás procesos compartidos se comporten de forma indeseable. Por ejemplo, un proceso que se ejecuta con una cuenta de invitado puede dañar de esta manera otro proceso que se ejecuta con una cuenta privilegiada. Esta es una razón importante para evitar el uso de secciones compartidas en archivos DLL.
Si ciertos empaquetadores ejecutables comprimen una DLL (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 compartidas no deben comprimirse si están destinadas a ser utilizadas simultáneamente por múltiples programas, ya que cada instancia de programa tendría que llevar su propia copia de la DLL, lo que resultaría en un mayor consumo de memoria.
Al igual que las bibliotecas estáticas, las bibliotecas de importación para DLL se indican 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 administración de memoria, está vinculada a través de 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, ambos son archivos en formato Unix ar .
La vinculación a bibliotecas dinámicas generalmente se realiza mediante la vinculación a una biblioteca de importación al crear o vincular para crear un archivo ejecutable. El ejecutable creado contiene una tabla de direcciones de importación (IAT) mediante la cual se hace referencia a todas las llamadas a funciones DLL (cada función DLL a la que se hace referencia contiene su propia entrada en la IAT). En tiempo de ejecución, el IAT se llena con direcciones apropiadas 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 vincularlas 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. Asimismo, se pueden importar funciones desde una DLL ya sea 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 DLL. Es común que las funciones internas se exporten únicamente por ordinal. Para la mayoría de las funciones de la API de Windows, solo se conservan los nombres en las diferentes versiones de Windows; los ordinales están sujetos a cambios. Por lo tanto, no se pueden importar de manera confiable funciones API de Windows por sus ordinales.
Importar funciones por ordinal proporciona un rendimiento ligeramente mejor que importarlas por nombre: las tablas de exportación de archivos DLL están ordenadas por nombre, por lo que se puede utilizar una búsqueda binaria para encontrar una función. Luego, el índice del nombre encontrado se utiliza para buscar el ordinal en la tabla Exportar ordinal. En Windows de 16 bits, la tabla de nombres no estaba ordenada, por lo que la sobrecarga de 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 funciones importadas en tiempo de compilación. Para las importaciones vinculadas, el vinculador guarda la marca de tiempo y la suma de verificació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, de ser así, Windows omite el procesamiento de las importaciones. De lo contrario, si la biblioteca es diferente a la que estaba vinculada, Windows procesa las importaciones de forma normal.
Los ejecutables vinculados 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 ningún inconveniente en vincular las importaciones. Por ejemplo, todas las aplicaciones estándar de Windows están vinculadas a las DLL del sistema de su respectiva versión de Windows. Una buena oportunidad para vincular las importaciones de una aplicación a su entorno de destino es durante la instalación de la aplicación. Esto mantiene las bibliotecas "vinculadas" hasta la próxima actualización del sistema operativo. Sin embargo, sí cambia la suma de verificación del ejecutable, por lo que no es algo que se pueda hacer con programas firmados o programas administrados por una herramienta de administración de configuración que utiliza sumas de verificación (como las sumas de verificación MD5 ) para administrar las versiones de los archivos. 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 vincular un ejecutable están disminuyendo.
Los archivos DLL se pueden cargar explícitamente en tiempo de ejecución, un proceso al que Microsoft se refiere simplemente como enlace dinámico en tiempo de ejecuciónLoadLibrary , mediante el uso de la función API (o LoadLibraryEx). La GetProcAddressfunción API se utiliza para buscar símbolos exportados por nombre y FreeLibrarypara descargar la DLL. Estas funciones son análogas a dlopen, dlsymy 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 las construcciones del lenguaje.
Normalmente, una aplicación que está vinculada a la 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 vincularse 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á buscar ni cargar la DLL cuando se inicie la aplicación; en su lugar, el vinculador incluye un código auxiliar en la aplicación que intentará encontrar y cargar la DLL LoadLibrarycuando GetProcAddressse 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, será detectada por el sistema operativo, que finalizará el programa con un mensaje de error.
El mecanismo de carga retrasada también proporciona enlaces de notificación , lo que permite a la aplicación realizar 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, la externalpalabra clave se utiliza en la declaración de función para señalar el nombre de la DLL, seguida de namepara nombrar el símbolo (si es diferente) o indexpara identificar el índice.
En Visual Basic (VB), sólo se admiten enlaces en tiempo de ejecución; pero además de utilizar LoadLibraryfunciones GetProcAddressAPI, se permiten declaraciones de funciones importadas.
Al importar funciones DLL a través de declaraciones, VB generará un error de tiempo de ejecución si DLLno se puede encontrar el archivo. El desarrollador puede detectar el error y gestionarlo adecuadamente.
Al crear archivos DLL en VB, el IDE solo permitirá la creación de archivos DLL ActiveX; sin embargo, se han creado métodos [7] para permitir al usuario decirle explícitamente al vinculador que incluya un archivo .DEF que define la posición ordinal y el nombre de cada función exportada. . Esto permite al usuario crear una DLL estándar de Windows usando Visual Basic (Versión 6 o inferior) a la que se puede hacer referencia mediante una declaración "Declarar".
Microsoft Visual C++ (MSVC) proporciona varias extensiones al C++ estándar que permiten especificar funciones como importadas o exportadas directamente en el código C++; estos han sido adoptados por otros compiladores de Windows C y C++, incluidas las versiones de GCC para Windows . 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, pueden enumerarse en la sección IMPORTAR o EXPORTAR del DEFarchivo utilizado por el proyecto. El DEFarchivo lo procesa el vinculador, en lugar del compilador, y por lo tanto no es específico de C++.
La compilación DLL producirá archivos DLLy LIB. El LIBarchivo (biblioteca de importación) se utiliza para vincular 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 predeterminado del sistema o en el mismo directorio que el programa que lo utiliza. Las DLL del servidor COM se registran mediante regsvr32.exe, que coloca la ubicación de la DLL y su ID global única ( 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 usando su identificador de clase y su identificador de interfaz.
Los siguientes ejemplos muestran cómo utilizar enlaces específicos del idioma para importar símbolos para vincularlos a una DLL en tiempo de compilación.
Delfos
{$CONSOLA TIPO APLICACIÓN}Ejemplo de programa ; // función de importación que suma dos números function AddNumbers ( a , b : Double ) : Double ; Llamada estándar ; externo 'Ejemplo.dll' ; // programa principal var R : Doble ; comenzar R : = Agregar Números ( 1 , 2 ) ; Writeln ( 'El resultado fue:' , R ) ; fin . C
El archivo 'Example.lib' debe incluirse (suponiendo que se genere Ejemplo.dll) en el proyecto antes del enlace estático. 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 vinculador no sabría dónde encontrar la definición de AddNumbers. Es posible que también sea necesario copiar el archivo DLL 'Example.dll' a la ubicación donde se generaría el archivo .exe mediante el siguiente código:
#incluir <windows.h> #incluir <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 []) { resultado doble = AgregarNúmeros ( 1 , 2 ); printf ( "El resultado fue: %f \n " , resultado ); devolver 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 idioma.
Tenga en cuenta que los cuatro ejemplos son vulnerables a ataques de precarga de DLL, ya que ejemplo.dll se puede resolver en un lugar no deseado por el autor (a menos que se excluya explícitamente, el directorio de la aplicación va antes de las ubicaciones de la biblioteca 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 busca antes que los directorios de la biblioteca del sistema) y, por lo tanto, se busca una versión maliciosa de la biblioteca. Consulte la referencia para obtener orientación 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 Declaración explícita Función AddNumbers Lib "Example.dll" _ ( ByVal a As Double , ByVal b As Double ) Como doble Subprincipal ( ) Atenuar resultado como resultado doble = Agregar números ( 1 , 2 ) Depurar . Imprimir "El resultado fue: " & Resultado Fin Sub Ejemplo de programa ; {$APPTYPE CONSOLE} usa Windows ; var AgregarNúmeros : función ( a , b : entero ) : Doble ; Llamada estándar ; LibHandle : HMODULE ; comenzar LibHandle : = LoadLibrary ( 'ejemplo.dll' ) ; si LibHandle <> 0 entonces AddNumbers := GetProcAddress ( LibHandle , 'AddNumbers' ) ; si está asignado ( AddNumbers ), entonces Writeln ( '1 + 2 =' , AddNumbers ( 1 , 2 ) ) ; Leer ; fin . #incluir <windows.h> #incluir <stdio.h> // firma de función DLL typedef doble ( * importFunction ) ( doble , doble ); int main ( int argc , char ** argv ) { importFunction agregarNúmeros ; doble resultado ; HINSTANCIA hindstLib ; // Cargar el archivo DLL hinstLib = LoadLibrary ( TEXTO ( "Example.dll" )); if ( hinstLib == NULL ) { printf ( "ERROR: no se puede cargar la DLL \n " ); devolver 1 ; } // Obtener 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 ); devolver 1 ; } // Llamar a la función. resultado = agregarNúmeros ( 1 , 3 ); // Descargar el archivo DLL FreeLibrary ( hinstLib );// Mostrar resultado printf ( "El resultado fue: %f \n " , resultado ); devolver 0 ; } El enlace de tipos de Python utilizará la API POSIX en sistemas POSIX.
importar tipos de cmy_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. mi_dll . Agregar números . restitipo = ctipos . c_doblep = mi_dll . AgregarNúmeros ( ctypes . c_double ( 1.0 ), ctypes . c_double ( 2.0 ))print ( "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 independiente del idioma y legible por máquina. Alojar objetos COM en una DLL es más liviano y les permite compartir recursos con el proceso del cliente. Esto permite que los objetos COM implementen potentes servidores en interfaces GUI simples como Visual Basic y ASP. También se pueden programar desde lenguajes de scripting. [12]
Debido a una vulnerabilidad comúnmente conocida 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 nuevamente y muchos cientos de programas fueran encontrados vulnerables. [18] Los programas que se ejecutan desde ubicaciones no seguras, es decir, carpetas en las que el usuario puede escribir como el directorio Descargas o 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 UNIX, pero solo contiene una pequeña cantidad de información necesaria para indicarle al sistema operativo cómo interactúa el programa ("importa") el dll.
Esta información está vinculada a .exe.