что такое инъекция кода
Что такое инъекция кода в Windows
И нъекция кода распространена в Windows. Приложения «вводят» фрагменты своего собственного кода в другой запущенный процесс, чтобы изменить его поведение. Этот метод можно использовать для добра или зла, но в любом случае это может вызвать проблемы.
Инъекция кода также обычно называется инъекцией DLL, потому что введенный код часто представляет собой файл библиотеки DLL (динамической библиотеки ссылок). Тем не менее, приложения также могут вводить другие типы кода, которые не являются DLL.
Для чего используется инъекция кода
Внедрение кода используется для выполнения всевозможных трюков и функций в Windows. Данная возможность используется как хорошими так и вредоносными программами. Например:
Является ли инъекция кода плохой
Этот метод постоянно используется широким спектром приложений в Windows. Это единственный реальный способ выполнить множество задач. По сравнению с современной мобильной платформой, такой как iOS от Apple или Android от Google, Windows более мощная ОС, которая предлагает такую гибкость разработчикам.
Конечно, со всей этой силой возникает определенная опасность. Инъекция кода может вызвать проблемы и ошибки в приложениях. Google говорит, что пользователи Windows, у которых есть код, внедренный в браузер Chrome, на 15% чаще подвержены сбоям Chrome, поэтому Google работает над блокировкой этого. Корпорация Майкрософт отмечает, что вредоносное приложение может использовать инъекции кода для вмешательства в настройки браузера, что является одной из причин, по которым он уже заблокирован в Edge.
Microsoft даже предоставляет инструкции по проверке загруженных сторонних DLL в Microsoft Outlook, поскольку они вызывают много сбоев Outlook.
Как проверить внедренные DLL-файлы
Вы можете проверить внедрение кода в своей системе с помощью мощного приложения Process Explorer от Microsoft. Это в основном расширенная версия диспетчера задач, дополненная функциями.
Загрузите и запустите Process Explorer. Нажмите View > Lower Pane View > DLLs или нажмите Ctrl + D.
Выберите процесс в верхней панели и посмотрите в нижнюю панель, чтобы увидеть загруженные DLL. Столбец «Company Name» предоставляет полезный способ фильтрации этого списка.
Например, это нормально видеть множество DLL, созданных корпорацией Microsoft, здесь, поскольку они являются частью Windows. Также нормально видеть библиотеки DLL, сделанные той же компанией, что и рассматриваемый процесс, — «Google Inc.» в случае Chrome на скриншоте ниже.
Вы не так много можете сделать, если найдете в Вашей системе инъекцию кода, кроме удаления программы, внедряющей код, чтобы предотвратить возникновение проблем. Например, если Chrome аварийно завершает работу, Вы можете посмотреть, есть ли какие-либо программы, внедряющие код в Chrome, и удалите их, чтобы предотвратить их вмешательство в процессы Chrome.
Как работает инъекция кода
Инъекция кода не изменяет основное приложение на Вашем диске. Вместо этого он ожидает, что это приложение будет запущено, и оно добавит дополнительный код в этот запущенный процесс, чтобы изменить его функционирование.
Windows включает в себя множество интерфейсов прикладного программирования (API), которые можно использовать для внедрения кода. Процесс может присоединяться к целевому процессу, распределять память, записывать DLL или другой код в эту память, а затем инструктировать целевой процесс для выполнения кода. Windows не запрещает процессам на вашем компьютере мешать друг другу.
Для получения дополнительной технической информации ознакомьтесь с этим сообщением в блоге, в котором объясняется, как разработчики могут внедрять библиотеки DLL, а также смотреть на другие типы инъекций кода в Windows.
В некоторых случаях кто-то может изменить базовый код на диске, например, заменив DLL-файл, который поставляется с ПК-игрой с измененным, чтобы включить обман или пиратство. Это технически не «инъекция кода». Код не вводится в запущенный процесс, но программа вместо этого обманывается при загрузке другой DLL с тем же именем.
💉 Что такое инъекция кода в Windows
Вставка кода в виде инъекции распространена в Windows.
Приложения «вводят» фрагменты своего кода в другой процесс.
Этот метод может быть хорошим или плохим, но в любом случае это может вызвать проблемы.
Ввод кода часто называют инъекцией DLL, потому что введенный код часто представляет собой файл библиотеки DLL (dynamic link library).
Однако приложения могут внедрять другие типы кода, без связи библиотек DLL и процессов.
Какая инъекция кода используется для чего
Ввод кода используется для выполнения всех видов трюков и функциональных возможностей в Windows.
Хотя легитивные программы также используют его, он также используется вредоносными программами. Например:
Является ли инъекция кода плохой практикой?
Этот метод постоянно используется в самых разных приложениях в Windows.
Это единственный реальный способ выполнить множество задач. В отличии Apple iOS или Android от Google, рабочий стол Windows настолько мощный, что он предлагает такую гибкость для разработчиков.
Конечно, со всей этой мощностью возникает определенная опасность.
Ввод кода может вызвать проблемы и ошибки в приложениях.
Google говорит, что пользователи Windows, использующие браузер Chrome, на 15% чаще сталкиваются с сбоями Chrome, поэтому Google работает над блокировкой этого момента.
Microsoft отмечает, что инъекция кода может использоваться вредоносными приложениями для вмешательства в настройки браузера, которые уже заблокированы в Edge.
Сторонние библиотеки DLL загружаются в Microsoft Outlook, поэтому они вызывают так много сбоев Outlook.
Другими словами, инъекция кода – это своего рода грязный хак.
В идеальном мире существовал бы безопасный способ достижения определенных целей, без ввода кода, который не вызвал бы потенциальную нестабильность.
Тем не менее, инъекция кода сегодня является обычной частью платформы приложений Windows.
Это так или иначе происходит в фоновом режиме на вашем ПК с ОС Windows.
Мы могли бы назвать это необходимым злом. Мы оставляем эти риски за собой.
Как проверить внедренные DLL-файлы
Вы можете проверить внедрение кода в своей системе с помощью приложения Process Explorer от Microsoft.
Это в основном расширенная версия диспетчера задач, разработанная с некоторыми дополнительными функциями.
Загрузите Process Explorer.
Нажмите View > Lower Pane View > DLLs или нажмите Ctrl + D.
Выберите процесс в верхней панели и посмотрите внизу загруженные DLL.
Столбец «Company name» предоставляет полезный способ фильтрации этого списка.
Например, это совершенно нормально видеть множество DLL, созданных корпорацией Microsoft,поскольку они являются частью Windows.
Также нормально видеть библиотеки DLL, сделанные той же компанией, что и рассматриваемый процесс, – «Google Inc.» в случае Chrome на скриншоте ниже.
Поэтому мы можем найти несколько DLL-файлов, сделанных «AVAST Software».
Это антивирусное программное обеспечение avast в нашей системе вводит в Chrome код, для работы библиотеки фильтров блокировки Avast Script.
Теперь вы можете произвести анализ своих процессов.
К примеру, если ваш браузер Chrome иногда выдает сбои, вы можете проверить его на внедренные сомнительные DLL и удалить их.
Взламываем сайты: шпаргалка по SQL инъекциям
Типы SQLi
Существует 5 основных типов SQL инъекций:
Далее мы разберем их детальней.
Уязвимые точки
Уязвимые точки для атаки находятся в местах, где формируется запрос к базе: форма аутентификации, поисковая строка, каталог, REST-запросы и непосредственно URL.
Защита от SQLi
Для каждого сервера и фреймворка есть свои тонкости и лучшие практики, но суть всегда одинакова.
Нельзя вставлять данные в запрос напрямую. Всегда обрабатывайте ввод отдельно и формируйте запрос исключительно из безопасных значений.
Создавайте белые списки: их значительно труднее обойти, чем черные. Все названия таблиц, полей и баз должны быть заданы конкретными значениями в вашей программе. Это касается и операторов.
Естественно, не забывайте про ограничение прав доступа к базе.
Тем не менее, кибербезопасность – это тот случай, когда понимание принципов нападения – лучший способ защиты.
Классические атаки
Самый простой пример критически уязвимого для SQLi кода выглядит следующим образом:
Представляя такой антипример, можно понять принцип действия атак, которые мы рассмотрим ниже.
Комментирование
Использование однострочных комментариев позволяет игнорировать часть запроса, идущую после вашей инъекции. Например, ввод в уязвимое поле Username запроса admin’— позволит зайти на ресурс под администратором, потому что поверка пароля будет закомментирована. Конечно, сейчас такой тип уязвимости встречается очень редко, но помнить о ней стоит.
Многострочные комментарии могут справится с проверкой или определить тип базы данных. Например, подобные запросы обойдут примитивный текстовый анализ:
А некоторые особые комментарии позволят определить тип базы данных в целях дальнейшей эксплуатации уязвимостей:
Манипуляции со строками
Существует ряд более продвинутых способов обходить черные списки. Например, против фильтра кавычек можно использовать конкатенацию строк:
В MySQL для обхода сложных паттернов можно представлять строки в шеснадцатиричном виде, с помощью функции HEX() или вводить их посимвольно:
Обход аутентификации
Есть стандартный словарь, содержащий в себе основные запросы, для обхода уязвимой формы аутентификации. Впервые его опубликовали лет 10 назад и регулярно дополняют. Не забудьте прогнать через него формы регистрации на своем сайте:
Union injection
UNION это SQL-команда, позволяющая вертикально комбинировать данные из разных таблиц в одну. Это одна из самых популярных и опасных классических инъекций.
Допустим, на сайте есть список товаров с уязвимой строкой поиска. Тогда, подобрав правильное количество колонок и определив их название, через UNION можно вывести практически любые данные.
Последовательные запросы
Если целевой сервис работает на SQL Server и ASP/PHP, либо на PostgreSQL и PHP, можно использовать простой знак ‘;’ для последовательного вызова вредоносных запросов:
Возможный урон
Конкретных примеров и нюансов довольно много, не будем перечислять все. Главное, помните, что комбинируя эти приёмы и различные специфические функции, атакующий может получить полный доступ к базе и даже командной строке.
Error-Based
Чтобы побороть этот тип атак, достаточно запретить вывод ошибок на проде. Тем не менее, давайте на примере разберем, чем вам может грозить игнорирование этой меры.
Последовательное выполнение следующих запросов к SQL Server, позволит определить в тексте ошибки названия столбцов:
Слепые инъекции
В более-менее хорошо сделанном приложении атакующий не увидите ни ошибок, ни результата UNION-атаки. Тут приходит очередь действовать вслепую.
Условные выражения
Атаки с использованием IF и WHERE – основа слепого метода. Они являются одной из причин, почему используемые вами операторы должны быть закодированы в программе, а не генерироваться абы как. Синтаксис для разных баз будет отличаться:
Boolean-based
Если атакующий все же может получить информацию о наличии или отсутствии ошибки из HTTP-статуса, в сервисе имеется уязвимость к обычной слепой атаке. Рассмотрим запрос, который позволит нам при помощи алгоритма бинарного поиска посимвольно определить название первой таблицы и в дальнейшем всех данных:
Time-Based
Если атакующий не наблюдает никаких отличий в ответах сервера, остается полностью слепая атака. Примером будет использование функций SLEEP или WAIT FOR DALAY:
Конечно, реальные примеры будут выглядеть примерно как boolean-based, только true и false атакующий будет отличать по времени отклика. Недостатки такого метода очевидны. Если выбрать слишком маленькую задержку, будет сильное влияние сторонних факторов типа пинга. Если слишком большую – атака займет очень много времени и её, скорее всего, остановят.
Конечно, по SQLi можно писать целые книги, но мы постарались объяснить ключевые принципы с примерами.
9 самых популярных типов инъекционных атак на веб-приложения
В первые дни Интернета одним из наиболее распространенных методов атаки был простая метод грубой силы (Brute Force). Данную атаку обычно выполняли боты. Но бывают случаи, когда люди тысяча комбинаций имен пользователей и паролей чтобы найти совпадение, для доступа к учетной записи жертвы.
Атаки грубой силой больше не являются угрозой благодаря политике паролей, ограниченным попыткам входа в систему и капчам. Но киберпреступники любят открывать новые методы и использовать их для выполнения новых типов атак.
Давным-давно они обнаружили, что текстовые поля в приложениях или на веб-страницах можно использовать, вводя в них неожиданный текст, который заставит приложение делать то, что оно не должно было делать. Таким образом, на сцену вышли так называемые инъекционные атаки.
1. Внедрение кода (Code injection)
Внедрение инъекций в текстовые поля является одним из наиболее распространенных типов атак. Если злоумышленники знают язык программирования, структуру, базу данных или операционную систему, используемую веб-приложением, они могут ввести код через поля ввода текста, чтобы заставить веб-сервер делать то, что он хочет.
Эти типы инъекционных атак возможны для приложений, в которых отсутствует проверка входных данных. Чтобы предотвратить эти атаки, приложение должно ограничивать столько, сколько может разрешить входным пользователям.
Например, необходимо ограничить объем ожидаемых данных, проверить формат данных, прежде чем принимать их, и ограничить набор разрешенных символов.
Уязвимости внедрения кода легко найти, просто протестировав ввод текста веб-приложения с различными типами контента. Но когда злоумышленнику удастся использовать одну из этих уязвимостей, это может привести к потере конфиденциальности, целостности, доступности или функциональности приложения.
2. SQL инъекции
В результате злоумышленник может проходить через экран входа в систему или выполнять более опасные действия, такие как чтение конфиденциальных данных непосредственно из базы данных, изменение или уничтожение данных или выполнение операций администратора в базе данных.
3. Командные инъекций
Эти атаки также возможны, в основном из-за недостаточной проверки ввода. Они отличаются от атак внедрения кода тем, что злоумышленник вставляет системные команды вместо фрагментов программного кода или сценариев. Следовательно, хакеру не нужно знать язык программирования, на котором базируется приложение, или язык, используемый базой данных. Но они должны знать операционную систему, используемую хост-сервером.
Вставленные системные команды выполняются операционной системой хоста с привилегиями приложения, которые могут позволить выставлять содержимое произвольных файлов, находящихся на сервере, показывать структуру каталогов сервера, среди прочего, изменять пароли пользователей и многое другое.
Эти атаки могут быть предотвращены системным администратором путем ограничения уровня доступа к системе веб-приложений, работающих на сервере.
4. XSS (межсайтовый скриптинг)
Всякий раз, когда приложение принимает ввод от пользователя, который оно генерирует, не проверяя и не кодируя его, оно дает злоумышленнику возможность отправлять вредоносный код другому конечному пользователю.
Атаки с использованием межсайтовых скриптов (XSS) используют эти возможности для внедрения вредоносных сценариев в надежные веб-сайты, которые в конечном итоге отправляются другим пользователям приложения, которые становятся жертвами злоумышленника.
Браузер жертвы выполнит вредоносный скрипт, не зная, что ему нельзя доверять. Поэтому браузер разрешает ему получать доступ к токенам сеансов, файлам cookie или конфиденциальной информации, хранящейся в браузере. При правильном программировании скриптов могут даже переписать содержимое файла HTML.
5. XPath инъекций
Этот тип атаки возможен, когда веб-приложение использует информацию, предоставленную пользователем, для создания запроса XPath для данных XML. Эта атака работает аналогично SQL-инъекции : злоумышленники отправляют искаженную информацию в приложение, чтобы узнать, как структурированы данные XML, а затем снова атакуют, чтобы получить доступ к этим данным.
В отличие от того, что происходит с SQL, в XPath нет разных версий. Это означает, что внедрение XPath может быть выполнено в любом веб-приложении, использующем данные XML, независимо от реализации. Это также означает, что атака может быть автоматизирована; следовательно, в отличие от SQL-инъекций, он может быть применен к произвольному числу целей.
6. Инъекции почтовых команд
Этот метод атаки может использоваться для эксплуатации почтовых серверов и приложений, которые создают операторы IMAP или SMTP с неправильно проверенным пользовательским вводом.
Иногда серверы IMAP и SMTP не имеют надежной защиты от атак, как это было бы в случае большинства веб-серверов, и, следовательно, могли бы быть более уязвимыми. Входя через почтовый сервер, злоумышленники могут обойти ограничения, такие как капчи, ограниченное количество запросов и т.д.
Чтобы использовать SMTP-сервер, злоумышленникам нужна действующая учетная запись электронной почты для отправки сообщений с введенными командами. Если сервер уязвим, он будет отвечать на запросы злоумышленников, позволяя им, например, переопределить ограничения сервера и использовать свои службы для рассылки спама.
Внедрение IMAP может осуществляться в основном в приложениях веб-почты с использованием функции чтения сообщений. В этих случаях атаку можно выполнить, просто введя в адресной строке веб-браузера URL-адрес с введенными командами.
7. CRLF инъекции
Например, вставка CRLF в HTTP-запрос с последующим определенным HTML-кодом может отправлять пользовательские веб-страницы посетителям веб-сайта.
Эта атака может быть выполнена для уязвимых веб-приложений, которые не применяют надлежащую фильтрацию к пользовательскому вводу. Эта уязвимость открывает двери для других типов атак с использованием инъекций, таких как XSS и внедрение кода, а также может происходить на взломанном веб-сайте.
8. Инъекция заголовка узла
На серверах, на которых размещено множество веб-сайтов или веб-приложений, заголовок узла становится необходимым для определения того, какой из веб-сайтов или веб-приложений надлежит запросу, каждое из которых известно как виртуальный хост, должен обрабатывать входящий запрос.
Значение заголовка сообщает серверу, на какой виртуальный хост отправлять запрос. Когда сервер получает неверный заголовок узла, он обычно передает его первому виртуальному узлу в списке. Это представляет собой уязвимость, которую злоумышленники могут использовать для отправки произвольных заголовков узлов первому виртуальному узлу на сервере.
Манипуляции с заголовком узла обычно связаны с приложениями PHP, хотя это также может быть сделано с помощью других технологий веб-разработки. Его последствия могут включать выполнение чувствительных операций злоумышленниками, например, сброс пароля и т.д.
9. Инъекция LDAP
Запросы LDAP включают использование специальных управляющих символов, которые влияют на его управление. Злоумышленники могут потенциально изменить предполагаемое поведение запроса LDAP, если они могут вставить в него управляющие символы.
Опять же, основной проблемой, которая допускает атаки с использованием LDAP, является неправильно проверенный пользовательский ввод. Если текст, отправляемый пользователем в приложение, используется как часть запроса LDAP без его очистки, запрос может закончиться получением списка всех пользователей и его отображением злоумышленнику, просто используя звездочку (*) справа поместите внутрь входной строки.
Предотвращение инъекционных атак
Как мы видели в этой статье, все инъекционные атаки направлены на серверы и приложения с открытым доступом для любого пользователя Интернета. Ответственность за предотвращение этих атак распределяется между разработчиками приложений и администраторами серверов.
Большинство атак допускаются на серверах с языком программирования PHP и если вы хотите защитить свое php приложение то, прочитайте о 6 советов по безопасности для защиты вашего PHP сайта.
Разработчики приложений должны знать риски, связанные с неправильной проверкой пользовательского ввода, и изучать лучшие практики для очистки пользовательского ввода в целях предотвращения рисков.
Администраторы серверов должны периодически проверять свои системы, чтобы обнаруживать уязвимости и исправлять их как можно скорее. Существует много вариантов выполнения этих аудитов, как по запросу, так и автоматически.
Укольчик кода. Играемся с Code Injection под Windows
Содержание статьи
Code Injection – процесс инъекции своего кода в память чужого приложения с дальнейшим его выполнением. Вектор применения довольно широкий, начиная от зловредов и заканчивая различными читами и ботами для игр. В частном случае (который и будет рассмотрен в этой статье) мы можем выполнять функции чужого приложения со своими параметрами. Подобная концепция используется в игровых ботах.
Предисловие
Допустим, у нас есть некий бот, который играет за нас в какую-нибудь игру. От него требуется, помимо сбора игровых данных и принятия решений, еще и производить какие-либо действия в игре. Допустим он решил, что ему требуется атаковать противника. Его алгоритм действий может быть таким:
Последний шаг будет выглядеть в общем случае, как вызов функции:
По умолчанию игровой клиент никаких API возможностей для вызова своих внутренних функций не предоставляет, поэтому единственным способом вызвать внутриигровую функцию как раз и является Code Injection.
Думаю, не надо напоминать, что игровые клиенты защищены от подобных вещей античитами и их обход — тема уже совершенно другой статьи =)
DLL Injection, DLL Hijacking и Code Injection
Хотя эти понятия довольно близкие, крайне важно понимать, чем они отличаются:
Необходимый минимум знаний
Основным мастхэвом является знание языка Си (поскольку это основной язык, используемый в этой статье). Также требуется наличие некоего представления об WinApi, x86 ассемблере и базовые навыки в дебаге с помощью OllyDBG (или любого другого Windows отладчика).
Пишем подопытного
Программа очень примитивна. При нажатие Enter она просто выдаёт содержимое буфера на экран. Содержимое буфера жестко прописано в памяти и нигде не меняется.
Рис. 1 Программа test.exe
Хакер #199. Как взломали SecuROM
Отлаживаем программу
Теперь нам нужно найти интересующие нас адреса и функции. Использовать будем обычный 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
Рис. 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 процесса
Теперь мы можем суммировать эти оффсеты с BaseAddress-ом и получить абсолютные адреса в памяти:
Убедимся, что это те адреса, которые нам нужны. Попробуем вытащить из памяти значение буффера:
Результат представлен на рисунке 9.
Рис. 9 Получение значение буфера
Отлично, значит, адреса мы нашли верные =) Теперь попробуем вызвать функцию со своими параметрами. Для этого нужно написать небольшой ассемблерный код, поместить его в памяти того процесса и передать на него управление. По сути это небольшой шеллкод, поэтому использовать я буду те же принципы, что используются в шеллкодинге.
Шеллкод для вызова функции с нашим параметром представлен на рисунке 10.
Рис. 10 Листинг шеллкода
Байт CC используется здесь для отладки (он является брейпоинтом для отладчика) и в самом шеллкоде не фигурирует. Будь очень внимателен с указателем на стек — если ошибешься в расчетах, в момент возврата из нашего кода (RETN) программа может передать управление куда угодно. Это вызовет падение программы, в которую мы инжектимся. Также будь внимателен с соглашением о вызовах функций, поскольку разные компиляторы по-разному вызывают функции. Длина шеллкода задана жестко, поскольку обычные функции для подсчета длины строки ломаются о нулевые байты.
И всё-таки наша задача вызвать функцию со своим аргументом, поэтому продолжаем. Реализуем вызов функции:
Адреса буфера и функции заполняются изначально символами XXXX и YYYY. Предполагается, что в дальнейшем мы их заменим реальным адресами. Цикл тут для того, чтобы можно было послать несколько сообщений за один запуск инжектора. Вся логика построена в генерации шеллкода «на лету»: адреса берутся из переменных по ходу выполнения программы. Строка, которую мы передаем в качестве аргумента, хранится после шеллкода, её адрес высчитывается как адрес выделенного участка памяти + длина основной нагрузки шеллкода.
Результат работы
Теперь, когда все готово, пришло время на практике проверить работоспособность. Запускаем подопытную программу, а затем стартуем наш инжектор. Как видишь, все прекрасно работает.
Рис. 11 Инжектор 
Рис. 12 Подопытная программа
Заключение
Пришло время закругляться. Надеюсь, ты понял, что Code Injection — сложный, но довольно мощный инструмент. Если правильно совмещать техники Code Injection, DLL Injection и Hooking, можно буквально творить чудеса. Овладев этими техниками, ты сможешь создавать свои читы, писать ботов и различную продвинутую малварь (последнее я не рекомендую, потому что это попадает по 273 статью УК, не забывай про закон).
Пожалуй это всё, чем я хотел поделиться в рамках данной статьи. Спасибо за внимание =)
Аркадий «Betepok» Литвиненко
Постоянный участник CTF c пятилетним опытом участия. Представитель команды BalalaikaCr3w и LC↯BC (объединение More Smoked Leet Chicken и BalalaikaCr3w)