themalwareguardian/uefi-security-research-howyar-sysreturn-netcopyАнализ после CVE-2024-7344 утилиты Howyar SysReturn NetCopy — заметки по обратной разработке, уязвимые бинарные файлы, переписка с вендором и инструментарий proof-of-concept для CVE-2026-79298 (обход IA-32 Secure Boot через пользовательский PE-загрузчик RxPE в BOOTia32.efi).
Под покровом Secure Boot некоторые архитектуры погружаются глубже, чем уязвимости, которые их обнажили. Некоторые бинарные файлы отзываются. Некоторые патчи выпускаются. Но глубоко под поверхностью старые привычки оставляют следы. Вот что остаётся, когда уязвимость раскрыта, исправлена и забыта.
Находкам, задокументированным в этом репозитории, был присвоен идентификатор CVE-2026-79298.
В ходе процесса скоординированного раскрытия вендор подтвердил, что исправление, связанное с CVE-2024-7344, затрагивало только путь загрузки x64. Путь загрузки IA-32 — включая BOOTia32.efi, распространяемый в составе функции SysReturn NetCopy, — никогда не был включён в первоначальное исправление. В результате уязвимый компонент IA-32 продолжал распространяться коммерчески вплоть до версии 11.3.034 (июль 2026).
Специализированный репозиторий CVE ссылается сюда для полной технической глубины: обратная разработка, анализ бинарных файлов, переписка с вендором, артефакты воспроизведения и инструментарий proof-of-concept.
➡️ Исследование: CVE-2026-79298
На протяжении 2026 года я глубоко занимался безопасностью UEFI — разработкой буткитов, обходами Secure Boot, эксплуатацией прошивок, анализом CVE, разработкой наступательного инструментария, публикацией исследований. Это область, в которой я решил специализироваться, и каждая неделя приносит что-то новое. Часть этой работы involves эксплуатацию известных CVE в компонентах UEFI. Часть involves исследование программного обеспечения, которое поставляется с загрузчиками UEFI, но получило мало публичного внимания. И часть — та часть, которую документирует этот репозиторий — involves постановку вопроса, который, как мне кажется, слишком часто упускают из виду:
Как выглядит продукт после CVE?
Не во время спешки с патчами. Не на той неделе, когда выходит advisory. Восемнадцать месяцев спустя, когда давление спало, когда исследователи двинулись дальше, когда никто больше не смотрит.
Этот репозиторий — моя попытка ответить на этот вопрос для одного конкретного продукта: Howyar SysReturn NetCopy.
И я думаю, что то, что я нашёл, удивит людей.
Всё в исследованиях безопасности связано с чем-то ещё, если проследить нити достаточно далеко. Эта конкретная нить началась на работе. Нам поручили проанализировать реальный риск атак UEFI и буткитов против конкретной категории сред: образовательных центров. Звучит нишево. Это не так.
Вот реальность, которую большинство людей за пределами этой области не вполне осознают. В среднем городе может легко насчитываться 70 000 или более общих устройств, развёрнутых в школах — ноутбуков и рабочих станций, используемых учениками от восьми до пятнадцати лет, работающих под управлением дистрибутивов Linux, потому что лицензирование Windows в таком масштабе часто неподъёмно дорого.
Теперь спросите себя: на скольких из этих машин Secure Boot правильно включён? Честный ответ в большинстве мест — на очень немногих. И причина не в халатности. Это операционная реальность.
Правильное включение Secure Boot в среде Linux означает подпись каждого ядра. Каждое обновление ядра — а уязвимости ядра Linux в последние годы появляются быстро — требует нового подписанного образа, развёртываемого на каждой отдельной машине. Это означает скоординированные конвейеры обновлений, инфраструктуру управления ключами, обученный персонал и постоянное сопровождение тысяч конечных точек, распределённых по десяткам локаций.
Для организаций с такими ресурсами это выполнимо. Для большинства школьных округов — нет. Просто недостаточно людей, недостаточно бюджета и недостаточно инструментов, чтобы сделать это правильно в таком масштабе. Поэтому Secure Boot остаётся отключённым.
Пароли BIOS не устанавливаются — потому что их ротация на 70 000 машинах с ограниченным персоналом непрактична. И эти машины стоят там, полностью открытые на уровне прошивки, используемые сотнями учеников каждый день.
Что это на самом деле означает с точки зрения безопасности: атакующий, понимающий эксплуатацию UEFI, может скомпрометировать одну из этих машин на уровне прошивки — до загрузки ОС, до запуска любого защитного ПО, до того, как любой механизм защиты получит шанс вмешаться. Буткит может сохраняться между перезагрузками, между переустановками ОС, между всем. Я знаю это, потому что сам разрабатываю такой инструментарий. Эти техники существуют. Они не теоретические.
Это известная проблема. Она широко признана. И она не исчезнет в ближайшее время.
Операционный ответ на эту проблему — то, что школы на самом деле развёртывают вместо надлежащего Secure Boot — это ПО для восстановления.
Идея проста: что бы ученик ни сделал во время сессии, всё возвращается к известному чистому состоянию после следующей перезагрузки. Вредоносное ПО, изменения конфигурации, повреждённые системные файлы, случайно или намеренно удалённые данные — всё исчезает. Это резко снижает затраты на обслуживание и даёт администраторам способ управлять общими машинами без необходимости иметь идеальные средства защиты на уровне прошивки на каждом устройстве.
Когда мы начали оценивать, какие продукты используются в этих средах, всплыло несколько названий. Одно из них — Howyar SysReturn — тайваньский продукт, специально разработанный для образовательных развёртываний, с явной поддержкой школьных компьютерных классов, общих рабочих станций и крупномасштабных управляемых сред.
Как только я увидел это название, я точно знал, что хочу сделать.
В январе 2025 года ESET Research опубликовала раскрытие CVE-2024-7344 — обхода Secure Boot, затрагивающего SysReturn и несколько других продуктов для восстановления, построенных на той же кодовой базе.
Уязвимость была элегантной в глубоко разочаровывающем смысле. Подписанное Microsoft приложение UEFI — доверенное прошивкой, способное запускаться даже при включённом Secure Boot — реализовывало свой собственный кастомный PE-загрузчик полностью с нуля. Вместо использования стандартных функций UEFI LoadImage и StartImage, которые обеспечивают проверку подписи Secure Boot, он разбирал и исполнял EFI-бинарники вручную из файла под названием cloak.dat. Зашифрованного XOR с однобайтовым ключом. Без проверки подписи. Всё, что было внутри этого файла, исполнялось с полным доверием на уровне прошивки.
Microsoft отозвала уязвимые бинарные файлы в обновлении Patch Tuesday за январь 2025 года. Индустрия безопасности переключилась на следующую тему. Но я продолжал думать об этом.
Не потому, что сама уязвимость осталась нерешённой — ESET задокументировала её тщательно, и отзыв был однозначным. Меня продолжал тянуть другой вопрос. Вопрос того рода, на который можно ответить только со временем:
Они действительно это исправили? Или просто обошли давление?
Есть разница. Настоящее исправление устраняет первопричину — в данном случае использование кастомного PE-загрузчика, обходящего Secure Boot. Обходной путь заставляет непосредственную проблему исчезнуть, оставляя базовую архитектуру нетронутой.
Я хотел знать, что именно сделала Howyar.
Я связался с Howyar Technologies напрямую и запросил ознакомительную копию SysReturn для профессиональной оценки закупки — что, учитывая профессиональный контекст, породивший это исследование, было совершенно правдиво.
Вендор был отзывчив и полезен. Они предоставили полную пробную лицензию, руководства, обучающие видео и полный ознакомительный пакет. Они также ответили на подробные вопросы о совместимости с Secure Boot, что, как оказалось, напрямую связано с тем, что я обнаружил позже.
Вся эта переписка включена в этот репозиторий без правок.
Я не собираюсь раскрывать здесь технические детали — для этого и существует каталог Vulnerability Research, и я искренне рекомендую прочитать его полностью. Но вот что я скажу.
UEFI — это отдельный мир. Разработчиков, работающих в нём, немного. Процессы проверки безопасности, существующие для прикладного ПО или веб-сервисов, обычно не доходят до компонентов прошивки. Плохие практики, однажды укоренившись, имеют тенденцию сохраняться — не из злого умысла, а потому что экосистема мала, внимание редко, а последствия ошибок часто невидимы для всех, кроме горстки исследователей, обращающих внимание.
То, что я обнаружил в SysReturn v11.2.031 — выпущенной в апреле 2026 года, более чем через пятнадцать месяцев после отзыва Microsoft — является ярким примером именно такой динамики.
Первопричина не была устранена. Уязвимый бинарный файл не был заменён. Что изменилось, так это операционная часть: другой путь загрузки для систем с включённым Secure Boot, оставивший почти всё остальное нетронутым.
Кастомный PE-загрузчик — компонент RxPE, названный в собственных отладочных строках бинарного файла — присутствует в релизе апреля 2026 года, функционируя идентично тому, как он функционировал в версии, которую ESET анализировала в 2024 году.
Хэш Authenticode бинарного файла, который Howyar выпустила в апреле 2026 года, совпадает, байт в байт, с хэшем, который Microsoft отозвала в январе 2025 года.
Я думаю, это важно. Я думаю, люди должны об этом знать. И я думаю, что техническая документация в этом репозитории достаточно подробна, чтобы любой, кто захочет проверить эти находки самостоятельно, мог это сделать.
| Каталог | Описание |
|---|---|
📚 00 Manual | Руководства вендора, брошюры и официальная документация продукта, предоставленные Howyar |
📦 01 Binaries | Ключевые бинарные файлы, извлечённые из ознакомительного пакета для анализа |
📬 02 Disclosure | Полная переписка по электронной почте с Howyar Technologies в ходе процесса оценки |
🔬 03 Vulnerability Research | Обратная разработка, анализ бинарных файлов, проверка Authenticode, анализ формата ALRM, скрипты и технические находки |
Техническая история — полная обратная разработка BOOTia32.efi, формат полезной нагрузки ALRM, XOR-расшифровка, кастомный PE-загрузчик RxPE, совпадение хэша Authenticode с отозванным бинарным файлом и анализ того, что Howyar на самом деле изменила, а что оставила нетронутым — всё это здесь:
Если вы хотите получить контекст о самой CVE перед погружением в анализ после «патча», advisory от ESET — хороший источник. Я также поддерживаю репозиторий, документирующий CVE-2024-7344 и связанные уязвимости UEFI более подробно.
Начинайте читать. Покров всё ещё там.
