Windows boot pcat bootmgr

Windows Boot Manager — загрузчик операционных систем Windows Vista/7/8/10. Естественно поддерживается EFI режим загрузки. И конечно же его можно использовать не только для загрузки Windows.

Картинка с сайта: www.bootdev.ru

Нет поддержки загрузки образов дисков, таких как ISO, IMG и т.д., но данный вопрос решается с помощью загрузчика Grub4Dos, который используется в качестве посредника.

Создать и редактировать файл конфигурации BCD, можно либо через командную строку (команда bcdedit), либо более удобно, с помощью программы EasyBCD или BOOTICE.

Recently, I have spent some time for reverse engineering bootkit. It has been a fun exercise, but I had to struggle for setting up the environment before that as I could not find a page explains these steps. So as a note for me, I wrote down how to build a bootkit debugging environment as well as how to configure Windows in order to attach a debugger at some early uncommon boot stages.

Boot Processes

Here are boot processes of BIOS based Windows XP and Windows 7 systems. I will discuss each stage except for BIOS (POST) and Ntoskrnl.exe.

Boot Process (XP)

BIOS (POST) -> MBR -> VBR -> Ntldr (Real-Mode) -> Ntldr (Protected-Mode) -> Ntoskrnl.exe

Boot Process (Windows 7)

BIOS (POST) -> MBR -> VBR -> Bootmgr (Real-Mode) -> Bootmgr (Protected-Mode) -> Winload.exe -> Ntoskrnl.exe

Debugging

MBR, VBR, Ntldr (Real-Mode) and Bootmgr (Real-Mode) 

We need Bochs as no break points are provided on the course of these steps.

Installing OS on Bochs is not hard unless you try to find the perfect configurations such as smooth mouse movement, correct clock speed and working NICs. Since we are not going to use this OS anything but boot debugging, I do not encourage you to spend time for it.

What you need to do to install OS are roughly as follows:

1. Create a flat hard disk image with 10GB size using bximage.exe.
2. Configure bochs.bxrc with boches.exe to use the created hard disk image and an OS installer ISO image.
3. Start to install OS.

Installation may take a few hours. I also strongly recommend you to use the latest version of Bochs to avoid unnecessary troubles. Even if your old IDA Pro does not work with the latest one like my case, you can switch to old one after you completed the installation process for debugging. Here are my bochsrc files for version 2.6.6 and 2.4.6 with nearly identical configurations. You may use them as samples when you are not familiar with Bochs.

Once you have finished installing the OS (no need for applying Windows updates), you can debug MBR and VBR with either running it with bochsdbg.exe or corroborating with IDA Pro. If you hope to take the former way, you can add the following settings to enable a GUI debugger.

—-
display_library: win32, options=»gui_debug»
—-

Although the GUI debugger works perfectly fine, it is far better to use IDA Pro if you have. Here is an article about this process by HeyRays, but in a nutshell, you can follow these steps:

1. Download a file mentioned in the article.
2. Copy mbr.py to the same directory as a location of the hard disk image file.
3. Download and copy this batch file to the same directory (you will need to change paths in it).
4. Run the batch file. 

You will see IDA Pro breaks at the very beginning of MBR (0x7c00) unless there is an error in configurations. Now, you can trace the code and should be able to debug VBR as well.

Картинка с сайта: standa-note.blogspot.com

Ntldr (Real-Mode) and Bootmgr (Real-Mode)

Although it is totally possible to trace the code until it reaches to Ntldr or Bootmgr, it can be time consuming. One solution is to modify their entry point code with a breakpoint. Luckily, offset 0 of these files are actually entry points, so we can change offset 0 to a breakpoint. Here is an original entry point of Ntldr.

Картинка с сайта: standa-note.blogspot.com

Also, as we are using a flat hard disk image file, we can search code pattern of Ntldr or Bootmgr from the image file and change it. In my case, Ntldr was found at offset 0x133D55E00 in the image file.

Картинка с сайта: standa-note.blogspot.com

Like the above image, you will probably need to install a magic_break provided by Bochs rather than regular 0xCC since the runtime environment is different from usual, the protected mode. Bochs treats an instruction ‘xchg bx, bx’ (0x87 0xdb) as a breakpoint when the following statement was added to the bochsrc.

—- 

magic_break: enabled=1 

—-

Once you boot the virtual machine with Bochsdbg.exe, you should see the VM breaks at 0x2:0002.

Картинка с сайта: standa-note.blogspot.com

0x2:0000 is the actual breakpoint which we have set. You can look an IDA to find where to go from here. In my case, the execution need to go to 0x01d8.

Then you can change EIP with a ‘set $eip = 0x01d8’ command and step in with a ‘s’ command to execute a regular code sequence.

Картинка с сайта: standa-note.blogspot.com

Note that my Old IDA Pro (v6.0) did not stop when execution reached at a magic_breakpoint, but this issue may have already been solved on the latest version of IDA.

Ntldr (Protected-Mode)

Steps for debugging Ntldr (Protected-mode) is relatively straightforward:

—- 

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

[debug]
/debug /debugport=COM1: /baudrate=115200 /debugstop

[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=»Microsoft Windows XP Professional» /noexecute=optin /fastdetect
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=»Microsoft Windows XP Professional (Debug)» /noexecute=optin /fastdetect /debug /debugport=COM1: /baudrate=115200

—- 

Once you reboot the debugee XP system, it waits to be connected by a kernel debugger.  In order to load symbols and suppress error messages, you can manually read an osloader.exe image.

—-
kd> .readmem E:\osloader.exe 0x400000 L0x1000
Reading 1000 bytes..
kd> .imgscan /l /r 00400000
MZ at 00400000 — size 80000
  Name: osloader.EXE
  Loaded osloader.EXE module
—-

Now, you are free to see how Ntoskrnl.exe and boot drivers are initialized.

Картинка с сайта: standa-note.blogspot.com

Bootmgr (Protected-Mode)

Bootmgr is called the boot manager and responsible for listing a boot menu and firing up an appropriate program according to a user’s selection in the list.

Unlike debugging Ntldr, you can activate the boot manager debugger with the following commands.

—- 

bcdedit /bootdebug {bootmgr} on 

—-

Картинка с сайта: standa-note.blogspot.com

Note that the executable file is located in C:\Windows\Boot\PCAT\bootmgr and contains a 32bit PE image as with Ntldr.

Winload.exe

Winload.exe is called the boot loader and used for the regular boot procedure. It basically loads Ntoskrnl.exe and some other boot drivers. Enabling the boot loader debugger can be simply done with bcdedit like the case of Bootmgr.

—- 

bcdedit /bootdebug on 
—-

Картинка с сайта: standa-note.blogspot.com

Further Research

Вообщем достаточно лениво переустанавливать всю ОСь.

Очередной потерянный файл при загрузке файл
«BOOTMGR IS MISSING press ctrl+alt+delete»

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

Автоматический режим ничего не нашел, ака всё корректно.

2. Естественно переходим к командной строке

Обратите внимание, на команду bootsect /nt60 all, так как стандартный способ скопировать файл bootmgr с дистрибутива windows 7 потерпела не удачу.
По порядку, ставим дистрибутив windows 7, в биосе выставляем загрузку с привода, загружаемся, начинается процесс установки, только не нажимаем «Установить», а жмем «Восстановление системы»

Далее «командная строка»
Описываю стандартную ситуацию, которая почти всегда помогает, кроме случае аппаратных сбоев (неисправность жесткого диска, кабеля прочее).
После загрузки командной строки, у вас в большинстве случаев активно следующая строка

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

Далее, как войдем в утилиту набираем:

Смотрим и запоминаем, какой раздел системный, а какой привод.
Набираем

Обратно возвращаемся в строку

Скопируем наш файлик bootmgr с дистрибутива windows 7 для этого наберем в строке (в моем случае привод диск G, а системный раздел с операционкой диск D) поэтому набираем:

жмем enter
Набираем

жмем enter в большинстве случаев это помогает, то есть появляется надпись «команда успешно выполнена с копировано 1 файл», но в моем случаев вышла надпись «отказа в доступе скопирована 0 файл».

Поэтому использовал эту команду:

1

bootsect d: /force /mbr

Которая выполнилась без проблем.

Кстати да забыл, до этого в командной строке были успешно выполнены команды, альтернативы в win xp это fixboot и fixmbr, которые в win viste/7 выглядят следующим образом:

и

Виктория под досом не видит этот контроллер, хард просканить не могу, точнее могу, но пока не вытащил из корпуса ноутбука.

Кстати команды из командной строки консоли восстановления windows

и

1

bootrec /rebuildbcd

Показали найдено операционных систем — 0

Закинутый новый bootmgr ничего не дал, при попытку загрузиться операционка говорит, что данный boot файл отличается от того, что нужен.

Два live cd отказались грузиться, сейчас качаю посвежее.

Есть у кого нибудь какие либо мысли.Восстановление системы

Многие технические специалисты в своей работе сталкиваются с ошибками, возникающими на различных стадиях загрузки операционной системы Windows. Случился и в моем практике не так давно достаточно нетипичный сбой этапа загрузки, в котором мне, к моему огромному недовольству, затруднительно было сходу разобраться. Смысл проблемы заключался в том, что вышедшая из строя по достаточно нетривиальной цепочке причин, система Windows 7 (Профессиональная) отказывалась грузиться во всех, без исключения, режимах загрузки. Процесс загрузки просто «вис» на черном экране на этапе, следующем за графическим экраном заставки (splash screen). Код работы с видеоадаптером устанавливал разрешение в родное для монитора, а далее загрузка просто-напросто останавливалась, при этом отчетливо был виден графический курсор мыши, сам манипулятор функционировал. Я так полагаю, что у профессионалов подобное явление обозначается термином черный экран смерти (Black Screen of Death, KSOD), наиболее распространенными причинами которого являются: повреждение различных частей реестра, невозможность запуска критически важных служб и кривая установка разрешений на системные каталоги (все эти вещи зачастую вызваны обновлениями). Большая просьба не путать термин «черный экран смерти» с общеизвестным синим экраном смерти (Blue Screen of Death, BSOD). Как я уже упоминал, загрузка в безопасном режиме останавливалась на том же самом месте, то есть я вообще никак, ни в каком из режимов не мог загрузить ОС!! С грустью вспомнил обо всех хваленых средствах диагностики загрузки вида xbootmgr и прочих трассировщиках, которые оказывались абсолютно бесполезными в подобной ситуации. Потом пришла мысль, что хорошо было бы подключиться каким-нибудь отладчиком удаленно и просто протрассировать код до ошибки, но подобным опытом я пока не обладаю, а проблему надо было решать в сжатые сроки.

В действительности, проблему удалось таки решить «по старинке», воспользовавшись отличным средством Microsoft DaRT, благо удалось докопаться до виновника сбоя.

Однако, сама ситуация навела меня на размышления о том, что на дворе уже далеко ведь не первая версия операционной системы, да и эра технологий, так сказать, в полном разгаре :), а пользователи Windows продолжают наблюдать «неопределенные состояния», в которых операционная система не в силах хотя бы на простом уровне вычислить причину сбоя и сообщить об этом оператору!! С другой стороны для меня лично очевидно, насколько сложно создать код, который отслеживал бы все возможные внутренние состояния. Как же быть? Ведь я совершенно не могу понять, на каком именно этапе загрузка остановилась. Поизучав материалы, которые имеются в Сети по теме этапов загрузки, понял, что большинстве своем они не дают представления о характерах и причинах возникновения ошибок, а содержат лишь общие рекомендации по устранению. Поэтому у меня возникло желание углубиться в материал и сделать себе небольшую карту ошибок этапов загрузки, да и для дальнейшего изучения он был бы неплохой отправной точкой. Так родилась идея начать серию статей по описанию стадий загрузки Windows с уклоном в сторону диагностики ошибок. Затем захотелось посмотреть на проблему ошибок загрузки Windows не с точки зрения последовательности «описание — снимок экрана — а попробуйте во это решение», а именно со стороны изучения всех возможных причины возникновения той или иной ошибки непосредственно с изучением кода. Да и вообще, мне лично всегда было интересно погрузиться до глубин кода, заглянуть «в файл» и прикоснуться к граням алгоритмов загрузки Windows, понять больше, познакомиться с ошибками, которые никогда не встречались мне на практике и не были освещены в информационном пространстве Сети, понять происходящее «изнутри».

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

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

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

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

В данной версии статьи будет описана классическая схема разбиения и загрузки (legacy boot), основанная на использовании PC/AT BIOS и MBR.

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

Об ошибках в модулях загрузки

Непосредственно перед тем как начать описание процесса загрузки и возникающих в процессе проблем, я бы хотел сделать небольшое отступление на тему ошибок Bootmgr, Winload и ntoskrnl, возникающих в ходе работы кода одноименных модулей. Многие критичные процедуры кода, реагируя на те или иные условия, генерируют числовые идентификаторы ошибок и возвращают их через произвольный регистр (чаще всего это eax). Поскольку регистр, хранящий код ошибки, часто сохраняется либо умышленно не используется, ошибки в «сквозном» режиме передаются на верхний уровень иерархии вложенных подпрограмм, то есть просто при множественном возврате из них по команде ret. Таким образом ошибки регистрируются до тех пор, пока в коде не встречается логика обработки ошибки. Подобных участков обработки ошибок Bootmgr у нас несколько:

• Блок кода в процедуре BmMain, выдающий ошибку BlInitializeLibrary failed …;
• Блок кода в процедуре BmMain, выдающий ошибку BlResourceFindMessage failed …;
• Блок кода в процедуре BmMain, выдающий ошибку BlXmiInitialize failed …;
• Процедура BmFatalErrorEx, которая является глобальным обработчиком ошибок на все остальные случаи;
• Процедура BlStatusError, которая вызывается из процедур MmHapReportHeapCorruption и BmFatalErrorEx в аварийной ситуации, проверяет наличие активного отладчика и случае наличия выдает специальную ошибку *** Fatal error …;

Некоторые обработчики незамедлительно выдают сообщение о возникшей проблеме на консоль, а вот глобальный кейс-обработчик BmFatalErrorEx содержит более витиеватую логику обработки поступившего кода с выдачей уже развернутого текста ошибки. Другая особенность обработки ошибок Bootmgr/Winload заключается в том, что, насколько я смог разобраться, менее значимые ошибки замещаются более значимыми. А это означает, что если ошибка возникла в какой-то процедуре как реакция на определенное условие, то другая ошибка, возникшая позже и являющаяся более приоритетной, может в процессе дальнейшего исполнения кода просто «затереть» первичную ошибку. Из этого следует, что на консоли пользователь видит лишь один результирующий статус, имеющий самый высокий приоритет, хотя, вероятно, имелся и менее приоритетный статус (или серия статусов), который был потерян.
Все ошибки, возникающие на этапах загрузки операционной системы Windows можно подразделить на две общие категории:

• Ошибка NT_ERROR (NTSTATUS). Хорошо знакомый разработчикам статус, использующийся для передачи результатов ошибок между разными компонентами ОС. Используется в ошибках Bootmgr/Winload, то есть сразу начиная с этапа Bootmgr.
• Ошибка BSOD BugCheck (STOP). Фатальная ошибка, хорошо знакомый всем нам синий экран смерти. Может возникать на поздних стадиях загрузки ОС, после того как подгружается логика обработки критических ошибок на этапе Ntoskrnl.

Код NTSTATUS — это 32-битное числовое значение, описывающее статус выполнения (результат завершения) кода подпрограммы/функции.

NTSTATUS частично описан в заголовочном файле ntstatus.h комплекта Windows WDK. Значения подразделяются на четыре категории:

• NT_SUCCESS (0 − 0x3FFFFFFF);
• NT_INFORMATION (0x40000000 − 0x7FFFFFFF);
• NT_WARNING (0x80000000 − 0xBFFFFFFF);
• NT_ERROR (0xC0000000 — 0xFFFFFFFF);

По коду можно заметить, что неотрицательные значения соответствуют «успешному» завершению подпрограммы, отрицательные — «ошибочному». Числовой статус обычно ассоциирован с текстовым описателем, который призван олицетворять понятный человеку, осмысленный текст ошибки (в теории, а на практике иногда весь мозг сломаешь в догадках). Полный список статусов NTSTATUS достаточно внушителен, но весь он нам не потребуется, поскольку далеко не все ошибки из этого списка мы можем наблюдать на изучаемых этапах загрузки Windows, а это, согласитесь, существенно облегчает нам работу

Некоторые особенности ошибок

У ошибок в коде Bottmgr я выделил несколько особенностей:

• В коде Bootmgr присутствуют так называемых «перекодирующих процедур», которые на входе проверяют значения некоторых ошибок NT_ERROR (диапазон 0xC0000000-0xFFFFFFFF) и, в зависимости от неких условий, преобразуют их в предупреждения NT_WARNING (диапазон 0x80000000-0xBFFFFFFF). По этой причине некоторые ошибки пользователь вообще никогда не будет наблюдать на результирующем ошибочном экране, выводимом Bootmgr. Однако, я этот факт в своей работе не учитывал и описывал все без исключения ошибки.
• Следующий немаловажный момент в логике обработки ошибок заключается вот в чем: Информационные сообщения об ошибках BootMgr/Winload, выводимые кодом модулей, вовсе не обязательно будут однозначно соответствовать уникальному значению NTSTATUS! Вот вам простой пример, наверняка многие видели на практике вот такую вот ошибку:

  Не удалось запустить Windows. Возможно, это произошло из-за недавнего изменения конфигурации оборудования или программного обеспечения. Чтобы устранить ошибку: 1. Вставьте установочный диск Windows и перезагрузите компьютер. 2. Выберите параметры языка,  затем нажмите кнопку «Далее». 3. Выберите пункт «Восстановить компьютер». Если этот диск отсутствует, обратитесь за помощью к системному администратору или изготовителю компьютера. Состояние: 0xc000000f Сведения: Сбой меню загрузки, поскольку требуемое устройство недоступно.

  А вот теперь та же самая ошибка, но с другим состоянием:

  Не удалось запустить Windows. Возможно, это произошло из-за недавнего изменения конфигурации оборудования или программного обеспечения. Чтобы устранить ошибку: 1. Вставьте установочный диск Windows и перезагрузите компьютер. 2. Выберите параметры языка,  затем нажмите кнопку «Далее». 3. Выберите пункт «Восстановить компьютер». Если этот диск отсутствует, обратитесь за помощью к системному администратору или изготовителю компьютера. Состояние: 0xc000000e Сведения: Сбой меню загрузки, поскольку требуемое устройство недоступно.

  Описание идентично, а коды разные!! Из этого следует, что одно текстовое сообщение об ошибке (сведения) может группировать сразу несколько родственных состояний (кодов ошибок). Если я нигде не ошибся, то для меня это, честно говоря, открытие! Получается, что разработчики решили особо не заморачиваться и не описывать в коде реакции на все возможные варианты ошибок, а ограничиться лишь конечным списком пояснений с выдачей конкретизирующего кода состояния (по которому и можно определить детали). И удивляться тут нечему, ведь данный факт опирается на бессмысленность генерации в коде реакции на все возможные состояния, поскольку код Bootmgr генерирует более 70 (!) уникальных ошибок, при том что многие неявны и по ним очень сложно работать, да и многие коды ошибок Bootmgr действительно одинаковы на разные события. Не думаю, что разработчик будет сидеть и корпеть над уникальным описанием для каждой ошибки.

• Еще одна особенность ошибок Bootmgr проистекает из второго пункта и заключается в том, что одно и то же состояние (например, C00000001) может иметь различные причины возникновения внутри разных по назначению функций. Имеется ряд ошибок Bootmgr, под которые может подпадать достаточно широкий спектр проблем в разнообразных функциональных частях образа Bootmgr. В одной функции ошибка имеет один смысл, в другой функции — другой. Поэтому, подобные ошибки лишь с большой натяжкой могут быть подогнаны под общее определение, иногда лишь отдаленно отражающее реальную суть происходящего, соответственно и рекомендации по устранению могут иметь большое количество пунктов, логически не связанных между собой. Вот такая вот реальность!!

Учитывая все вышеописанные обстоятельства, мы примем на вооружение следующую логику:

При возникновении ошибки сначала обращаем внимание на код состояния (NTSTATUS), как на наиболее информативный, а уж затем, при необходимости, руководствуемся сведениями об ошибке.

Собственно, этот постулат и будет у нас основополагающим, мы будем изучать ошибки Bootmgr, а не их описания. Это позволит нам более детально локализовать, конкретизировать проблему, то есть сделать её более определенной в причине собственного возникновения.

BmFatalErrorEx

Хотелось бы еще отдельно упомянуть основную процедуру для вывода сообщений об ошибках на консоль, именуемую BmFatalErrorEx. Она вызывается примерно из 9 мест на протяжении всего кода Bootmgr. Сама процедура предназначена для группировки ошибок по классам и вывода ограниченного количества сообщений об ошибках. Я думаю практически всем специалистам приведенный ниже шаблон достаточно хорошо знаком:

Указанная самой последней строка «Сведения» может содержать одну из нижеследующих текстовых строк:

Как можно заметить, не все ошибки имеют свою локализацию на русскому языке. Не знаю с чем это может быть связано, однако имеются две вероятных причины: я неправильно распарсил ресурсы главного модуля bootmgr.exe, либо пропустил какие-то записи в файле локализации bootmgr.exe.mui.
Ну и наконец то давайте уже переходит к анализу ошибок Bootmgr. Хотелось бы заметить, что вступление у нас было бы неполным, если бы сразу перешли к этапу Bootmgr и не осветили, хотя бы даже и поверхностно, стадии, которые ему предшествуют и относятся к процессу работы кода BIOS, MBR, PBR (VBR), ибо без них сюжетная линия повествования не была бы цельной.

Стадия BIOS

На IBM PC/AT-совместимой машине с классическим BIOS, код прошивки (firmware) на финальной стадии своего функционирования, по очереди перебирает устройства загрузки, заданные пользователем через меню настройки (Setup), и пытается считать с каждого из этих устройств загрузочный сектор. Сектор этот носит название Главной Загрузочной Записи (Master Boot Record, MBR). После загрузки с носителя загрузочного сектора, код BIOS проверяет наличие в последних двух байтах сигнатуры AA55h, и если сигнатура не обнаружена, то будет предпринята попытка перехода к другому устройству, если это устройство последнее в списке загрузки, то выдается одна из следующих ошибок (зависит от вендора оборудования):

Как Вы видите, с точки зрения ошибок финальная стадия BIOS достаточно проста, поскольку характеризуется всего-лишь невозможность нахождения кода MBR, а именно 512-байтного физического сектора с предопределенной сигнатурой AA55h.

Стадия MBR

Если коду BIOS удалось успешно считать первый физический сектор носителя в память и успешно проверить его сигнатуру, то он передает считанным данным управление. Начинает выполняться непосредственно сам код MBR. Поскольку в этом миниатюрном участке кода сложно выделить данные, то мы просто будем говорить о блоке кода и данных, который содержит всего три ошибки, детектируемые на стадии выполнения кода главной загрузочной записи. ASCII-строки ошибок располагаются во второй половине 512-байтного сектора и выглядят следующим образом:

Картинка с сайта: datadump.ru

Если обратите внимание, в данном случае со смещения 160 начинаются те самые ошибки. Ну а теперь давайте более детально остановимся на каждой из них:

Ошибка	Error loading operating system
Описание	Код не смог считать сектор с носителя при помощи функций прерывания int 13h. Ошибку возвращает код BIOS, который взаимодействует с портами контроллера. Проблема в BIOS? Это слишком старая материнская плата, у которой имеются проблемы с обработкой int 13h? Или физическая проблема контроллера/носителя?
Решение	Обновить/сбросить BIOS. Поменять материнскую плату на совместимую Проверить шлейф; Проверить накопитель на предмет аппаратных неисправностей.

Стадия PBR (VBR)

MBR нашел раздел, помеченный активным, загрузил с него первый физический сектор NTFS-раздела (партиции, тома) PBR (VBR), проверил его сигнатуру и передал ему управление. Как мы помним, основной целью кода PBR является загрузка Менеджера загрузки Windows (Windows Boot Manager, BootMgr) и передача ему управления.

Ошибка	A disk read error occurred
Описание	Универсальная комплексная ошибка, используемая кодом PBR сразу на нескольких стадиях: код PBR в попытке проверить самого себя (!) сравнивает начальные байты сектора с ASCII-значением NTFS (сигнатура, которая предваряет Boot Parameter Block, BPB) код не смог определить наличие расширений int 13h код пытается получить расширенный блок параметров диска при помощи int 13h код сравнивает значение из BPB, расположенного в начале сектора со значением, возвращенным функцией 48h прерывания int 13h.
Решение	Ваш BIOS не поддерживает расширения прерывания работы с диском 13h? Такие ситуации у нас полностью должны быть исключены, ну конечно если Вы не откопали совсем уж старую материнскую плату Во всех остальных случаях остается вариант с поврежденным блоком BPB в загрузочном секторе раздела. Его можно восстановить целиком со всем PBR, загрузившись в консоль восстановления и выполнив команду: bootrec /fixboot

Стадия Boot Manager (BOOTMGR)

Вот тут то у нас и начинается самое интересное, собственно то, ради чего данная статья и задумывалась. Код PBR(VBR) находит зарезервированный загрузочный раздел (System Reserved), находит в корне раздела файл Bootmgr и загружает его в память, затем передает ему управление. Стоит обратить отдельное внимание на оригинальный файл Bootmgr, располагающийся в корне зарезервированного раздела. Если Вы заметили он не имеет расширения, поскольку это не исполняемый PE-файл в привычном нам понимании, а составной файл, содержащий в начале 16-битную «заглушку» реального режима и «запакованный» 32-битный PE-файл bootmgr.exe. После загрузки в память управление получает именно 16-битная «заглушка», которая и занимается переводом процессора в 32-битный защищенный режим, использующий плоскую модель памяти, распаковкой оригинального .exe-файла и передачей ему управления.

Инициализация

Bootmgr.exe стартует с основной процедуры BmMain, которая сразу же начинает выполнять инициализацию внутренних структур и ключевых аппаратных компонентов системы при помощи процедуры: BlInitializeLibrary. Эта процедура включает в себя такие подпрограммы как InitializeLibrary, ReinitializeLibrary. Код которых, в свою очередь, друг за другом вызывает следующие процедуры:

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

Текст вывода намекает нам на то, что произошел сбой в какой-то из перечисленных выше подпрограмм. Поскольку данная ошибка охватывает достаточно большой диапазон кода и не имеет текстового описателя, то оператору будет довольно сложно понять в какой именно подпрограмме она возникла. Из этого следует, что единственный способ выявить причину, это попытаться вычислить её по коду ошибки. А что, в свою очередь, представляет из себя код 0xXXXXXXXX? Так ведь это же описанный выше NTSTATUS. Коды ошибок и их описания смотри в разделе ниже. Ну а мы двигаемся дальше.

Открытие BCD

После первичной инициализации логика bootmgr выполняет открытие файла данных конфигурации загрузки (BCD), который размещается:

• Для традиционной PC/AT (MBR) загрузки — на активном разделе по пути \Boot\BCD;
• Для современной UEFI загрузки — на разделе EFI по пути \EFI\Microsoft\Boot\BCD;

Для достижения этой цели используется процедура под названием BmOpenDataStore.

Файл данных конфигурации загрузки (Boot Configuration Data, BCD) — база данных, содержащая конфигурацию отдельных аспектов этапа загрузки. По структуре идентична файлу реестра Windows, после загрузки монтируется в куст HKLM\BCD00000000.

Как Вы уже поняли, BCD является одной из ключевых структур процесса загрузки, содержащей пункты меню загрузки, описывающие пути и настройки определенных элементов конфигурации. Естественно, что любые проблемы с этой базой сразу же выливаются в критические ошибки Bootmgr и невозможность продолжения процесса загрузки операционной системы.
Далее проверяются настройки журналирования этапов загрузки и если логгирование включено, то статус записывается в файл %SystemDrive%\Boot\bootstat.dat процедурой BmpInitializeBootStatusDatalog.
Затем процедура BlResourceFindHtml используется для поиска ресурсного файла bootmgr.xsl внутри ресурсной секции (.rsrc) образа файла bootmgr.exe.

Bootmgr.xsl является конфигурационным файлом, который содержит общие настройки параметров меню: внешнего вида, количества выводимых пунктов меню, наименование пунктов, описание горячих клавиш, цветового оформления меню, наличия разных опций и прочее.

Затем предпринимается попытка найти файл bootmgr.exe.mui, содержащий локализованные версии сообщений. На этапе поиска ресурсов, в случае возникновения проблем с нахождением/открытием оных, мы можем наблюдать ошибку:

Тут у нас ситуация, похожая ту, которая описывалась на этапе инициализации. Текст данной ошибки Bootmgr говорит о том, что в процедуре возникла проблема с нахождением ключевых ресурсов, которые потребуются в дальнейшей работе. Поскольку процедура многосоставная, то и источников проблемы может быть множество. Одной из причин данной ошибки могут быть проблемы с файлом bootmgr.xsl, поскольку без параметров, в нем описанных, дальнейшее выполнение невозможно. Коды ошибок у нас опять же сгруппированы в разделе под названием «Возникающие ошибки» ниже по тексту.
Далее ссылка на данные, загруженные из файла bootmgr.xsl передается процедуре BlXmiInitialize, которая предназначена для разбора содержимого файла и вывода на консоль меню загрузки на основе обнаруженных настроек. В случае, когда инсталлировано несколько операционных систем, либо присутствует несколько пунктов выбора, процедура отображает текстовое меню загрузки и ожидает пользовательского выбора.
при неудачном окончании процедуры выдается ошибка:

Ошибка говорит нам о том, что на этот раз уже с содержимым файла bootmgr.xsl что-то не так. Вероятно, присутствуют ошибки в операндах, структуре. Возможно, пользователь пытался изменить внешнее представление меню при помощи какой-то редактора и допустил ошибку.
Далее происходит проверка собственной цифровой подписи при помощи процедуры BmFwVerifySelfIntegrity. На этом этапе мы можем видеть ошибку C0000428.
Отдельно происходит проверка на наличии файла гибернации hiberfil.sys при помощи процедуры BmResumeFromHibernate, и в случае необходимости, код вызывает winresume.exe и начинает восстановление системы из режима гибернации.

Далее, в коде имеется еще один локальный обработчик ошибки, который предназначен для вывода на консоль следующего содержания:

Честно признаюсь, воочию я никогда в живой природе подобной ошибки не наблюдал, да и судя по коду она возникает только в случае подключенного отладчика в теле процедуры BlStatusError непосредственно перед передачей управления отладчику посредством вызова прерывания командой int 3, поэтому акцентировать внимание мы на ней не будем.

Загрузка пункта и передача управления OSLoader

Этот этап у нас является финальным в логике работы модуля Bootmgr. Когда пункт загрузки выбран пользователем, либо назначен автоматически, процедура под названием BmpLaunchBootEntry начинает загружать выбранный пункт загрузки. Процедура BlImgStartBootApplication через подмножество вложенных процедур передает параметры и управление загрузчику операционной системы следующего этапа под названием winload.exe (OSLoader), располагающемуся на выбранном разделе по пути ?:\Windows\System32\winload.exe либо ?:\Windows\System32\boot\winload.exe.

Возникающие ошибки

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

Выводы

Изучение внутренней структуры ошибок Bootmgr достаточно трудоемкое и кропотливое занятие, требующее огромного количества времени, а самое главное, недюжих знаний, каковыми я пока что не обладаю. Следствием этого, как Вы могли уже заметить, является тот факт, что далеко не все ошибки Bootmgr освещены достаточно подробно. В отсутствии вменяемой логики анализа исходного кода приходится изучать ошибки Bootmgr по ассемблерному листингу в отладчике. Вероятно, кто-то из профессионалов реверсинга может посоветовать восстанавливать исходные тексты на языке C/C++ для упрощения восприятия, но и данными, казалось бы, необходимыми знаниями я пока не наделен. Поэтому, статья находится в статусе альфа как не до конца проработанная, тем не менее, надеюсь, что даже в таком сыром виде будет полезна кому-либо в качестве плацдарма для изучения специфических, возникающих на начальной стадии Bootmgr, ошибок. Какие выводы можно сделать по данному материалу? Я думаю, основной вывод, который напрашивается: невозможно точно характеризовать возникающую ошибку Bootmgr и определенно сказать об причине её возникновения даже по числовому идентификатору NTSTATUS, поскольку многие статусы имеют различные причины в различных функциях. Единственное что можно сделать, это попытаться по перебору возможных причин ошибки дойти до настоящего виновника сбоя, затем уже воспользовавшись для ошибки рекомендациями по устранению. Можно воспользоваться и общими алгоритмами, которые на каждом шагу можно встретить в Сети, однако не все из них действенны. Возможно, большинство ошибок, которые приведены в результирующей таблице, на практике никогда никому не встречались и скорее всего, в живой природе можно наблюдать значительно меньший диапазон ошибок, которые уже более-менее изучены и по которым написаны развернутые мануалы по устранению. Однако, судя по некоторым темам конференций, можно сказать, что раритетные ошибки всё же имеют место быть, поэтому в качестве отправной точки материал всё же пригодится.