Antarctic: разрыв между подписанным файлом и ядром в памяти

Основная цепочка в локальном снимке

Antarctic — UEFI-приложение с Linux-ориентированным продолжением. Вход задаёт цель GRUB, устанавливает перехват LoadImage и запускает исходный загрузчик. Следующая стадия работает с уже загруженным образом; затем цепочка пытается дойти до декомпрессора Linux и изменить распакованное ядро. Это существенно иной объект исследования, чем Benthic, которому уже нужен контекст драйвера Windows. E42 E43 E44 E45

README данного снимка содержит анонс и сильные заявления о первенстве. Они не используются как технический результат. Статья ESET о Bootkitty опубликована в 2024 году и позднее дополнена сведением о студенческом происхождении проекта. Существование другого исследования не позволяет автоматически считать код Antarctic его точной копией или частью той же цепочки. S27

Сначала LoadImage, затем изменение образа

В Hooks02LoadImage.c сначала вызывается оригинальная функция загрузки. Только после её результата и получения сведений о загруженном образе выполняется дальнейшая обработка. Это важная временная граница: предметом анализа становится образ в памяти после загрузки, а не обязательно подменённый файл на носителе. E43

При этом право запустить сам Antarctic уже предполагается входной точкой. Перехват позднее загруженного GRUB не доказывает первоначальный обход Secure Boot. Для такого утверждения нужна отдельная цепочка, объясняющая допуск первого EFI-компонента. Иначе исследование незаметно подменяет задачу «получить исполнение» задачей «использовать уже имеющееся исполнение».

Для Blue из этого следует необходимость связать файл, факт его загрузки и дальнейшее состояние памяти. Подпись первого и хеш второго могут быть корректными, тогда как третье уже изменено. Это не делает подписи бесполезными: они отвечают на другой, точно определённый вопрос.

GRUB и выбор декомпрессора

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

Эта цепочка привязана к семейству функций распаковки и их машинному представлению. Другой алгоритм сжатия ядра, иная сборка или иной загрузочный путь могут изменить достижимость. Поэтому из найденного кода нельзя вывести поддержку «любого Linux». Даже общая архитектура x86-64 недостаточна для такого обещания.

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

Распакованный буфер становится объектом атаки

Zstd-обработчик сохраняет сведения о destination buffer, возвращает выполнение оригинальному декомпрессору, затем использует результат как размер сканирования. Он ищет участок, обозначенный как module_sig_check, и при успешном поиске пытается изменить поведение проверки. Отдельно выполняется замена строки версии Linux на демонстрационный маркер. E45

Ключевой объект здесь — уже распакованный vmlinux в памяти. Проверка хеша сжатого файла vmlinuz на диске не является измерением этого позднего состояния. Чтобы обнаружить переход, датчик должен либо контролировать промежуток изменения, либо получить достоверное свидетельство о конечном объекте.

Значение возврата декомпрессора трактуется кодом как длина. В просмотренном участке не показана полноценная проверка того, что это успешный размер в пределах destination capacity, до последующего сканирования. Это статическая зона риска, требующая сверки контракта конкретной функции и ABI. Нельзя считать любое ненулевое значение доказательством валидного распакованного ядра. E45

Пустой Vmlinux.c и реально существующая логика

Файл Hooks03Linux03Vmlinux.c содержит include и разделители, но не реализации функций. Если оценивать проект по дереву каталогов, можно ошибочно приписать ему отдельный завершённый модуль работы с vmlinux. Реальная видимая правка распакованного ядра находится в Hooks03Linux02Vmlinuz.c. E46 E45

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

Module signing — один механизм в более широкой политике

Документация Linux описывает проверку подписи модуля самим ядром и отдельно различает конфигурации, в которых неподписанные модули допускаются или отвергаются. Следовательно, имя функции проверки не определяет всю политику загрузки модулей на конкретном дистрибутиве. S26

Даже предполагаемое изменение одной проверки не доказывает отключение lockdown, IMA appraisal, ограничений namespace, политики LSM или иных путей отказа. Для полного вывода нужно проследить вызовы и условия именно рассматриваемой версии ядра. В этом исследовании подтверждена цель правки исходного образца, а не универсальная возможность загрузить любой LKM.

Red: сильная гипотеза — разрыв целостности между проверкой загружаемого образа и использованием распакованного кода. Её нельзя подтверждать только строкой изменённой версии ядра.

Blue: фиксируйте, что именно измеряет каждый датчик: ESP, загруженный PE, распакованное ядро или последующие модули. Эти свидетельства дополняют друг друга, но не взаимозаменяемы.

Следы и ограничения индикаторов

Демонстрационная строка L3nux version может быть полезным ориентиром для этого снимка, но это слабый универсальный индикатор. Строку легко убрать, она не доказывает успешную правку политики и может находиться просто в неисполнявшемся файле. Более сильная совокупность — объяснённый путь запуска, аномальное перенаправление управления и подтверждённое изменение семантики проверяемого объекта. E45

Итог исследования снимка

Antarctic показывает активную попытку перенести вмешательство в поздний, распакованный образ Linux. При этом остаются предпосылки первого запуска, зависимости от GRUB и Zstd, вопрос корректности ABI и отсутствие динамического подтверждения. Такой профиль значительно информативнее ярлыка «Linux bootkit»: он указывает, где искать свидетельства и какие утверждения пока не имеют достаточной опоры.

  34  #include <Modules/Module1_Boot/Hooks/Hooks03Linux03Vmlinux.h>
  35  
  36  
  37  
  38  // START -> FUNCTIONS -------------------------------------------------------------------------------------------------------------------------
  39  // START -> FUNCTIONS -------------------------------------------------------------------------------------------------------------------------
  40