Здравствуйте, уважаемые читатели Хабра.
После долгого перерыва с вами опять я и мы продолжаем копаться во внутренностях UEFI. На этот раз я решил показать несколько техник, которые позволяют упростить реверс и отладку исполняемых компонентов UEFI на примере устаревшего-но-все-еще-популярного PEI-модуля SecureUpdating, который призван защищать прошивку некоторых ноутбуков HP от модификации.
Предыстория такова: однажды вечером мне написал знакомый ремонтник ноутбуков из Беларуси и попросил посмотреть, почему ноутбук с замененным VideoBIOS'ом не хочет стартовать, хотя такой же точно рядом успешно стартует. Ответ оказался на поверхности — не стартующий после модификации ноутбук имел более новую версию UEFI, в которую добрые люди из HP интегрировали защиту от модификации DXE-тома (а там и находится нужный нам VideoBIOS вместе с 80% кода UEFI), чтобы злобные вирусы и не менее злобные пользователи ничего там не сломали ненароком. Тогда проблема решилась переносом PEI-модуля SecureUpdating из старой версии UEFI в новую, но через две недели тот же человек обратился вновь, на этот раз на похожем ноутбуке старая версия модуля работать отказалась, и моя помощь понадобилась вновь.
Если вас заинтересовали мои дальнейшие приключения в мире UEFI PEI-модулей с дизассемблером и пропатченными переходами — добро пожаловать под кат.
Пара ссылок на ликбез
Если вам почти ничего не понятно — ничего страшного, у меня есть несколько поясняющих терминологию статей: 1, 2, 3, почитайте и возвращайтесь. Для фанатов оригинальной документации всегда в наличии спецификация UEFI PI, там все расписано намного подробнее.
Необходимые файлы и инструменты
Для разборки вышеупомянутой прошивки нам понадобятся:
- Собственно файл с прошивкой, мне был выслан вот этот.
- Любая утилита для работы с образами UEFI, я буду использовать UEFITool на правах ее автора, но вы можете использовать любую на ваш вкус, к примеру uefi-firmware-parser или PhoenixTool — это не принципиально.
- Hex-редактор на ваш выбор, я воспользуюсь HxD.
- Дизассемблер с поддержкой PE32-файлов, здесь нам идеально подойдет IDA 6.6 Demo, т.к. PEI-модули в подавляющем большинстве случаев 32-битные и ограничения демо-версии слишком сильно не помешают. Если уважаемый xvilka сможет показать, как в radare2 подгрузить структуры из C-файла, я попробую следующий мод сделать именно в нем, а пока IDA — наше все.
- Из комплекта efi-utils понадобится здоровенный файл behemoth.h, содержащий в себе определения практически всех возможных структур данных, используемых в UEFI. В нашем случае понадобятся всего пара-тройка.
Отправная точка
Итак, со слов товарища-ремонтника нам известно следующее: любое изменение DXE-тома приводит к мертвому ноутбуку, моргающему Caps-lock'ом, а изменения в других частях образа к такому исходу не приводят. Это значит, что где-то хранится либо контрольная сумма, либо ЭЦП, которая проверяется кодом одного из PEI-модулей, и, если она сошлась, управление передается в фазу DXE, а если нет — оно передается куда-то туда, где нам не рады.
Нам нужно выяснить следующее:
- Где именно хранится КС/ЭЦП?
- Кто ее проверяет?
- И, главное, как сделать так, чтобы проверка всегда заканчивалась успешно?
Поехали!
Делай раз!
Открываем файл с прошивкой в UEFITool и смотрим внимательно:
На вид ничего необычного, кроме сообщения о том, что внутри свободного пространства одного из UEFI-томов нашлись данные, которых по спецификации там быть не должно. Именно так производители (из тех, кто не очень верит в спецификацию) обычно прячут свои контрольные суммы или цифровые подписи. Двойным щелчком по сообщению выбираем том, в котором эти самые данные нашлись, и достаем его целиком в файл dxe.vol для анализа. UEFITool закрывать не надо — еще пригодится.
Открываем полученный файл Hex-редактором и рассматриваем, начиная с конца, ведь свободное место в томе может быть только там:
Тут же находится очень подозрительный кусок данных размером 100h (помечен красным), а за ним — сигнатура $SIG, версия прошивки F.50 и кодовое имя платформы 68CPK. Таким образом, на первый вопрос ответ, предположительно, получен.
Делай два!
Чтобы ответить на второй, нужно поискать PEI-модули, которые обращаются к этому блоку данных. Это бывает достаточно непросто и часто приходится пробовать несколько вариантов. Самый простой — поискать другие вхождения сигнатуры $SIG, но в данном случае нас сразу же постигает неудача — других вхождений такой строки в образе нет. Но если блок ищется не по сигнатуре, значит он ищется либо по смещению, либо по абсолютному адресу. Смещение его внутри тома — 12FEE0h. Переключаемся на UEFITool и ищем поиском без учета заголовков Hex-паттерн E0FF12 (процессоры Intel все еще LittleEndian, поэтому порядок байт пришлось поменять):
Ииии… БИНГО, всего 2 вхождения, и оба — в одном и том же PEI-модуле с многообещающим именем SecureUpdating. Вынимаем его без заголовков в файл su.bin для дальнейшего анализа:
Таким образом, предположительно, получен ответ и на второй вопрос.
Делай три!
Осталось разобраться с третьим. Для этого нужен дизассемблер, немного знаний об устройстве PEI-модулей и много-много терпения. Запускаем IDA, соглашаемся с условиями демонстрационного режима и открываем полученный ранее файл.
Идем в Options -> Compiler... и выставляем их вот таким образом:
Затем идем в File -> Load File -> Parse C header file... и загружаем вышеупомянутый в списке необходимых файл behemoth.h с определениями UEFI-структур:
На ошибки разбора обращать внимание не стоит — они в данном случае не навредят.
Теперь открываем вкладку Structures, идем в Edit -> Add structure type... (или нажимаем Insert, так быстрее), там нажимаем Add standard structure и в появившемся списке находим самую важную для PEI-файлов структуру — EFI_PEI_SERVICES, которую и добавляем:
Заодно добавим EFI_GUID и EFI_FFS_FILE_HEADER — пригодятся.
Структура EFI_PEI_SERVICES (если совсем точно — двойной указатель на её экземпляр, созданный ядром PEI) передается в качестве параметра в точку входа каждого PEI-модуля и практически во все его функции. Сделано так потому, что часть PEI вынуждена исполняться непосредственно из flash-памяти, которая в тот момент доступна только для чтения, поэтому глобальные переменные в таких PEI-модулях недоступны и все свое приходится носить с собой. Это неприятное ограничение для программиста, зато оно очень помогает в исследовании и отладке PEI-модулей, т.к. разыменование двойного указателя — не слишком популярная процедура в обычном коде, и потому большую часть вызовов PEI-сервисов можно отследить глазами прямо в листинге. Вот к нему и вернемся, но начала вспомним (или узнаем), как выглядит точка входа в PEI-модуль. Не спешите гуглить, выглядит она вот так:
EFI_STATUS
EFIAPI
PeimEntry(
IN EFI_FFS_FILE_HEADER *FfsFileHeader,
IN EFI_PEI_SERVICES **PeiServices
) {
...
}
EFI_STATUS — это typedef для unsigned int, EFIAPI — typedef для stdcall, первый параметр указывает на тот FFS-файл, в котором находится вызываемый PEI-модуль (на случай, если модуль хранит рядом с собой какие-то данные и ему нужен доступ к ним), а второй — уже описанный выше двойной указатель на таблицу PEI-сервисов. Вооружившись этим знанием, смело меняем тип функции start (выделив ее и нажав клавишу Y), получается примерно так:
Теперь по листингу видно следующее: сначала идет череда вызовов функций, для которых PeiServices не нужен. Чаще всего они занимаются вводом-выводом в/из IO-портов и прочей магией такого рода, проверим это предположение, перейдя в первую по порядку:
Действительно, функция выполняет вывод данных в порт 24Eh. Следующие несколько я опущу (они очень похожие, пишем-читаем IO-порты) и перейду к тем, которые PeiServices все же используют.
Первая оказывается тривиальной и просто сохраняет PeiServices в глобальную переменную (что указывает на то, что наш PEI-модуль выполняется уже из оперативной памяти, но зоркий глаз специалиста заметил бы это еще по информации о PE-файле в UEFITool):
Следующая уже намного больше и намного интереснее, особенно если выставить ей правильные типы параметра и возвращаемого значения:
Выделенный красным фрагмент сразу после пролога и обнуления локальных переменных — тот самый заметный паттерн с разыменованием двойного указателя, о котором я говорил выше. Чтобы понять, какой именно PEI-сервис был вызван, нам и нужны были все эти танцы вокруг структур, теперь можно установить курсор на [eax + 28], нажать T и выбрать в появившемся окне EFI_PEI_SERVICES.GetBootMode:
Посмотрев ее сигнатуру, можно сделать вывод, что var_134 — это на самом деле переменная на стеке, в которую и будет записано значение текущего режима загрузки. Затем это значение сравнивается с 11h и если оно ему равно — вычисления идут дальше, а если все же равно — кладем в eax ноль и уходим на return. 11h в данном случае — это BOOT_ON_S3_RESUME, т.е. если система просыпается из ACPI Sleep Mode, то функция всегда возвращает 0 (а это на местном наречии EFI_SUCCESS). Если же система загружается в из другого состояния, то исполнение идет дальше, и в итоге проходит через вот такое интересное место:
Ба, старые знакомые! Те самые вхождения 12FEE0h, по которым мы этот модуль и нашли. И сначала функцией CopyMem та подозрительная КС/ЭЦП копируется в буфер, а затем оригинальное место затирается байтом FFh, которым пустое место в DXE-томе и заполнено изначально, а дальше следует вызов функции, которая эту самую КС/ЭЦП проверяет.
Можно, конечно, начать теперь исследовать ее, но ведь эта часть кода вообще не исполняется, если система просыпается из S3 (что логично, поскольку ничего из DXE-тома для S3 не нужно, зато просыпаться нужно как можно скорее), и все тем не менее работает, поэтому для начала сделаем так, чтобы этот конкретный PEI-модуль думал, что у нас вечное лето и всегда S3_RESUME, и пропускал любые проверки.
Для этого достаточно поменять cmp [ebp+BootMode], 11h на xor eax, eax, тогда следующий за ним jnz не выполнится никогда, но если он никогда не должен выполнится, то проще заменить сам переход на пару NOP'ов:
Меняем в Hex-редакторе выделенный фрагмент на 90 90 и все готово.
Заключение
Дальнейшее — дело техники. Заменяем через Replace Body… содержимое оригинальной PE32-секции на модифицированный файл, вносим нужные нам изменения в DXE-том, сохраняем изменения и прошиваем получившийся образ на программаторе. У меня этого ноутбука не было, сделал модификацию и отправил результаты просителю. Через пару часов был получен ответ: «огромное спасибо, все работает, клиент доволен», и я с чистой совестью пошел писать статью, которую вы только что прочитали.
Спасибо за внимание и удачных вам модификаций.
Автор: CodeRush
