20 replies to this topic

[mr_]

There are claims that FAT is the most compatible file system, followed by FAT 32, followed by NTFS. Is this a myth or is there evidence?

On http://www.goodells.net/multiboot/ it will be explained that the MBR is the first sector on a harddisk. (LBA Sector 0 on IBM compatible computer). The BIOS will load the boot code and jump into it. The boot code in the MBR is just a dumb application (not os specific!) looking for the active partition and chainloading the volume boot record.

How can the file system (FAT, FAT32, NTFS, ext2 or whatever) be relevant for the BIOS?

In order to get an operating system on USB booting on as many motherboards as possible... What can be done? As workarround can be used PLoP Bootmanager and Kicker Disk's specific to the operating system.

But beside this? The bootloader or better said the MBR / VBR is important?

We can choose between many different bootloaders, most have a different MBR. There is also makebootfat with USB multi "standard" booting.

Which method will provide best USB booting compatibility? Is it makebootfat? Is there a research / comparison on that?

[was_jaclaz]

All the "trick" is in the BIOS.

Knowing what the heck is written in the BIOS code may give a final answer.

A BIOS may just as an example:

• check for a given Partition type ID
• use CHS only and NOT LBA ( ignoring partition type specific type of addressing)
• use LBA only and NOT CHS (ignoring partition type specific type of addressing)
• use int13H or not
• whatever else

FAQ #10 here:
http://home.graffiti...SB/USBfaqs.html
lists some of these experiences.

Here you can find a possible explanation of why the HP USB formatting utility may have an advantage over a "standard" MBR:
http://www.boot-land...?...=2246&st=15

The most "compatible" thing from summing the various experiences and reports appears to be:

• having a FAT16 partition, CHS mapped (06) but with "balanced" data in the LBA part
• partition being <504/528 Mb as to fall within the first CHS limit:
  http://www.storagere.../sizeMB504.html
• having a MBR CODE with int13h disabled
• having the possibility to change the partition type from 06 to 0E and viceversa

The makebootfat "special" MBR should only be needed for the (very few) BIOSes that lack the capability to boot from a HD-like device (i.e. that can only boot from "super-floppy" or "ZIP disk"), though there are not enough reports to judge whether it could represent the one-size-fits-all solution that theoretically could be.

Please note that at the moment there is no known solution for actually booting a NT based system from a device that is seen by BIOS as "super-floppy", in these cases one needs to use the "XP Kansas City Shuffle" or "Fake Signature" method.

jaclaz

[cdob]

There are some strange BIOS out there.

Ignore MBR Boot code.
Read fourth partition entry and boot this partition.
http://www.boot-land...?showtopic=4863

http://ftp.nluug.nl/...ot/makeboot.txt

-Z, --zip
If possible force the ZIP-Disk compatibility. It sets a geometry of 32 sectors and 64 heads. It also uses the 4'th partition entry in the partition table.

Another example:
Given a MBR USB stick, hence similar to a hard disk.
BIOS boot from MBR USB stick and map USB stick to (fd0), hence a superfloppy.

I've no solution for these strange BIOS to boot NT based system direct.

I'm used to grub4dos at MBR and syslinux to partition boot code.
Boot grub4dos first. And change to syslinux for some proposes, like UBCD.

Please note that at the moment there is no known solution for actually booting a NT based system from a device that is seen by BIOS as "super-floppy"

Thanks, this answer an not asked question.
Do you have a idea? Maybe adjust boot code: Media Descriptor, Drive ID or hidden sectors?

in these cases one needs to use the "XP Kansas City Shuffle" or "Fake Signature" method.

Yes, this works.

[was_jaclaz]

Do you have a idea? Maybe adjust boot code: Media Descriptor, Drive ID or hidden sectors?

That would be a good topic for research.
In a bootsector we have
(data gathered from various pages on the Starman's Realm):
http://thestarman.pcministry.com/
http://mirror.href.com/thestarman/
and from here:
http://averstak.trip...dox/bootsec.htm

HD:

15h	Byte	F8	"Fixed Disk"	 Media Descriptor ID

FD:

15h	Byte	F0	=>	Media Descriptor Byte: F0 essentially means 'Not

					identifiable' (this byte is more for telling the

					OS whether or not the media is a hard disk or a

					floppy disk rather than its exact size).  An F8

					byte means a 'Fixed Disk' (hard drive); only a

					few other bytes have ever been used here.*



* FF=DS,8 SPT; FE=SS,8 SPT; FD=DS, 9 SPT (the 360kb diskette);

   FC=SS,9 SPT; F9 = DS,9 SPT (a 720kb) or DS,15 SPT.  Apparently the fact

   that F9 could mean either of these, signaled the end of its usefulness!

Value	DOS version	Meaning

FF	1.1	5 1/4 floppy, 320KB

FE	1.0	5 1/4 floppy, 160KB

FD	2.0	5 1/4 floppy, 360KB

FC	2.0	5 1/4 floppy, 180KB

F9	3.0	5 1/4 floppy, 1.2MB

F9	3.2	3 1/2 floppy, 720KB

F8	2.0	Any Hard Drive

F0	3.3	3 1/2 floppy, 1.44MB

HD:

FAT16:

24h	Byte	80	128 (First HD)	 Physical Disk Drive ID

FAT32:

40h	Byte	80	128 (First HD)	 Physical Disk Drive ID



FD:

FAT12 (Read FAT16):

24h	Byte	00	00 (First Floppy)	 Floppy Disk Drive ID

FAT32 (theoretical):

40h	Byte	00	00 (First Floppy)	 Floppy Disk Drive ID

About the apparent (please read substantial ) stupidity of changing the Address for SAME data, see here:
http://homepages.tes...ystem-type.html

Unfortunately, due to a very poor piece of design on Microsoft's and IBM's parts, the signature fields of the various types of BPB are not in the same place. So the signature byte in one kind of BPB is an entirely different field in another kind of BPB. Furthermore, there is no magic number to indicate that a boot block even has a BPB at all. (No, the 0xAA55 signature at offset 0x1FE does not perform this function, because (a) it also occurs in MBRs, and ( too many filesystem creation utilities omit it when creating volume boot records. The "OEM name" field, whose handling by Linux and by various Microsoft operating systems is a design disaster in its own right1, does not perform this function, either.)

These have the unfortunate consequences that it is harder than it need have been to determine whether a BPB exists in a boot block and what type of BPB it is.

(Design tips that can be learned from this mess: For variant records, always locate your signature fields at the same byte offset into the record. Where a variant record can also be absent entirely, include some kind of additional signature, such as magic number that is at least 32 bits wide or a pair of record length and record checksum fields, to indicate the mere presence of the record.)

other apparent (and substantial ) various stupidities, read here:
http://homepages.tes...fat-widths.html
http://homepages.tes...name-field.html
http://web.archive.o...5/rk20_dsk.mspx
http://support.micro...kb/148637/en-us
http://homepages.tes...eter-block.html
Just for the record, some reports/hints about using makebootfat switches can be found here (a little more "expanded" trhan original readme file):
http://www.911cd.net...o...13784&st=44


A good source for various versions/releases of bootsectors - disassembled and commented:
http://www.supervinx.com/Download.html

Hidden sectors should NOT be a problem, they can be set to any value, as long as it is compliant with the actual position of the appropriate sectors, I remember DOS era floppy protection scheme based on hiding some sectors, but again, due to the different implementations and wrong, partial, or deviated assumptions this bootsector field is constellated with, it is well possible that "something" checks this field to be 0 to check the media type (floppy)
http://mirror.href.c...mbr/MSWIN41.htm

" Count of hidden sectors preceding the partition that contains this FAT volume. This field is generally only relevant for media visible on interrupt 0x13. This field should always be zero on media that are not partitioned. Exactly what value is appropriate is operating system specific."

HD ( FAT12/FAT16/FAT32):

1Ch	Double Word	0000003F	63	 Number of Hidden Sectors (Cyl=0 Head=0) for the first partition



FD:

1Ch	Double Word	00000000	00	 Number of Hidden Sectors always 0 on standard floppies

The bytes from offsets 1Ch through 1Fh are a Double-Word containing the 'Number of Hidden Sectors.' Practically every floppy diskette you'll ever see will only have zeros here; as will the next four bytes (offsets 20h through 23h), another Double-Word, used in DOS versions 3 (and above) for disk partitions having more than 65,535 sectors! And if that's the case, then the bytes at offsets 13h-14h must be zero.

jaclaz

[mr_]

Knowing what the heck is written in the BIOS code may give a final answer.

Right now that code has never been leaked?

[MedEvil]

Right now that code has never been leaked?

[mr_]

What is so funny about it?

To be honest, this was a serious question. The source code for some versions of MS-DOS and some source code of Windows has been leaked. I think, if to much people are working on whatever then secrets will leak, it's almost a physical law.

So if this was leaked, why it should be impossible that some legacy BIOS code has been leaked? Now after people are working on "more Open" BIOS it would be logical that access to legacy BIOS source code will spread, well hopefully.

[MedEvil]

To be honest, this was a serious question.

Sorry mr_, but you crack me up.
You make such a wave and then you post stuff like that. Just couldn't help myself.

The point jaclaz was trying to make, was that there is no such thing as 1 BIOS. Every motherboard has it's own and even those differ depending on the version .

So if one would know, what is written in this specific BIOS, you're using to boot from USB, then one would know how to prepare the Stick to make it work.

[ispy]

Fake it baby fake it!

The execution is building a fake hard drive image, with the same signature as the external hard drive. After boot stage1, Windows matches the external hard drive's signature against boot loader information, and presumes the external hard drive is the boot disk, and continue boot stage2.

All you need is grub4dos, VMWare, and contig.exe. Here is the method:

1. Throw external hard drive 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 files from external hard drive to VMDK partition:

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 the first 0x1be bytes of the bootsector from external hard drive to *-flat.vmdk.
6. Change bytes from 0x1b0 - 0x1be, make the VMDK have the same MBR checksum as external hard drive.The MBR checksum is sum of 128 ULONG value.
7. Load this VMDK from GRUB4DOS:

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

Here is the same signature and checksum for two bootsectors:

-----------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 hard drive bootsect to Fake Image,
copy line mark FF from Fake Image to External hard drive bootsect,
make other lines identical.

The files under SYSTEM32\Drivers are:

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
&

N-Joy.sys (Just Kidding ya!)

ispy

[mr_]

The point jaclaz was trying to make, was that there is no such thing as 1 BIOS. Every motherboard has it's own and even those differ depending on the version .

I understand that but I still guess many code will be shared.

So if one would know, what is written in this specific BIOS, you're using to boot from USB, then one would know how to prepare the Stick to make it work.

Got it...

But what's wrong with asking if 1 of them has been leaked?

[MedEvil]

But what's wrong with asking if 1 of them has been leaked?

Nothing, except that all have been 'leaked'.
BIOS are not compiled or at least they weren't, they are written the way you can download them.

So in essence, you have the sourcecode, just that it's assembler sourcecode.

[mr_]

I found some source code (looks real, including comments) from award 1999 but it seams the bios menu hadn't any USB options at this time. It's an interesting read.

You are right, the source is not compiled, it's assembled, but imho this is a bit of a word game.

[was_jaclaz]

Right now that code has never been leaked?

YES.
http://homepages.tes...no-answers.html

But what's wrong with asking if 1 of them has been leaked?

Simply it wouldn't be legal to use it.

Instead of losing time in something that is morally wrong and possibly illegal, why don't you employ your time and capabilities in an opensource loadable BIOS?
http://www.openfirmw...ome_to_OpenBIOS
http://www.coreboot....ome_to_coreboot
http://aebios.com/


@ispy
What is the point of copying and paste some info, partial, incomplete, outdated, without even citing where you got them from?
For the record:
http://www.911cd.net...showtopic=21242
There are links in the thread for signature checksum programs and also to batches and programs to ease or automate the build.

jaclaz

[mr_]

Simply it wouldn't be legal to use it.

What's illegal while reading source code?

Instead of losing time in something that is morally wrong

Everyone has another moral, for example I think it's morally wrong not to hide source code. So we better don't talk about moral.

and possibly illegal,

It's trivial to prove that killing someone else is not legal and you get sued, you can read this all time in newspapers and judgements.

Also it's questionable which laws we need to care here. Probable the valid ones for me, for the server location and admin's location. Everything is illegal somewhere, but this doesn't prevent me to live without being afraid.

Can you prove that someone got sued for reading source code? I think this will be hard, therefore this discussion about legality is very theoretical.

I could understand your objection if it's about writing a BIOS competitor, but that's here really not the case.

why don't you employ your time and capabilities in an opensource loadable BIOS?

It doesn't help with existing motherboards. If the time has come (if at any time) and it's better I like to pay a surcharge for it.

[was_jaclaz]

BIOS source code is not a book you read for entertainment, unless you have a very queer idea of what fun is, the only reason would be to write and use a new BIOS.

Having read a leaked source may become a problem for the result, read all the problems ReactOS and Samba guys went through.

It doesn't help with existing motherboards.

Well, why not?
You can allright write a new BIOS for your old motherboard, I guess any moterboard still working has a flashable chip, and in any case there are EPROM and EEPROM programmers.

To possibly clear the matter a bit, a BIOS has some "standard" code that is the same for every motherboard/chipset and some "specific" code that is peculliar to a given motherboard/chipset/supported buses/supported processors, but since someone wrote it, it is possible to write a replacement for it.

That is what the guys at coreboot.org are trying to do, adding support to a large number of chipsets and MB, currently around 200:
http://www.coreboot....ed_Motherboards
some of which are really oldish ones...

jaclaz

[mr_]

BIOS source code is not a book you read for entertainment, unless you have a very queer idea of what fun is,

Wasn't the leaked Windwos source code fun?
http://www.kuro5hin....2/15/71552/7795

the only reason would be to write and use a new BIOS.

Or to understand booting?

Having read a leaked source may become a problem for the result, read all the problems ReactOS and Samba guys went through.

Of course reading the Windows source code and admitting it when writing a Windows clone/alternative is dumb. Copying is clearly illegal.

There is still nothing wrong with the reading alone.

Well, why not?
You can allright write a new BIOS for your old motherboard, I guess any moterboard still working has a flashable chip, and in any case there are EPROM and EEPROM programmers.

To possibly clear the matter a bit, a BIOS has some "standard" code that is the same for every motherboard/chipset and some "specific" code that is peculliar to a given motherboard/chipset/supported buses/supported processors, but since someone wrote it, it is possible to write a replacement for it.

That is what the guys at coreboot.org are trying to do, adding support to a large number of chipsets and MB, currently around 200:
http://www.coreboot....ed_Motherboards
some of which are really oldish ones...

jaclaz

Well, now in order to to fix/understand booting there are two options.

Either try understanding what is written in legacy bios and to adjust or to spend years with programming a full bios replacment for every computer I want this (which is a hell lot of work and will introduce more problems then it solves, perhaps also creates new of the addressed and scared legal problems). Fot me the latter is definitive only a theoretically option.

[was_jaclaz]

Either try understanding what is written in legacy bios ....

You still appear to be missing the point that ANY "legacy" BIOS is anyway "board/chipset" specific, so you would need to find the leaked source of the specific BIOS for your board.....

jaclaz

[mr_]

You still appear to be missing the point that ANY "legacy" BIOS is anyway "board/chipset" specific, so you would need to find the leaked source of the specific BIOS for your board.....

jaclaz

No, I think I got the point.

Some part of the BIOS is generic and code that is being reused, the other part is specific.

There is no indication that USB booting is a part of the specific code. I think the whole USB support is inside the generic part, and how to read harddisks also.

But true, there might be several revisions of that code which wouldn't make things better.

[was_jaclaz]

There is no indication that USB booting is a part of the specific code. I think the whole USB support is inside the generic part, and how to read harddisks also.

Actually, no, since there are, besides diffrent chips, different "kinds" of chips (read OHCI, UHCI, EHCI) USB support is strictly "specific".

jaclaz

[mr_]

Actually, no, since there are, besides diffrent chips, different "kinds" of chips (read OHCI, UHCI, EHCI) USB support is strictly "specific".

jaclaz

The support for the chip my be specific, but
OHCI - USB 1.0
UHCI - USB 1.1
EHCI - USB 2.0...

For example EHCI should contain a lot of generic code as it's a specification.

Only because some USB chip needs another driver (speciric) I see no reason why the harddisk should be read in another manner (generic for a lot builds).

[was_jaclaz]

Yep, what I mean is that a "base" BIOS, say, by "Award", is modified by, say, "Asus", to support a given "kind" of chip "Asus" is using on the specific motherboard hardware, say OHCI.

So, ONLY the "generic" code for OHCI is added to the "base" bios. (NO code for EHCI or for UHCI)

Then, due to particularities in the actual USB chip, bus, northbridge, southbridge or whatever_bridge on the motherboard, the "generic" OHCI code maybe further modified/patched/tuned for the specific board.

So you need at least TWO "leaked" BIOS for two differents "kinds" of of chip, to find out which part changes between UHCI, OHCI, EHCI, but you cannot say if all the changes are just due to the different "kind" of chip or if they are due to the different chips.

On the other hand, (IF USB boot/support is working/implemented ) finding "sets" to be compared between some two hundred BIOS:
http://www.coreboot....ed_Motherboards
and having access to the documentation:
http://www.coreboot.org/Documentation

might be easier...

jaclaz