Главная » Хабрахабр » [Из песочницы] The Kernel-Bridge Framework: мостик в Ring0

[Из песочницы] The Kernel-Bridge Framework: мостик в Ring0

Хотели ли Вы когда-нибудь заглянуть под капот операционной системы, посмотреть на внутреннее устройство её механизмов, покрутить винтики и посмотреть на открывшиеся возможности? Возможно, даже хотели поработать напрямую с железом, но считали, что драйвера — rocketscience?

Предлагаю вместе пройтись по мостику в ядро и посмотреть, насколько глубока кроличья нора.

А также, набор юзермодных и ядерных API и обёрток для быстрой и удобной разработки в Ring0 как для новичков, так и для продвинутых программистов. Итак, представляю драйвер-фреймворк для kernel-хакинга, написанный на C++17, и призванный, по возможности, снять барьеры между ядром и юзермодом или максимально сгладить их присутствие.

Основные возможности:

  • Доступ к портам ввода-вывода, а также проброс инструкций in, out, cli и sti в юзермод через IOPL
  • Обёртки над системной пищалкой
  • Доступ к MSR (Model-Specific Registers)
  • Набор функций для доступа к юзермодной памяти других процессов и к памяти ядра
  • Работа с физической памятью, DMI/SMBIOS
  • Создание юзермодных и ядерных потоков, доставка APC
  • Юзермодные Ob*** и Ps***-каллбэки и фильтры файловой системы
  • Загрузка неподписанных драйверов и ядерных библиотек

… и многое другое.
А начнём мы с загрузки и подключения фреймворка в наш проект на C++.

GitHub

Для сборки очень желательно пользоваться новейшей версией Visual Studio и последним доступным пакетом WDK (Windows Driver Kit), скачать который можно с официального сайта Microsoft.

Для тестирования прекрасно подойдёт бесплатный VMware Player с установленной Windows, не ниже Windows 7, любой разрядности.

Сборка тривиальная и вопросов не вызовет:

  1. Открываем Kernel-Bridge.sln
  2. Выбираем нужную разрядность
  3. Ctrl+Shift+B

В результате мы получим драйвер, юзермодную библиотеку, а также сопутствующие служебные файлы (*.inf для ручной установки, *.cab для подписи драйвера на Microsoft Hardware Certification Publisher и т.д.).

Для этого выполним в командной строке от имени администратора: Для установки драйвера (если нет необходимой для х64 цифровой подписи кода — соответствующего EV-сертификата) нужно перевести систему в тестовый режим, игнорирующий наличие цифровой подписи у драйверов.

Если всё сделано правильно, в нижнем правом углу появится надпись, что Windows находится в тестовом режиме. bcdedit.exe /set loadoptions DISABLE_INTEGRITY_CHECKS
bcdedit.exe /set TESTSIGNING ON

… и перезагрузим машину.

Настройка тестовой среды завершена, приступим к использованию API в нашем проекте.

Фреймворк имеет следующую иерархию:

/Kernel-Bridge/API — набор функций для использования в драйверах и ядерных модулях, не имеют внешних зависимостей и могут быть свободно использованы в сторонних проектах
/User-Bridge/API — набор юзермодных обёрток над драйвером и служебные функции для работы с PE-файлами, PDB-символами и т.д.
/SharedTypes/ — одновременно и юзермодные, и ядерные хедеры, содержащие необходимые общие типы

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

Итак, создадим консольный проект на C++, подключим необходимые заголовочные файлы и загрузим драйвер:

#include <Windows.h> #include "WdkTypes.h" // Универсальные типы для x32/x64 и определения из WDK
#include "CtlTypes.h" // Определения структур IOCTL-запросов для драйвера
#include "User-Bridge.h" // API, предоставляемый драйвером int main()
{ using namespace KbLoader; BOOL Status = KbLoadAsFilter( L"X:\\Folder\\Path\\To\\Kernel-Bridge.sys", L"260000" // Высота нашего драйвера в стеке фильтров ); if (!Status) return 0; // Драйвер успешно загружен! // Теперь мы можем использовать API ... // Выгружаемся: KbUnload(); return 0;
}

Отлично! Теперь мы можем использовать API и взаимодействовать с ядром.
Начнём с наиболее востребованного функционала в среде разработчиков читов — чтение и запись памяти чужого процесса:

using namespace Processes::MemoryManagement; constexpr int Size = 64;
BYTE Buffer[Size] = ; BOOL Status = KbReadProcessMemory( // Или KbWriteProcessMemory, чтобы записать ProcessId, 0x7FFF0000, // Желаемый адрес в контексте ProcessId &Buffer, Size
);

Ничего сложного! Опустимся на уровень ниже — чтение и запись ядерной памяти:

using namespace VirtualMemory; constexpr int Size = 64;
BYTE Buffer[Size]; // И "куда", и "откуда" могут быть и ядерными, // и юзермодными адресами в контексте ТЕКУЩЕГО процесса:
BOOL Status = KbCopyMoveMemory( reinterpret_cast<WdkTypes::PVOID>(Buffer), // Куда 0xFFFFF80000C00000, // Откуда Size, FALSE // Говорим драйверу, что буферы не пересекаются
);

А что насчёт функций для взаимодействия с железом? Например, I/O-порты.

Пробросим их в юзермод, взведя 2 бита IOPL в регистре EFlags, отвечающие за уровень привилегий, на котором доступны инструкции in/out/cli/sti.

Таким образом, мы сможем выполнять их в юзермоде без ошибки Privileged Instruction:

#include <intrin.h> using namespace IO::Iopl; // Для примера, включим системную пищалку! KbRaiseIopl(); // Теперь in/out/cli/sti доступны в юзермоде! ULONG Frequency = 1000; // 1 kHz
ULONG Divider = 1193182 / Frequency; __outbyte(0x43, 0xB6); // Установим режим прямоугольных импульсов // Устанавливаем делитель для частоты тактового генератора:
__outbyte(0x42, static_cast<unsigned char>(Divider));
__outbyte(0x42, static_cast<unsigned char>(Divider >> 8)); __outbyte(0x61, __inbyte(0x61) | 3); // Включаем пищалку (подачу импульсов на мембрану) for (int i = 0; i < 5000; i++); // Можно попробовать Sleep(), но IOPL может сброситься при возврате в юзермод! __outbyte(0x61, __inbyte(0x61) & 252); // Останавливаем пищалку KbResetIopl();

Но что насчёт настоящей свободы? Ведь зачастую хочется выполнить произвольный код с привилегиями ядра. Напишем весь ядерный код в юзермоде и передадим на него управление из ядра (SMEP отключается автоматически, перед вызовом драйвер сохраняет FPU-контекст и сам вызов происходит внутри try..except-блока):

using namespace KernelShells; // Для примера вызовем KeStallExecutionProcessor:
ULONG Result = 1337;
KbExecuteShellCode( []( _GetKernelProcAddress GetKernelProcAddress, PVOID Argument ) -> ULONG { // Этот код будет выполнен в Ring0 // Динамически импортируем нужные ядерные функции: using _KeStallExecutionProcessor = VOID(WINAPI*)(ULONG Microseconds); auto Stall = reinterpret_cast<_KeStallExecutionProcessor>( GetKernelProcAddress(L"KeStallExecutionProcessor") ); Stall(1000 * 1000); // Останавливаем процессор на одну секунду ULONG Value = *static_cast<PULONG>(Argument); return Value == 1337 ? 0x1EE7C0DE : 0; }, &Result, // Argument &Result // Result
); // Функция вернёт Result = 0x1EE7C0DE

Но кроме баловства с шеллами, есть и серьёзный функционал, позволяющий создавать простейшие DLP на основе подсистемы файловых, объектных и процессных фильтров.

Это позволит, к примеру, блокировать доступ к произвольным файлам или подменять информацию о серийных номерах жёсткого диска. Фреймворк позволяет фильтровать CreateFile/ReadFile/WriteFile/DeviceIoControl, а также события открытия\дуплицирования хэндлов (ObRegisterCallbacks) и события запуска процессов\потоков и подгрузки модулей (PsSet***NotifyRoutine).

Принцип работы:

  1. Драйвер регистрирует файловые фильтры и устанавливает Ob***/Ps***-каллбэки
  2. Драйвер открывает Communication-порт, к которому подключаются клиенты, желающие подписаться на то или иное событие
  3. Юзермодные приложения присоединяются к порту и получают от драйвера данные о произошедшем событии, выполняют фильтрацию (урезают хэндлы в правах, блокируют доступ к файлу и т.д.) и возвращают событие в ядро
  4. Драйвер применяет полученные изменения

Пример подписки на ObRegisterCallbacks и урезание доступа к текущему процессу:

#include <Windows.h>
#include <fltUser.h> #include "CommPort.h"
#include "WdkTypes.h"
#include "FltTypes.h"
#include "Flt-Bridge.h" ... // Слушатель событий ObRegisterCallbacks:
CommPortListener<KB_FLT_OB_CALLBACK_INFO, KbObCallbacks> ObCallbacks; // Предотвратим открытие хэндла нашего процесса с правами PROCESS_VM_READ:
Status = ObCallbacks.Subscribe([]( CommPort& Port, MessagePacket<KB_FLT_OB_CALLBACK_INFO>& Message
) -> VOID { auto Data = static_cast<PKB_FLT_OB_CALLBACK_INFO>(Message.GetData()); if (Data->Target.ProcessId == GetCurrentProcessId()) { Data->CreateResultAccess &= ~PROCESS_VM_READ; Data->DuplicateResultAccess &= ~PROCESS_VM_READ; } ReplyPacket<KB_FLT_OB_CALLBACK_INFO> Reply(Message, ERROR_SUCCESS, *Data); Port.Reply(Reply); // Отвечаем драйверу
});

Итак, мы вкратце пробежались по основным моментам юзермодной части фреймворка, но за кадром остался ядерный API.

API и обёртки зависят только от самих себя и не зависят от внешнего окружения: Вы можете свободно использовать их в своём собственном драйвере. Весь API и обёртки расположены в соответствующей папке: /Kernel-Bridge/API/
Они включают работу с памятью, с процессами, со строками и блокировками, и много с чем ещё, существенно упрощая разработку своих собственных драйверов.

Пример работы со строками в ядре — камень преткновения всех новичков:

#include <wdm.h>
#include <ntstrsafe.h>
#include <stdarg.h> #include "StringsAPI.h" WideString wString = L"Some string";
AnsiString aString = wString.GetAnsi().GetLowerCase() + " and another string!"; if (aString.Matches("*another*")) DbgPrint("%s\r\n", aString.GetData());

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

  1. Пишете обработчик в /Kernel-Bridge/Kernel-Bridge/IOCTLHandlers.cpp
  2. В этом же файле добавляете обработчик в конец массива Handlers в функции DispatchIOCTL
  3. Добавляете индекс запроса в перечисление Ctls::KbCtlIndices в CtlTypes.h в ТУ ЖЕ ПОЗИЦИЮ, что и в массиве Handlers в п.2
  4. Вызываете свой обработчик из юзермода, написав обёртку в User-Bridge.cpp, произведя вызов с помощью функции KbSendRequest

Поддерживаются все три вида ввода-вывода (METHOD_BUFFERED, METHOD_NEITHER и METHOD_IN_DIRECT/METHOD_OUT_DIRECT), по-умолчанию используется METHOD_NEITHER.

В статье охвачена лишь малая толика всех возможностей. Вот и всё! Надеюсь, фреймворк будет полезен начинающим разработчикам компонентов ядра, реверс-инженерам, разработчикам читов, античитов и защит.

В дальнейших планах: А также, принять участие в разработке приглашаются все желающие.

  • Обёртки для прямых манипуляций с PTE-записями и проброс ядерной памяти в юзермод
  • Инжекторы на основе уже существующих функций создания потоков и доставки APC
  • GUI-платформа для живого реверс-инжиниринга и исследования ядра Windows
  • Скриптовый движок для выполнения кусочков ядерного кода
  • Поддержка SEH в динамически загружаемых модулях
  • Прохождение HLK-тестов

Благодарю за внимание!


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Перевод] Создание собственной цветовой палитры

Адаптировано из нашей будущей книги «Рефакторинг UI» Когда выбираешь цвет, настраиваешь несколько параметров с музыкальными словечками типа «триада» или «четвёртый мажор» — и получаете пять идеальных цветов для своего веб-сайта? Видели эти модные генераторы цветовой палитры? Такой вычислительный и научный ...

Как настроить установку переменных окружения Nuxt.js в рантайме, или Как сделать всё не как все и не пожалеть

(Иллюстрация) В предыдущем раунде битвы с этим фреймворком они показали, как запустить проект на Nuxt так, чтобы все были счастливы. Senior web developer’ы Антон и Алексей продолжают рассказ о непростой борьбе с Nuxt. В новой статье поговорим о реальном применении ...