bootdoor: передача управления через границы загрузки

Архитектурный смысл образца

bootdoor показывает сравнительно компактную цепочку переноса исполнения. Входной EFI-код сохраняет исходные функции таблиц, размещает свою копию в памяти типа EfiRuntimeServicesData и перехватывает ExitBootServices и SetVirtualAddressMap. Далее он пытается получить контроль в момент перехода загрузчика к ядру и использует уже загруженный драйвер ACPI.SYS как промежуточную точку исполнения. Авторство GuidePoint Security указано в заголовках файлов. E28 E31

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

Первый вопрос: откуда взялось право стартовать

EfiMain начинается уже в исполняющемся EFI-контексте. Это исходное условие, а не доказательство пути его получения. В комментарии упоминается намерение поддерживать Secure Boot, но само описание намерения не показывает эксплуатацию доверенного загрузчика или преодоление политики подписи. E28

Для сравнительной таблицы поэтому используются две независимые колонки: «начальный контроль» и «действия после него». Изменённая прошивка виртуальной машины, контролируемый EFI-файл и эксплуатация уязвимости загрузчика могут привести к схожей поздней стадии, но означают совершенно разные исходные возможности противника. Смешивание этих сценариев искусственно завышает доступность атаки.

Runtime-память решает только одну часть задачи

Вход вычисляет объём копии, выделяет страницы и сохраняет физический адрес. Пока код работает в одной среде, адрес выглядит достаточным. Однако после передачи управления ОС он может потребовать иного представления. Именно поэтому существует отдельный SetVirtualAddressMap: он обходит дескрипторы карты, находит диапазон с собственной копией и вычисляет соответствующий виртуальный адрес. E28 E30

Этот участок делает явным важный принцип: «память не освобождена» и «код может корректно обратиться к этой памяти» — разные свойства. Необходимо также, чтобы страницы имели допустимые права и чтобы указатели, которыми пользуется программа, относились к действующему адресному пространству. Наличие типа RuntimeServicesData не является гарантией исполнимости на любой платформе.

Официальная спецификация UEFI описывает отдельный контракт runtime services и виртуального отображения. Из него не следует разрешение использовать произвольные boot services после завершения загрузочной фазы. Поэтому в анализе bootdoor адресный переход рассматривается как конкретный механизм, а не как универсальная магия «ниже ОС». S24

ExitBootServices как точка наблюдения

Обработчик ExitBootServices ищет PE-образ, содержащий вызывающий адрес, затем проверяет признаки подходящего модуля и ищет внутреннюю функцию передачи управления. В коде есть сигнатурные варианты и сохранение оригинального участка для продолжения исполнения. Это показывает зависимость от конкретного машинного кода загрузчика. E29

При исследовании новой сборки ОС отсутствие ожидаемой последовательности является отдельным результатом. Оно не доказывает ни исправление уязвимости, ни наличие защиты от всей техники. Аналогично совпадение сигнатуры не доказывает семантическое совпадение функции: нужно подтвердить границы образа, назначение участка и действительный путь вызова.

Обратный поиск образа выполняется циклом, который предполагает существование подходящего заголовка в доступной памяти. Это пример скрытого предусловия. Высокоуровневая схема часто рисует здесь одну стрелку «найти winload», но в реальном коде за ней стоит серия обращений к памяти и предположение о структуре окружения.

Почему используется ACPI.SYS

OslArchTransferToKernel обходит список загруженных модулей, ищет ACPI.SYS и его ресурсную секцию, сохраняет исходные параметры драйвера и меняет точку входа вместе с характеристиками секции. Модификация происходит в загруженном образе. Поэтому наличие исходного подписанного файла на диске не описывает весь путь исполнения этой копии. E31

Назначение промежуточного драйвера — получить вызов уже в контексте ядра, где доступны другие API. В DrvMain разрешаются необходимые функции ядра, отображается переданная область нагрузки, затем выполняется попытка восстановить часть исходного состояния и продолжить нормальную инициализацию драйвера. E32

Из этого нельзя заключать, что весь ACPI.SYS подменён на диске, или что процесс обязательно переживёт любой механизм контроля целостности. Надёжность восстановления и совместимость с HVCI требуют отдельной проверки. В частности, восстановление отдельных полей PE не тождественно доказанному восстановлению всех инвариантов загрузчика и драйвера.

Red и Blue смотрят на разные свидетельства

Red: содержательная проверка гипотезы должна показать переход между контекстами. Вывод EFI-функции, вызов функции ядра и дальнейшая жизнеспособность ОС — отдельные контрольные точки.

Blue: ищите не только неизвестный файл, но и несоответствие происхождения указателей. Если entrypoint или исполняемая область не объясняется нормальной загрузкой соответствующего образа, это повод углубить расследование.

При работе с дампом сравнение должно учитывать релокации, исправления импортов и законные особенности загрузки. Подозрительное изменение становится убедительнее, когда одновременно объясняет перенаправленный control flow, необычное владение памятью и несоответствие исходному образу. Один необычный флаг секции — слабее такой совокупности.

Резидентность, закрепление и восстановление

Восстановление системы должно соответствовать найденному источнику повторного запуска. Очистка текущей памяти не удаляет изменённый firmware image, а переустановка Windows не гарантирует восстановление прошивки виртуальной машины. Это причинный вывод из разделения уровней, а не утверждение, что bootdoor в данном исследовании был установлен на какой-либо системе.