Jump to content











Photo
* * * * * 1 votes

Hack Bootmgr to boot Windows in BIOS to GPT

bios gpt bootmgr winload

  • Please log in to reply
335 replies to this topic

#26 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 03 February 2014 - 09:18 AM

Ok from what I could figure out... Setting the boot flag to active for the protective partition causes it to have problems... and won't go back until something else is also changed, causing recalculation of checksum, maybe?..

 

It's kind of like you're avoiding the suggestion of trying gptmbr.bin, whose documentation explains[1] that Microsoft operating systems can be booted on GPT disks with BIOS firmware using a hybrid MBR.

 

You get me wrong @Sha0. The above code has really piqued my interest, because I don't want to use grub and eventually want to use syslinux or the other one which does not depend on a BIOS boot partition. You bet I'll be trying it out soon.. But grub is the easiest to install, and it's really not the biggest problem.

 

If bootmgr does its part in a GPT disk, then our problem is solved. Which consists of the VBR, bootmgr and bcd. We could use ANY hybrid GPT- compatible boot-code(as opposed to partition table, see below). That means we have Grub, syslinux, and JdeBP's MBR code, and we can choose any of them.

 

The link explains that Windows can be booted using a Hybrid MBR partition table, which is a ugly and dangerous hack... not to mention not standards compliant. Only Hybrid MBR-compatible partition managers can operate safely on it.... because both MBR partition table as well as GPT must be kept synchronised. However it works, and has worked for ages, primarily on Intel Macs, and is a well-known, tried, tested method. Not new at all.

 

Also, 0xEF is the MBR partition type code for booting from MBR-partitioned disk in a UEFI-firmwared computer. This is the opposite situation. We want to boot from a GPT-partitioned disk in a BIOS-firmwared computer. What I'm attempting to do here is to boot windows off a spec-compliant and standard GPT disk.

 

Hybrid MBR violates the spec to satisfy bootmgr. I think we should do the opposite, cajole bootmgr into falling in line with the spec.


Edited by milindsmart, 03 February 2014 - 09:20 AM.


#27 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 03 February 2014 - 10:09 PM

If bootmgr does its part in a GPT disk, then our problem is solved. Which consists of the VBR, bootmgr and bcd. We could use ANY hybrid GPT- compatible boot-code(as opposed to partition table, see below). That means we have Grub, syslinux, and JdeBP's MBR code, and we can choose any of them.

I don't know why the BootMgr for BIOS firmware would include any code for finding the system volume (the filesystem with the BCD) on a GPT disk. I guess you're hoping that the code is there and that there's an on-off switch for it?

The link explains that Windows can be booted using a Hybrid MBR partition table, which is a ugly and dangerous hack... not to mention not standards compliant. Only Hybrid MBR-compatible partition managers can operate safely on it.... because both MBR partition table as well as GPT must be kept synchronised. However it works, and has worked for ages, primarily on Intel Macs, and is a well-known, tried, tested method. Not new at all.

Did someone say it was new? :)

Also, 0xEF is the MBR partition type code for booting from MBR-partitioned disk in a UEFI-firmwared computer.

It's the code for a (U)EFI system partition. I am not aware of any prohibition for using it with BIOS firmware. Are you? It was used in the shared steps so that it's not just any old FAT partition. It doesn't matter a lot.

This is the opposite situation. We want to boot from a GPT-partitioned disk in a BIOS-firmwared computer. What I'm attempting to do here is to boot windows off a spec-compliant and standard GPT disk.
 
Hybrid MBR violates the spec to satisfy bootmgr. I think we should do the opposite, cajole bootmgr into falling in line with the spec.

Well, if you don't wish to use a hybrid MBR, you could install an INT 0x13 hook which spoofs a hybrid MBR. Later, when the operating system loads, it won't use INT 0x13 and the original, pure GPT with non-hybrid protective MBR will be intact. Syslinux' MEMDISK could be hacked into such a thing relatively easily.

#28 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 03 February 2014 - 11:11 PM

I don't know why the BootMgr for BIOS firmware would include any code for finding the system volume (the filesystem with the BCD) on a GPT disk. I guess you're hoping that the code is there and that there's an on-off switch for it?

It mostly doesn't. But it does have all the generic library functions to read the GPT. Probably we just need to write a new function, fudged from another section which reads winload.exe from GPT partition just fine, for example. Is that too tough? I don't know. Will be learning to do it if we get around to that option, which is the final, non-hacky approach.
 

It's the code for a (U)EFIsystem partition. I am not aware of any prohibition for using it with BIOS firmware. Are you? It was used in the shared steps so that it's not just any old FAT partition. It doesn't matter a lot.

It's an MBR partition type code. It's one byte. GPT requires a 64 bit GUID as partition type code.
 

Well, if you don't wish to use a hybrid MBR, you could install an INT 0x13 hook which spoofs a hybrid MBR. Later, when the operating system loads, it won't use INT 0x13 and the original, pure GPT with non-hybrid protective MBR will be intact. SyslinuxMEMDISK could be hacked into such a thing relatively easily.

 
Aha, this sounds like a plan.

In fact there are loads of options :

  1. use Joakim's embedded BCD
  2. store the MBR as a small image file, use memdisk
  3. store an MBR disk layout as a partition in the GPT disk, use memdisk
  4. the hook that you just mentioned.
  5. hack bootmgr

In fact, (4) seems the 2nd cleanest, with least work involved. Except if bootmgr is already beyond Int 13h 's by the time it's looking for the BCD. In which case 2-4 won't work. Do you know exactly how bootmgr finds the BCD?

 

Did someone say it was new? :)

Well you seemed to imply so :)



#29 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 03 February 2014 - 11:15 PM

BTW... I posted

 

http://www.sevenforu...-mbrs-duet.html

 

:)



#30 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 04 February 2014 - 03:37 AM

It's an MBR partition type code. It's one byte. GPT requires a 64 bit GUID as partition type code.

That's the second time you've responded to something as though there was a claim to the contrary. There was no claim that is incompatible with what you've just shared. Please only read (and reply to) what's actually written. :)
 

In fact there are loads of options...

And don't forget hacking wimboot, which Michael Brown poured a ton of effort into and which can extract the BootMgr.Exe from the BIOS version of BootMgr and invoke it directly.
 

In fact, (4) seems the 2nd cleanest, with least work involved. Except if bootmgr is already beyond Int 13h 's by the time it's looking for the BCD. In which case 2-4 won't work. Do you know exactly how bootmgr finds the BCD?

BootMgr isn't beyond INT 0x13s. The "real-mode stub"[1] will have passed it a pointer to a structure which, when you follow it far enough, contains two call-backs for real-mode work.

Regarding the BCD, the BlGetBootOptionDevice and MiscGetBootOption functions might be relevant. I don't know. I thought that the VBR code would pass on the partition entry at DS:SI and BootMgr's real-mode stub would process it and pass it on to the embedded BootMgr.Exe. The link you shared to JdBP's article suggests that's not the case. Try taking a look at wimboot's /src/bootapp.h's struct bootapp_entry_wtf3_descriptor definition, perhaps.
 

Well you seemed to imply so :)

No. I was trying to help you to accomplish your goal without hacking BootMgr, but I guess I misunderstood the goal. Some folks join these forums and start inventing, only to realize that it's already been done and is old news. If you're familiar with the old news, then that's great! It'll be exciting to find out how you achieve this goal.

By the way, there're some BIOSes which actually want one of the MBR partition entries to have the bootable bit set before they'll load the sector and execute the code. These BIOSes can never boot a protective MBR (which is defined to have the bootable bit clear). There is some (U)EFI firmware which won't recognize a disk as a GPT disk if it doesn't contain a protective MBR. Unfortunately, this means that there is no way to satisfy both of these with the same MBR.

[1] Which obviously doesn't strictly operate in real-mode.

#31 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 04 February 2014 - 06:21 AM

That's the second time you've responded to something as though there was a claim to the contrary. There was no claim that is incompatible with what you've just shared. Please only read (and reply to) what's actually written. :)


haha sorry...  :loleverybody: my thoughts got messed up... Yes you're right, there's nothing similar to 0xEF for BIOS GPT... If we're going to use a hybrid MBR, it might as well be 0xEF. 
 

And don't forget hacking wimboot, which Michael Brown poured a ton of effort into and which can extract the BootMgr.Exe from the BIOS version of BootMgr and invoke it directly.

I tried to find out more about wimboot, but sadly need more info. A couple of threads about it on this site did not help... Of course, I don't really know much about WIMs or SDIs, so it would be good if you can point me to some relatively beginner level stuff on those. Like WIM vs SDI vs. raw image vs. a plain archive vs.. ?

Also, I thought the Vista RTM (pre SP1) bootmgr was uncompressed, and read that it's 16 bit header could be used to call bootmgr.exe directly... So why such a complex piece of software like wimboot?
 

BootMgr isn't beyond INT 0x13s. The "real-mode stub"[1] will have passed it a pointer to a structure which, when you follow it far enough, contains two call-backs for real-mode work.

Regarding the BCD, the BlGetBootOptionDevice and MiscGetBootOption functions might be relevant. I don't know. I thought that the VBR code would pass on the partition entry at DS:SI and BootMgr's real-mode stub would process it and pass it on to the embedded BootMgr.Exe. The link you shared to JdBP's article suggests that's not the case. Try taking a look at wimboot's /src/bootapp.h's struct bootapp_entry_wtf3_descriptor definition, perhaps.

Wow nice info... So the real mode stub is not actually in real mode... How? Bochs showed it alternating between 16 bit real mode and 16 bit protected mode hundreds of times.. I really didn't know what to make of it. But yes your explanation makes sense of why the code seemed to refer a location to which bootmgr.exe never wrote to.

I have a good mind to hack the VBR into accepting the numbers through DS:SI ... maybe another day :-)
 

No. I was trying to help you to accomplish your goal without hacking BootMgr, but I guess I misunderstood the goal. Some folks join these forums and start inventing, only to realize that it's already been done and is old news. If you're familiar with the old news, then that's great! It'll be exciting to find out how you achieve this goal.

Oh please do keep telling me when there are existing solutions... In this case for a few months I have been following this whole EFI and GPT field. Booting in general I'm mostly learning by getting my hands dirty since just recently  :D
 

By the way, there're some BIOSes which actually want one of the MBR partition entries to have the bootable bit set before they'll load the sector and execute the code. These BIOSes can never boot a protective MBR (which is defined to have the bootable bit clear). There is some (U)EFI firmware which won't recognize a disk as a GPT disk if it doesn't contain a protective MBR. Unfortunately, this means that there is no way to satisfy both of these with the same MBR.

[1] Which obviously doesn't strictly operate in real-mode.

well those BIOSes and UEFIes can go screw themselves  :buehehe:  The grand assumptions of the BIOS engineers of yesterday.... "There will never be any other way to partition hard disks than tired old MBR".



#32 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 05 February 2014 - 03:41 AM

I tried to find out more about wimboot, but sadly need more info. A couple of threads about it on this site did not help...

Its source code is written in C and its author, Michael Brown, has licensed the software as "open source." It lives with iPXE at the iPXE web-site.

Of course, I don't really know much about WIMs or SDIs, so it would be good if you can point me to some relatively beginner level stuff on those. Like WIM vs SDI vs. raw image vs. a plain archive vs.. ?

It seems there are many parallels between various operating systems' booting mechanisms:
  • Boot from floppy disk, hard disk, optical disc
  • Boot from RAM disk (example: historical Linux initrd)
  • Boot from compressed RAM disk (example: historical Linux compressed initrd)
  • Boot from RAM-based filesystem (example: modern Linux initramfs)
  • Boot from compressed RAM-based filesystem (example: modern Linux compressed initramfs, example: .WIM files)
My understanding is that in Microsoft Windows NT descendants, there are two sorts of modes for using a RAM-disk:
  • The disk image for the virtual disk contains a regular filesystem
  • The disk image is a "dummy" and a special filesystem driver uses an archive to pretend that filesystem is on that virtual disk
With the former, the disk image is just an image of a regular disk. It can have any regular disk filesystem on it. With the latter, the disk image is just a dummy to pretend "there is a disk" and the files are provided by a special filesystem driver, such as the one that knows how to mount .WIM files.

If you had $0.05 for every boot-from-virtual-disk scenario that Microsoft used with Windows >= Windows XP, I think you'd have at least $0.15.

Also, I thought the Vista RTM (pre SP1) bootmgr was uncompressed, and read that it's 16 bit header could be used to call bootmgr.exe directly... So why such a complex piece of software like wimboot?

Wimboot doesn't require any disk. The BIOS version of BootMgr expects some kind of disk.

It's actually doing a similar strategy to .WIMs themselves, only back one step in the boot-process. You hand it a set of files and it emulates an INT 0x13 disk with a FAT filesystem on it containing those files. The magic is that it doesn't use any disk image; sector-read requests have dynamically-generated content without having built an entire disk image in memory.

Wow nice info... So the real mode stub is not actually in real mode... How? Bochs showed it alternating between 16 bit real mode and 16 bit protected mode hundreds of times.. I really didn't know what to make of it. But yes your explanation makes sense of why the code seemed to refer a location to which bootmgr.exe never wrote to.

The stub for BIOS BootMgr and the (U)EFI BootMgFw.Efi play a similar role: Both establish some amount of firmware abstraction for the "proper" BootMgr itself. Why do I think this? Because both of them pass parameters to the proper BootMgr which include callbacks.

For the BIOS BootMgr, it calls back into the stub for disk-reads. For each read, the stub will bounce from protected mode into real mode, perform the INT 0x13, then bounce back into protected mode, then return the data and control to BootMgr. This is the same for many boot-loaders, including MEMDISK and GRUB4DOS.

Oh please do keep telling me when there are existing solutions... In this case for a few months I have been following this whole EFI and GPT field. Booting in general I'm mostly learning by getting my hands dirty since just recently  :D

Thinking about it some more, you could probably use wimboot without doing any hacking, just as some of your other options do...
  • Using a GPT partition as an MBR disk image or floppy disk image (GRUB4DOS could map this)
  • Using an MBR disk image or floppy disk image from some filesystem on some GPT partition (GRUB4DOS or MEMDISK could map this)
Using wimboot, you wouldn't have an disk image, but you could get the same result: You could boot BootMgr with an arbitrary BCD, then that BCD could refer to the actual GPT disk. I could probably make an example and attach it to a future post, if that seems like an interesting solution. A nice feature is that the BCD is easily accessible without having to be "put inside" and "taken out of" a disk image any time you change it.

well those BIOSes and UEFIes can go screw themselves  :buehehe:  The grand assumptions of the BIOS engineers of yesterday.... "There will never be any other way to partition hard disks than tired old MBR".

:buehehe: Indeed.

#33 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 05 February 2014 - 07:16 AM

That's a LOT of information to take it, so I will reply as soon as I can... I have a research colloquium this week, so I might reply in the weekend... 

 

But on another note, I successfully booted Windows 7 32-bit in the same method! :)

 

Of course it was expected, but this is something considered VERY impossible.



#34 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 05 February 2014 - 02:29 PM

My understanding is that in Microsoft Windows NT descendants, there are two sorts of modes for using a RAM-disk:

  • The disk image for the virtual disk contains a regular filesystem
  • The disk image is a "dummy" and a special filesystem driver uses an archive to pretend that filesystem is on that virtual disk
With the former, the disk image is just an image of a regular disk. It can have any regular disk filesystem on it. With the latter, the disk image is just a dummy to pretend "there is a disk" and the files are provided by a special filesystem driver, such as the one that knows how to mount .WIM files.

 

I finally understood what this means : basically the difference between initrd and initramfs. There isn't that sector-based image anywhere... It is loaded from disk in a form ready to address from RAM. And forced to stay in memory by configuration.
 

Wimboot doesn't require any disk. The BIOS version of BootMgr expects some kind of disk.

It's actually doing a similar strategy to .WIMs themselves, only back one step in the boot-process. You hand it a set of files and it emulates an INT 0x13 disk with a FAT filesystem on it containing those files. The magic is that it doesn't use any disk image; sector-read requests have dynamically-generated content without having built an entire disk image in memory.

So it's more like a filesystem driver.. Except that since the program, say bootmgr, cannot be made aware of a simpler way to access the files, we feed it in a dumbed-down form it understands. This is the next best thing to unplugging it's inbuilt FAT "filesystem driver" and accept one from memdisk or grub4dos. Right?
 

The stub for BIOS BootMgr and the (U)EFI BootMgFw.Efi play a similar role: Both establish some amount of firmware abstraction for the "proper" BootMgr itself. Why do I think this? Because both of them pass parameters to the proper BootMgr which include callbacks.

For the BIOS BootMgr, it calls back into the stub for disk-reads. For each read, the stub will bounce from protected mode into real mode, perform the INT 0x13, then bounce back into protected mode, then return the data and control to BootMgr. This is the same for many boot-loaders, including MEMDISK and GRUB4DOS.

That explains how it can read files in 32-bit mode without having set up DMA.... hmm....
 

Thinking about it some more, you could probably use wimboot without doing any hacking, just as some of your other options do...

  • Using a GPT partition as an MBR disk image or floppy disk image (GRUB4DOS could map this)
  • Using an MBR disk image or floppy disk image from some filesystem on some GPT partition (GRUB4DOS or MEMDISK could map this)
Using wimboot, you wouldn't have an disk image, but you could get the same result: You could boot BootMgr with an arbitrary BCD, then that BCD could refer to the actual GPT disk. I could probably make an example and attach it to a future post, if that seems like an interesting solution. A nice feature is that the BCD is easily accessible without having to be "put inside" and "taken out of" a disk image any time you change it.

 


Yes I think this is the best idea : simply spoof or fake a new MBR disk containing just the system partition on the GPT disk, along with the MBR itself probably, from a saved bin file, as we currently use for booting grub from bootmgr. As you said, the sector reads will just be translated into the required address, or to a file.

Once handed to winload.exe, there is no need of it anyway. Perhaps something must be done to unload it from memory at an appropriate time.

One bootkit called VBootKit basically patches bootmgr in memory. In some sense, we're hooking 0x13 to memdisk, which is very much like patching in memory....  :clap: 

Is this hard to do?



#35 cdob

cdob

    Gold Member

  • Expert
  • 1288 posts

Posted 05 February 2014 - 11:04 PM

Using wimboot, you wouldn't have an disk image, but you could get the same result: You could boot BootMgr with an arbitrary BCD, then that BCD could refer to the actual GPT disk.


Thanks for the brilliant wimboot explanation. I wasn't aware of this so far.

additonal references:
http://jamesbond3142...cgi/BIOSBootGPT
http://ipxe.org/wimboot
http://forum.ipxe.or...ad.php?tid=5745

Given a Windows 7 default EFI installation:
one 100 MB EFI partition and another system partition.

At gparted, 100 MB EFI partition selected: "Manage Flags" and tick "legacy boot".

100 MB partition mounted at E:
syslinux64.exe --force --directory /boot/ --install E:

At hexeditor: the first 440 bytes from gptmbr.bin copied to HDD MBR

Files:
E:\bootmgr
E:\boot\BCD
E:\boot\ldlinux.sys
E:\boot\ldlinux.c32
E:\boot\syslinux\wimboot
E:\boot\syslinux\linux.c32
E:\boot\syslinux\libcom32.c32
E:\boot\syslinux\syslinux.cfg
Default Wimboot7

LABEL Wimboot7
  com32 linux.c32
  append wimboot initrdfile=/bootmgr,/boot/bcd

Booted to hard disk: syslinux and wimboot are executed.
Bootmgr is loaded and bcd processed:

Next: BSOD 0x50 PAGE_FAUT_IN_NONPAGED_AREA

What did I do wrong?
Do you have any idea?

#36 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 06 February 2014 - 02:12 AM

Next: BSOD 0x50 PAGE_FAUT_IN_NONPAGED_AREA

What did I do wrong?
Do you have any idea?

Which BCD did you use? (bcdedit /store e:\boot\bcd /enum all) Did you pass a dummy .WIM file? It might be that you were booting a Windows PE without a .WIM.

#37 cdob

cdob

    Gold Member

  • Expert
  • 1288 posts

Posted 06 February 2014 - 08:04 PM

Which BCD did you use?

The BCD file is a copy from the previous used floppy, the Post #10 describe the content.
http://reboot.pro/to...pt/#entry181899
 

Did you pass a dummy .WIM file? It might be that you were booting a Windows PE without a .WIM.

It's booting flat file windows 7, no PE. No, there is no wim file.


Another approach: floppy image extracted and copied to E:\boot\syslinux\W7.img
# Boot Windows7 from floppy
LABEL Windows7
 LINUX memdisk
 INITRD W7.img
 APPEND raw
Windows 7 does boot from MBR to GPT partition.
One hard disk used only, and a friendly BIOS.

'APPEND raw' is importand. Without this, there is a black screen only.

#38 steve6375

steve6375

    Platinum Member

  • Developer
  • 6272 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 07 February 2014 - 01:05 PM

Just for your interest, I found a blog post about the EFI system partition which looks interesting.

Also here for detailed explanation of how it works.



#39 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 08 February 2014 - 11:48 AM

The BCD file is a copy from the previous used floppy, the Post #10 describe the content.
http://reboot.pro/to...pt/#entry181899
 
It's booting flat file windows 7, no PE. No, there is no wim file.


Another approach: floppy image extracted and copied to E:\boot\syslinux\W7.img

# Boot Windows7 from floppy
LABEL Windows7
 LINUX memdisk
 INITRD W7.img
 APPEND raw
Windows 7 does boot from MBR to GPT partition.
One hard disk used only, and a friendly BIOS.

'APPEND raw' is importand. Without this, there is a black screen only.

 

Awesome work... So if we use a disk image it works fine... BTW what is a "friendly" BIOS in this context?

I believe Sha0 will be able to get wimboot to work without any actual image, by creating it on the fly. 

 

Since you are already able to make that way work, I decided to check what bootmgr on a GPT disk has a problem with... If it knows what GPT is, then why can't it find BCD in its own partition on that disk?

I sat down and stepped through bootmgr.exe in bochs.... 

  • The number of disks in a variable called _FirmwareDisks is indeed equal to the number of disks, in my case 1
  • This disk is recognized as having a GPT partition table
  • However, this disk is not considered as the one it needs to read, most likely due to some comparison, of signature, I suspect.

Have to investigate this further.


Edited by milindsmart, 08 February 2014 - 11:49 AM.


#40 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 08 February 2014 - 12:49 PM

For reference on internals of bootmgr.exe

 

https://news.saferby...nical-overview/

http://www.nvlabs.in..._whitepaper.pdf

 

Update : It is indeed a comparison of something like a signature... failing function : BlpDeviceCompare(x,x)


Edited by milindsmart, 08 February 2014 - 01:05 PM.


#41 cdob

cdob

    Gold Member

  • Expert
  • 1288 posts

Posted 08 February 2014 - 03:03 PM

BTW what is a "friendly" BIOS in this context?

Sha0 described some BIOS behaviour at Pos #30
http://reboot.pro/to...e-2#entry182066

A "friendly" BIOS (as for a GPT disk) loads boot code despide a default protective MBR entry.
No validation check about active partition, or partition boot code.
  • milindsmart likes this

#42 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 08 February 2014 - 09:15 PM

My suspicion was right......

 

When BlpDeviceCompare fails, it reads from memory and compares the GPT disk GUID with the MBR disk signature. They not being equal causes it to give up.

 

Just for ref : 26h memory bytes @ 0x1014c0 are compared with @ 0x1012f8. The former has the GPT disk GUID (starting from byte 9), and it seems the latter has the MBR signature(which is all zeros). Apart from this also has a significant byte at byte no. 5.... The former has it 00h, and latter 01h. 

 

So now no hacking of bootmgr.exe itself required, because this memory is not part of the bootmgr.exe image, nor of the 16-bit stub, nor of the VBR....

 

What writes to these places?

 

0x1014c0 is written to by the 16 bit stub, instruction at 0x20782. also modified by DiskPcatCreateDeviceEntry, instruction at 0x4111f5

0x1012f8 is ALSO written to by the SAME 16 bit stub, instruction at 0x20782. It is called by about 4 functions overall, so it's probably returning different data to each.

 

Considering it's a pretty important part of windows, would it be possible to have an open-source initiative to disassemble the 16-bit stub with meaningful names? Legal? workable? I'm increasingly out of my depth here though, so what say?

 

Another reference, in chinese though... google translate does a good job : detailed boot process : http://bbs.chinaunix...004043-1-1.html


Edited by milindsmart, 08 February 2014 - 09:21 PM.


#43 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 18 February 2014 - 04:26 PM

@cdob, did you get the wimboot version running? Digging into bootmgr is taking more time than i thought.



#44 cdob

cdob

    Gold Member

  • Expert
  • 1288 posts

Posted 19 February 2014 - 04:25 PM

did you get the wimboot version running?

No, I didn't succeeded. BSOD still.

#45 Sascha Weaver

Sascha Weaver
  • Members
  • 5 posts
  •  
    China

Posted 26 May 2014 - 05:17 AM

I've managed to boot Windows under BIOS + GPT setup with a small virtual MBR disk image (can be as small as 10 MiB, because NTFS needs to be at least 8 MiB).
 
Project Syslinux developed a module called MEMDISK, it's just a 26 kB small file, but is capable of loading disk images, including floppy image, (raw) hard disk image and iso image. This module can be involed from multiple bootloaders, such as GRUB Legacy, GRUB, Grub4Dos, and Syslinux of course.
 
I used to install Windows boot files (bootmgr and Boot\BCD) on a seperate physical USB drive with MBR layout. However carrying a USB drive to boot Windows is inconvenient.  So I tried to make a disk image of it and it worked. Here is how it works:
 
First, boot into Windows PE and use diskpart to prepare your disks.
# To see what disks you have
DISKPART> list disk
# System disk is disk 0 (to which Windows itself will be installed on)
# Windows PE disk is disk 1 (ignore it)
# The to-be-created VHD is disk 2 (to which Windows boot files will reside)
DISKPART> select disk 0
DISKPART> list partition
DISKPART> select partition 4
DISKPART> format label="Windows 8.1" quick
DISKPART> assign letter=c
# ^ Formatting Windows partition and assign letter C:
# Create and attach VHD
DISKPART> create vdisk file=c:\bootmgr.vhd maximum=32 type=fixed
DISKPART> attach vdisk
# Create and activate boot partition in VHD
DISKPART> select disk 2
DISKPART> create partition primary offset=1024
DISKPART> active
DISKPART> format label=bootmgr quick
# Assign a letter B:
DISKPART> assign letter=b
# Exit diskpart
DISKPART> exit
 
Second, install Windows and Windows boot files:
# Extract install.wim to C:
X:\> imagex /apply install.wim 1 c:
# Write boot sector and BCD
X:\> bootsect /nt60 b: /mbr
X:\> bcdboot c:\Windows /s b:
Now we've got a normal (without PBR, without BCD, without special partition flag) partition with Windows files in it, and a small (32 MiB) VHD file with Windows boot files (bootmgr, Boot\BCD, et cetra) in it.
 
I used to think that I need to convert VHD into raw image with "VBoxManage clonehd --type raw bootmgr.vhd bootmgr.img", but the good news is, when created with "type=fixed", the vhd file is no more than a raw image file + 512 Bytes footer, which will be recognized as "unpartitioned space" and will be ignored. So "type=fixed" vhd file can be directly fed to MEMDISK without convertion.
 
So here is how to load the small virtual boot disk in Grub4Dos:
 title bootmgr.vhd
   kernel /path/to/memdisk harddisk
   initrd /path/to/bootmgr.vhd
And here is my GRUB example:
menuentry "bootmgr.vhd" {
  linux16 /boot/syslinux/memdisk harddisk
  initrd16 /boot/bootmgr.vhd
}
 
Enjoy your Windows in BIOS + GPT.
 
Here is my original blog post (in Chinese): https://wzyboy.im/post/1049.html

Edited by Sascha Weaver, 26 May 2014 - 05:24 AM.

  • sebus likes this

#46 steve6375

steve6375

    Platinum Member

  • Developer
  • 6272 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 26 May 2014 - 08:34 AM

In modern grub4dos (2013/2014) memdisk is not required

 

map --mem /path/to.vhd (hd3)

map --hook

chainloader (hd3,0)+1

 

should be equivalent to using memdisk?

 

or try this for faster method

map /path/to.vhd (hd3)
map --hook
chainloader (hd3,0)+1



#47 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13068 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 26 May 2014 - 09:13 AM

In modern grub4dos (2013/2014) memdisk is not required

Also in "ancient", like 2012, 2011, 2010 and even 2009.

 

@Sascha Weaver

Nice. :)

Can you provide some explanation for the image needing to be 8 MiB minimum?

I am asking because the minimum NTFS image (with "normal" 4096 bytes clusters) that I create is around 3 Mb (provided that the 8 sectors cluster is needed for whatever reason) and there are ways (already used to make much smaller ones, the approach has been in use to reduce size of boot.sdi for some time) see:

http://www.msfn.org/...ize-of-bootsdi/

 

Also, this is not much different from the good ol' way of using a boot floppy (or floppy image with syslinux/memdisk or grub4dos) like:

http://www.multiboot....uk/floppy.html

(but that was used on "normal" BIOS+MBR systems, cannot say if it could work in this "mixed mode" setup).

 

:duff:

Wonko



#48 cdob

cdob

    Gold Member

  • Expert
  • 1288 posts

Posted 26 May 2014 - 03:39 PM

to boot Windows under BIOS + GPT setup

So here is how to load the small virtual boot disk in Grub4Dos

Do you boot grub4dos from the GPT disk?
How do you install grub4dos to the GPT disk?
 

Also, this is not much different from the good ol' way of using a boot floppy (or floppy image with syslinux/memdisk or grub4dos)

Post #37 contains a floppy disk example http://reboot.pro/to...e-2#entry182138
Yes, a floppy disk image works at "mixed mode" setup.

bcdboot likes to copy unicode language files too.
This won't fit at a 1.44 MB floppy disk. Copy \bootmgr and \boot\bcd only.
bcdboot may work at a bigger floppy disk.

VHD is the OS default image format nowadays.

#49 Sascha Weaver

Sascha Weaver
  • Members
  • 5 posts
  •  
    China

Posted 26 May 2014 - 04:08 PM

Also in "ancient", like 2012, 2011, 2010 and even 2009.

 

@Sascha Weaver

Nice. :)

Can you provide some explanation for the image needing to be 8 MiB minimum?

 

It seems like diskpart and diskmgmt.msc told me the NTFS needs to be at least 8 MiB. When I create an NTFS partition with less than 8 MiB in size, it shows a corrupted file system.



#50 Sascha Weaver

Sascha Weaver
  • Members
  • 5 posts
  •  
    China

Posted 26 May 2014 - 04:12 PM

Do you boot grub4dos from the GPT disk?
How do you install grub4dos to the GPT disk?

 

Sorry, I've never used Grub4Dos. I am a GRUB user. I'll remove that section.

 

bcdboot likes to copy unicode language files too.
This won't fit at a 1.44 MB floppy disk. Copy \bootmgr and \boot\bcd only.
bcdboot may work at a bigger floppy disk.

 

Yes, East Asian font files are big. The core file is only bootmgr and BCD. I tried with only that two files and it worked.







Also tagged with one or more of these keywords: bios, gpt, bootmgr, winload

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users