Bootmgr (Boot manager, Windows Boot Manager) — это очередной этап развития загрузчиков (менеджеров загрузки) для операционных систем MS Windows. Bootmgr Windows 7 представляет собой дальнейшее эволюционирование хорошо известного нам по предыдущим версиям Windows загрузчика NTLDR , который был переписан с учетом потребности поддержки интерфейса EFI (Extensible Firmware Interface, Расширенный интерфейс прошивки), осуществляющего взаимодействие между кодом операционной системой и микрокодом, управляющим оборудованием. Тем не менее, загрузчик сохранил совместимость и со старой, традиционной схемой загрузки ОС, использующей последовательность BIOS -> MBR -> PBR (VBR) -> BOOTMGR -> winload.exe -> ntoskrnl.exe -> SMSS -> Winlogon , часть каковой мы и будем рассматривать в данной статье. Начиная с Windows Vista загрузчик операционной системы получил название bootmgr ( bootmgfw.efi / bootmgr.efi для механизма загрузки EFI) и представляет собой гибридный исполняемый файл, располагающийся на скрытом системном разделе, и предназначающийся для подготовки среды загрузки ядра, обеспечения простого интерфейса взаимодействия с пользователем на начальном этапе, и загрузки непосредственно кода ядра операционной системы.
Тут самое время задаться вопросом, зачем разработчикам вводить отдельный раздел для классической схемы загрузки (BIOS/MBR)? Ведь раньше то ничего подобного не создавалось, все прекрасно загружалось без всяких там скрытых разделов, все файлы цепочки загрузки находились на основном системном разделе, куда же проще? А ответ, как мне кажется, достаточно прост. Выше мы уже упомянули, что схема загрузки была переделана Microsoft с учетом потребностей новой технологии UEFI, в которой для этих целей активно используется специальный раздел ESP. Так что же, для UEFI использовать один алгоритм загрузки, а для классической BIOS/MBR оставлять традиционный? Подобное решение влечет за собой огромное количество проблем и необходимость обновления двух веток кода, не проще ли привести все "к одному знаменателю", и традиционную и UEFI-загрузки реализовать в рамках единого алгоритма, и для традиционной схемы создав специальный раздел? Собственно что и было сделано.
Поэтому, раздел System Reserved в традиционной схеме загрузки (BIOS/MBR) предназначается для:
- приведения иерархий разметки диска/файловой системы (используемых при традиционной (legacy) загрузке) в соответствие с аналогичной структурой стандарта UEFI: размещение на разделе (в классифицированном дереве директорий) файлов операционной системы, фигурирующих в начальном этапе загрузки ОС ( Bootmgr / BCD );
- дополнительной защиты загрузочных файлов операционной системы от (не)преднамеренных деструктивных действий приложений/пользователя;
- хранения загрузочных файлов BitLocker Drive Encryption в случае, если используется шифрование разделов;
Раздел этот создается автоматически на этапе установки операционной системы и имеет типовой размер порядка 100Mb (хотя может быть уменьшен до 30Mb без потери функционала).
Но вернемся к нашему загрузчику Bootmgr. По внутренней структуре файла, которую мы подробнее рассмотрим далее, bootmgr представляет из себя некий гибрид из блока кода на языке ассемблера, и встроенного образа PE-формата (написанного на языке C) с ресурсами и дополнительными секциями, содержащими наборы рабочих данных.
Где находится bootmgr Windows 7
В ОС Windows 7 bootmgr имеет довольно ощутимый размер для файла загрузки (в тестовой системе = 383786 байт), поскольку, как мы сможем увидеть позже, по большей части написан на языке высокого уровня, в отличии от кода MBR и PBR, которые реализованы на низкоуровневом языке Ассемблера и имеют куда более скромные размеры. Располагается bootmgr в корневом каталоге основного активного скрытого раздела размером в 100 мегабайт. Данный раздел размещается в начале диска, предваряя все остальные. Партиции этой не присваивается логического имени (буквы диска), поэтому в самой операционной системе она невидима для стандартных пользовательских средств. Как вы можете догадаться, таким вот незатейливым способом данная партиция защищена от деструктивных действий пользователя, могущих повлечь за собой повреждение критически важной загрузочной информации.
Для того, чтобы найти файл bootmgr в системе, необходимо сначала научиться взаимодействовать со скрытым разделом. Для этого открываем апплет Управление компьютером , щелкнув правой кнопкой мыши на иконке "Компьютер" и выбрав пункт "Управление", либо можно запустить ( Win + R ) из командной строки diskmgmt.msc . Текущий пользователь должен иметь права администратора. В ответ на это действие откроется окно следующего вида:
Для того, чтобы увидеть содержимое скрытого раздела, нам необходимо назначить ему логический номер (букву). На рисунке (схематично) я обозначил последовательность действий, которые нам необходимо предпринять. После выбора пункта "Изменить букву диска или путь к диску" у нас появится следующее окно выбора:
После нажатия кнопки ОК логическое имя будет присвоено разделу и он станет доступен в проводнике. Содержимое его, которое нам как раз и необходимо, наконец-то можно увидеть. Но это еще не все, дело в том, что некоторые файлы и директории раздела имеют атрибут "скрытый", поэтому нам нужно включить отображение скрытых и системных файлов. Это можно сделать в свойствах папки (Параметры папок и поиска — Вид). А теперь, давайте взглянем на искомый нами файл bootmgr , который можно увидеть прямо в корне партиции:
На рисунке бывает порой сложно, а чаще и вовсе не получается наглядно отобразить всю структуру раздела, поэтому приведу его в виде текстового списка. Итак, содержимое скрытого раздела "Зарезервировано системой" выглядит следующим образом:
Возможно некоторые читатели помнят мою самую первую статью на ресурсе, посвященную загрузке Windows с VHD-образа. Возможно я бы и не вернулся к этой теме, если бы не нашлись люди, попытавшиеся повторить данную технологию на своих домашних машинах. Естественно, с реализацией этого решения возникли проблемы, касающиеся в основном тех ошибок, которые выплевывает bootmgr в тех случаях, когда ему что либо не нравится. Попытки интерпретации ошибок загрузки вроде 0xc03a0003 путем гугления к особо ценным результатам не приводят, а документация Microsoft на этот счет хранит многозначительное молчание. Возникла идея изучить процесс обработки VHD-образов, получив информацию из первых рук, то есть от самого загрузчика.
Если обратится к уже имеющейся в сети информации, то существует замечательный блог "Записки эникейщика о Windows" на страницах которого (раз, два и три) размещены, на мой взгляд, самые ценные сведения, по вопросам устройства bootmgr. Автор подробно рассмотрел процесс загрузки, включая исследования кода MBR и PBR, остановившись на структуре bootmbr, кратко описав происходящие при его работе процессы.
Мы же пойдем дальше — опишем инструментарий, который можно использовать для изучения устройства загрузчика и попытаемся разобраться с некоторыми, интересующими нас алгоритмами. Если такое предложение показалось кому-то интересным, милости прошу под кат
Загрузчик Bootmgr появился в операционных системах семейства Windows начиная с Windows Vista. Причиной его разработки послужило то, что старый добрый ntldr, использовавшийся в линейке NT не мог загружать систему, на компьютерах с материнскими платами оснащенными UEFI, в те времена (2005 год) мало распространенными среди широкого круга рядовых пользователей.
По умолчанию, при штатной установке, этот загрузчик помещается в отдельный раздел, расположенный в начале HDD, с размером, достаточным для размещения самого bootmgr а так же файлов его конфигурации. Данный раздел не монтируется в обычном режиме работы системы и буква диска ему не присваивается. В системах с MBR создания этого раздела можно избежать, устанавливая Windows на предварительно размеченный и отформатированный HDD. В этом случае загрузчик помещается в тот же раздел, что и файлы ОС. Системы с EFI + GPT изначально требуют наличия такого раздела, имеющего тип 0xef и отформатированного в FAT.
Таким образом, первая наша задача — добыть bootmgr. Желательно взять его из системы, которая будет выступать в роли подопытной. Для этого установим ОС Windows на виртуальную машину. Это может быть и VirtualBox, и VMware, и QEMU — всё зависит от того, каким инструментарием виртуализации вы располагаете. Я преимущественно работаю в ОС Linux, буду в основном ориентироваться на инструменты применяемые там, хотя уделю внимание и Windows.
Итак, предположим у нас есть виртуальная машина (ВМ) с установленной на ней Windows 7 (x86). Разметка диска выполнена на основе MBR, система установлена в один раздел. Допустим это QEMU, диск на котором установлена подопытная имеет формат raw. то есть обыкновенный двоичный образ. Монтируем этот образ
На смонтированном разделе мы увидим следующее содержимое
Для нас представляет интерес файл bootmgr. Однако, прежде нам нужен не совсем он, а 32-разрядный образ загрузчика bootmgr.exe, который находится в bootmgr в упакованном виде. Для его распаковки необходимо использовать утилиту bmzip, которая написана в общем-то для Windows (с наскока собрать её под Linux не вышло), поэтому распаковку выполним на виртуальной машине. Бинарную сборку этой утилиты, которая бы работала нормально оказалось довольно трудно найти, несмотря что тут дана ссылка на неё. В итоге, пакет был найден на каком-то из сайтов, посвященных кастомизации bootmgr. Для работы bmzip оказалась необходима библиотека MSCompression.dll. Готовый к работе пакет теперь можно скачать тут.
Создадим на диске ВМ папку utils и скопируем туда bmzip.exe вместе с MSCompression.dll. Отмонтируем образ и запустим ВМ. Запустим командную строку от имени администратора. Чтобы случайно не попортить загрузчик сделаем его копию
Файл загрузчика является скрытым и системным, поэтому снимем с него эти атрибуты
В итоге получаем распакованный образ bootmgr.exe
Выключаем ВМ и снова монтируем её диск в линуксе. Создадим какую-нибудь папку, где будем потрошить загрузчик дизассемблером и скопируем туда распакованный образ
Теперь скормим полученный "экзешник" дизассемблеру. Например IDA Pro. Запустим "иду" и откроем в ней добытый файл.
IDA верно идентифицирует файл как 32-разрядный исполняемый файл формата PE. Жмем ОК. Теперь, если в IDA Pro установлен плагин для работы с pdb-файлами, по ходу дизасеммблирования нам предложат загрузить отладочные символы, и не откуда нибудь, а сайта Microsoft.
Соглашаемся и получаем такую картину
Ага, слева мы видим прототипы функций, содержащихся в исследуемом файле, благодаря тому что согласились загрузить отладочные символы. Это очень сильно облегчит нам последующую работу. А пока определим точку входа в код загрузчика, и нетрудно догадаться что это будет функция BmMain(). Однако, не принимая это на веру жмем Ctrl + E
убеждаясь что наша догадка верна — BmMain() является точкой входа, расположенной по адресу 0x401000. Жмем ОК и перемещаемся на начало кода
Видим мы заголовок функции BmMain() с внушительным списком локальных переменных, и чуть ниже и сам код функции
Разобраться в мешанине ассемблерного кода довольно трудно, да и не зачем этого делать. Прежде всего определимся с тем, какие функции загрузчика мы хотим изучить. Я что-то там говорил о VHD? Ну так поищем среди кода что-нибудь, касающееся виртуальных дисков. Щелкаем правой кнопкой по списку функций слева и в вывалившемся контекстном меню выбираем "Quick filter" (или перейдя в окно с прототипами жмем Ctrl + F). В строке поиска набираем "vhd" и…
да, таковые функции имеются в количестве 33 штук. Среди них VhdOpen() очевидно будет отвечать за открытие виртуального диска, а вот например VhdiVerifyVhdFooter() как пить дать отвечает за проверку футера VHD-диска на корректность. То есть мы примерно представляем себе, куда будем ставить точки останова в отладчике. Кстати, поговорить об отладке самое время
Запускаем виртуальную машину с ключами -s -S — это включает режим отладки
ВМ запускается и сразу же становится на паузу, ожидая подключения отладчика
Важно! Ни в коем разе не используйте ключ -enable-kvm применяющий аппаратную виртуализацию. При её использовании отладка в QEMU не работает.
Теперь на панели инструментов в IDA выбираем отладчик "Remote GDB debugger"
Ответив "Да" на несколько заданных нам вопросов получим окошко
где вобьем параметры соединения с ВМ: localhost на порту 1234. Жмем ОК. Нам сообщат, что некоторый процесс уже запущен и ожидает подключения отладчика — не хотим ли мы присоединится к нему? Конечно же ходим!
Поэтому отвечаем "Да" и.
мы встаем на паузу где-то в начала bios виртуальной машины. Великолепно, но теперь мы должны добраться до того места, где начинает выполнятся bootmgr. Ставим точку останова на функции BmMain(). Нажимаем на панели инструментов список точек останова, жмем Insert на клавиатуре и указываем на каком адресе мы хотим прервать выполнение кода и перейти в отладку
Вбиваем адрес 0x401000. Если же мы хотим поставить бряк на нужную нам функцию, то идем в главное меню и открываем в сеансе отладки список функций: View -> Open subviews -> Functions. В появившемся списке правой кнопкой мыши вызываем контекстное меню и выбираем Add breakpoint. Теперь жмем F9 и после недолгого ожидания попадаем в самое начало кода загрузчика
Теперь мы можем проходить код по шагам, смотреть значения регистров и стека, отслеживать стек вызовов и так далее. В какой-то степени отладчик, встроенный в IDA удобен и интуитивно понятен.
Возможно меня спросят — а можно ли использовать GDB? Можно, запускаем ВМ в режиме отладки, запускаем gdb в консоли
Подключаемся к удаленной сессии ВМ
Включаем отображение дизассемблированных инструкций
Если вас не устраивает синтаксис AT&T переключаемся на интел
Ставим точку останова на BmMain() и запускаем исполнение
Пожалуйста, мы видим почти тоже самое, что видели в IDA, располагая при этом всей мощью GDB. Почти, потому что тут мы не сумеем использовать отладочные символы от Microsoft, ибо GDB их не понимает. Но возможности GDB не в пример более широки, чем возможности IDA именно в плане процесса отладки и его автоматизации.
Однако, существует ещё одна возможность отладки, мимо которой пройти нельзя
Те, кто занимается разработкой драйверов для ОС Windows безусловно знакомы с этим замечательным отладчиком. Замечателен он тем, что имеет возможности сравнимые с возможностями линуксового GDB. Единственным его недостатком является жуткий способ настройки его интерфейса. Но мы опустим эти моменты, а обратимся к возможностям данного отладчика для решаемой нами задачи.
Итак, пускай на у нас имеется ВМ на основе VirtualBox. Создадим для этой ВМ COM-порт со следующими параметрами
Это виртуальный COM-порт, пробрасываемый в именованый канал. Для отладки через последовательный порт виртуальную машину следует настроить соответствующим образом. Загружаем её и запускаем консоль с административными правами. С ней вводим команды настройки загрузчика для отладки
Эта команда включит возможность отладки загрузчика. Далее настроим порт для отладки
Указываем, что мы используем COM1 со скоростью 115200 бод. Отлично, выключаем ВМ и запускаем отладчик.
Отладчик WinDbg можно скачать официально с сайта Microsoft вместе с комплектом для разработки драйверов. Однако у этой сборки отладчика есть проблема — глюк с отображением значений регистров. Поэтому я использую сборку, которая качается с того же сайта редмодовцев, на которую ведет ссылка из твитера некоего Доминика Вонга. В этой сборке данный баг отсутствует. Запускаем WinDbg следующей командой
Откроем настройки интерфейса (File -> Open Workspace in File) в который среди прочих параметров сохранен путь http://msdl.microsoft.com/download/symbols для загрузки отладочных символов с серверов Microsoft. У меня этот путь заранее вбит в настройки (File -> Symbol File Path) и сохранен в теме для WinDbg. Такая настройка позволит нам автоматически получить отладочную информацию для загрузчика.
Теперь запустим ВМ. Практически сразу она встанет на паузу, а в окне отладчика мы увидим следующую картину
Ага, отладчик подключился к ВМ и встал на точке, любезно предоставленной нам майкрософтом. Ну что же, теперь нам доступны все возможности отладки с использованием windbg.
Однако мы останавливаемся не в самом начале кода загрузчика, а чуть дальше. Как показывает пошаговая отладка мы находимся как раз за функцией BlInitializeLibrary() которая обеспечивает начальную инициализацию оборудования
и, при отладке при помощи IDA мы сюда просто не попадаем. Таким образом, при отладке с WinDbg от нас ускользает часть действий bootmgr сразу после его запуска. В этом заключается недостаток использования стандартных средств отладки, предоставленных Microsoft. Однако, недоступный код мы всегда сможем исследовать отдельно с помощью IDA.
Теперь, в качестве примера, посмотрим на то, как bootmgr работает с образами VHD фиксированного размера.
Всё ниже следующее рассматривается на отладчике WinDbg, подключенном к ВМ на VirtualBox, но в равной степени справедливо и для других методов отладки, с учетом их особенностей. ВМ, используемая в данном примере содержит две системы: одна установлена на HDD, другая на VHD образ. Поставим точку останова на функции VhdOpen()
и нажмем F5. Отладчик встанет на указанной функции
Причем, внимание — мы ещё вообще не заходили в меню загрузки и не выбирали загрузку из VHD. А это означает, что проверка VHD происходит задолго до появления меню. Такое же поведение мы и наблюдаем, например если подсунем bootmgr пустой VHD. Меню загрузки нам вообще не покажут, а покажут ошибку с кодом 0xc000000F.
Проходим чуть дальше, нажимая F10 или вводя в комадной строке p и дойдем до вызова VhdiAllocateVhdData() — очевидно это создание в памяти некоторых структур для работы с образом
Чуть ниже расположен вызов VhdiVerifyAndInitializeVhd() — очевидно проверка корректности образа. Это показалось мне интересным и я пошел внутрь (F11)
Ниже, после некоторых подготовительных операций загрузчик читает последние 512 байт образа, в которых содержится так называемый "футер" образа, вызывая функцию VhdiReadVhdInformation(). Не надо ходить к гадалке, чтобы понять — функция возвратит указатель на структуру, содержащую данные футера. Как мне удалось выяснить, этот указатель, после вызова VhdiReadVhdInformation() оказывается в регистре ecx. Его значение равно 0x110098. Посмотрим на память по тому адресу
Команда читает память по указанному адресу, выводя её в окно отладчика в виде последовательности байт
Ага, мы видим знакомое слово — conectix. Это поле предваряет футер VHD образа, носит название cookie и хранит память о том, что Microsoft купила технологию VHD у фирмы Conectix, которая разработала данный формат виртуальных дисков для старых компьютеров Macintosh, Это несомненно футер VHD, мы можем видеть тут сигнатуру операционной системы в которой он был создан (Wi2k) а так же последовательность win указывает на то, что VHD создан средствами Windows. Да, все так и было. Пройдя чуть дальше мы натыкаемся на вызов VhdiVerifyVhdFooter() проверяющий формат футера. В качестве параметра он получает указатель на вышеописанную структуру, почему-то через регистр esi (. )
Этот участок кода интересовал меня больше всего, поэтому где-то с помощью IDA Pro, где-то руками, я преобразовал его в псевдокод на C
Футер VHD можно представить в виде следующей структуры (в комментариях указаны смещения от её начала).
Пользуясь этими данными можно сделать вывод о том, какие поля футера проверяет bootmgr и какие ошибки он выбрасывает. При корректном VHD образе данная функция возвращает ноль, в иных случаях расклад таков
Полученная мной информация решила спор возникший с коллегой по форуму, на котором обсуждалась методика загрузки Windows с VHD. Я его проиграл, считая что образы, созданные VirtualBox не будут грузится с помощью bootmgr. VirtualBox, создавая такие образы пишет все поля в соответствии со спецификацией Microsoft, кроме поля creator_application, куда записано win в оригинальном образе и vbox в случае с виртуалбоксом. Но это поле не проверяется bootmgr-ом, так что диски работают, а у меня они не работали по совсем другой причине, которая является предметом совсем другой истории.
Возможно, статья несколько сумбурна. Но, она говорит о том, что горшки обжигают не боги, а отладка низкоуровневого кода Windows лишь дело техники. Интересующую вас информацию всегда можно получить, приложив к этому голову и руки. В этом тексте я попытался обобщить разрозненную информацию, собранную мной в сети по вопросам отладки bootmgr. Надеюсь что у меня это получилось, благодарю всех читателей за внимание и.
    Существовавший еще с времен Windows NT, загрузчик операционной системы NTLDR , начиная с Windows Vista, заменен новым диспетчером загрузки BOOTMGR . Вызвано это тем, что старый добрый NTLDR уже не годился для выполнения загрузки системы на компьютерах, использующих спецификацию Extensible Firmware Interface (EFI). EFI — новый расширенный интерфейс для доступа к компьютерному оборудованию, призванный заменить базовую систему ввода-вывода BIOS. Модель EFI является новым поколением реализации интерфейса между оборудованием компьютера и операционными системами, и в недалеком будущем полностью заменит просуществовавшую несколько десятилетий модель BIOS.
Новый диспетчер загрузки bootmgr ориентирован на использование специального хранилища конфигурации загрузки BCD ( B oot C onfiguration D ata), а также специально разработанных приложений и данных спецификации EFI. Для совместимости с версиями Windows, предшествующим Windows Vista, новый диспетчер BOOTMGR обеспечивает поддержку загрузки операционных систем предыдущего поколения компьютеров на базе BIOS.
Данная статья не касается особенностей использования BOOTMGR в системах с EFI , и в основном, рассматривает принципы использования диспетчера загрузки на стандартном компьютерном оборудовании без использования нового интерфейса.
Механизм загрузки операционной системы Windows 7.
    Процесс загрузки любой операционной системы начинается всегда одинаково — после проверки оборудования, управление получает подпрограмма BIOS, (Basic Input/Output System), считывающая с устройства загрузки первый сектор, являющийся главной загрузочной записью MBR ( M aster B oot R ecord ). Запись MBR располагается в первом секторе загрузочного диска и занимает 512 байт (стандартная длина сектора). Это не обязательное условие — MBR может занимать более одного сектора, что зависит от конкретной разновидности загрузчика. Хотя запись MBR не является строго зависимой от платформы загружаемой ОС, она отличается, например, для файловых систем DOS, Windows и Linux.
Структура любой записи MBR включает в себя 2 основных элемента — программный код первичного загрузчика и таблицу разделов. Обязательным признаком наличия записи MBR является специальный код (сигнатура) в двух последних байтах — 55AA . Наличие сигнатуры проверяется подпрограммой BIOS в первую очередь, и при ее отсутствии, диск считается не загрузочным.
Для ознакомления с загрузчиками и загрузочными записями, желательно иметь программу для просмотра данных секторов диска, лучше — с возможностью интерпретации содержимого в виде стандартных элементов файловой системы (MBR, PBR, таблицы разделов и т.п.), как например, утилита для поиска, редактирования и восстановления данных DMDE (DM Disk Editor and Data Recovery Software). Программа DMDE распространяется как в платной, так и в бесплатной редакции. DMDE имеет набор бесплатных функций, таких как дисковый редактор, простой менеджер разделов, создание образов и клонирование дисков, реконструкция массивов RAID, восстановление файлов из текущей панели. Платные редакции поддерживают восстановление файлов и директорий без ограничений, в DMDE Professional Edition также предоставляются дополнительные возможности восстановления данных для клиентов. Скачать программу можно на сайте разработчика.
Впрочем, можно обойтись и без относительно сложной специализированной программы DMDE, для освоения которой может потребоваться некоторое время, а воспользоваться более простыми инструментами. Большинство программ для тестирования накопителей и восстановления данных позволяют просматривать и редактировать данные выбранных секторов. Так, например, выглядит запись MBR, просматриваемая с помощью бесплатной версии программы тестирования накопителей Victoria for Widows
    Перед сигнатурой (по смещению 0x1BE относительно начала сектора) располагается таблица разделов (Partition Table), состоящая из 4-х элементов по 16 байт каждый, что определяет максимальное число (не более4-х) первичных разделов на одном жестком диске. Соответственно, размер таблицы разделов — 64 байта.
Каждый элемент таблицы описывает тип раздела , например — 00h — раздел неопределенного типа, попросту — свободное место, 01h — 12 битный FAT, 05h — дополнительный раздел, 07h — раздел NTFS и т.д.). Кроме типа раздела, присутствует признак активности (возможности загрузки) — код 80h, а также адрес начала раздела, адрес конца , смещение относительно MBR и размер — количество блоков выделенное данному разделу.
В общем виде, структура главной загрузочной записи MBR, может быть представлена следующим образом:
— программный код и данные начального загрузчика. (446 байт.)
— таблица разделов диска (4 поля по 16 байт — 64 байта)
— сигнатура 55AA (2 байта)
| Программа и данные начального загрузчика. | Таблица разделов диска | 55AA |
После считывания в оперативную память компьютера, программный код начального загрузчика получает управление и выполняет поиск активного раздела (Active), — раздела, с которого может выполняться загрузка конкретной операционной системы. Такой раздел имеет свою загрузочную запись, называемую загрузочной записью раздела PBR ( P artition B oot R ecord ) . Содержимое загрузочной записи активного раздела зависит от загружаемой операционной системы и, обычно имеет размер более чем длина одного сектора.
В случае с загрузкой Windows 7 (а также Windows Vista / Server 2008 и последующих ОС семейства Windows) программный код загрузчика раздела выполняет подготовку и выполнение следующего этапа загрузки системы — считывание в оперативную память и передачу управления специальной программе — диспетчеру загрузки BOOTMGR .
Диспетчер загрузки bootmgr представляет собой файл небольшого размера, расположенный в корневом каталоге активного раздела. Основное его предназначение — обеспечение дальнейшей процедуры загрузки в соответствии с существующей конфигурацией , хранящейся в специальном хранилище — хранилище данных конфигурации ( BCD — B oot C onfiguratin D ata ), представляющем собой файл с именем BCD , находящийся в каталоге BOOT активного раздела.
Как видим, следующий этап загрузки операционной системы обеспечивается уже диспетчером bootmgr в соответствии с существующей конфигурацией BCD. В общем случае, диспетчер загрузки может выполнить не только загрузку ядра установленной на данном компьютере Windows, но и другие, имеющиеся в конфигурации варианты — загрузку Windows NT/2000/XP, операционных систем семейства Linux, загрузку ОС из образов ( файлов wim ) , виртуальных дисков ( файлов VHD ) и т.п.
При стандартной установке современных операционных систем семейства Windows на новый жесткий диск, в качестве активного раздела используется, автоматически создаваемый при инсталляции в первой части диска, раздел небольшого размера ( около 100Мб для Windows 7, 350Мб для Windows 8 и 500Мб для Windows 10 ). Данному разделу не присваивается буква, и в проводнике он не отображается. Это сделано с целью защиты загрузчика от небезопасных для него действий пользователя — удаления файлов конфигурации или самого диспетчера, сжатия файловой системы и т.п. Кроме того, при такой организации структуры диска, легко реализуется процедура восстановления активного раздела из ранее созданного образа без потери установленной системы и пользовательских данных.
При просмотре в Диспетчере логических дисков, активный раздел отображается под названием "Зарезервировано системой" :
Таким образом, для того, чтобы выполнилась загрузка Windows с диспетчером BOOTMGR, активный раздел, как минимум, должен содержать правильную загрузочную запись PBR , файл диспетчера bootmgr и конфигурационные данные в файле BOOTBCD , являющимся системным хранилищем конфигурации загрузки . В случае с загрузкой Windows, диспетчер bootmgr считывает из хранилища конфигурации данные, необходимые для загрузки ядра системы, и передает управление приложению, выполняющему следующий этап ( winload.exe ) .
Кроме хранилища конфигурации загрузки, в данном разделе могут быть файлы и каталоги, необходимые для выполнения загрузки в соответствии с имеющимися дополнительными конфигурациями, например, загрузчик предыдущих версий Windows NTLDR и необходимые для него файлы, а также средства поддержки национальных алфавитов ( файлы локализации).
Хранилище данных конфигурации загрузки (BCD Store).
Обычно файл bootmgr и каталог Boot имеет атрибуты "скрытый" и "системный". Для получения доступа к активному разделу стандартными средствами, можно присвоить ему букву и включить отображение скрытых файлов, однако, нужно понимать, что любое неквалифицированное вмешательство в конфигурацию загрузки может привести к невозможности загрузки системы. При чем, неработоспособную конфигурацию загрузки можно получить даже без выполнения вышеперечисленных действий. Например, при неверном использовании стандартного редактора хранилища конфигурации — утилиты командной строки BCDEDIT . Поэтому, прежде чем вносить какие-либо изменения в конфигурацию загрузки, необходимо позаботиться о том, чтобы иметь возможность восстановления работоспособности системы в том случае, когда ее загрузка станет невозможной. Вопросам восстановления загрузки посвящен отдельный раздел статьи и, настоятельно рекомендую, прежде чем приступать к практическим действиям, внимательно ознакомиться с ним.
Программный код диспетчера загрузки , получив управление, выполняет поиск и обработку данных конфигурации загрузки (файл BCD в папке BOOT активного раздела), в соответствии с которыми выполняется дальнейшие этапы загрузки ( отображение меню, выбор загружаемой ОС или средств диагностики, загрузка ядра и т.п. ). По своей структуре, файл \bootBCD является кустом реестра и отображается в редакторе реестра Windows как раздел HKLMBCD0000000x
Таким образом, диспетчер загрузки bootmgr работает с данными хранилища конфигурации загрузки BCD как с обычным разделом реестра Windows. Поскольку, данный раздел реестра предназначен для использования загрузчиком BOOTMGR, при ручном просмотре c использованием редактором реестра, он имеет разрешение только на чтение, которое можно изменить с помощью контекстного меню, вызываемого правой кнопкой мышки. Естественно, на данный раздел реестра, как и на любой другой, распространяются все допустимые действия, выполняемые в редакторе — просмотр, изменение, удаление, импорт и экспорт.
Раздел конфигурации BCD содержит подраздел Description с параметрами описания и подраздел Objects с объектами конфигурации загрузки. Данные конфигурации загрузки можно условно разделить на 3 основных составляющих:
— хранилище BCD (Store)
— записи в хранилище (Entries)
— параметры записей (Entry Options)
Иерархически, хранилище конфигурации загрузки представляет собой совокупность объектов (Objects ), состоящих из отдельных элементов (Elements):
Каждый из объектов представляет собой упорядоченную структуру элементов, обрабатываемую диспетчером загрузки. Существует 3 типа объектов:
— приложения ( application objects)
— наследуемые объекты ( inheritable objects)
— устройства (device objects)
Если вернуться к отображаемой редактором реестра структуре хранилища конфигурации, то заметно, что каждый подраздел раздела Objects имеет имя, представляющее собой глобальный уникальный идентификатор — GUID . Идентификатор GUID формируется программным путем и однозначно является уникальным для той системы, где он создается. Алгоритм формирования GUID построен таким образом, что каждый новый генерируемый идентификатор никогда не совпадает с другим, существующим в данной системе. Обозначается GUID в виде групп из шестнадцатеричных цифр, разделяемых дефисами, и заключенными в фигурные скобки:
Некоторые объекты стандартных приложений конфигурации загрузки имеют предопределенные идентификаторы , связывающие некоторые из идентификаторов GUID с внутренними идентификаторами (псевдонимами) редактора bcdedit
