Dll hijacking что это

Обновлено: 04.07.2024

Не только на C++. Новые технологии, процессы и Agile.

вторник, 9 сентября 2014 г.

DLL Hijacking

DISCLAIMER: Вся информация предоставлена исключительно в ознакомительных целях. Автор не несет ответственности за любой возможный вред, причиненный материалами данной статьи.

Продолжаем усложнять жизнь злоумышленникам. В этот раз посмотрим как написать приложение, которое не будет подвержено атаке DLL Hijacking.

В папке приложения (где расположен исполняемый файл).
В текущей директории.
В системной директории (обычно C:\Windows\System32).
В системной 16-битной директории (да, это до сих пор делается для совместимости — C:\Windows\System).
В директории Windows (C:\Windows).
В каталогах, которые обозначены в переменной окружения PATH.

Начиная с Windows 2000 можно создать пустой файл mycoolapp.exe.local рядом с исполняемый файлом, чтобы форсировать поиск в локальной директории.
Начиная с Windows XP можно создать файл c XML манифестом mycoolapp.exe.manifest либо сохранить этот манифест в ресурсах приложения (как RT_MANIFEST). XML манифест переопределяет порядок поиска подгружаемых библиотек.
Начиная с Windows XP SP2 по умолчанию включена функция SafeDllSearch (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode) и поиск в текущей директории осуществляется позже, чем обычно (после поиска в директории Windows).
Если системе известна библиотека, то она сразу загружает доверенную копию библиотеки. Список известных библиотек хранится в реестре в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs.

Старые программы, которые не учитывают рекомендации для сертификации под Windows, используют свою директорию в Program Files для хранения данных. Т. е. пользователь имеет доступ на запись в данную директорию — это также дает возможность злоумышленнику подложить вредоносную DLL.

Найти библиотеки, которые подгружает та или иная программа несложно — можно воспользоваться средством ProcMon из пакета Sysinternals Suite. Тут можно детально посмотреть что происходит при запуске процесса и далее в процессе работы. Эта утилита будет полезна добросовестным создателям надежного ПО тем, что позволит проинспектировать поведение своего продукта. В ней хорошо видно какие DLL загружаются и по каким путям происходят попытки загрузки.

В операционной системе 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-файлов, которые могут быть использованы для повышения привилегий.

Шаг 2 — Разрешения на папки

Если программное обеспечение установлено в каталог C:\ вместо C:\Program Files , то по умолчанию у аутентифицированных пользователей будет доступ на запись в этот каталог. Кроме того, такое программное обеспечение как Perl, Python, Ruby и т. п. обычно добавляется в переменную PATH. Это дает возможность повышения привилегий, так как пользователь может записать в данный каталог вредоносную DLL, которая будет загружена при следующем запуске процесса и получить права этого процесса.

Слабые разрешения на папку

Шаг 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

PowerSploit

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

Модуль Find-ProcessDLLHijack найдет все процессы в системе, которые пытаются загрузить отсутствующие DLL.

PowerSploit — Обнаружение процессов с отсутствующими DLL

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

Обнаружение папок с правами на изменение

Последний шаг заключается в создании зловредной DLL в одной из папок с Modify (M) — разрешениями.

Создаем DLL в папке со слабыми разрешениями

Заключение

Для возможности повышения привилегий через подмену DLL должны быть выполнены следующие условия:

DLL Hijacking — это популярный метод осуществления вредоносных полезных нагрузок. В этой статье перечислены около 300 исполняемых файлов, уязвимых для данной атаки в Windows 10, а также показано, как с помощью нескольких строк VBScript могут быть выполнены некоторые из вариантов DLL Hijacking с повышенными привилегиями, минуя UAC.

DLL Hijacking

Прежде всего, нужно разобраться с определением этого понятия. DLL Hijacking — это, в самом широком смысле, обман легитимного (доверенного) приложения для загрузки произвольной библиотеки DLL. Такие термины, как DLL Search Order Hijacking, DLL Load Order Hijacking, DLL Spoofing, DLL Injection и DLL Side-Loading часто ошибочно используются для того, чтобы дать определение этому понятию. В лучшем случае эти термины описывают какие-то конкретные случаи DLL Hijacking, но часто применяются взаимозаменяемо и, следовательно, не совсем верно. Как зонтичный термин, DLL Hijacking является более точным определением, так как он включает в себя захват DLL из легитимной DLL.

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

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

DLL replacement : нужно заменить законную DLL на вредоносную DLL. Это может быть осуществлено в сочетании с DLL проксированием , которое дает возможность всем свойствам оригинальных файлов остаться неизменными.
DLL search order hijacking : библиотеки DLL, указанные приложением без пути, разыскиваются в указанных местах в определенном порядке. Процесс происходит путем размещения вредоносной библиотеки DLL в том месте, которое находится в поиске до фактической библиотеки DLL. Иногда оно содержит рабочий каталог целевого приложения.
Phantom DLL hijacking : вредоносная DLL используется вместо несуществующей DLL, после этого нужно попытаться загрузить легитимное приложение.
DLL redirection : надо изменить путь, по которому выполняется поиск DLL, например, отредактировав переменную окружения %PATH% или файлы .exe.manifest / .exe.local для перемещения папки, содержащей вредоносную DLL (Подробнее почитать об этом можно здесь или, перейдя по этой ссылке ).
WinSxS DLL replacement : следует заменить легитимную DLL на вредоносные dll файлы в соответствующей папке winsxs целевых файлов. Этот способ часто называется еще DLL side-loading .
Relative path DLL Hijacking: нужно скопировать (и необязательно переименовать) легитимное приложение в папку, доступную для осуществления записи пользователем, вместе с вредоносной DLL. В использовании этого способа есть сходство с (Signed) Binary Proxy Execution , разновидностью которого также является « bring your own LOLbin ». В последнем же легитимное приложение перемещается вместе с вредоносной DLL, а не копируется из легитимного местоположения на машине жертвы.

Поиск уязвимых исполняемых файлов

Самой большой проблемой является поиск уязвимого исполняемого файла, который можно использовать с разрешениями пользователя по умолчанию. При таргетинге на предустановленные системные исполняемые файлы в Windows атака обычно исключает первый подход, в то время как любые папки, соответствующие 2 и 3 способу, должны быть доступны для записи пользователем, как и файлы и папки в вариантах 4 и 5. Однако, это все мимо.

Следует уделить внимание шестому, самому слабому методу, о котором и пойдет речь в данной статье, хотя обычно он не подходит для получения персистенции или эскалации привилегий. Нужно работать с OceanLotus / APT32, которые в конце 2019 года уже использовались для применения законного rekeywiz.exe вместе с вредоносным duser.dll . В этом случае программа внедряет законное программное обеспечение и сбросывает его на диск, применив подход «bring your own LOLbin» (другой способ достижения такого же результата заключается в копировании легитимного исполняемого файла из папки \system32\, предполагая, что исполняемый файл еще не был пропатчен).

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

Подход

Для того чтобы не запутаться, надо ограничиться исполняемыми файлами, присутствующими по умолчанию в c:\windows\system32\. В тестируемом экземпляре Windows 10 v1909 это составляло в общей сложности 616 исполняемых файлов или 613, если рассматривать только подписанные приложения.

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

На картинке видно, как это работает.

Такой подход позволяет идентифицировать все библиотеки DLL, запрашиваемые каждым приложением, которые станут потенциальными кандидатами для проведения атаки DLL Hijacking. Самый надежный способ узнать, какие библиотеки DLL правильно загружены, — это скомпилировать собственную версию библиотеки DLL и сделать ее запись в уникальный файл после успешной загрузки. Если затем повторить описанный выше подход для всех целевых исполняемых файлов и библиотек DLL, это приведет к созданию коллекции файлов, которая даст пользователю понимание того, какие библиотеки DLL уязвимыми для DLL Hijacking.

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

В этой статье приведены несколько способов эксплуатации загрузки DLL, которые могут быть применены на практике в ближайшем будущем.

Загрузка DLL (dll hijacking) является новым типом атаки Windows. Эта уязвимость, насколько мне известно, вызвана неправильным функционированием во всех версиях Windows. Объяснение этого поведения можно найти на этой странице MSDN. Стоит отметить, что многие считают этот недостаток лишь возможностью, но не настоящей ошибкой, потому что таким образом это и задумывалось в Microsoft. Я категорически не согласен с этим, т.к. не могу представить ни одного разумного использования процедуры загрузки DLL из той же директории, что и открываемый файл.

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

Подобные уязвимости присутствуют во многих известных программах. Таким образом, можно приложить DLL к файлу почти любого типа, например, к таким как PDF, HTML, JPG, MP3, AVI и другим. Даже некоторые Windows приложения уязвимы. Peter Eeckhoute из команды corelan начал составлять неофициальный список, с которым можно посмотреть здесь. Скорее всего, вы используете многие уязвимые приложения. Вы должны ознакомиться с этим списком, если вы используете Windows вне зависимости от версии или редакции.

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

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

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

Совет: Этот тип атак может быть нейтрализован закрытием любых исходящих подключений к общим папкам SMB/WebDav. Порты 445 и 135.

Для использования данного направления достаточно запаковать множество «чистых» файлов и вредоносный DLL в сжатую папку/архив. Жертва извлечет эти файлы и откроет один из них, запустив DLL злоумышленника.

Злоумышленник сжимает 30 jpg картинок и dll в zip файл. Жертва извлекает все в папку и открывает одну из картинок. Жертва заражена.

Не буду описывать остальные примеры, потому что они похожи.

Совет: Перед открытием файлов любого типа, особенно скачанных из интернета, проверьте, нет ли DLL файла в этой же директории. Не забудьте включить отображение скрытых файлов и расширений в параметрах папки. Также рекомендуется переместить только нужные файлы в другую созданную вами директорию. Это обезопасит вас.

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

Злоумышленник размещает торрент на публичном трекере, который содержит много mp3 файлов и вредоносный DLL. Жертва собирается послушать новый альбом и заражается.
Злоумышленник получает доступ администратора к базе данных торрент трекера (недавно это случилось с ThePirateBay) и заменяет торрент с высоким трафиком на зараженный. Это может вызвать крупное заражение в течение нескольких минут.

Совет: Тот же совет, что и выше. Убедитесь, что в папке нет DLL файлов прежде чем открывать файл любого типа. Если у вас трекер или база данных, убедитесь, что веб-сервер или база данных не подвержены любым типам уязвимостей, как например SQL-инъекции, XSS и т.д.

Использование уязвимостей нескольких приложений

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

Злоумышленник открывает доступ к общей папке, которая содержит много .avi файлов и три вредоносных DLL: одну для VLC, другую для Media Player Classic и последнюю для Winamp. Злоумышленник может воспользоваться уязвимостями трех приложений, увеличивая шанс заражения жертвы.

В этой статье приведены несколько способов, которые могут быть применены на практике в ближайшем будущем. Если вы хотите ознакомиться со всеми уязвимыми приложениями и найти свой способ или попытаться найти собственные уязвимые приложения, то я рекомендую использовать набор, предоставленный HD Moore.

Code Injection – процесс инъекции своего кода в память чужого приложения с дальнейшим его выполнением. Вектор применения довольно широкий, начиная от зловредов и заканчивая различными читами и ботами для игр. В частном случае (который и будет рассмотрен в этой статье) мы можем выполнять функции чужого приложения со своими параметрами. Подобная концепция используется в игровых ботах.

Предисловие

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

Найти уникальный идентификатор противника. (параметр idEnemy)
Принять решение, какой тип атаки использовать. (параметр typeAttack)
Произвести атаку с учетом идентификатора и типа атаки.

Последний шаг будет выглядеть в общем случае, как вызов функции:

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

Думаю, не надо напоминать, что игровые клиенты защищены от подобных вещей античитами и их обход — тема уже совершенно другой статьи =)

DLL Injection, DLL Hijacking и Code Injection

Хотя эти понятия довольно близкие, крайне важно понимать, чем они отличаются:

DLL Hijacking - процесс подмены DLL у приложения. Сильно отличается от DLL/Code Injection, несмотря на схожесть названия. Суть заключается в том, что мы помещаем вредоносные DLL рядом с программой: если приложение уязвимо, оно подгрузит вредоносные DLL вместо оригинальных.
Code Injection - процесс инъекции кода в память процесса, с целью его дальнейшего выполнения.
DLL Injection - процесс подгрузки своей DLL в память процесса. На практике проще, чем Code Injection и используется значительно чаще. Но бывают частные случаи, когда приходится использовать Code Injection вместо DLL Injection. Поэтому лучше знать обе техники. =)

Необходимый минимум знаний

Основным мастхэвом является знание языка Си (поскольку это основной язык, используемый в этой статье). Также требуется наличие некоего представления об WinApi, x86 ассемблере и базовые навыки в дебаге с помощью OllyDBG (или любого другого Windows отладчика).

Пишем подопытного

Программа очень примитивна. При нажатие Enter она просто выдаёт содержимое буфера на экран. Содержимое буфера жестко прописано в памяти и нигде не меняется.

Рис. 1 Программа test.exe

Отлаживаем программу

Теперь нам нужно найти интересующие нас адреса и функции. Использовать будем обычный OllyDbg (или любой другой отладчик). Наиболее интересная для нас функция — PrintMessage. Способов её найти в отладчике масса, приведу самый простой: запускаем программу в отладчике, зажимаем Step Over (F8), в этот момент отладчик начинает бодро бегать по инструкциям. Когда он остановится на каком-то CALL или JMP, проваливаемся в них (Enter) и сразу ставим breakpoint (F2). После этого перезапускаем отладку (Ctrl + F2) и снова зажимаем Step Over (F8). На этот раз отладка перешагнет через предыдущий барьер, но упрётся в следующий. Ставим новый breakpoint, перезапускаем отладку и снова зажимаем Step Over. Так мы повторяем до тех пор, пока не упрёмся в вызов функции getchar. Этот вызов находится в функции main непосредственно перед вызовом функции PrintMessage — как раз то, что нам и нужно!

В итоге вызов PrintMessage у меня получился по адресу 0x001613C0. Само собой, у тебя адреса будут другие и вполне возможны отличия в ассемблерном коде. Ассемблерный листинг моей функции PrintMessage приведён на рисунке 2.

Рис. 2 Функция PrintMessage

Давай еще найдем нашу константу default message . Так как мы уже нашли функцию main, можно легко выловить адрес константы из кода. Так же легко можно найти её и в секции: поскольку она является константой, то хранится в секции .rdata. Чтобы выбрать секцию, жмем Alt + M и ищем .rdata (в столбце Owner должен быть test). Для поиска по секции можно использовать поиск (Ctrl + N). У меня получился адрес 0x001658B8.

Рис. 3 Константа в памяти

Листинг самого вызова нашей функции тоже пригодится.

Рис. 4 Вызов функции PrintMessage

Пишем инжектор

Для начала нам нужно найти нужный процесс. Идентификатором процесса в Windows является его PID (DWORD):

Функция вытаскивает все активные процессы и сверяет их имена с аргументом. Если нужный процесс нашелся, то она возвращает его PID. А если ты уберешь комментарий перед printf, функция выведет тебе все текущие процессы.

Теперь пишем основную логику для функции main. Наша задача — найти PID нужного процесса (в нашем случае test.exe) и сохранить его для дальнейших действий:

Рис. 5 PID процесса

Так, PID мы получили. Теперь нам нужен HANDLE процесса. Дописываем в main:

Рис. 6 Handle процесса

Пришло время решить первую проблему: ASLR. Address space layout randomization (ASLR) — это технология, применяемая в операционных системах, при использовании которой случайным образом изменяется расположение в адресном пространстве процесса важных структур, а именно: образа исполняемого файла, подгружаемых библиотек, кучи и стека (© Wikipedia). Другими словами, процесс при каждом новом запуске будет располагаться по разным адресам. Но ведь нам нужно обладать точными адресами внутри чужого процесса для дальнейших манипуляций! Как же быть?

Решается это проблема очень просто, с помощью всего одной функции:

Функция принимает в себя PID и имя модуля (если мы работаем с памятью процесса, а не памятью библиотек, которые к нему подключены, имя модуля будет аналогично имени процесса). На рисунке 7 приведена карта модулей и секций нашего test.exe (взято из OllyDbg).

Рис. 7 Карта модулей и секций

Дописываем в main наше определение BaseAddress:

Рис. 8 BaseAddress процесса

Теперь нам нужно получить адреса буфера и функции PrintMessage в абсолютном виде. Для этого нам нужны offset (сдвиги) этих двух адресов по адресу модуля. Например, адрес буфера в OllyDBG равен 0x001658B8. Еще мы знаем, что модуль test.exe в отладчике (см. карту модулей) загрузился по адресу 0x00150000. Вычитаем 0x001658B8 - 0x00150000 и получаем 0x158B8. Это и есть offset для буфера. Аналогично высчитываем оффсет для функции PrintMessage.

Теперь мы можем суммировать эти оффсеты с BaseAddress-ом и получить абсолютные адреса в памяти:

Убедимся, что это те адреса, которые нам нужны. Попробуем вытащить из памяти значение буффера:

Результат представлен на рисунке 9.

Рис. 9 Получение значение буфера

Отлично, значит, адреса мы нашли верные =) Теперь попробуем вызвать функцию со своими параметрами. Для этого нужно написать небольшой ассемблерный код, поместить его в памяти того процесса и передать на него управление. По сути это небольшой шеллкод, поэтому использовать я буду те же принципы, что используются в шеллкодинге.

Шеллкод для вызова функции с нашим параметром представлен на рисунке 10.

Рис. 10 Листинг шеллкода

Байт CC используется здесь для отладки (он является брейпоинтом для отладчика) и в самом шеллкоде не фигурирует. Будь очень внимателен с указателем на стек — если ошибешься в расчетах, в момент возврата из нашего кода (RETN) программа может передать управление куда угодно. Это вызовет падение программы, в которую мы инжектимся. Также будь внимателен с соглашением о вызовах функций, поскольку разные компиляторы по-разному вызывают функции. Длина шеллкода задана жестко, поскольку обычные функции для подсчета длины строки ломаются о нулевые байты.

И всё-таки наша задача вызвать функцию со своим аргументом, поэтому продолжаем. Реализуем вызов функции:

Результат работы

Теперь, когда все готово, пришло время на практике проверить работоспособность. Запускаем подопытную программу, а затем стартуем наш инжектор. Как видишь, все прекрасно работает.

Рис. 11 Инжектор
Рис. 12 Подопытная программа

Заключение

Пришло время закругляться. Надеюсь, ты понял, что Code Injection — сложный, но довольно мощный инструмент. Если правильно совмещать техники Code Injection, DLL Injection и Hooking, можно буквально творить чудеса. Овладев этими техниками, ты сможешь создавать свои читы, писать ботов и различную продвинутую малварь (последнее я не рекомендую, потому что это попадает по 273 статью УК, не забывай про закон).

Пожалуй это всё, чем я хотел поделиться в рамках данной статьи. Спасибо за внимание =)

Аркадий «Betepok» Литвиненко

Постоянный участник CTF c пятилетним опытом участия. Представитель команды BalalaikaCr3w и LC↯BC (объединение More Smoked Leet Chicken и BalalaikaCr3w)

Читайте также: