Violent_Maid

Дарова!!1

Если вы вдруг будете на ZeroNights, то я, это, буду на Heap Stage рассказывать про CVE-2025-54502.

На самом деле я расскажу немножко больше, как минимум плюсану AGESA/OpenSIL, чутка приправлю ASP/PSP и поговорим немножко про один из отростков RoT.

Так что это, да. Тут я там там вы здесь 😎

Вообще, SMN (System Management Network) штука интересная, так как каким-то неведомым мне образом, может защищать от чтения определённые (?) сегменты памяти.

Например вот вам UMC (Unified Memory Controller). По оффсетам +144h и +148h должен лежать Scramble Key и конфиги для TSME/AMD Memory Guard. И, несмотря на то, что я могу получить конфигурационные регистры UMC, я не могу посмотреть на эти два поля...

Можно ли повлиять как-то на SMN, не имея на руках бутром, и, соответственно, КОДЕ ЭКЗЕКУШЕН в смешных местах? Я думаю, что да. Как? Ну, я предполагаю, что если достаточно побаловаться с UMC, то можно что-то да выцепить.

UMC может иметь до 12 каналов для DRAM слотов. И оно взаимодействует только с одним слотом DRAM (?). То есть, на каждый канал по одному слоту (?).

Базовые адреса для UMC, по видимому (на моей эмпирике) всегда одинаковые: первые 4 канала имеют адреса 0x50000, 0x150000, 0x250000 и 0x350000. Заканчиваются соответственно: 0x60000, 0x160000, 0x260000, 0x360000. Однако, если можно так сказать, каналы UMC поделены на 2 сегмента, по оффсету +A00h уже содержатся всякие секретики (да те же ключи для TSME, например).

Радует только что, если ты найдёшь способ что-то сделать с одним каналом — отвалятся все по той же логике, так как данных маппинги одинаковые и практически ничего не меняется от канала к каналу (ну кроме чего-то по оффсету +128h).

А вообще, я софист агугага бубубу гугугу бебебе 😚😚😚

System Management Network (SMN) - это шина для коммуникации между ASP/PSP и другими МК (по типу SMU (System Management Unit)). Может получать доступ к внутренним регистрам и ко всему, к чему подключена.

SMN может ммапать слоты до 1МБ, что предостаточно для загрузки бинарей (именно так загружается тот же SMU при некоторых кондициях). Технически, можно даже составить карту памяти с помощью отслеживания вызова пары функций внутри Stage 2 загрузчика.

Но вот почему на AMDшном рут комплексе 2 регистра для работы с SMN?

Я не знаю, но у меня есть план

😂😂😂

Доводилось ли вам, мои маленькие интернет-друзья, интересоваться тем, что происходит внутри всеми любимого АМУДЕ ПЭЭСПЭ? Надеюсь, нет. Ведь эта штука очень забавная. А нам, молодым-шутливым, только голову ломать хочется. Поэтому, люди придумали РеВёРс! Занимаясь которым можно немножечко свои шарики за колёсики закатить. Рекомендую начать прямо сейчас, кстати!

С чего бы попроще начать? Ну, определённо с чего-то, что не будет заставлять голову болеть, даааааа...

В какой-то момент, когда я, скажем, занимался поиском смешных вещей, что подарят мне доступ к System Management Unit (SMU), наткнулся на одну забавную вещицу. Я совершенно случайно обнаружил для себя сисколл (ID 0x21 в Stage 2 загрузчике для версий 0.28.x.x), что закидывает ключики в Unified Memory Controller (UMC). Конкретно не вспомню, кто сисколлит это чудо, но точно кто-то из ABL1-ABL4 (AGESA Bootloader), ну и можно сюда плюсануть уже OpenSIL.

Сложив для себя все имеющиеся факты, я примерно понял, что речь тут, по видимому, о TSME. Но более известна эта аббревиатура под другим названием AMD Memory Guard. Эта вот такая смешная штука, что шифрует память, блин!

Чудный сисколл, как и говорилось выше, ответственен за запись ключиков в UMC. Из аргументов он принимает, очевидно, флаги для шифрования, а также некий AddrTweakEn, я пока не определил кто это конкретно. Но скорее всего адрес с приколами!

Помимо калькуляции твиков шифрования на основе битиков в флагах, меня зацепила одна вещь. На первом скрине, gScrambleDataKey константный, буквально; это не адрес, это просто ключ. Этот небольшой ключик записывается по 4 адресам, вероятно самого контроллера: 0x50000, 0x150000, 0x250000 и 0x350000. На что влияет ключик? Ну, я думаю, что в совокупность с посчитанными твиками, он влияет на энтропию.

На основе уже битиков из другого регистра (gUmcProgramFlags, 0x134B0, фотокарточка 2), выбирается вариант программирования ключиков. В отличие от лежащего в сыром виде Scramble ключика, там уже всё нормально. В случае первого варианта, AMD Playstation Portable попытается взять буфер из некоего S5 Buffer (я очень хочу предположить, что это речь про режимы энергопотребления, но не буду). Второй вариант возьмёт существующий адрес, лежащий в ещё одном регистре, ну и после программирования постучится к CCP за SHA-256 хэшем (да).

А, ну вы возможно увидели некий WriteKeys, я предполагаю, что это значение может зависеть от того, прогорели ли фьюзы (а я думаю, что у TSME него есть свой фьюз (как у Intel AntiTheft, блин!)).

Адреса, по которым могут храниться ключи, я показывать не буду, потому что они вполне себе могут быть разными, да и оставлю это на ваш интерес. Адресов всего 4. Только вам это, коде экзекушен инсайд амд плейстейшн портабл необходим. Ну или можете воспользоваться недавно найденным приколом на 16 поколениях АМУДЕ!

В конечном итоге, к моим целям эта находка никуда не привела.

Даров!

Вообще, оказывается, у меня есть данный аниме-канал. Только сейчас вспомнил. И почему никто не сказал? Но да ладно.

На текущий момент я готовлю увлекательные посты про факты из мира доты 2 смешные особенности ASP/PSP, пишу тулчейн для анализа бинарей ASP/PSP и пытаюсь придумать стратегии для атак с последующим дампом бутрома (а это уже шаг к грани безумия). Последнее, в свою очередь, может открыть дорогу к "контролируемому" динамическому анализу (а соответственно, более детальное понимание работы интересующих меня компонентов).

Помимо этого, я относительно недавно начал интересоваться темой ковыряния baseband-чипов. Как-то этот движ у нас немного мёртвый (ну собственно как и мой). На текущий момент я почти собрал необходимые мне железяки (одна из них прямо на фотокарточке). Вполне вероятно, что в скором времени тут будет не только тема с ковырянием в AMD'шных решениях, но и что-то про сотовую связь/LTE/4G/5G/etc.

Из вырезанного контента (перефразировано в угоду блога, без "статейного флёра"):

У APCB есть группа, конфигурирующая чипсет — FCHG, исходя из данных из OpenSIL (спасибо, что у них открыт AGCL-R), он (тип) содержит в себе конфигурации для интерфейса eSPI (Enhanced Serial Peripheral Interface). В середине структуры типа есть массив MMIO адресов. Эти адреса могут быть пустыми, а могут быть и не пустыми (очень классно завёрнул, да?). Собственно, на материнке для отлома ASP они были заполнены. На скринах вы видите их содержимое.

Так как речь была про eSPI, я подумал, что оно как-то связано с LPC/ISA Bridge, с регистром SPI BASE ADDR (Bus 0, Device 0x14, Function 3, Offset 0xA0) оттуда (31:6 биты в регистре — это Spi_eSpi_BaseAddr), но позже вспомнил, что на современных чипсетах LPC/ISA Bridge содержит только 0xFFFFFFFF значения.

В какой-то момент, в голову пришла спонтанная идея дампа ACPI, и, да, это сработало, надо сказать. Адреса 0xFEDD8300 и 0xFEDD8B00 упомянуты только в таблице DSDT, в то время как адрес 0xFEDD8500 упомянут и в DSDT и в SSDT25. Все они "регистрировали" области операций (Operation Region), выглядит следующим образом:

OperationRegion(EURM, SystemMemory, 0xFEDD8500, 0x40)
OperationRegion(ERAM, SystemMemory, 0xFEDD8300, 0x100)
OperationRegion(ERM2, SystemMemory, 0xFEDD8B00, 0x100)
OperationRegion(ERM3, SystemMemory, 0xFEDD8500, 0x100)

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

Регион EURM находился в описании девайса UBTC — USB Type-C. Здесь только вопрос к названию самой области операций. Я смог это сопоставить только с ACPI UCM-UCSI, который должен управлять USB-C, как минимум, в винде.

Остальные регионы описаны в _SB.PCI0.SBRG, то есть System Bus Bridge. Находятся в описании EC0, видимо речь про Embedded Controller. В моей логике, области с именами ERAM, ERM2 и ERM3 относятся к Embedded Controller RAM, то есть, в эти области отображается содержимое EC RAM, и, по-видимому, предназначена для обмена между EC и ОС.

А, ну и если вы внимательны, то области ERAM и ERM3 имеют одинаковый адрес. Я не знаю с чем это связано, может, какая-то ошибка, а может регионы совмещены.

Адрес 0xFEDD8E00 был в массиве, но я не нашёл его упоминания нигде.

Так было на моей плате, на ваших может быть по другому, вплоть до того, что MMIO адресов не будет в APCB.

Another industry-wide knife fight.

- AMD Advisory - CVE - BDU -

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

Эдак ~40% готово точно. Постараюсь покрыть все аспекты что только возможно, включая пару штук в PSP, что мне стали интересны в его Off-Chip Bootloader'е. Попробуем без душнины, вроде бы в моём стиле написания текстов это получается с переменным успехом. На что-то из ряда вон выходящего, претендовать, конечно же не будем. Главное, чтоб было весело!

Stay tuned.

P.S: Chicago's beatdown hardcore bands sounds ethereal

Я анализирую ASP/PSP на протяжении более месяца (начал ещё в конце декабря 25 года), и пока что могу рассказать о нескольких забавных для меня вещах (за остальные мне дадут по хлебалу 😃):

1. AMD, судя по всему, "отделяет" обычные чипсеты и чипсеты класса "премиум".
Я перебрал достаточное количество прошивок материнских плат, в некоторых из них встречаются более интересные "премиумные" штуки. Я пока не хочу говорить, что они делают, в частности и из-за того, что я не уверен в точном понимании оных. В качестве "премиум" чипсетов, например, выступает линейка Threadripper (что справедливо для их цены).

2. Комплектация ASP/PSP МОЖЕТ (?) меняться от версий к версии и от вендора к вендору плат.
Возможно, это моя ошибка, которую мне лень прорабатывать, но, у одного вендора с более новой платой я не увидел MPM драйвера, в то время как у другого вендора этот драйвер был. MPM, судя по моему (пока что) поверхностному анализу — контролирует сетевую плату (вместе с прошивкой). У меня, например, это MT7921 (да, я ковыряю ноутбуки).
Я подозреваю, что у меня просто не распарсилось всё, что нужно. Можно будет попробовать YARA-сиги составить, как мне подсказал мой рук. Но он знает, что я extra ленивый.

Я частично смог подтвердить одну из своих теорий по поводу ASP/PSP и конкретно одного забавного компутерного компонента, и, надеюсь, смогу подтвердить её полностью. Что за теория? Не скажу 😈. Но, очень надеюсь, смогу перенести её и на Intel.

На текущий момент ASP/PSP — это не самая приоритетная задача.
Но мы потеем как можем.

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

У меня DSLogic на 32 канала, что на самом деле с головой достаточно (но и лишним не будет). А ещё осциллограф, но он просто по приколу (пока не особо не нужен).

Прицепить щупы не беда, сколько разобраться с DSView (софт для просмотра полученных сигналов). Я ещё разбираюсь, но у него как-то интересно работает захват «кадров» - через какое-то время старые «кадры» перезаписываются, из-за чего не всегда видно полную картину происходящего. Я подозреваю, что моя пустая голова запускает не тот режим захвата 😂.
Некоторое время назад мне знакомый дал пощупать Saleae с их Logic 2 - там работа с захваченным сигналом интуитивно понятнее (ИМХО).

Но в принципе, я доволен, бубубу бебебе выражать не буду 😈

Даров, pirozhki!

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

На самом деле, год пролетел для меня быстро, было немного тяжеловато, но как есть. Было много чего как хорошего, так и не очень. Из интересного я думаю, что отмечу поездку на OFFZONE. Это, в принципе, для меня была первая поездка на какую-либо конфу кбшников/ибшников. Было весело, надо сказать. Послушал пару докладов, пообщался с некоторыми ЧеЛоВеКаМи там, ЗАЛУТАЛ СМЕШНОЙ АДДОН ОТ ПТЛАБОВ (не, он реально прикольный) — в общем-то, остался доволен. Жаль, не попал на ZN.
Выступил (хоть и на закрытом) митапе внутри PT о SMM приколюхах, презу можно найти здеся. Она, конечно, не полная (с точки зрения покрытия тем), но даёт минимум. В принципе, не плохо.

Из самого важного: я до сих пор очень сильно потею над кое-чем, что я смог найти у AMD. Работа идёт уже месяц четвёртый, если не пятый. Есть куча затыков, которые меня тормозят (или торможусь я сам), но, неиронично, провожу время очень весело. К счастью, таймлайн, обзначенный мне, весьма большой, чтоб я мог ещё потупить немножечко. Я планирую рассказать о приколюшке в 2026 году. На мой взгляд, пласт получится обширный и детальный (а я постараюсь сделать именно так).

Что у меня запланировано на следующий год?
Я собираюсь полностью погрузиться в AMD PSP (сейчас это ASP, AMD Secure Processor) с точки зрения поиска багов/уязвимостей. В идеале бы ещё хотел потрогать Intel ME (как мои некоторые коллеги). По возможности, конечно, хотелось бы потрогать iOS, ибо там вообще весьма интересно и заманчиво всё устроено.
Собственно, следующий год ожидается весьма интересным. Тут бы не съехать с колёсиков окончательно!

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

Дальше будет только смешнее, сложнее и хардкорнее 😈

Мне очень нравится, как вендора подходят к "инфраструктуре" апдейта фирмвари на чипе. Не говорю про телебоны, FPGA, ПЛИСы, прочие Embedded-штуки,

Если раньше всё было относительно понятно, кто куда и зачем, то сейчас это вообще весело, буквально.

Один регистрирует протокол, два других их ремапят, четвёртый ремапит его для внешнего мира, какой-нибудь ещё один существует чисто по приколу. Какой-нибудь отдельный для капсульных апдейтов обращается к какой-то не идентифицируемой нормально штуке. Зарываешься в это болото с головой и в итоге ты вроде бы и понимаешь, что вообще делается, но как-то и не очень понимаешь.

А ещё нужно не забывать про элементы защиты, зависящие от RoT, они периодически даже мешают исследовательской работе.

Вообще, теоретически, для анализа вот такого говна можно использовать SPI эмуляторы, думается мне (первым в голову пришёл EM100Pro-G3). У меня недавно появилась FPGA плата (на цинке...), хороший пет проект может получиться. Осталось надыбать осциллограф. И, возможно, понять как жить с WSON-8 форм-фактором.

У меня skill issue, нутром чую.

Люди, собаки, люди с собаками, собаки с людьми, людособаки, собаколюды, собаколюдособаки, людособакилюды, собака.. бля.

Совершенно случайно обнаружил для себя архитектурный прекол, связанный с дескрипторами памяти SMRAM из SMM_CORE_PRIVATE_DATA. Я об этом ничего не слышал, не уверен, известен он или нет.

SMM_CORE_PRIVATE_DATA это "контрольная" структура доступная в рантайм маппинге, ею в частности пользуются драйвера с "дочерними" обработчиками, как пример. Саму структурку весьма просто найти в памяти (из ОС в том числе), я не буду рассказывать как это делать, это весьма просто.

Собственно, почему меня заинтересовало поле SmramRanges в SMM_CORE_PRIVATE_DATA? Дело в том, что эти дескрипторы, очевидно, в действительности совпадают с сконфигурированными адресами из MSR (SMM_ADDR, SMM_MASK - AMD; SMRR_PHYS_BASE, SMRR_PHYS_MASK - Intel) и TSEG соответственно.

В теории, поиск SMM_CORE_PRIVATE_DATA ради дескрипторов SMRAM может лишить нас лишней головной боли с получением зарезервированных адресов, а значит - сократить окно брутфорса некоторых специфичных адресов (брутфорсить 4 гигабайта это НЕ весело). Теперь не придётся стучаться к TSEG и BGSM (Base of GTT Stolen Memory) через MCFG и PCI Host Bridge на Intel. Ну или не придётся плакать, если вы любитель AMD, хотя я не уверен.

Вообще у меня огромный диссонанс из-за наличия протокола EFI_MM_CONFIGURATION_PROTOCOL, я его никогда не использовал и подозреваю, что он может выдавать те же результаты. Но так-то, во внешнем мире он судя по всему недоступен (я проверил). Интересно (на самом деле нет).

Uhhhhhhhhhhhhhhhhhhhh

Чёт давно я не появлялся в поле видимости коммунити, да и в принципе особо нечего рассказывать.

Назвиздел. Уже несколько месяцев я провожу псиопы исследования над процессорами AMD и их прошивками 😂
Более того, есть результат

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

А вот рассказать я о ней смогу только в апреле-мае 2026 года 😐

Ну, собсна, посветился и хватит.

Current vibes of today

МИНЗДРАВ ПРЕДУПРЕЖДАЕТ: БАГБАУНТИ УБИВАЕТ — исключительно авторские мюсли!

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

За свой 21 годик жизни я приходил к вендору "as is" (т.е самостоятельно) ровно 2 раза и оба раза с претензиями что XXX насрал в прошивку. Приходил в не очень далёком 23 году и в 25, 2 недели назад. Можно сослаться на сроки, мол, чё ты бухтишь, только 2 недели прошло. Но так-то в 23-м ответили в течении 3-х рабочих дней — вменяемые сроки. А сейчас я чувствую, что ко мне придут (если вообще придут) в лучшем случае через месяц-два. И это в какой-то степени расстраивает, но теперь есть понимание, что давить надо немного с другой стороны. Надеюсь, что pirozhki помладше (или те кто только собираются влиться в сферу) будут делать так сразу, а не как я!

TL;DR: бубубу бебебе