Boot from USB/Firewire HD without BIOS support, Fake Signature Method Options

[s4e]

The concept is build a fake HD image, with same signature as external HD. After boot stage1, Windows will match the external HD signature against boot loader information, and think the external HD is the boot disk, and continue boot stage2.

Before start, you need GRUB4DOS, and VMWare, and contig.exe from sysinternals. Here is the detail method:

1. Throw external HD into VMWare as a raw disk, make it USB Boot friendly.
2. Create a 0.1G pre-allocated VMWare image, run contig against the *-flat.vmdk file.
3. Format this VMDK, same filesystem format as external HD.
4. Copy Following file from external HD to VMDK partition:

CODE

\BOOT.INI
\NTDETECT.COM
\NTLDR
\WINDOWS\AppPatch\drvmain.sdb
\WINDOWS\FONTS\svgafix.fon
\WINDOWS\FONTS\svgasys.fon
\WINDOWS\FONTS\vga850.fon
\WINDOWS\FONTS\vgaoem.fon
\WINDOWS\INF\biosinfo.inf
\WINDOWS\system32\bootvid.dll
\WINDOWS\system32\c_1250.nls
\WINDOWS\system32\c_850.nls
\WINDOWS\system32\hal.dll
\WINDOWS\system32\kdcom.dll
\WINDOWS\system32\l_intl.nls
\WINDOWS\system32\ntkrnlpa.exe
\WINDOWS\system32\ntoskrnl.exe
\WINDOWS\system32\config\system
\WINDOWS\system32\drivers\

here 850 is your XP default codepage.
5. Copy first 0x1be bytes of bootsect from external HD to *-flat.vmdk.
6. Change bytes from 0x1b0 - 0x1be, make the VMDK has same MBR checksum as external HD. MBR checksum is sum of 128 ULONG value.
7. Load this VMDK from GRUB4DOS:

CODE

map --read-only (...)/...-flat.vmdk (hd0)
map --hook
rootnotverify (hd0,0)
chainloader +1
boot

[jaclaz]

Interesting approach.

Is it tested?

Why using VMware .vmdk format, though?

As I see it using a RAW image should work as well, and you can use MBRFIX to change the MBR signature and need not to validate the checksum.

I must find the time to test this....

jaclaz

[s4e]

Interesting approach.

Is it tested?

Why using VMware .vmdk format, though?

As I see it using a RAW image should work as well, and you can use MBRFIX to change the MBR signature and need not to validate the checksum.

I must find the time to test this....

jaclaz

Yes, it's test with ASUS MB & FireWire HD.
The quick way to make 2 bootsect has same signature and checksum is:

CODE

------------EXTERNAL HD---------------------
0000190: 0000 0000 0000 0000 0000 0000 0000 0000  // ==
00001a0: 0100 07fe 3f02 3f00 0000 04bc 0000 0000  // FF <---\
00001b0: 0000 0000 002c 4463 fd62 7287 0000 8001  // ==     |
00001c0: 0100 07fe ffff 3f00 0000 828a a112 0000  // EE --\ |
00001d0: 0000 0000 0000 0000 0000 0000 0000 0000  // ==   | |
00001e0: 0000 0000 0000 0000 0000 0000 0000 0000  // ==   | |
00001f0: 0000 0000 0000 0000 0000 0000 0000 55aa  // ==   | |
-------------FAKE IMAGE------------------------           | |
0000190: 0000 0000 0000 0000 0000 0000 0000 0000  // ==   | |
00001a0: 0100 07fe ffff 3f00 0000 828a a112 0000  // EE <-/ |
00001b0: 0000 0000 002c 4463 fd62 7287 0000 8001  // ==     |
00001c0: 0100 07fe 3f02 3f00 0000 04bc 0000 0000  // FF ----/
00001d0: 0000 0000 0000 0000 0000 0000 0000 0000  // ==
00001e0: 0000 0000 0000 0000 0000 0000 0000 0000  // ==
00001f0: 0000 0000 0000 0000 0000 0000 0000 55aa  // ==

copy line mark EE from External HD bootsect to Fake Image,
copy line mark FF from Fake Image to External HD bootsect,
make other lines identical.

The files under SYSTEM32\Drivers used in my test are:

CODE

1394bus.sys
acpi.sys
AGP440.SYS
atapi.sys
battc.sys
classpnp.sys
compbatt.sys
disk.sys
dmio.sys
dmload.sys
fastfat.sys
fltMgr.sys
ftdisk.sys
iaStor.sys
intelide.sys
isapnp.sys
jraid.sys
ksecdd.sys
mountmgr.sys
mup.sys
ndis.sys
ntfs.sys
ohci1394.sys
partmgr.sys
pci.sys
pciide.sys
pciidex.sys
sbp2port.sys
scsiport.sys
symmpi.sys
usbd.sys
usbehci.sys
usbhub.sys
usbport.sys
USBSTOR.SYS
usbuhci.sys
vmscsi.sys
volsnap.sys
wmilib.sys

This post has been edited by s4e: Mar 6 2008, 09:26 AM

[Dietmar]

Hi s4e,

this is indeed a very interesting approach. Tomorrow I have holidays and I will test it.
I do not see, why it is only usable for a VMware image. It should also work with a real XP on the external harddisk.

I think the same for ETboot on bootland for real CD boot of XP.

If I understood all right, ntldr starts and loads all the USB drivers or in this example for firewire from the normal harddisk (or floppy or CD).
But the "rest" of XP starts from the external hardisk, exact at the moment after mup.sys can be seen in boot.log.
I believe, that this is possible. I have seen something like while testing boot from USB, but I never thought, that this could be an advantage. I thought, that this is a bad behavior of XP, but now I think, also very usefull.

Nice to hear from you all,

Dietmar

[s4e]

VMWare is not mandantory, but it make life a lot easier. You can dual boot the external HD, modify the RAW disk image, and test USB boot.

This post has been edited by Ed_P: Mar 6 2008, 11:59 PM

Reason for edit: Removed needless quote. Please use the ADD REPLY button.

[jaclaz]

Yes, I was thinking about using QEMU, and as said with purely RAW images you won't need a hex editor at all.

jaclaz

[Dietmar]

Hi s4e,

I am working on Your fantastic idea. Two connected harddisks with the same signature give BSOD late in the bootprocess.
This is direct after the point, that one of those 2 harddisks has to disappear, not to give XP two identical disks.

Can you please specify exact that moment, which You describe as changing from Bootstage 1 to Bootstage 2?

This is important, because this gives you the exact minimal filelist, which files are needed. I think, that those files are all together below 5 MB.

If You are right, the problem with no Bios support is solved to do USB boot (or booting from firewire or anything else, which has a signature and XP has a driver for).

I will write Tutorial 7.

EDIT: Do you use the Signatur() syntax in boot.ini or is it normal multi() ?

Nice to hear from You,

Dietmar

PS: Yesterday I was on the CEBIT in germany. I spoke with a man from OLPC Austria.
He told me a lot of things about the OLPC's hardware. After that I am sure, that XP can boot on the OLPC.

This post has been edited by Dietmar: Mar 9 2008, 06:38 AM

[s4e]

Windows don't support 2 disk with same signature. So you must use a disk image(or disabled disk) with NTLDR, and external HD without BIOS support. And Windows must see the external HD but not the fake boot disk.
For a list drivers needed in stage1, you can check ntbtlog.txt, all items above first \SystemRoot\system32\DRIVERS\ is required. It's all Start==0 drivers and some dependency. eq: WMILIB, USBPORT, USBD, BATTC, PCIIDEX, SCSIPORT, CLASSPNP, 1394BUS.
In BOOT.INI, I use the multi(0)disk(0)rdisk(0)partition(1)，because the disk image emulated as (hd0).

[Dietmar]

Hi s4e,

first try is BSOD 0x34.

I wonder, whether the USB drivers are not loaded.

Please s4e,
can you describe Step by Step, how you achived booting from firewire?
USB boot does not work until now.

Nice to hear from you,
Dietmar

[s4e]

It's simple. First fire the VMWare, create 0.1G pre-allocated virtual disk, contig it. boot into virtual windows, format it to NTFS. shutdown virtual windows guest. Map the virtual disk image to drive Z:, copy all files I mentioned before. Then unmap the image file, fix the signature & checksum. Reboot to GRUB4DOS, load the virtual disk.

[Debian]

you've sparked a revolution dude! guess I will still be here tomorrow morning ha! post your concept everyone is trying to boot e hdd just have a look at all the posts seasoned computer men with no answers.

once again master-plan m8

Debian

[dennis123123]

Wow, it's a bit confusing atm, but once the geniuses (Dietmar, Jaclaz etc ) figure things out about how to make this work fully, i cant wait.

Great job s4e

This post has been edited by dennis123123: Mar 10 2008, 02:50 AM

[Dietmar]

Hi all,

is it possible to chainboot a whole XP.img (4GB Fat32 XP, raw img, meaning with MBR and first aktive partition in it) with Grub4dos from the boot harddisk with XP on it?

Nice to hear from you,
Dietmar

This post has been edited by Dietmar: Mar 10 2008, 05:18 AM

[s4e]

Yes, it works. chainloader has two form: ramdisk and mapping. The mapping method hasn't size limitation, but require the image file is contiguous. That's why contig.exe is require, it's the simplest way making a single file contiguous.

[Dietmar]

Hi s4e,

I tried so much different approaches, but always BSOD.

After all the BSODS, I changed the menu.lst to

map (hd0,0)/wdstart.img (hd0)
map (hd0) (hd1)
map --hook
chainloader (hd0,0)+1
rootnoverify (hd0,0)

but with no success. wdstart.img contains exact those files and folders as you described with an identical bootsector as the USB stick. The USB sticks boots alone and the wdstart.img image is also tested.
The USB lamp is blinking at once when the wdstart.img is loaded via grub4dos, but then BSOD.

I also tried to boot a real XP image wdusb.img with grub4dos without any USB.
The drivers from Bootstage1 are loaded but then also BSOD. I think, that booting an image of the NT family with grub4dos
is impossible at the moment (see a comment of jaclaz:"In direct mapping, the image file must be contiguous.

The virtual disk is implemented using INT 13. Therefore, it can be accessed in system that still uses INT 13, such as all kinds of DOS and Windows 9X (compatible mode disk access), and it can't be accessed in system that usesprotected mode drivers, such as Linux, FreeBSD and Windows NT family OSs.
").


But even if it is not possible to boot a complete XP.img via grub4dos, your methode may work, because the Base drivers are loaded but the switching to the real USB disk fails.
At the moment I have no ideas, what else I could try.

Are you sure, that your firewire boot works not in an image of Vmware while Vmware is running?

Nice to hear from you
Dietmar

PS: Please make a try with a real external disk without any Vmware and a raw (real) hardisk image.
The use of contig.exe -a tells me, that my images are in one piece.
And please post your original menu.lst, thank you very much.

This post has been edited by Dietmar: Mar 10 2008, 11:44 AM

[Debian]

eventually sdb1 booted with XP installed.

[jaclaz]

@Debian
Really, you should post something more than one liners, so that people can understand what you want to say.

@Dietmar
Identical bootsector or same signature in the MBR?

The theory behind s4e's suggested method seems correct, I had no time (nor I'll have for the next few days) to test it, but it sounds both reasonable and feasible.

Maybe there is something else that is preventing it from working for you.

Can you confirm that the "other" hard disk (not the image) can boot normally?

This method should work (though of course completely unneeded) also for "standard" IDE hard disks.

I would suggest you to try it with the "XPcli" project, with two identical "hard drives", one in the form of a virtual disk mapped as a HD on the VM and the other one with a smaller sized image file contained within the first.

Say "outer" image 100 Mb, Inner image 25 Mb, and see what happens.

If it works, we can then try troubleshooting the USB issue.

The 0X34 error is "strange", I would have expected a 0x7b one or it was a 0x0000007b <0xF894D640> 0x00000034 one like this?: (numvbeer between <> may vary)

jaclaz

[s4e]

The bootsector must identical or same signature & checksum, signature @0x1b8-0x1bb is a disk identity, checksum is a bootsector identity.

[Dietmar]

Hi all,

some strange things are going on, hihi.
I tried to boot via grub4dos my MiniXP (last one with integrated diskpart, from a FAT32 partition, the underlying XP is also on Fat32).

Again BSOD.
But when I do chainbooting with grub4dos, and hit F8 after grub4dos in boot.ini (means Save Mode for MiniXP),
MiniXP was booted, but then appears a message, that lsass has found a wrong name, and reboots after a few seconds.
This means twice:

Booting an HD-image of the NT family with grub4dos is possible. (I wonder, why Tinybit says, that it is impossible.)

Therfor you have to change the "wrong name", what ever lsass is meaning with that.


Now I make a try with my first MiniXP, because it does not know anything about lsass.exe, because it has none...hihi.

It is possible, that the approach from s4e works for booting any device, that Bios has no knowledge of.

To change the Signature of the MBR, you cant use MbrFix.
This is, because MbrFix only changes the 8 Hexvalues for Signature, but does not correct the checksum of the MBR.
If you use after that from the recoveryconsole of XP fixmbr, the MBR is repaired, but has after a different Signature...grr.

Hi s4e, you description of how to change the Signatur and keep Checksum, isnt all ok.
You wrote, that the other lines have to be identical, but which is the identity: The connected external HD or the MBR of vmdk image?

------------EXTERNAL HD---------------------
0000190: 0000 0000 0000 0000 0000 0000 0000 0000 // ==
00001a0: 0100 07fe 3f02 3f00 0000 04bc 0000 0000 // FF <---\
00001b0: 0000 0000 002c 4463 fd62 7287 0000 8001 // == |
00001c0: 0100 07fe ffff 3f00 0000 828a a112 0000 // EE --\ |
00001d0: 0000 0000 0000 0000 0000 0000 0000 0000 // == | |
00001e0: 0000 0000 0000 0000 0000 0000 0000 0000 // == | |
00001f0: 0000 0000 0000 0000 0000 0000 0000 55aa // == | |
-------------FAKE IMAGE------------------------ | |
0000190: 0000 0000 0000 0000 0000 0000 0000 0000 // == | |
00001a0: 0100 07fe ffff 3f00 0000 828a a112 0000 // EE <-/ |
00001b0: 0000 0000 002c 4463 fd62 7287 0000 8001 // == |
00001c0: 0100 07fe 3f02 3f00 0000 04bc 0000 0000 // FF ----/
00001d0: 0000 0000 0000 0000 0000 0000 0000 0000 // ==
00001e0: 0000 0000 0000 0000 0000 0000 0000 0000 // ==
00001f0: 0000 0000 0000 0000 0000 0000 0000 55aa // ==

Big things are going on,
you will hear from me,

Dietmar

[jaclaz]

Wait a minute, now I am really confused, can we re-start from the beginning, possibly using the proper terms and clarify the matter?

In a normal Hard Disk MBR there is NO such thing as a checksum.

Usually bytes from offset 17B to 1AF are 00's.

Disk signature is 4 bytes 1B8 to 1BB.

In a normal Partition bootsector there is NO disk signature, but rather a Volume Number and NO checksums.

Volume number is in a different position on the bootsector depending if it is FAT16, FAT32 or NTFS.

VMware disk images may be different, but there are a few versions of them, which version was used for this test, (not only the version of VMware, the actual version and type of disk image)?

jaclaz