Вопрос Реверс SMM/запуск своего вредоноса на уровне ring -2

Начинающий
Начинающий
Статус
Оффлайн
Регистрация
21 Июн 2025
Сообщения
58
Реакции
2
Вопрос, вдруг реально кто-то шарит за работу SMM в винде углубленно.

SMM работает на уровне ring -2(да, этот уровень существует)

Введу в суть:Я исследую SMI(аппаратный переключатель контекста), грубо-говоря это аппаратное прерывание, которое передает полный контроль над процессором кода уже SMM.
Моя цель такова:вызвать SMI и выполнить код своего вредоноса в SMM(то-есть на уровне ring -2). Выполняя код на этом уровне, я выхожу за пределы операционной системы, меня буквально ничто не может задетектить, ни защитные механизмы винды, ни антивирусы.
Кстати, гипервизором тоже я управляю на этом уровне, а значит и всеми уровнями VTL)
Но, есть одна проблема, это - SMRR, Intel Bios Guard, и наш "любимый" SecureBoot, также из нового добавили TPM + Measured Boot, задача которых как я понял, обеспечивание верифицируемости цепочки доверия от hardware до самой винды

Вопрос: Есть ли какие-то уязвимости в SMI, известные или не совсем векторы атак, позволяющие обойти все эти слои защиты? Или найти уязвимость на столь глубоком уровне, запустив код на котором ты буквально король ОС невозможно?

Гитхабодрочеры на месте?
 
Вопрос, вдруг реально кто-то шарит за работу SMM в винде углубленно.
SMM и Windows никак не связаны друг с другом, первый работает прозрачно для любой из ОС на x86_64 процессорах.

Введу в суть:Я исследую SMI(аппаратный переключатель контекста), грубо-говоря это аппаратное прерывание, которое передает полный контроль над процессором кода уже SMM.
Ну не грубо говоря, а буквально триггерит пин 0xB2 на чипсете (или любой другой, который указан в FADT (имеет смысл его проверять, если речь идёт о софтварных прерываниях)), из-за чего ядро процессора, триггернувшего пин, переходит в другой режим работы.

вызвать SMI и выполнить код своего вредоноса в SMM(то-есть на уровне ring -2).
Кстати, гипервизором тоже я управляю на этом уровне, а значит и всеми уровнями VTL)
Я смотрю ты не очень умный, но пытаешься говорить на умные темы. Не понимаю зачем правда.

Но, есть одна проблема, это - SMRR, Intel Bios Guard, и наш "любимый" SecureBoot, также из нового добавили TPM + Measured Boot, задача которых как я понял, обеспечивание верифицируемости цепочки доверия от hardware до самой винды
SMRR здесь не причём, всё что он делает - конфигурирует ренжи для SMRAM каждого ядра процессора. Узнать ренжи можно и без MSR.
Intel Boot Guard и AMD PSB зачастую не сконфигурированы на материнских платах для домашнего пользования.
Secure Boot здесь не причём. Банально HOB с SMM IPL и SMM драйверами загружается DXE IPL ранее, нежели остальные HOB с DXE драйверами. Secure Boot верифицирует DXE драйвера и приложения BDS и TSL фаз.
TPM и Measured Boot не помешают при правильном подходе.

Есть ли какие-то уязвимости в SMI
В SMI нет. В SMM есть.

известные или не совсем векторы атак, позволяющие обойти все эти слои защиты?
Поверхность для атак есть всегда, ты просто не понимаешь о чём говоришь, поэтому их и не видишь. Атаковать ACM блобы и IBB того же IBG можно уже из SMM. Остальные вещи решаемы весьма просто.

Или найти уязвимость на столь глубоком уровне, запустив код на котором ты буквально король ОС невозможно?
В завсимости от того, какой SMI обработчик.


Вот только твоя идея сидеть в SMM мертва уже из коробки, учитывая новенький SMM Isolation.
 
SMM и Windows никак не связаны друг с другом, первый работает прозрачно для любой из ОС на x86_64 процессорах.


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



Я смотрю ты не очень умный, но пытаешься говорить на умные темы. Не понимаю зачем правда.


SMRR здесь не причём, всё что он делает - конфигурирует ренжи для SMRAM каждого ядра процессора. Узнать ренжи можно и без MSR.
Intel Boot Guard и AMD PSB зачастую не сконфигурированы на материнских платах для домашнего пользования.
Secure Boot здесь не причём. Банально HOB с SMM IPL и SMM драйверами загружается DXE IPL ранее, нежели остальные HOB с DXE драйверами. Secure Boot верифицирует DXE драйвера и приложения BDS и TSL фаз.
TPM и Measured Boot не помешают при правильном подходе.


В SMI нет. В SMM есть.


Поверхность для атак есть всегда, ты просто не понимаешь о чём говоришь, поэтому их и не видишь. Атаковать ACM блобы и IBB того же IBG можно уже из SMM. Остальные вещи решаемы весьма просто.


В завсимости от того, какой SMI обработчик.


Вот только твоя идея сидеть в SMM мертва уже из коробки, учитывая новенький SMM Isolation.

Спасибо что объяснил, только недавно начал про SMM читать, просто заинтересовался им и решил у знающих спросить про уязвимости.
Вот только твоя идея сидеть в SMM мертва уже из коробки, учитывая новенький SMM Isolation.

А что касаемо уровня ring -1?

Если найти уязвимость в гипервизоре и запустить вредонос на его уровне, получается механизмы защиты которые находятся в VTL-0 не смогут же задетектить меня? То есть, гипервизор же на VTL-1 работает, а как мы знаем архитектурно с VTL-0 нельзя смотреть что происходит в VTL-1.
Я смотрю ты не очень умный, но пытаешься говорить на умные темы. Не понимаю зачем правда.

Я ток недавно начал про SMM читать, может поэтому кажется как человеку который более опытнее
 
Последнее редактирование:
Если найти уязвимость в гипервизоре и запустить вредонос на его уровне, получается механизмы защиты которые находятся в VTL-0 не смогут же задетектить меня? То есть, гипервизор же на VTL-1 работает, а как мы знаем архитектурно с VTL-0 нельзя смотреть что происходит в VTL-1.
Сам Hyper-V весьма хорошо написан, найти в нём RCE/ACE не самая простая задача. Да и ещё с возможностью аллокации удовлетворяющих страниц памяти.
Другое дело его компоненты, но в рядовых случаях ты их в принципе не увидишь, если сам не пользуешься предоставляемым инструментарием (ВМ и вот это всё). И на моей памяти они всё ещё менее значимые чем securekernel и сам Hyper-V.
Чисто теоретически, можно направить силы на securekernel, найти условный ACE (что в принципе тоже маловероятно) и попробовать что-то с этим сделать.

Только смысла для таких цепочек я не вижу, на этом бы я и закончил, будь я менее опытен в этих делах.
 
Сам Hyper-V весьма хорошо написан, найти в нём RCE/ACE не самая простая задача. Да и ещё с возможностью аллокации удовлетворяющих страниц памяти.
Другое дело его компоненты, но в рядовых случаях ты их в принципе не увидишь, если сам не пользуешься предоставляемым инструментарием (ВМ и вот это всё). И на моей памяти они всё ещё менее значимые чем securekernel и сам Hyper-V.
Чисто теоретически, можно направить силы на securekernel, найти условный ACE (что в принципе тоже маловероятно) и попробовать что-то с этим сделать.

Только смысла для таких цепочек я не вижу, на этом бы я и закончил, будь я менее опытен в этих делах.
Понял, спасибо за ответы
 
Назад
Сверху Снизу