Динамическая библиотека

Эта статья о реализации OS/2 и Windows. Общие сведения о динамическом связывании библиотек см. в разделе Динамический компоновщик .

Не путать с динамически загружаемой библиотекой .

Динамическая библиотека

Расширение имени файла	.dll
Тип интернет-СМИ	приложение/vnd.microsoft.portable-исполняемый файл
Единый идентификатор типа (UTI)	com.microsoft.windows-динамическая-ссылка-библиотека
Магическое число	МЗ
Разработано	Майкрософт
Контейнер для	Общая библиотека

Библиотека динамической компоновки ( DLL ) — это общая библиотека в Microsoft Windows или OS/2 операционной системе .

DLL может содержать исполняемый код (функции), данные и ресурсы в любой комбинации.

Расширения файлов

Файл DLL часто имеет расширение. .dll, но может иметь любое расширение файла. Разработчики могут использовать расширение файла, которое описывает содержимое файла, например .ocx для элементов управления ActiveX и .drv для устаревшего драйвера устройства .

DLL, содержащую только ресурсы, можно назвать ресурсной DLL . Примеры включают значков библиотеку , иногда имеющую расширение .iclи библиотека шрифтов , имеющая расширения .fon и .fot.

Формат файла

Формат файла DLL такой же, как и у исполняемого файла ( EXE ), но разные версии Windows используют разные форматы. В 32- и 64-разрядных версиях Windows используется переносимый исполняемый файл (PE), а в 16-разрядных версиях Windows — новый исполняемый файл (NE).

Основное различие между DLL и EXE заключается в том, что DLL не может быть запущена напрямую, поскольку операционной системе требуется точка входа для начала выполнения. Windows предоставляет служебную программу (RUNDLL.EXE/RUNDLL32.EXE) для выполнения функции, предоставляемой DLL.

Поскольку они имеют одинаковый формат, EXE-файл можно использовать как DLL. Потребляющий код может загружать EXE-файл с помощью того же механизма, что и загрузка DLL.

Фон

Первые версии Microsoft Windows запускали программы вместе в одном адресном пространстве . Каждая программа должна была взаимодействовать, уступая центральный процессор другим программам, чтобы графический интерфейс пользователя (GUI) мог выполнять многозадачность и был максимально отзывчивым. Все операции на уровне операционной системы обеспечивались базовой операционной системой: MS-DOS . Все службы более высокого уровня предоставлялись библиотеками Windows «Библиотека динамической компоновки». рисования API , интерфейс графического устройства (GDI), был реализован в DLL под названием GDI.EXE, пользовательский интерфейс в USER.EXE. Эти дополнительные уровни поверх DOS должны были использоваться всеми запущенными программами Windows не только для того, чтобы позволить Windows работать на машине с менее чем мегабайтом оперативной памяти, но и для того, чтобы программы могли взаимодействовать друг с другом. Код в GDI должен был преобразовать команды рисования в операции на конкретных устройствах. На дисплее ему приходилось манипулировать пикселями в буфере кадра. При рисовании на принтере вызовы API нужно было преобразовать в запросы к принтеру. Хотя можно было обеспечить жестко запрограммированную поддержку для ограниченного набора устройств (например, дисплея цветного графического адаптера HP LaserJet , языка команд принтера ), Microsoft выбрала другой подход. GDI будет работать, загружая разные фрагменты кода, называемые « драйверами устройств », для работы с разными устройствами вывода.

Та же архитектурная концепция, которая позволяла GDI загружать разные драйверы устройств, также позволяла оболочке Windows загружать различные программы Windows, а также вызывать эти программы вызовы API из общих библиотек USER и GDI. Этой концепцией было «динамическое связывание».

В обычной закрытой статической библиотеке разделы кода просто добавляются в вызывающую программу, когда ее исполняемый файл создается на этапе «связывания»; если две программы вызывают одну и ту же подпрограмму, эта подпрограмма включается в обе программы на этапе их связывания. При динамическом связывании общий код помещается в один отдельный файл. Программы, вызывающие этот файл, подключаются к нему во время выполнения, при этом операционная система (или, в случае ранних версий Windows, расширение ОС) выполняет привязку.

В ранних версиях Windows (от 1.0 до 3.11) библиотеки DLL были основой всего графического интерфейса. Таким образом, драйверы дисплея представляли собой просто библиотеки DLL с расширением .DRV, которые предоставляли пользовательские реализации одного и того же API рисования через унифицированный интерфейс драйвера устройства (DDI), а API рисования (GDI) и GUI (USER) были просто экспортированными вызовами функций. GDI и USER — системные библиотеки DLL с расширением .EXE.

Идея создания операционной системы из набора динамически загружаемых библиотек является основной концепцией Windows, которая сохраняется с 2015 года. . DLL предоставляют стандартные преимущества разделяемых библиотек , такие как модульность . Модульность позволяет вносить изменения в код и данные в одной автономной DLL, используемой несколькими приложениями, без каких-либо изменений в самих приложениях.

Еще одним преимуществом модульности является использование универсальных интерфейсов для подключаемых модулей. Может быть разработан единый интерфейс, который позволяет легко интегрировать как старые, так и новые модули во время выполнения в уже существующие приложения без каких-либо изменений в самом приложении. Эта концепция динамической расширяемости доведена до крайности в объектной модели компонентов , лежащей в основе ActiveX .

В Windows 1.x, 2.x и 3.x все приложения Windows использовали одно и то же адресное пространство и одну и ту же память. DLL загружалась в это адресное пространство только один раз; с этого момента все программы, использующие библиотеку, имели к ней доступ. Данные библиотеки использовались всеми программами. Это можно использовать как косвенную форму межпроцессного взаимодействия или случайно повредить различные программы. С появлением 32-битных библиотек в Windows 95 каждый процесс выполнялся в собственном адресном пространстве. Хотя код DLL может быть общим, данные являются конфиденциальными, за исключением случаев, когда общие данные явно запрашиваются библиотекой. Тем не менее, большая часть Windows 95 , Windows 98 и Windows Me была построена на основе 16-битных библиотек, что ограничивало производительность микропроцессора Pentium Pro при запуске и в конечном итоге ограничивало стабильность и масштабируемость версий Windows для DOS.

Ограничения

Хотя технология DLL является основой архитектуры Windows, у нее есть недостатки.

DLL Ад

Ад DLL описывает плохое поведение приложения при использовании неправильной версии DLL. Стратегии смягчения последствий включают в себя:

• .NET Framework
• Решения на основе виртуализации, такие как Microsoft Virtual PC и Microsoft Application Virtualization, поскольку они обеспечивают изоляцию между приложениями.
• Боковая сборка

Общее пространство памяти

Исполняемый код DLL выполняется в пространстве памяти вызывающего процесса и с теми же правами доступа, что означает небольшие накладные расходы при их использовании, но также и отсутствие защиты вызывающей программы, если DLL имеет какой-либо тип ошибка.

Функции

Возможность обновления

Технология DLL позволяет изменять приложение, не требуя повторной компиляции или повторного связывания компонентов. Библиотеку DLL можно заменить, чтобы при следующем запуске приложения использовалась новая версия DLL. Для корректной работы изменения DLL должны поддерживать обратную совместимость .

Даже операционную систему можно обновить, поскольку она доступна приложениям через библиотеки DLL. Системные библиотеки DLL можно заменить, чтобы при следующем запуске приложений они использовали новые системные библиотеки DLL.

Управление памятью

В Windows API файлы DLL организованы в разделы . Каждый раздел имеет свой собственный набор атрибутов, например, доступен ли он для записи или только для чтения, исполняемый (для кода) или неисполняемый (для данных) и так далее.

Код в DLL обычно используется всеми процессами, использующими эту DLL; то есть они занимают одно место в физической памяти, а не занимают место в файле подкачки . Windows не использует позиционно-независимый код для своих DLL; вместо этого код перемещается по мере загрузки, фиксируя адреса всех точек входа в местах, свободных в пространстве памяти первого процесса, загрузившего DLL. В старых версиях Windows, в которых все запущенные процессы занимали одно общее адресное пространство, для всех процессов всегда было достаточно одной копии кода DLL. Однако в более новых версиях Windows, которые используют отдельные адресные пространства для каждой программы, можно использовать одну и ту же перемещенную копию DLL в нескольких программах только в том случае, если каждая программа имеет одни и те же виртуальные адреса, свободные для размещения кода DLL. Если некоторые программы (или их комбинация уже загруженных DLL) не имеют этих свободных адресов, то необходимо будет создать дополнительную физическую копию кода DLL, используя другой набор перемещенных точек входа. Если необходимо освободить физическую память, занятую участком кода, ее содержимое отбрасывается, а затем при необходимости перезагружается непосредственно из файла DLL.

В отличие от разделов кода, разделы данных DLL обычно являются частными; то есть каждый процесс, использующий DLL, имеет собственную копию всех данных DLL. При желании разделы данных можно сделать общими, что позволит осуществлять взаимодействие между процессами через эту общую область памяти. Однако, поскольку пользовательские ограничения не распространяются на использование общей памяти DLL, это создает дыру в безопасности ; а именно, один процесс может повредить общие данные, что, вероятно, приведет к нежелательному поведению всех других процессов совместного использования. Например, процесс, запущенный под гостевой учетной записью, может таким образом повредить другой процесс, работающий под привилегированной учетной записью. Это важная причина избегать использования общих разделов в DLL.

Если DLL сжимается определенными упаковщиками исполняемых файлов (например, UPX ), все разделы ее кода помечаются как доступные для чтения и записи и не подлежат совместному использованию. Разделы кода для чтения и записи, как и разделы частных данных, являются частными для каждого процесса. Таким образом, библиотеки DLL с разделами общих данных не следует сжимать, если они предназначены для одновременного использования несколькими программами, поскольку каждый экземпляр программы должен иметь свою собственную копию DLL, что приводит к увеличению потребления памяти.

Импортировать библиотеки

Как и статические библиотеки, библиотеки импорта для DLL отмечаются .lib расширение файла. Например, kernel32.dll , основная динамическая библиотека для базовых функций Windows, таких как создание файлов и управление памятью, связана через kernel32.lib. Обычный способ отличить библиотеку импорта от правильной статической библиотеки — это размер: библиотека импорта намного меньше, поскольку она содержит только символы, относящиеся к реальной DLL, которые должны обрабатываться во время компоновки. Тем не менее, оба файла являются файлами формата Unix .

Связывание с динамическими библиотеками обычно осуществляется путем связывания с библиотекой импорта при сборке или связывании для создания исполняемого файла. Созданный исполняемый файл затем содержит таблицу адресов импорта (IAT), по которой ссылаются на все вызовы функций DLL (каждая ссылочная функция DLL содержит собственную запись в IAT). Во время выполнения IAT заполняется соответствующими адресами, которые указывают непосредственно на функцию в отдельно загруженной DLL.

В Cygwin/MSYS и MinGW библиотекам импорта обычно присваивается суффикс .dll.a, сочетающий в себе суффикс Windows DLL и суффикс ar Unix. Формат файла аналогичен, но символы, используемые для обозначения импорта, отличаются ( _head_foo_dll против __IMPORT_DESCRIPTOR_foo). Хотя его набор инструментов GNU Binutils может генерировать библиотеки импорта и ссылаться на них, быстрее ссылаться на DLL напрямую. Экспериментальный инструмент в MinGW под названием genlib можно использовать для создания библиотек импорта с символами в стиле MSVC.

Разрешение символов и привязка

Каждая функция, экспортируемая DLL, идентифицируется числовым порядковым номером и, при необходимости, именем. Аналогично, функции можно импортировать из DLL либо по порядковому номеру, либо по имени. Порядковый номер представляет положение указателя адреса функции в таблице адресов экспорта DLL. Внутренние функции обычно экспортируются только по порядковому номеру. Для большинства функций Windows API в разных выпусках Windows сохраняются только имена; порядковые номера могут быть изменены. Таким образом, невозможно надежно импортировать функции Windows API по их порядковым номерам.

Импорт функций по порядковому номеру обеспечивает лишь немного лучшую производительность, чем импорт их по имени: таблицы экспорта DLL упорядочены по имени, поэтому двоичный поиск для поиска функции можно использовать . Индекс найденного имени затем используется для поиска порядкового номера в таблице экспорта порядковых номеров. В 16-битной Windows таблица имен не сортировалась, поэтому затраты на поиск имен были гораздо более заметными.

Также возможно привязать исполняемый файл к определенной версии DLL, то есть разрешить адреса импортируемых функций во время компиляции. Для связанного импорта компоновщик сохраняет метку времени и контрольную сумму библиотеки DLL, к которой привязан импорт. Во время выполнения Windows проверяет, используется ли та же версия библиотеки, и если да, то Windows обходит обработку импорта. В противном случае, если библиотека отличается от той, к которой была привязана, Windows обрабатывает импорт обычным способом.

Связанные исполняемые файлы загружаются несколько быстрее, если они запускаются в той же среде, для которой они были скомпилированы, и точно в то же время, если они запускаются в другой среде, поэтому привязка импорта не имеет недостатков. Например, все стандартные приложения Windows привязаны к системным библиотекам DLL соответствующей версии Windows. Хорошая возможность привязать импорт приложения к целевой среде во время установки приложения. Это сохраняет библиотеки «связанными» до следующего обновления ОС. Однако при этом изменяется контрольная сумма исполняемого файла, поэтому это невозможно сделать с подписанными программами или программами, управляемыми инструментом управления конфигурацией, который использует контрольные суммы (например, контрольные суммы MD5 ) для управления версиями файлов. Поскольку в более поздних версиях Windows отказались от фиксированных адресов для каждой загруженной библиотеки (по соображениям безопасности), возможность и ценность привязки исполняемого файла уменьшаются.

Явное связывание во время выполнения

Файлы DLL могут быть явно загружены во время выполнения (процесс, называемый Microsoft просто динамическим связыванием во время выполнения) , с использованием LoadLibrary (или LoadLibraryEx) Функция API. GetProcAddress Функция API используется для поиска экспортированных символов по имени и FreeLibrary – выгрузить DLL. Эти функции аналогичны dlopen, dlsym, и dlclose в стандартном API POSIX .

Процедура явного связывания во время выполнения одинакова для любого языка, поддерживающего указатели на функции , поскольку она зависит от API Windows, а не от языковых конструкций.

Отложенная загрузка

Обычно приложение, связанное с библиотекой импорта DLL, не запускается, если DLL не может быть найдена, поскольку Windows не запустит приложение, пока не найдет все библиотеки DLL, которые могут понадобиться приложению. Однако приложение может быть связано с библиотекой импорта, чтобы обеспечить отложенную загрузку динамической библиотеки. В этом случае операционная система не будет пытаться найти или загрузить DLL при запуске приложения; вместо этого компоновщик включает в приложение заглушку, которая попытается найти и загрузить DLL через LoadLibrary и GetProcAddress когда вызывается одна из его функций. Если DLL не может быть найдена или загружена или вызываемая функция не существует, приложение сгенерирует исключение , которое можно перехватить и обработать соответствующим образом. Если приложение не обработает исключение, оно будет перехвачено операционной системой и завершит работу программы с сообщением об ошибке.

Механизм отложенной загрузки также предоставляет перехватчики уведомлений , позволяющие приложению выполнять дополнительную обработку или обработку ошибок при загрузке DLL и/или вызове любой функции DLL.

Вопросы компилятора и языка

Дельфи

В исходном файле ключевое слово library используется вместо program. В конце файла функции, которые нужно экспортировать, перечислены в exports пункт.

Делфи не нужен LIB файлы для импорта функций из DLL; для ссылки на DLL, external Ключевое слово используется в объявлении функции для обозначения имени DLL, за которым следует name назвать символ (если он отличается) или index для идентификации индекса.

Microsoft Visual Basic

В Visual Basic (VB) поддерживается только связывание во время выполнения; но помимо использования LoadLibrary и GetProcAddress Функции API, объявления импортированных функций разрешены.

При импорте функций DLL через объявления VB генерирует ошибку времени выполнения, если DLL файл не может быть найден. Разработчик может обнаружить ошибку и обработать ее соответствующим образом.

При создании библиотек DLL в VB среда IDE позволяет создавать только библиотеки DLL ActiveX, однако методы были созданы. чтобы позволить пользователю явно указать компоновщику включить файл .DEF, который определяет порядковый номер и имя каждой экспортируемой функции. Это позволяет пользователю создать стандартную библиотеку Windows DLL с помощью Visual Basic (версии 6 или ниже), на которую можно ссылаться через оператор «Объявить».

С и С++

Microsoft Visual C++ (MSVC) предоставляет несколько расширений стандарта C++ , которые позволяют указывать импортируемые или экспортируемые функции непосредственно в коде C++; они были приняты другими компиляторами C и C++ для Windows, включая версии GCC для Windows . Эти расширения используют атрибут __declspec перед объявлением функции. Обратите внимание: когда доступ к функциям C осуществляется из C++, их также необходимо объявить как extern "C" в коде C++, чтобы сообщить компилятору, что следует использовать связь C.

Помимо указания импортируемых или экспортируемых функций с помощью __declspec атрибуты, они могут быть перечислены в разделе ИМПОРТ или ЭКСПОРТ на странице DEF файл, используемый проектом. DEF файл обрабатывается компоновщиком, а не компилятором, и поэтому он не является специфичным для C++.

Компиляция DLL создаст оба DLL и LIB файлы. LIB файл (библиотека импорта) используется для связывания с DLL во время компиляции; в этом нет необходимости для связывания во время выполнения. Если DLL не является сервером модели компонентных объектов (COM), DLL Файл должен быть помещен в один из каталогов, перечисленных в переменной среды PATH, в системный каталог по умолчанию или в тот же каталог, где находится программа, использующая его. Библиотеки DLL COM-сервера регистрируются с помощью regsvr32.exe, который помещает расположение библиотеки DLL и ее глобальный уникальный идентификатор ( GUID ) в реестр. Затем программы могут использовать DLL, просматривая ее GUID в реестре, чтобы определить ее местоположение, или создать экземпляр COM-объекта косвенно, используя его идентификатор класса и идентификатор интерфейса.

Примеры программирования

Использование импорта DLL

В следующих примерах показано, как использовать привязки для конкретного языка для импорта символов для связывания с DLL во время компиляции.

Дельфи

{$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.

С

Файл «Example.lib» должен быть включен (при условии, что файл example.dll создан) в проект перед статическим связыванием. Файл «Example.lib» автоматически создается компилятором при компиляции DLL. Невыполнение приведенного выше оператора приведет к ошибке компоновки, поскольку компоновщик не будет знать, где найти определение AddNumbers. Файл DLL «Example.dll» также может потребоваться скопировать в место, где будет создан файл .exe с помощью следующего кода:

#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;
}

Использование явного связывания во время выполнения

В следующих примерах показано, как использовать средства загрузки и связывания во время выполнения с использованием привязок Windows API для конкретного языка.

Обратите внимание, что все четыре примера уязвимы для атак с предварительной загрузкой DLL , поскольку файл example.dll может быть разрешен в непредусмотренное автором место (если явно не исключено, что каталог приложения идет перед расположением системной библиотеки и без HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode или HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\CWDIllegalInDLLSearch текущий рабочий каталог просматривается раньше, чем каталоги системной библиотеки), и, таким образом, обнаруживается вредоносная версия библиотеки. См. ссылку на руководство Microsoft по безопасной загрузке библиотек: следует использовать SetDefaultDllDirectories в kernel32 чтобы удалить каталог приложения и текущий рабочий каталог из пути поиска DLL, или используйте SetDllDirectoryW в kernel32 чтобы удалить текущий рабочий каталог из пути поиска DLL.

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

Дельфи

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.

С

#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;
}

Питон

Привязка Python ctypes будет использовать POSIX API в системах POSIX.

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)

Объектная модель компонента

Модель компонентных объектов (COM) определяет двоичный стандарт для размещения реализации объектов в файлах DLL и EXE. Он предоставляет механизмы для поиска и версии этих файлов, а также независимое от языка и машиночитаемое описание интерфейса. Размещение COM-объектов в DLL является более легким и позволяет им совместно использовать ресурсы с клиентским процессом. Это позволяет COM-объектам реализовывать мощные серверные части для простых интерфейсов с графическим интерфейсом, таких как Visual Basic и ASP. Их также можно запрограммировать на языках сценариев.

Взлом DLL

Из-за уязвимости, широко известной как перехват DLL, подмена DLL, предварительная загрузка DLL или установка двоичных файлов, многие программы загружают и выполняют вредоносную DLL, содержащуюся в той же папке, что и файл данных, открытый этими программами. Уязвимость была обнаружена Георгием Гунинским в 2000 году. В августе 2010 года он получил всемирную известность после того, как компания ACROS Security вновь обнаружила его и многие сотни программ были признаны уязвимыми. Программы, запускаемые из небезопасных мест, т. е. из папок, доступных для записи пользователем, таких как « Загрузки» или каталог Temp , почти всегда подвержены этой уязвимости.

См. также

• Dependency Walker — утилита, которая отображает экспортированные и импортированные функции файлов DLL и EXE.
• Динамическая библиотека
• Библиотека (вычисления)
• Линкер (вычисления)
• Загрузчик (вычислительный)
• Moricons.dll
• Объектный файл
• Общая библиотека
• Статическая библиотека
• DLL Ад

Ссылки

• Харт, Джонсон. Системное программирование Windows, третье издание . Аддисон-Уэсли, 2005 г. ISBN   0-321-25619-0 .
• Ректор, Брент и др. Программирование Win32 . Addison-Wesley Developers Press, 1997. ISBN   0-201-63492-9 .

Внешние ссылки

• dllexport, dllimport на MSDN
• Библиотеки динамической компоновки в MSDN
• Безопасность библиотеки динамической компоновки на MSDN
• Порядок поиска в библиотеке динамической компоновки в MSDN
• Рекомендации Microsoft по безопасности: небезопасная загрузка библиотеки может привести к удаленному выполнению кода.
• Что такое DLL? на сайте поддержки Microsoft
• Библиотечные функции динамической компоновки в MSDN
• Спецификация формата переносимого исполняемого файла Microsoft и общего объектного файла
• Спецификация Microsoft для файлов dll
• Ковровая бомбардировка и отравление директорией
• MS09-014: Устранение уязвимости Safari Carpet Bomb
• Дополнительная информация о векторе удаленной атаки с предварительной загрузкой DLL
• Обновленная информация о векторе удаленной атаки с предварительной загрузкой DLL
• Загружайте библиотеку безопасно