Windows Sandbox представляет собой инновационную функцию, добавленную Microsoft в Windows с целью создания легковесной изолированной среды для безопасного запуска приложений. Эта технология позволяет запускать программное обеспечение в полностью «песочном» окружении, которое отделено от основной системы, предотвращая тем самым влияние вредоносного или нестабильного кода на хост-машину. Быстрый старт и удобство использования сделали Windows Sandbox привлекательным инструментом не только для конечных пользователей, но и для исследователей в области безопасности и разработчиков драйверов. Однако возможности песочницы значительно расширяются, если взглянуть глубже на ее внутренние механизмы и способы изменения стандартного процесса загрузки. Одним из таких перспективных направлений является внедрение буткита — особой формы вредоносного или исследовательского кода, способного перехватывать этапы загрузки операционной системы и изменять поведение ядра до его запуска.
В контексте Windows Sandbox использование буткита открывает новые горизонты для экспериментов с ядром, обхода системных ограничений таких, как PatchGuard, и автоматизации загрузки собственных драйверов без традиционного присоединения отладчика. Для начала важно понять, что Sandbox устроен на основе виртуализации с применением формата VHDx и хитростей файловой системы NTFS. Большая часть системных файлов фактически представлена ссылками (reparse points), указывающими на каталоги из основной ОС. Это позволяет развернуть изолированную среду практически без дополнительных затрат дискового пространства и существенно ускоряет старт виртуальной машины. Центральным элементом является файл BaseLayer.
vhdx, который содержит корневую структуру файловой системы Windows Sandbox. Примечательно, что на хосте доступна папка BaseLayer, смонтированная из этого VHDx, расположенная по пути C:\ProgramData\Microsoft\Windows\Containers\BaseImages\<GUID>\BaseLayer. Это предоставляет возможность напрямую читать и изменять содержимое файловой системы песочницы при работе с правами TrustedInstaller, особенно при включенном режиме разработки. Кроме того, при активации режима разработки появляется DebugLayer — дополнительный слой, позволяющий подменять файлы конфигурации, включая BCD и реестровые хранилища, без изменения основного BaseLayer. Правда, активация режима разработки отключает снепшоты и значительно замедляет запуск Sandbox, требуя удаления папки Snapshots и перезапуска службы CmService для применения изменений после модификации.
Для достижения исполнения пользовательского кода на этапе загрузки операционной системы в Windows Sandbox применяется UEFI. Понимание работы этой системы особенно важно, поскольку именно UEFI отвечает за загрузку файловых образов с EFI-раздела, инициируя загрузчик Windows. Обычный порядок загрузки предусматривает запуск файла \EFI\Microsoft\Boot\bootmgfw.efi. Этот файл доступен на хост-машине по упомянутому пути и является ключевой точкой внедрения буткита.
Способ внедрения заключается в том, чтобы встроить собственный код в исполняемый файл bootmgfw.efi, при этом изменив приёмник управления (точку входа) на загружаемый модуль буткита. Важным моментом является необходимость корректной обработки изначального кода, для чего буткит сохраняет оригинальный адрес точки входа и возвращается к ней после выполнения собственных задач. Такой подход позволяет дополнить или изменить процесс загрузки, не нарушая общую функциональность загрузчика. Однако простая модификация bootmgfw.
efi сталкивается с проблемой системных проверок целостности. Процесс сверки целостности реализован в функции BmFwVerifySelfIntegrity, которая напрямую считывает файл с устройства, обходя стандартные системные интерфейсы. Для обхода этого барьера есть два метода: отключение проверок через загрузочную конфигурацию командой bcdedit с параметром nointegritychecks, либо более тонкая и незаметная техника — внедрение хука непосредственно в BmFwVerifySelfIntegrity, подменяющего результат проверки на успешный. Второй вариант предпочтительнее с точки зрения скрытности и стабильности работы внутри Sandbox. Дальнейшее усложнение связано с загрузчиком winload.
efi, который загружает ядро ntoskrnl.exe с целым набором параметров и защитных механизмов, таких как PatchGuard и DSE (Driver Signature Enforcement). При помощи буткита осуществляется перехват функции OpenProtocol, которая ответавает за открытие протоколов UEFI и вызывается в загрузчике. В момент вызова OpenProtocol определяется, когда загружается образ ядра ntoskrnl.exe.
После этого осуществляется детурирование функции BlImgLoadPEImageEx, ответственной за загрузку PE-модулей, что позволяет внедрить патчи непосредственно в код ядра до его инициализации. Благодаря этой технике успешно отключаются такие механизмы безопасности, как Driver Signature Enforcement, путем изменения параметров инициализации функции CiInitialize в SepInitializeCodeIntegrity, а также PatchGuard, благодаря модификации KeInitAmd64SpecificState. Это снимает ограничения на загрузку неподписанных драйверов и нарушений безопасности ядра, что было ранее возможно только с включенным тестовым режимом и подключенным отладчиком. Важным моментом для разработчика становится сам процесс отладки буткита. В случае классических Hyper-V виртуальных машин можно использовать последовательный порт и специальное оборудование, однако Windows Sandbox таких возможностей из-за ограничений виртуальной среды не предоставляет.
В качестве альтернативы используется трюк с журналированием — буткит записывает диагностические данные в определённые файлы внутри виртуальной файловой системы, доступ к которым можно отследить с хоста с помощью Process Monitor. Этот нестандартный подход позволяет получать подробную информацию о ходе загрузки и работе буткита без необходимости прямого подключения к среде внутри песочницы. Все описанные методы делают использование буткита в Windows Sandbox мощным инструментом для специалистов, работающих с ядром Windows, драйверами и низкоуровневым исследованием безопасности. Это значительно упрощает задачи разработки, поскольку отпадает необходимость в постоянном подключении полноценного отладчика и длительном ручном процессе копирования и запуска драйвера в виртуальной среде. Для разработчиков, начинающих работать с UEFI, рекомендуются проекты и структуры, предоставляющие удобные средства для написания и компиляции загрузочных модулей.
Хотя SandboxBootkit использует минимальные заголовки из EDK2, сторонние проекты, такие как VisualUefi, могут значительно облегчить старт, предоставляя готовый инструментарий и шаблоны для разработки EFI приложений и буткитов. В итоге буткит для Windows Sandbox открывает новые перспективы по исследованию и модификации ядра Windows, предлагая надежные способы обхода штатных защитных механизмов и создания удобной среды для тестирования драйверов и низкоуровневых компонентов. Это особенно актуально в условиях возрастающей сложности системной безопасности и популярности виртуализированных песочниц в профессиональной практике. Знания, описанные в контексте буткита для Sandbox, позволяют углубить понимание работы UEFI, процесса загрузки Windows и особенностей взаимодействия виртуальной среды с хостовой ОС, что ценно как для исследователей, так и для разработчиков.
