Динамически подключаемая библиотека ( DLL ) является Microsoft реализация «s из общей библиотеки концепции в Microsoft Windows и OS / 2 операционные системы . Эти библиотеки обычно имеют расширение файла DLL
, OCX
(для библиотек , содержащих ActiveX элементов управления), или DRV
(для устаревших системных драйверов ). Форматы файлов для DLL такие же, как и для файлов Windows EXE, то есть Portable Executable (PE) для 32-разрядной и 64-разрядной Windows и New Executable (NE) для 16-разрядной версии.Windows. Как и в случае с EXE, библиотеки DLL могут содержать код , данные и ресурсы в любой комбинации.
Расширение имени файла | .dll |
---|---|
Тип интернет-СМИ | приложение / vnd.microsoft.portable-исполняемый |
Единый идентификатор типа (UTI) | com.microsoft.windows-динамическая-библиотека-компоновка |
Магическое число | MZ |
Разработано | Microsoft |
Контейнер для | Общая библиотека |
Файлы данных с тем же форматом файла, что и DLL, но с разными расширениями и, возможно, содержащими только разделы ресурсов, могут называться ресурсными DLL . Примеры таких DLL включают библиотеки значков , иногда имеющие расширение ICL
, и файлы шрифтов с расширениями FON
и FOT
. [1]
Задний план
Первые версии Microsoft Windows запускали программы вместе в одном адресном пространстве . Каждая программа должна была взаимодействовать, передавая центральный процессор другим программам, чтобы графический интерфейс пользователя (GUI) мог работать в многозадачном режиме и быть максимально отзывчивым. Все операции на уровне операционной системы обеспечивались базовой операционной системой: MS-DOS . Все услуги более высокого уровня предоставлялись библиотеками Windows «Библиотека динамической компоновки». Drawing 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 ». [2] По состоянию на 2015 год.[Обновить]Microsoft продвигает .NET Framework как одно из решений проблем ада DLL, хотя теперь они продвигают решения на основе виртуализации, такие как Microsoft Virtual PC и Microsoft Application Virtualization , поскольку они обеспечивают превосходную изоляцию между приложениями. Альтернативным решением для смягчения последствий ада DLL была реализация параллельной сборки .
Функции
Поскольку библиотеки DLL, по сути, такие же, как и EXE-файлы, выбор из них для создания как части процесса компоновки является для ясности, поскольку можно экспортировать функции и данные из любого из них.
Невозможно напрямую выполнить DLL, поскольку для загрузки операционной системы через точку входа требуется EXE-файл , отсюда и существование таких утилит, как RUNDLL.EXE или RUNDLL32.EXE, которые обеспечивают точку входа и минимальную структуру для DLL. которые содержат достаточно функций для выполнения без особой поддержки.
Библиотеки DLL предоставляют механизм для общего кода и данных, позволяя разработчику общего кода / данных обновлять функциональность без необходимости повторного связывания или повторной компиляции приложений. С точки зрения разработки приложений Windows и OS / 2 можно рассматривать как набор обновляемых DLL, позволяющих приложениям для одной версии ОС работать в более поздней, при условии, что поставщик ОС гарантирует, что интерфейсы и функциональность совместимы.
Библиотеки DLL выполняются в пространстве памяти вызывающего процесса и с теми же разрешениями доступа, что означает небольшие накладные расходы при их использовании, но также отсутствие защиты для вызывающего EXE, если в 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, которые должны обрабатываться во время компоновки. Тем не менее, оба являются файлами формата ar Unix .
Связывание с динамическими библиотеками обычно осуществляется путем связывания с библиотекой импорта при сборке или компоновке для создания исполняемого файла. Созданный исполняемый файл затем содержит таблицу адресов импорта (IAT), с помощью которой ссылаются на все вызовы функций DLL (каждая упомянутая функция DLL содержит свою собственную запись в IAT). Во время выполнения IAT заполняется соответствующими адресами, которые указывают непосредственно на функцию в отдельно загруженной DLL. [3]
В Cygwin / MSYS и MinGW библиотекам импорта обычно присваивается суффикс .dll.a
, объединяющий как суффикс Windows DLL, так и суффикс ar Unix. Формат файла похож, но символы, используемые для обозначения импорта, разные (_head_foo_dll vs __IMPORT_DESCRIPTOR_foo). [4] Хотя его инструментальная цепочка GNU Binutils может генерировать библиотеки импорта и связываться с ними, связываться с DLL напрямую быстрее. [5] Экспериментальный инструмент в 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
в POSIX стандарта API.
Процедура явного связывания во время выполнения одинакова для любого языка, поддерживающего указатели на функции , поскольку она зависит от Windows API, а не от языковых конструкций.
Отложенная загрузка
Обычно приложение, связанное с библиотекой импорта DLL, не запускается, если DLL не может быть найдена, потому что Windows не запустит приложение, пока не найдет все библиотеки DLL, которые могут понадобиться приложению. Однако приложение может быть связано с библиотекой импорта, чтобы разрешить отложенную загрузку динамической библиотеки. [6] В этом случае операционная система не будет пытаться найти или загрузить DLL при запуске приложения; вместо этого в приложение добавляется заглушка компоновщиком, который пытается найти и загрузить DLL через LoadLibrary и GetProcAddress при вызове одной из его функций. Если DLL не может быть найдена или загружена или вызываемая функция не существует, приложение сгенерирует исключение , которое может быть перехвачено и обработано соответствующим образом. Если приложение не обрабатывает исключение, оно будет перехвачено операционной системой, которая завершит программу с сообщением об ошибке.
Механизм отложенной загрузки также обеспечивает перехватчики уведомлений , позволяя приложению выполнять дополнительную обработку или обработку ошибок при загрузке DLL и / или вызове любой функции DLL.
Особенности компилятора и языка
Delphi
В исходном файле ключевое слово library
используется вместо program
. В конце файла экспортируемые функции перечислены в exports
разделе.
Delphi не нужны LIB
файлы для импорта функций из DLL; для связи с DLL external
ключевое слово используется в объявлении функции для обозначения имени DLL, за которым name
следует имя символа (если оно отличается) или index
для идентификации индекса.
Microsoft Visual Basic
В Visual Basic (VB) поддерживается только связывание во время выполнения; но в дополнение к функциям using LoadLibrary
и GetProcAddress
API разрешены объявления импортированных функций.
При импорте функций DLL через объявления VB генерирует ошибку времени выполнения, если DLL
файл не может быть найден. Разработчик может обнаружить ошибку и обработать ее соответствующим образом.
При создании библиотек DLL в VB среда IDE разрешает создание только библиотек DLL ActiveX, однако были созданы методы [7], позволяющие пользователю явно указать компоновщику включить файл .DEF, который определяет порядковый номер и имя каждой экспортируемой функции. . Это позволяет пользователю создавать стандартную DLL Windows с помощью Visual Basic (версии 6 или ниже), на которую можно ссылаться с помощью оператора «Declare».
C и C ++
Microsoft Visual C ++ (MSVC) предоставляет несколько расширений для стандартного C ++, которые позволяют указывать функции как импортированные или экспортируемые непосредственно в коде C ++; они были приняты другими компиляторами Windows C и C ++, включая версии GCC для Windows . Эти расширения используют атрибут __declspec
перед объявлением функции. Обратите внимание, что при доступе к функциям C из C ++ они также должны быть объявлены, как extern "C"
в коде C ++, чтобы сообщить компилятору, что следует использовать связь C. [8]
Помимо указания импортируемых или экспортируемых функций с помощью __declspec
атрибутов, они могут быть перечислены в разделе ИМПОРТ или ЭКСПОРТ DEF
файла, используемого проектом. DEF
Файл обрабатывается с помощью линкера, а не компилятор, и таким образом это не является специфической для C ++.
Компиляция DLL создаст как файлы, так DLL
и LIB
. LIB
Файл (библиотеки импорта) используется для связи против DLL во время компиляции; это не обязательно для связывания во время выполнения. Если DLL не является сервером модели компонентных объектов (COM), DLL
файл должен быть помещен в один из каталогов, перечисленных в переменной среды PATH, в системном каталоге по умолчанию или в том же каталоге, что и программа, использующая его. DLL-библиотеки COM-сервера регистрируются с помощью regsvr32.exe, который помещает расположение DLL и ее глобальный уникальный идентификатор ( GUID ) в реестр. Затем программы могут использовать DLL, просматривая ее GUID в реестре, чтобы найти ее местоположение, или создать экземпляр COM-объекта, косвенно используя его идентификатор класса и идентификатор интерфейса.
Примеры программирования
Использование импорта DLL
В следующих примерах показано, как использовать привязки для конкретного языка для импорта символов для связывания с DLL во время компиляции.
Delphi
{$ КОНСОЛЬ APPTYPE} пример программы ;// импортируем функцию, складывающую два числа function AddNumbers ( a , b : Double ) : Double ; StdCall ; внешний 'Example.dll' ;// основная программа var R : Double ;начало R : = AddNumbers ( 1 , 2 ) ; Writeln ( 'Результат был:' , R ) ; конец .
C
Файл Example.lib должен быть включен (при условии, что Example.dll сгенерирован) в проект (опция «Добавить существующий элемент» для проекта!) Перед статической компоновкой. Файл Example.lib автоматически создается компилятором при компиляции DLL. Невыполнение вышеуказанного оператора приведет к ошибке связывания, поскольку компоновщик не будет знать, где найти определение AddNumbers. DLL-файл Example.dll также может быть скопирован в место, где будет создан EXE-файл, с помощью следующего кода.
#include #include // Функция импорта, которая складывает два числа extern «C» __declspec ( dllimport ) double AddNumbers ( double a , double b );int main ( int argc , char * argv []) { двойной результат = AddNumbers ( 1 , 2 ); printf ( "Результат был:% f \ n " , результат ); возврат 0 ; }
Использование явного связывания во время выполнения
В следующих примерах показано, как использовать средства загрузки и связывания во время выполнения с помощью привязок Windows API для конкретных языков.
Обратите внимание, что все четыре образца уязвимы для атак с предварительной загрузкой DLL , поскольку example.dll может быть разрешен в место, непредусмотренное автором (текущий рабочий каталог находится перед местоположениями системной библиотеки), и, следовательно, для вредоносной версии библиотеки. См. Ссылку на руководство Microsoft по безопасной загрузке библиотек: нужно использовать SetDllDirectoryW
in kernel32
для удаления поиска в текущем каталоге перед загрузкой каких-либо библиотек. [9]
Microsoft Visual Basic
Опция Явная Declare Function AddNumbers Lib "Example.dll" _ ( ByVal в As Double , ByVal б As Double ) Как DoubleSub Main () Dim Result As Double Result = AddNumbers ( 1 , 2 ) Debug . Напечатайте «Результат был:» & Результат Конец Подп.
Delphi
пример программы ; {$ APPTYPE CONSOLE} использует Windows ; var AddNumbers : function ( a , b : integer ) : Double ; StdCall ; LibHandle : HMODULE ; begin LibHandle : = LoadLibrary ( 'example.dll' ) ; если LibHandle <> 0, то AddNumbers : = GetProcAddress ( LibHandle , 'AddNumbers' ) ; если присвоено ( AddNumbers ), то Writeln ( '1 + 2 =' , AddNumbers ( 1 , 2 ) ) ; Readln ; конец .
C
#include #include // Сигнатура функции DLL typedef double ( * importFunction ) ( double , double );int main ( int argc , char ** argv ) { importFunction addNumbers ; двойной результат ; HINSTANCE hinstLib ;// Загрузка файла DLL hinstLib = LoadLibrary ( TEXT ( "Example.dll" )); if ( hinstLib == NULL ) { printf ( "ОШИБКА: невозможно загрузить DLL \ n " ); возврат 1 ; }// Получить указатель на функцию addNumbers = ( importFunction ) GetProcAddress ( hinstLib , "AddNumbers" ); if ( addNumbers == NULL ) { printf ( "ОШИБКА: не удалось найти функцию DLL \ n " ); FreeLibrary ( hinstLib ); возврат 1 ; }// Вызов функции. результат = addNumbers ( 1 , 3 );// Выгрузка DLL-файла FreeLibrary ( hinstLib );// Отображаем результат printf ( "Результат был:% f \ n " , результат );возврат 0 ; }
Python
Привязка Python ctypes будет использовать POSIX API в системах POSIX.
import ctypesmy_dll = ctypes . cdll . LoadLibrary ( "Example.dll" )# Следующая спецификация метода "рестайпа" необходима для того, чтобы # Python понял, какой тип возвращает функция. my_dll . AddNumbers . restype = ctypes . c_doubleр = моя_длл . AddNumbers ( ctypes . C_double ( 1.0 ), ctypes . C_double ( 2.0 ))print ( "Результат был:" , p )
Компонентная объектная модель
Модель компонентных объектов (COM) определяет двоичный стандарт для размещения реализации объектов в файлах DLL и EXE. Он предоставляет механизмы для поиска и создания версий этих файлов, а также независимое от языка и машиночитаемое описание интерфейса. Размещение COM-объектов в DLL более легкое и позволяет им совместно использовать ресурсы с клиентским процессом. Это позволяет COM-объектам реализовывать мощные серверные компоненты для простых интерфейсов GUI, таких как Visual Basic и ASP. Их также можно запрограммировать на языках сценариев. [10]
Перехват DLL
Из-за уязвимости, обычно известной как перехват DLL, подмена DLL, предварительная загрузка DLL или установка двоичного файла, многие программы загружают и запускают вредоносную DLL, содержащуюся в той же папке, что и файл данных, открытый этими программами. [11] [12] [13] [14] Уязвимость была обнаружена Георгием Гунински в 2000 году. [15] В августе 2010 года она получила всемирную известность после того, как ACROS Security снова обнаружила ее и многие сотни программ были признаны уязвимыми. [16] Программы, запускаемые из небезопасных мест, т. Е. Из доступных для записи папок, таких как « Загрузки» или « Временный каталог», почти всегда подвержены этой уязвимости. [17] [18] [19] [20] [21] [22] [23]
Смотрите также
- 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 Preloading
- Обновление вектора удаленной атаки с предварительной загрузкой DLL
- Безопасная загрузка библиотеки
- ^ Корпорация Майкрософт. «Создание ресурсной библиотеки DLL» . Сетевая библиотека разработчика Microsoft .
- ^ «Конец ада DLL» . Корпорация Майкрософт. Архивировано из оригинала на 2008-05-06 . Проверено 11 июля 2009 .
- ^ «Понимание таблицы адресов импорта» .
- ^ «Создание и использование библиотек DLL» .
Библиотека импорта представляет собой обычную UNIX-подобную библиотеку .a, но она содержит лишь крошечный бит информации, необходимый для того, чтобы сообщить ОС, как программа взаимодействует с («импортирует») dll. Эта информация связана с .exe.
- ^ "LD и WIN32" . ld документация .
- ^ «Поддержка компоновщика для DLL с отложенной загрузкой» . Корпорация Microsoft . Проверено 11 июля 2009 .
- ^ Петруша, Рон (26.04.2005). «Создание Windows DLL с помощью Visual Basic» . O'Reilly Media . Проверено 11 июля 2009 .
- ^ MSDN , Использование extern для указания связи
- ^ «Безопасная загрузка библиотек для предотвращения атак предварительной загрузки DLL» . Служба поддержки Microsoft . Проверено 28 октября 2019 года .
- ^ Сатран, Майкл. «Модель компонентных объектов (COM)» . msdn.microsoft.com .
- ^ Подмена DLL в Windows
- ^ «Атаки с предварительной загрузкой DLL» . msdn.com . Проверено 25 марта 2018 года .
- ^ «Подробнее о векторе удаленной атаки DLL Preloading» . technet.com . Проверено 25 марта 2018 года .
- ^ "Обновление вектора удаленной атаки с предварительной загрузкой DLL" . technet.com . Проверено 25 марта 2018 года .
- ^ «Двойной щелчок по документам MS Office в проводнике Windows может в некоторых случаях запускать произвольные программы» . www.guninski.com . Проверено 25 марта 2018 года .
- ^ «Бинарная установка - официальный веб-сайт забытой уязвимости. Безопасность ACROS» . www.binaryplanting.com . Проверено 25 марта 2018 года .
- ^ Ковровые бомбардировки и отравление в каталоге
- ^ «Разработчик в Mozilla: пожалуйста, сбросьте старые процессы установки Windows» . theregister.co.uk . Проверено 25 марта 2018 года .
- ^ «Gpg4win - Рекомендации по безопасности Gpg4win 25.11.2015» . www.gpg4win.org . Проверено 25 марта 2018 года .
- ^ «McAfee KB - Бюллетень по безопасности McAfee: исправление безопасности для нескольких программ установки и удаления McAfee (CVE-2015-8991, CVE-2015-8992 и CVE-2015-8993) (TS102462)» . service.mcafee.com . Проверено 25 марта 2018 года .
- ^ «fsc-2015-4 - F-Secure Labs» . www.f-secure.com . Архивировано из оригинального 31 -го июля 2017 года . Проверено 25 марта 2018 года .
- ^ «Уязвимость и прекращение поддержки ScanNow DLL Search Order перехвата» . Rapid7.com . 21 декабря 2015 . Проверено 25 марта 2018 года .
- ^ Команда VeraCrypt. «oss-sec: CVE-2016-1281: Установщики TrueCrypt и VeraCrypt для Windows позволяют выполнять произвольный код с повышенными привилегиями» . seclists.org . Проверено 25 марта 2018 года .