Removable Media Bit Options

[online]

Hi, all!

As known Lexar BootIt utility is able to flip removable bit from UFD in order to show it as fixed disk, but unfortunely not for all devices...

http://www.911cd.net/forums//index.php?sho...st&p=103213

http://files.filefront.com/lexar+usb+forma...;/fileinfo.html

http://www.microsoft.com/whdc/archive/usbfaq.mspx

On two UFDs (PHILIPS 512MB and PEAK 8GB) it works great for me and most of all for my motherboard's BIOS, but on two other ones (Transcend 2GB and PEAK 32GB) seems to me there is no way to reach the result (maybe Hitachi Microdrive is a last chance, but I do not think it would work for BIOS issues)...

I had been crazy to discover how and where it does the change on UFD, but without success: is known how this software is able to flip (and to restore it) that removable bit from USB flash drives?
Is that action reproducible with an HEX Editor (for example)?

Every suggestion is veeery appreciated!

[jaclaz]

I had been crazy to discover how and where it does the change on UFD, but without success: is known how this software is able to flip (and to restore it) that removable bit from USB flash drives?
Is that action reproducible with an HEX Editor (for example)?

NO.

The "flippable" bit is in the controller firmware, which is NOT accessible by anything but the specific tool.

And since each chip manufacturer has different ways to access the firmware, and the firmware itself can be at different addresses, it is very unlikely that a "universal" tool can be made.

The only possibility would be to log USB packets sent by the original utility, "decode" them and write a program replicating them.

But of course, if you have the right utility, why bother recreating it from scratch?

A more likely possibility would be a hardware device to be put between the USB port and the USB device behaving at hardware level as a filter and changing on-the-fly the value sent in reply to the OS query, i.e. behaving exactly like the cfadisk.sys or dummydisk.sys do at software level.


jaclaz

[online]

Many thanks for your reply!

But of course, if you have the right utility, why bother recreating it from scratch?

Simple, because that tool seems to work not for "all" devices... and I was looking (hope is the last to die) in a "mimetic/emulative" hardware-way...

behaving exactly like the cfadisk.sys or dummydisk.sys do at software level.

Yep! For me that is almost unbelievable (and I will try it on 2nd machine soon), but installing "cfadisk.sys" on HD (not USB) and restoring a TrueImage backup (from UFD PEAK 8GB) it worked on UFD PEAK 32GB even for a BIOS that tipically refuses almost every request of booting a removable disk (seems it likes fixed disks) if not stricktly served like himself pretends (and where in fact all my previous attempts was failed)...

[online]

I will try it on 2nd machine soon

I am amazed and very pleased: using "cfadisk.sys" and restoring a backup image created from 8GB device to 32GB one then it booted on the main machine and... also on 2nd machine!



Lexar BootIt utility worked fine on my UFD PEAK Xtreme2 200x 8GB (flipping the removable bit at "hardware" level), but not on PEAK Xtreme2 200x 32GB, then I was not able to boot from it... I say 32GB device not booted, nor on the first (AMI/Asus P5B Deluxe) machine neither on the second one (AMI/Asus P5AD2-E Premium).
I noticed that both BIOS like USB devices as Fixed Disks and boot them like a charm, as Removable devices instead the BIOSes pretend so more attentions (max 2GB partition and FAT file system at first, but also Floppy drive contemporarely deactivated and not always a standard bootloader even under PE environments (VistaPE).


Now, really I do not realize how a Windows driver can "positively" influence a BIOS detection (or however function) on the same machine and even on a different machine, but it does!


Btw: furthermore, I noticed that under Hardware properties (booting from 32GB UFD, that is the device which controller's driver was changed with "cfadisk.sys" under SATA Windows) the PEAK manufacturer name is changed in "Hitachi Global Storage Technologies" (please, see the screenshot)... then, that driver write something on the UFD "hardware"... in fact then both BIOSes can handle it as Hard Disk, although if connected under Windows of different machines (then without "cfadisk.sys" installed) it obviously continues to be seen as Removable device (with standard manufacturer name)...

This post has been edited by online: May 26 2008, 02:41 PM

Attached thumbnail(s)

 

[jaclaz]

online,
you are missing the idea of a filter driver, think of it like a keyboard driver, if you have the "proper" national QWERTY keyboard and driver, if you press the W key you type a W, if you have a QZERTY keyboard driver you press the W and you get a Z.

Rest assured, a filter driver does not write anything to hardware.

The device sends:
1) it's real name
2) it's real "removable" status

the filter driver gets this information and (NO MATTER what it gets) sends to the OS:
1) the internal name ( "Hitachi" in this case)
2) the status of "fixed"

Check the article by Anton Bassov illustrating the "other" filter driver dummydisk.sys:
http://www.codeproject.com/KB/system/sovie...ct_hooking.aspx

jaclaz

[online]

Thank you, jaclaz, for your explanation!

Really, even if I did not know the whole background, I imagined how it worked... but the issue for me was another one (or, better, two ones).

1) the same (32GB) UFD, with the same TIB image restored, and without changes of any type, before Hitachi driver installation (under "host" Windows, not under USB Windows) does not boot in any way, but after filter driver installation (only under "host" Windows and only on one machine) then it perfectly boots... even on another machine that never has seen Hitachi driver...

2) if I have not installed Hitachi filter driver on USB Windows, but as said only on "host" Windows, how is it possible that in Hardware properties (running USB Windows with any HDs connected and even on another machine) I (we) can read "Hitachi Global Storage Technologies"? (please, see the previous screenshot on right side)
Who, or better what has written that information... and where... and how?

As said I was (and I am) very amazed about that and when I said "that driver write something on the UFD "hardware"" I meant: >


By the way, and just for my great curiosity about that, if you had an explanation also for that then you instantly will become my personal hero...

[jaclaz]

I am sorry I won't be able to become your personal hero, but I do not think that black (nor "white" for that matter) magic applies to USB devices, and it seems like the only possible explanation for what you report.

Something must have been overlooked in the test you made or in the report.

I would double check if on the second machine does a cfadisk.sys exist....

....then try reading the info on the USB stick with a "low-level" utility, like one of these:
http://www.boot-land.net/forums/?showtopic=4661

jaclaz

This post has been edited by jaclaz: Oct 29 2008, 11:12 AM

[online]

jaclaz, you're right: twice!
I've just found "cfadisk.sys" file in driver folder on that UFD...

Really I just do not know how it stay here, but it is... maybe the first time I misused driver installation (while UFD was plugged... now I tried to replicate the "error" too, but without "success"), however I'm (I was) sure that on UFD I never regularly installed it (> only on SATA drive)...
Then, the "mistery" is solved...



Btw1: I could say I'm still tryng and experimenting (and tiring?), and that I'm managing many drives and many images, etc... etc... and however, really it would be true!

Btw2: thank you so much for your fine reply!