Comments 10
пару замечаний
он не скрытый, просто не смонтирован
по крайней мере, имеет рartition type 0х07, в MBR — это точно не hidden partition
почему везде одно и тоже? это же не совсем верно. открываем спецификации UEFI и читаем:
откуда пошло, что ESP имеет FAT32 — уж и не знаю, но это продублировано практически везде
ну и 0xef
остальное, как говорится — торт
По умолчанию, при штатной установке, этот загрузчик помещается в отдельный скрытый раздел, расположенный в начале HDD, с размером, достаточным для размещения самого bootmgr а так же файлов его конфигурации.
он не скрытый, просто не смонтирован
по крайней мере, имеет рartition type 0х07, в MBR — это точно не hidden partition
Системы с EFI + GPT изначально требуют наличия такого раздела, имеющего тип 0xef00 и отформатированного в FAT32.
почему везде одно и тоже? это же не совсем верно. открываем спецификации UEFI и читаем:
The file system supported by the Extensible Firmware Interface is based on the FAT file system. EFI defines a specific version of FAT that is explicitly documented and testable.
откуда пошло, что ESP имеет FAT32 — уж и не знаю, но это продублировано практически везде
ну и 0xef
остальное, как говорится — торт
Благодарю, исправлено
да не за что…
теперь бы узнать, почему винда не грузится ни в bios ни в uefi режиме с partition_table-less накопителей. далее в личке.
теперь бы узнать, почему винда не грузится ни в bios ни в uefi режиме с partition_table-less накопителей. далее в личке.
Ядро NT требует наличия Disk signature (MBR) или Disk GUID (GPT) на загрузочном накопителе. Если на загрузочном накопителе нет таблицы разделов, то и этих данных нет, а значит у Windows нет возможности найти загрузочный накопитель при переходе с прерываний BIOS или вызовов UEFI на непосредственный доступ через собственный драйвер.
Спасибо!
Познавательно для людей давно не в теме. Вижу со времён отладки через softice в ring0 живой системы жизнь несколько упростилась.
Познавательно для людей давно не в теме. Вижу со времён отладки через softice в ring0 живой системы жизнь несколько упростилась.
я просто оставлю это здесь: https://github.com/reactos/reactos/tree/master/reactos/boot/environ/app/bootmgr :)
Это конечно хорошо, но всё же реактроровский код != код винды. Тем более что той же поддержки vhd тут пока нет
Согласен насчет VHD, но та ссылка была приведена для того, чтобы наглядно показать принцип работы менеджера загрузки(Bootmgr), которая мало чем отличается(кроме функциональных расширений) от оригинального менеджера загрузки винды по логической составляющей. В любом случае было бы полезным привести ту ссылку в самом начале статьи хотя бы для тех людей, которые ничего не мыслят в механизации процесса загрузки. К тому же название статьи «Изучаем Bootmgr» намекает на то, что контекст работы бут менеджера будет освещен хоть каким то образом. За статью в целом плюс.
Если бы не поленились импортировать структуру в Ida pro через меню File->Load file->Parse C header, то получили бы читабельный код
Код
signed int __usercall VhdiVerifyVhdFooter@<eax>(vhd_footer_t *footer@<esi>)
{
signed int retval; // edi@1
uint32_t v2; // edi@2
int v3; // eax@2
int v4; // eax@6
int v5; // eax@10
retval = 0xC03A0003;
if ( RtlCompareMemory(footer, "conectix", 8u) == 8 )
{
v2 = footer->disk_type;
footer->disk_type = 0;
v3 = BlUtlCheckSum(footer, 512);
footer->disk_type = v2;
if ( v3 == v2 )
{
if ( HIWORD(footer->file_format_version) == 1 )
{
v4 = *(_DWORD *)&footer->disk_geometry.heads;
if ( v4 == 2 || v4 == 3 || v4 == 4 )
{
v5 = *(_DWORD *)&footer->creator_host_os[0];
if ( v5 != 'k2iW' && v5 )
{
retval = 0xC00000BB;
}
else if ( footer->current_size & 0x1FF || footer->original_size & 0x1FF )
{
retval = 0xC03A0012;
}
else
{
retval = 0;
}
}
else
{
retval = 0xC03A0004;
}
}
else
{
retval = 0xC03A0005;
}
}
else
{
retval = 0xC03A0002;
}
}
return retval;
}
а как там с продолжением? очень интересно излагаете ))
Sign up to leave a comment.
Изучаем Bootmgr. Часть 1 — инструментарий и основные принципы отладки начальных этапов загрузки ОС Windows