https://github.com/0x00Alchemist/Deadwing

https://github.com/0x00Alchemist/Deadwing

GitHub

GitHub - 0x00Alchemist/Deadwing: SMM driver/rootkit for platform memory access with R3 <-> R0 <-> R-2 communication.

SMM driver/rootkit for platform memory access with R3 <-> R0 <-> R-2 communication. - 0x00Alchemist/Deadwing

Дарова!

Сразу скажу, ничего не проплачено, я просто делюсь проектом ещё одного своего знакомого (я уже это делал, когда делился CTF ивентом от своего дорогуши).

Ближе к сути. Опять же, один из моих знакомых тут решил поднять тележную конфу/форум по разработке читов и всему присущему (реверс, сесурити). Поэтому, если вам интересно что-то из этого, вы можете присоединиться к конфе смешной. Ссылочка, соответственно: https://t.me/makingcheat

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

Telegram

CheatXplorer #cheatdev

первое русскоязычное коммьюнити читеров в телеграм правила: https://github.com/sapdragon/cheatxplorer/blob/main/readme.md

Хорошо, мы зарегистрировали свой хендлер. А как нам общаться, ебать? Платформа предоставляет два протокола для коммуникации, которые доступны нам как в SMM, так и в DXE, а также в последующих фазах, в том числе в рантайме, при условии, что указатель на протокол будет сконвертирован. У нас есть EFI_MM_COMMUNICATION_PROTOCOL и EFI_MM_COMMUNICATION2_PROTOCOL протоколы (1, 2), которые обращаются к SMM Core и триггерят (1, 2) нужный хендлер через сервисы SmiManage или Trigger (1, 2). Учитывая, что данные протоколы конвоируют данные, нам также необходимо хранить где-то данные для хендлера, которые будут позже конвоированы в пространство SMM. Платформа для таких вещей имеет несколько типов пулов: EfiRuntimeServicesData, EfiRuntimeServicesData, EfiReservedMemoryType, EfiACPIMemoryNVS (и вроде бы ещё EfiACPIReclaimMemory, если не ошибаюсь). С другими типами памяти протоколы не работают, так как не предоставляются фазе рантайма.
Где же выделять буфер для коммуникации? В любом месте, кроме как SMM, так как SMRAM закрывается и открывается отдельным протоколом (мы, технически, можем даже это контролировать, неся ущерб целостности платформы), а в эти окошки очень трудно попасть. Единственное релевантное решение, которое я придумал - написание промежуточного рантаймового DXE драйвера, который ловит регистрацию EFI_MM_COMMUNICATION_PROTOCOL/EFI_MM_COMMUNICATION2_PROTOCOL (1, 2), выбрасывает тестовый SMI в ивенте, который триггерит сервис ExitBootServices и ещё один ивент, что конвертирует указатель на проткол, пул памяти и пару функций, реализующих коммуникацию между режимами и публикует пакет данных для модулей ОС. Это удобно, тащемта, несмотря на то, что в итоге мой драйвер находится в HOB, который загружается DXE Core ещё раньше, чем SMM Core.
Я опущу ещё один метод, потому что хочу рассказать ещё о двух менее очевидных, а ко второму "официальному" вернусь позже. Мы можем общаться с "внешним миром" и SMM, неиронично, через NVRAM переменные, при условии, что у нас есть флаг EFI_VARIABLE_NON_VOLATILE. Это может быть удобно в том случае, если целевая ОС реализует возможность регистрировть такие пременные (кеширует сервисы напрямую, я рассказывал об этом здесь, где это можно увидеть на винде, например). Однако, при работе с SMI хендлерами мы не можем обращаться напрямую к рантаймовым сервисом, так как это "не кекурно" и вообще процессор выбросит \#PF, потому что вызов данных сервисов будет за SMRAM (очень красиво cтавим классы). Поэтому, нам необходимо предварительно зарегистрировать коллбек на регистрацию протокола EFI_SMM_VARIABLE_PROTOCOL, только тогда мы можем общаться с рантаймом через NVRAM переменные. Мне, лично, этот метод кажется костыльным.
Есть ещё забавный вариант общаться через Save State (это по сути "карта" со всеми регистрами и их состояниями на момент срабатывания перырвания), кешируя в SMM драйвере EFI_MM_CPU_PROTOCOL протокол, я читал, что это работает на CSM системах с легаси прерываниями (например, INT15 D042). Я смотрел, как это работает, и работает оно не очень, подозреваю, что из-за эмуляции.
Перейдём к ещё одному специфическому методу коммуникации - мы можем регистрировать ACPI таблицы определённого типа (но не сразу, только по прошествию какого-то промежутка времени), выделяя физический буфер с типом EfiACPIMemoryNVS или EfiACPIReclaimMemory, эти таблицы позже будут опубликованы для ОС. Это требует от нас возможность регистрировать SW SMI хендлеры, которые уже не доступны при эмуляции. Этим методом пользуется TCG драйвер для работы с TPM. Увы, нет возможности это затестить сейчас.

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

Stay safe. ???

Дарова, блин! ???
Мы давно с вами не виделись, пирожочечки!

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

Я занимался написанием SMM драйвера, что изначально казалось весьма сложной задачей, однако, по прошествию времени оказалось, что нет, это по сути более аутичное направление разработки (ну, как и вся около-прошивочное/embedded направление(я)) со своими приколами и постприколами. Ближе к сути со следующего абзаца.

Первым вопросом может стать коммуникация с "внешним миром" и SMM. У спецификации инициализации платформы есть несколько "официальных" предложений на этот счёт и ещё парочка неочевидных (один зависит от платформы).
Вся коммуникация, очевидно, происходит через SMI-хендлеры, которые, очевидно, регистрируются нами при первой инициализации SMM (DXE Foundation передаёт "список" драйверов платформы DXE Core, онный запускает SMM Core (не всегда первым)). Мы, в свою очередь, имеем 10 типов хендлеров (по спецификации), но только 4 нам интересны:
1. Root SMI - хендлеры, срабатывающие при каждом SMI, выброшенных платформой.
2. Child SMI - хендлеры, срабатывающие при явном указании SMM Core GUID данных хендлеров.
3. SW SMI - софтварные SMI, срабатывающие через триггер-порт B2, могут принимать данные через порт B3. Триггер-порты теоретически могут меняться, смотрите на FADT/FACP ACPI таблицу.
4. Periodic SMI - из названия, хендлеры, срабатывающие в период N времени.
5. SX SMI - хендлеры Sleep State (S0 - S5 или G1 -G3, если описывать комплексно).
6. USB SMI - хендлеры, что срабатывают при подключении USB устройств.
7. GPI SMI - General Purpose Input, не уверен за что они отвечают.
8. Standby SMI - хендлеры, что триггерятся на нажатие кнопки ожидания.
9. Power Button SMI - хендлеры, что триггерятся на нажатие кнопки питания.
10. I/O Trap SMI - хендлерры, обрабатывающие специфичные адреса/диапазоны I/O процессора.

Я работал с первыми тремя и самым удобным оказался в итоге второй вариант, так как для него завезён нормальный протокол в двух его версиях (1, 2). Последний имеет в себе возможность работать с виртуальными адресами (а ещё он реализован как отдельный драйвер на армах). Если мы работаем с рутовыми хендлерами, то их суть заключается в том, что они срабатывают при каждом выброшенном SMI. Это не совсем релевантно, так как им не очень удобно передавать пул памяти, в котором может содержаться необходимая информация (о пулах я скажу позже). Дебажить рутовые хендлеры также не сильно удобно при отладке бутовых фаз (DXE, BDS, TSL), так как, опять же, процессор в этих фазах выбрасывает их достаточное количество.
Интереснее обстоит вопрос с софтварными хендлерами (SW SMI). Видите ли, пирожочки, в основном отладка подобных вещей в первую очередь производится на QEMU и подобных вещах, а только потом на реальных машинах. Так вот, OVMF (образ прошивки для QEMU и подобных) не подразумевает реализацию протокола EFI_MM_SW_DISPATCH_PROTOCOL в виду некоторых хардварных особенностей. Этот протокол регистрируют "silicon-based" драйвера, которые не могут эмулироваться в виду тех или иных особенностей. В теории, нам ничего не мешает написать собственные драйвера или портировать один из предложенных (1, 2) с заменой и переработкой некоторых функций (например, этой), но это не входит в мои текущие задачи. Мы можем "эмулировать" работу софтварных хендлеров, регистрируя, например, рутовый хендлер, записывать в порт B2 номер хендлера и читать порт в хендлере, сравнивая значения из порта с нашим. На мой взгляд это кринжово и костыльно.

Тут мой знакомый открыл регистрацию на собственный CTF. Зная его - тасочки там будут фановые с примесью постмодерна (возможно даже без раста). Так что рекомендую заценить!

Что касательно меня - дропну кое-что в начале/середине мая. Работа заняла неприлично долго времени, учитывая, что у меня сейчас некоторые технические шоколадки, но, надеюсь, всё будет в порядке и дроп пройдёт все тесты (а тестами придётся обмазываться, как говном по стене)

https://vxtwitter.com/cr3mov/status/1783170345194664052
https://vxtwitter.com/cr3mov/status/1783170345194664052
https://vxtwitter.com/cr3mov/status/1783170345194664052

vxTwitter / fixvx

cr3.mov (@cr3mov)

gm We've opened registration for cr3 CTF at https://cr3c.tf/ Sorry for the delays, we were cooking our stuff. The platform is currently still in beta, feel free to report any bugs/inconsistencies to the #tickets on our discord! that's it, stay tuned for…

https://github.com/VoidSec/DriverBuddyReloaded

GitHub

GitHub - VoidSec/DriverBuddyReloaded: Driver Buddy Reloaded is an IDA Pro Python plugin that helps automate some tedious Windows…

Driver Buddy Reloaded is an IDA Pro Python plugin that helps automate some tedious Windows Kernel Drivers reverse engineering tasks - VoidSec/DriverBuddyReloaded

LogoFAIL slides (BlackHat 2023)

Новый год новым годом, а байтоёбство по расписанию ???

fight 'em // happy new year