Jump to content











Photo
- - - - -

How to patch FAT32 boot sector


  • Please log in to reply
28 replies to this topic

#1 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 26 July 2009 - 03:30 PM

Hello,

I remember reading an article about patching FAT32 boot sector (by setting 3 or 4 NOPs to the boot sector code) in order to fix MS boot sector code. In U_SET_XP program the wording is "CHS knockout".

I desperately searched using Google/BootLand but could find again this article :-(.
What I need is to know the old binary values to be patched, and the new values (NOPs).

Thank you.

#2 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7101 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 26 July 2009 - 03:34 PM

Here :idea::
http://www.911cd.net...o...1702&st=129

:P

jaclaz

#3 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 26 July 2009 - 03:57 PM

Thank you Master jaclaz for your quick answer !

#4 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7101 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 26 July 2009 - 04:07 PM

Thank you Master jaclaz for your quick answer !


You are welcome.

jaclaz

#5 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 26 July 2009 - 04:12 PM

For the records :

FAT32 boot sector ("MSWIN4.1" or "MSDOS5.0" found starting at address 0x03) :
At address 0xE6, 4 bytes 0x0F, 0x82, 0x4A, 0x00 => patched to 0x90 0x90 0x90 0x90

NTFS boot sector ("NTFS" found starting at address 0x03) :
At address 0xD9, 4 bytes 0x0F, 0x82, 0x3A, 0x00 => patched to 0x90 0x90 0x90 0x90

With this patch, I think I can solve my booting problem with my mp3 player :
http://www.boot-land...?showtopic=8493

Now I will go to experiment with this !

#6 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7101 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 26 July 2009 - 04:26 PM

With this patch, I think I can solve my booting problem with my mp3 player :


I cannot see how it could be related to it.

From what you posted, your only hope is finding a way to have makebootfat (or it's principles, i.e. double or triple use MBR, as tinybit suggested) working.

http://www.boot-land...?showtopic=7507

jaclaz

#7 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 26 July 2009 - 04:50 PM

@jaclaz

The problem is that I cannot use MBR : the mp3 player (= USB key) has only boot sector (in other words either you select under HDHacker boot sector for E: or Physical drive 1, the content is the same).

Originally the mp3 player came with an almost nulled (all zeroes) boot sector (no boot sector code, only the 55AA and few signature bytes at start). After formatting to FAT32 with XP, and patching the boot sector, I still have the "Disk error, Press any key to restart" message. chkdsk gives no problem, and the mp3 player works fot its music functions.

I understand that triple MBR assumes MBR, or in my case no MBR is possible.

#8 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7101 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 26 July 2009 - 06:04 PM

I understand that triple MBR assumes MBR, or in my case no MBR is possible.


Triple MBR assumes nothing.

You are assuming something. :P

The idea is to have some code that LOOKS to the BIOS and Windows as a MBR, but that can ALSO be seen as a bootsector (so that the MP3 thingie will still think it is a bootsector) and NO hidden sectors.
Or, if you prefer, a bootsector that has also partition data and disk signature.

Please try reading the above comparing it with this:

The problem is that I cannot use MBR : the mp3 player (= USB key) has only boot sector (in other words either you select under HDHacker boot sector for E: or Physical drive 1, the content is the same).

Doesn't it look strangely similar? :idea:

What if you actually READ:
http://www.boot-land...?...c=7507&st=5

AND this:
http://www.boot-land...p?showtopic=761

AND links within the latter? :)

Then, once you have got the hang of it, you can start experimenting with either makebootfat or tinybit's solution.

jaclaz

#9 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 26 July 2009 - 06:36 PM

@jaclaz

Thank you for your help. I tried makebootfat using your mkboot.cmd batch file. But as soon as I replug the mp3 player it automatically does a "Memory checking", which results in an automatic reformat of the USB key to factory mode by the player itself. The bootsector is reset to almost null as said previously.

Edit: if I install grub4dos to it, I got "disk error" message too from grub4dos boot code.

So the only boot sector it seems to accept is FAT32 boot sector, but then my BIOS could not boot it (Disk error), even after patching with 4 NOPs as said. So the problem is why the boot sector code cannot read the ntldr on the disk.

#10 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7101 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 26 July 2009 - 06:52 PM

I tried makebootfat using your mkboot.cmd batch file. But as soon as I replug the mp3 player it automatically does a "Memory checking", which results in an automatic reformat of the USB key to factory mode by the player itself. The bootsector is reset to almost null as said previously.

Edit: if I install grub4dos to it, I got "disk error" message too from grub4dos boot code.

So the only boot sector it seems to accept is FAT32 boot sector, but then my BIOS could not boot it (Disk error), even after patching with 4 NOPs as said. So the problem is why the boot sector code cannot read the ntldr on the disk.


NO.
The whole point is NOT that one.

The point is that even if you make it load NTLDR, any Windows NT based system WON'T boot from the stick, as it would miss Disk Signature and thus you won't have a valid arcpath.

Sure makebootfat won't work "as is", but maybe you can manually use it's "short MBR".

  • Format the stick as FAT32 (with NO partitions, as superfloppy).
  • Try using it as MP3. Make sure that the MP3 function does not change anything.
  • Post the bootsector.


jaclaz

#11 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 26 July 2009 - 07:17 PM

@jaclaz

Following are the requested data :
http://www.mediafire.com/?jnfxtwtf2tj

In the zip file:
BootSector_DriveE_YP-U3_original.dat : original boot sector from mp3 player
BootSector_DriveE_YP-U3_ntldr.dat : boot sector after formating with FAT32 (no NOP patch), mp3 player OK, "Disk Error, Press any key to restart" message
BootSector_DriveE_YP-U3_grub4dos.dat : boot sector after formating with FAT32 and grub4dos installed to boot sector, mp3 player OK, "disk error" message

#12 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7101 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 27 July 2009 - 09:51 AM

Got 'em.

I'll have a look and let you know.

jaclaz

#13 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7101 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 29 July 2009 - 07:32 AM

I have now what I presume to be a workable solution.

I still need to make a few tests and find an "easy" way to make you replicate it.

jaclaz

#14 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7101 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 29 July 2009 - 10:52 AM

OK. :P

This should be repeatable.

I am assuming you are already familiar with MBRBATCH/MKIMG batches, if not read here:
http://www.boot-land...?showtopic=3191
http://www.boot-land...?showtopic=5000

Have 'em (and the needed tools for it in a directory on the NTFS partition, say C:\mbrbatch), unxip to it also the mbrfat.bin inside the makebootfat package.

Open a command prompt in it.

Make sure you have the RIGHT \\.\PhysicalDriven for the USB stick.

Let's assume n=2

Run this command, see here for reference: http://www.boot-land...?...c=5000&st=1
dsfo \\.\PHYSICALDRIVE2 0 0 NUL

You should get 1.987.608.064 1.987.575.808 bytes as the size of your stick.

Now run mkimg with these parameters:
Image name: ktptest.img
Image size: 1987608064 1987575808
Geometry: 255/63
Part type: 0B
[ENTER] to use mksparse

In the Explorer window of the mounted drive paste NTLDR, NTDETECT.COM and a BOOT.INI (with at least two entries).

Start tiny hexer:
http://www.boot-land...?...=8296&st=13
(or the hexeditor you prefer).

Load the appropriate \\.\PhysicalDrive for the image.
Save first 512 bytes as freshMBR.DAT
Load the appropriate mounted drive letter.
Save first 512 bytes as freshBS.DAT

Now it comes the "tricky" part. :P

Open freshBS.DAT and save it as moddedBS.DAT.
Patch it with the four NOPs at offset 0xE6, i.e. 0F824A00->90909090
Save moddedBS.DAT.

Open freshMBR.DAT and save it as moddedMBR.DAT.
Open mbrfat.bin.
Copy mbrfat.bin wholly (from 0x00 to 0x01AB) OVER first 428 bytes of moddedMBR.DAT.
Save moddedMBR.DAT.
Copy first 89 bytes of moddedBS.dat (from 0x00 to 0x59 0x58) OVER first 89 bytes of moddedMBR.DAT
Save moddedMBR.DAT.
Open the file you attached before, BootSector_DriveE_YP-U3_original.dat.
Copy the volume label from BootSector_DriveE_YP-U3_original.dat (from 0x47 to 0x52) - 11 bytes OVER same location on BOTH moddedBS.DAT AND moddedMBR.DAT.
Save moddedMBR.DAT.
Save moddedBS.DAT.

Copy moddedMBR.DAT to the \\.\PhysicalDrive for the image, replacing the MBR.
Copy moddedBS.DAT to the mounted drive letter for the image, replacing the bootsector.
Copy again moddedBS.DAT to the mounted drive letter for the image, replacing sector 6, i.e. the backup of the bootsector.

Close Tiny Hexer.

Close the Explorer window opened by MKIMG, go on with MKIMG prompt and uninstall the VDK driver.

Test the image in Qemu (+ Qemu Manager). Note: You may need to run Unlocker on ktptest.img

If it works, clone it over the USB device or repeat the above hex editing directly on the USB device.

Check if the "stupid" MP3 thingy overwrites/modify anything. :P

You owe me a beer. :P (even if it doesn't work :idea:)


:)

jaclaz

#15 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 29 July 2009 - 12:06 PM

@jaclaz

I got this result :

dsfo \\.\physicaldrive1 0 0 nul
\\.\physicaldrive1 - The request could not be performed because of an I/O device error.
This error can probably be ignored.
OK, 1987575808 bytes, 525.625s, MD5 = 40ef7de416254cd4fcea2aab1fb6c57a

Could I continue? Are there any changes in your procedure then?

#16 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7101 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 29 July 2009 - 12:49 PM

@jaclaz

I got this result :

dsfo \\.\physicaldrive1 0 0 nul
\\.\physicaldrive1 - The request could not be performed because of an I/O device error.
This error can probably be ignored.
OK, 1987575808 bytes, 525.625s, MD5 = 40ef7de416254cd4fcea2aab1fb6c57a

Could I continue? Are there any changes in your procedure then?


Please read:

This error can probably be ignored.

as:

This error can definitely be ignored.

The Author of dsfo/dsfi has been overcautious.

About size, yes, it's allright, forgot to point out this. :P

The data in the bootsectors you sent is 3881984 sectors, hence 3.881.984x512=1.987.575.808 :idea:

The 1987608064 I used in my post was an initial "test" size., obtained by adding to the 3.881.984, 63 "hidden sectors", thus 3.881.984+63=3.882.047 and 3.882.047x512=1.987.608.064, that I wrote down in my notes and forgot to correct in the previous post, correcting it now.

You should try with the "right" 1987575808. :P

jaclaz

P.S.: I was forgetting, you are using a French XP, aren't you? :P
Remember to check this:
http://www.boot-land...?...=3191&st=17
http://www.boot-land...?...=3229&st=14
I don't remember having "adjusted" the batch for French punctuation.....:)

#17 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 29 July 2009 - 02:01 PM

@jaclaz

Wow, it took me as an exercise to learn and familiarize a little with TinyHexer.
Correction:
> Copy first 89 bytes of moddedBS.dat (from 0x00 to 0x59)
Should read of course:
Copy first 89 bytes of moddedBS.dat (from 0x00 to 0x58)


> Test the image in Qemu (+ Qemu Manager)
Result: it boots, I saw boot.ini menu!
I have to search for you a fresh beer :-).

> If it works, clone it over the USB device or repeat the above hex editing directly on the USB device
In the real device, the boot sector is physically the same sector as MBR, so how could your above procedure apply?

#18 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7101 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 29 July 2009 - 02:32 PM

In the real device, the boot sector is physically the same sector as MBR, so how could your above procedure apply?


Well, the idea is that the MBR AND the bootsector of the image are the "special" makebootfat mbrfat.bin.

mbrfat.bin works (or should work) this way:
  • it looks like a boot-sector, including the filesystem DATA and initial three bytes jump CODE
  • it works like a MBR

It is UNestablished whether it ALSO works as a bootsector, i.e. if it does also work as as a bootable bootsector on the (few) motherboards that only boot from "super-floppy", but you are in a "normal" situation:
  • your PC boots from a HD like device (and mbrfat.bin is a working MBR CODE, with the specific MBR DATA you supplied by NOT overwriting the last bytes 512-428 bytes of the MBR)
  • your MP3 thingy (hopefully :P) does NOT need bootsector booting CODE, only bootsector DATA on first sector of the device, which also mbrfat.bin undoubtedly provides (the first 89 bytes you supplied)

Of course, it depends on the actual checks the "stupid" MP3 thingy does, if for example it wants the number of "hidden sectors" to be equal to 0, we need to manipulate the data about "reserved sectors" or invent something else. :idea:

Since you are in Tiny Hexer, try the Tools->Structure Viewer-> FAT32 bootsector on the files. :)

Correction:
> Copy first 89 bytes of moddedBS.dat (from 0x00 to 0x59)
Should read of course:
Copy first 89 bytes of moddedBS.dat (from 0x00 to 0x58)

doing it now.

jaclaz

#19 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 29 July 2009 - 03:34 PM

@jaclaz

Unfortunately my last experimentation on real mp3 player was bad: it did "Memory checking" which means reformatting the drive, after applying mkbootfat mbr as indicated above.

I finally give up, since it was only for fun. In practive, the device is too slow (read 5 MB/s), too big vs. real USB key, and if I ever load UBCD4Win on it, it would leave less space for my mp3 files :-).

For information, this mp3 player originally is only equipped with MTP protocol, and not MSC (not USB mass-storage). By changing the firmware it becomes mass-storage device which is easier to handle. Now I am reversing it back to MTP since it supports extra functions like RDS radio station.

Many thanks to jaclaz for your help and guidance. You deserve a second fresh beer :idea: l learned a lot and had fun during experimentation.

#20 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7101 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 29 July 2009 - 03:43 PM

You mean you are giving UP? :P

That is NOT an option! :)

...what's the fun of it? :P

...are you going to tell your nephews:

You see that piece of rusted metal/plastic over the fireplace?
It used to be a MP3 player, I was very near to find a way to hack it in such a way to have it working BOTH as MP3 player and Mass Storage device, but I gave up, I keep it there since it reminds me of my failure at it.


or:

You see that piece of rusted metal/plastic over the fireplace?
It used to be a MP3 player, I was able to find a way to hack it in such a way to have it working BOTH as MP3 player and Mass Storage device, I keep it there since it reminds me of the fun I had at the time devising a way to do it. Pretty much useless, I know, but I did it!


:idea:

jaclaz

#21 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 29 July 2009 - 04:16 PM

Well, there were so many reformats of the device after my many experimentations, each time I have to reload everything, redo all my mp3 player many settings, reupload my mp3 files, so I am really tired of it. And the last straw was the last experimentation patching mkbootfat MBR, it hang TinyHexer so strongly that even explorer.exe hangs, no way to use the taskbar, just Ctrl-Tab. I tried to unplug by force without success. I have to reboot. It was enough for me, at least for today :-).

#22 dencorso

dencorso

    Frequent Member

  • Advanced user
  • 142 posts
  •  
    Brazil

Posted 31 July 2009 - 06:33 AM

Here :idea::
http://www.911cd.net...o...1702&st=129

For what it's worth, here I offer the boot-land community my revised version of Clemens Fruhwirth's KillCHS utility, both compiled and as source code, alongside with Fruhwirth's original code renamed killchs.ori, to help those interested in determining what I added to the code. My revised version can patch the NTFS boot loader and both flavors of the FAT-32 NTLDR boot loader (viz. MSWIN4.1 and MSDOS5.0). It has been compiled with djgpp's gcc 4.10 and runs in the NT-family Windows OSes, in Win 9x/ME and in plain DOS (but CWSDPMI is required).
Usage is simple:
KillCHS <filename.ext>
It will crash, however, if run without providing a filename.
Update (Aug 01, 2009): I've incorporated Icecube's suggestions (in post #24, below) and revised further the code. The new version (1.2) is more user-friendly, and only accepts one parameter, but it'll just complain and do nothing in case none or more are provided in the command line, instead of crashing on none and ignoring all parameters but the first, when more than one is provided.

Attached Files



#23 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7101 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 31 July 2009 - 12:43 PM

It was enough for me, at least for today :-).


Yesterday was already tomorrow. :P

Anyway I re-thought a bit about the matter:

Of course, it depends on the actual checks the "stupid" MP3 thingy does, if for example it wants the number of "hidden sectors" to be equal to 0, we need to manipulate the data about "reserved sectors" or invent something else. :idea:


On a "normal" "superfloppy":
The number of hidden sectors is 0 (zero) as the bootsector is first sector of the disk.
The number of reserved sectors is determined by size of volume and app that formatted it

i.e. in Tiny Hexer "Structure Viewer" (example):
...

Reserved Sectors&#58;			  &#39;0x0020&#39; &#40;32 dec&#41;

...

Hidden sectors&#58;				&#39;0x00000000&#39; &#40;0 dec&#41;

...

On a partitioned drive with 63 hidden sectors the values in the "right" bootsector (the one on sector 63 LBA) are, again in Tiny Hexer:
...

Reserved Sectors&#58;			  &#39;0x0024&#39; &#40;36 dec&#41;

...

Hidden sectors&#58;				&#39;0x0000003F&#39; &#40;63 dec&#41;

...

We copied this latter values on the "fake" bootsector DATA on first sector of disk, and they are actually "wrong", there.

You should try incrementing the "Reserved Sectors" and decrement the "Hidden Sectors" by the offset we created, i.e. 63 or 0x3F.

Thus you will have:
...

Reserved Sectors&#58;			  &#39;0x0063&#39; &#40;99 dec&#41;

...

Hidden sectors&#58;				&#39;0x00000000&#39; &#40;0 dec&#41;

...

When you will feel tomorrow has come, that would be the try to make. :)

@dencorso
Thanks for the app.
I cross-posted it on original thread:
http://www.911cd.net...o...1702&st=241

:P

jaclaz

#24 Icecube

Icecube

    Gold Member

  • Team Reboot
  • 1063 posts
  •  
    Belgium

Posted 31 July 2009 - 01:02 PM

@dencorso
The following code will check if a argv1 exists before continuing.
Also added some more info about what the program does (maybe not complete. I didn't read the topic very carefully).
int main&#40;int argc, char **argv&#41; {



	printf&#40;&#34;\nKillCHS, by Clemens Fruhwirth <clemens@endorphin.org>, 2007.\n\

&#40;revised by dencorso, 2009&#41;.\n\n \

   This program binary patches the FAT32/NTFS boot loader to never ever\n \

   use CHS based indexing again. CHS based access is broken when then\n \

   disk geometry for heads and sectors is different from the one\n \

   stored in the BPB.\n\n&#34;&#41;;



	if&#40;argc < 2&#41; {

		perror&#40;&#34;Usage&#58; killchs <file>\n&#34;&#41;; return 1;

	}



	int fd=open&#40;argv&#91;1&#93;,O_RDWR|O_BINARY&#41;;

	unsigned char buf&#91;512&#93;;
Side note: The source code is also not consistently formatted.

#25 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 31 July 2009 - 04:20 PM

@ktp

To make it bootable you need also:

FAT32 Bootsector - drive-id patch 0x80 at offset 0x40 , after XP format it is 00 and Not bootable

http://www.boot-land...?...5306&st=214

More Info on BootSector patches in Format Stick Section of improved Tutorial
http://www.boot-land...?showtopic=5306

:idea:




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users