Пожалуйста, тебе спасибо за тестирование. Нервов надо много только если разбираться с нуля, ничего в этом не понимая, а так — дело на час, и которых 40 минут — война с малознакомым radare2.
Встроенного там нет, зато его можно вставить в полноразмерный порт mPCIe, и он даже без оригинального меню иногда работает. Более новый модем работал бы и без снижения ему скорости порта до Gen1 принудительно, это просто модем такой кривой попался. Насчет комплектации — она отличается наличием самого модема (у меня изначально стоял SSD на 32 Gb в этом слоте вместо него) и пластиковой задней крышкой с прорезью под SIM-карту, все остальное — такое же.
Попробовал — не получается показать то, что мне нужно. Вот файл, который требуется для правильного определения вышеупомянутых структур, загружаем его через to small.h и даем команду t, чтобы посмотреть загруженное. В терминал вываливается 100500 строк текста, на которые не хватает прокрутки. Можно, конечно, буфер сделать больше у терминала, но лучше сделать список структур, а не просто дамп и возможность ходить по нему, выбрать структуру из списка и т.п.
Буду ждать, эту фичу заиметь было бы очень здорово.
Сразу вдогонку — с интерфейсом команды t надо что-то делать, а то там даже прокрутки нет, приходится угадывать названия структур, которые не влезают. И буфер преступно маленький, весь behemoth.h из ida-utils отказывается загружаться.
Стрелки то ладно, и такие пойдут, но за совет однозначно спасибо. Самый главный вопрос: можно ли сделать так, чтобы вместо call [eax + 0x80] отображалось call [eax + offset InstallProtocolInterface]? Я даже собрал минимально-достаточный заголовочный файл, чтобы получить структуры EFI_BOOT_SERVICES и EFI_RUNTIME_SERVICES, загрузил его командой to, но как сделать аналог apply structure offset в r2 — не понимаю. И можно ли вообще, а если нельзя — когда будет можно?
Нет, вручную только. Да и там, зачастую, недостает половины необходимых для нормальной работы данных — дескриптора, региона МЕ, а иногда вообще приложены только те модули, которые требутеся обновить.
Все, что делается до инициализации памяти, и она сама — будет лежать в открытом виде, т.к. оно исполняется прямо из SPI-flash. В этот же драйвер инициализации можно встроить вызов своего кода, который зарегистрирует обработчик события EndOfPei, при срабатывании которого будет доступен как весь расшифрованный код PEI, так и уже расшифрованный код DXE.
Код, на который мы можем влиять, все равно будет и потому такая защита все равно будет отломана.
Решение — запускать код, который производит валидацию прошивки, до reset vector'а, чтобы на него вообще никак нельзя было повлиять (или можно, но только имея private key, как на код ME), такая себе комбинация HW-based validation и HW root-of-trust. Вот это уже без доступа к ключам или уязвимостей аппаратуры не сломать.
Секреты там вокруг всего разводятся — монополия на рынке, страшно ее терять. :)
Рекомендую для исследований купить Intel Galileo Gen2, там практически настоящий i586+ с JTAG из коробки, открытый UEFI и открытая документация. SMM оно тоже умеет.
Если хочется чего-то более производительного — Minnowboard Max, там нет JTAG, и открытую прошивку обещают на днях, но не могут выпустить в течение полугода, но я надеюсь, что таки выпустят. А там уже обычный Atom со всеми его плюшками.
Про систему управления — да если бы. Половина SMM-кода занята эмуляцией всякой легасятины времен динозавров, другая — разные вендорские утилиты для прошивки БИОСа, получения информации о системе, управления подсветкой и т.п. То, что могли написать на AML, если бы у него был менее наркоманский синтаксис.
Через TPM нельзя нормально проверить целостность firmware (точнее, можно, но это также бессмысленно, как защита из статьи), поскольку TMP умеет только measurement, а validation все равно находится в коде и может быть обойден. Что толку от TPM со всеми его хэшами, если их никто не спрашивает?
Именно поэтому и Intel, и AMD уже имеют в активе технологии hardware-based fimrware validation, и у Intel они уже давно работают на некоторых ноутбуках. На этот стек технологий условия NDA особенно драконовские, потому скажу всего два слова: Intel BootGuard и AMD TrustZone.
БИОСа в первую очередь. К примеру, происходит где-то в непонятном месте ресет (вот ровно как в статье), а у нас релизный БИОС без strings output (т.е. отладочные строки через COM-порт он не выводит). Добавляем в него драйвер, который вешает по ловушке на CF9h, A2h и 64h и выводит тип ресета и SMM CPU Context, из которого можно достать значение RIP и точное место, откуда он произошел, затем сделать дамп этого куска памяти и разбираться уже предметно.
Действительно дополнительные возможности, другая версия Management Engine и другой БИОС. Можно ли завести AMT на десктопных чипсетах — знает полтора человека из Intel.
Это хорошо, когда можно найти совместимое оборудование, но иногда его либо уже не найти, либо придется два месяца ждать заказ из Китая. При этом ничего, кроме вот такой защиты идиотской, не мешает поставить другой чип, адаптировать под него БИОС (часто достаточно смены VEN/DEV IDs) и отдать починенный ноутбук уже завтра.
Слишком много всего — соглашусь на 500%, но так сейчас работает маркетинг в массовом сегменте, новые фичи важнее исправления стары багов. Это плохо, но пока — вот так.
Зависит от реализации, но чаще всего там есть и SMM-драйверы, и отдельная подсистема. И не работаю с серверными системами, поэтому из IPMI встречался пока только с Intel AMT, работает она без SMM или нет — тоже не проверял, но по идее не должна.
CSM — это Compatibility Support Module, т.е. слой эмуляции legacy BIOS. Если ОС поддерживает UEFI-загрузку и GOP — можно обойтись без него.
Чипы те называются Environmental Controller (EC), на некоторых платах для них пишут SMM-драйверы с вызовом через ACPI, чтобы управление получалось независимым от ОС.
У IO-trap'ов есть применение, мы их для отладки используем достаточно активно, к примеру.
Под конкретную машину надо брать и удалять из прошивки SMM-драйверы по одному, если исходного кода нет. Так оно будет отваливаться по частям и можно выяснить, без чего можно жить еще, а без чего уже нельзя.
Отключение возможно, но очень много вещей перестанет работать — эмуляция USB-устройств для DOS, CSM, мониторинг оборотов, IO-ловушки и масса другого. Можно опробовать удалить драйвер SmmInit или все SMM-драйверы и проверить.
Еще можно пропатчить БИОС на предмет обхода установки бита SMI_LOCK, а затем просто отключать источники SMI, пока не выяснится корень проблемы.
Его не надо вычленять, он в БИОСе в совершенно открытом виде лежит, в файлах типа SMM Driver, Combined PEI/SMM (исключительно редкий вид) и Combined DXE/SMM (раньше были распространены, сейчас от них отказались). Файлы лежат совершенно открыто в DXE-томе и по формату не отличаются от обычных DXE-драйверов, только вместо DXE_SYSTEM_TABLE используют SMM_SYSTEM_TABLE.
По существу вопроса: не было необходимости, поэтому можно считать, что не приходилось. Зато SMM-драйверов написал с десяток, так что кое-что понимаю в том, как они работают и зачем нужны. Рассказывать о конкретных особенностях не могу, NDA (я из второй половины вышеупомянутых людей как раз), но зато могу попросить: исследуйте популярные прошивки, пишите статьи, там конь не валялся еще и места море для улучшений как безопасности, так и функциональности.
Да, прошить такой БИОС получится только программатором, если в нем нет уязвимостей, через которые можно снять с него защиту от записи. Вышеупомянутая уязвимость S3-бутскрипта как раз одна из таких, и если с ее помощью снять биты BIOSWE и SMM_BWP, то шть можно будет хоть через Intel FTP, хоть через flashrom.
Более того, это не D6K такой краб, просто цель поставлена другая — научиться прошивать модифицированный БИОС поверх оригинального при помощи оригинальной же утилиты для обновления, и чтобы при этом все работало. Вот тут он поясняет свои дальнейшие действия после того места, на котором закончилась эта статья.
Сразу вдогонку — с интерфейсом команды t надо что-то делать, а то там даже прокрутки нет, приходится угадывать названия структур, которые не влезают. И буфер преступно маленький, весь behemoth.h из ida-utils отказывается загружаться.
Код, на который мы можем влиять, все равно будет и потому такая защита все равно будет отломана.
Решение — запускать код, который производит валидацию прошивки, до reset vector'а, чтобы на него вообще никак нельзя было повлиять (или можно, но только имея private key, как на код ME), такая себе комбинация HW-based validation и HW root-of-trust. Вот это уже без доступа к ключам или уязвимостей аппаратуры не сломать.
Рекомендую для исследований купить Intel Galileo Gen2, там практически настоящий i586+ с JTAG из коробки, открытый UEFI и открытая документация. SMM оно тоже умеет.
Если хочется чего-то более производительного — Minnowboard Max, там нет JTAG, и открытую прошивку обещают на днях, но не могут выпустить в течение полугода, но я надеюсь, что таки выпустят. А там уже обычный Atom со всеми его плюшками.
Про систему управления — да если бы. Половина SMM-кода занята эмуляцией всякой легасятины времен динозавров, другая — разные вендорские утилиты для прошивки БИОСа, получения информации о системе, управления подсветкой и т.п. То, что могли написать на AML, если бы у него был менее наркоманский синтаксис.
Именно поэтому и Intel, и AMD уже имеют в активе технологии hardware-based fimrware validation, и у Intel они уже давно работают на некоторых ноутбуках. На этот стек технологий условия NDA особенно драконовские, потому скажу всего два слова: Intel BootGuard и AMD TrustZone.
Слишком много всего — соглашусь на 500%, но так сейчас работает маркетинг в массовом сегменте, новые фичи важнее исправления стары багов. Это плохо, но пока — вот так.
Чипы те называются Environmental Controller (EC), на некоторых платах для них пишут SMM-драйверы с вызовом через ACPI, чтобы управление получалось независимым от ОС.
У IO-trap'ов есть применение, мы их для отладки используем достаточно активно, к примеру.
Под конкретную машину надо брать и удалять из прошивки SMM-драйверы по одному, если исходного кода нет. Так оно будет отваливаться по частям и можно выяснить, без чего можно жить еще, а без чего уже нельзя.
Еще можно пропатчить БИОС на предмет обхода установки бита SMI_LOCK, а затем просто отключать источники SMI, пока не выяснится корень проблемы.
По существу вопроса: не было необходимости, поэтому можно считать, что не приходилось. Зато SMM-драйверов написал с десяток, так что кое-что понимаю в том, как они работают и зачем нужны. Рассказывать о конкретных особенностях не могу, NDA (я из второй половины вышеупомянутых людей как раз), но зато могу попросить: исследуйте популярные прошивки, пишите статьи, там конь не валялся еще и места море для улучшений как безопасности, так и функциональности.