From: bilm on
If you use as guidance the MS DDK example "EnumCD" and/or KB 305184 to
enumerate CD/DVD devices you can get devices other than those that read &
write to actual (physical) optical discs.

Many USB memory sticks include an ISO file that is apparently recognized as
a device in the interface class GUID_DEVINTERFACE_CDROM.
Likewise for virtual drives. I've written hacks that seem to work in
eliminating these from enumeration.

The hack for virtual drives is to use SPDRP_ENUMERATOR_NAME and if it's not
IDE, USB or SBP(firewire) then it doesn't get enumerated. The memory stick
hack is searching the drive for the presence of a file with the dot iso
extension. I don't feel good about either of these.

Can anyone think of something I can use to improve reliability here ?

( GUID_DEVINTERFACE_CDROM is defined in Ntddstor.h )

bilm





From: Uwe Sieber on

I have never seen a USB drive with a fake CDROM whose
data come out of an ISO file present on this drive...

Anyway, so far I have such devices a USB devices only.
So, if the BusType is USB then you can call CM_Get_Parent
to get the USB device, then CM_Get_Child and CM_Get_Sibling
to get all the USB device's childs. One of them is
your CDROM. If you find a DISK too, then it is a USB drive
with DISK + fake CDROM.


Uwe




bilm wrote:
> If you use as guidance the MS DDK example "EnumCD" and/or KB 305184 to
> enumerate CD/DVD devices you can get devices other than those that read &
> write to actual (physical) optical discs.
>
> Many USB memory sticks include an ISO file that is apparently recognized as
> a device in the interface class GUID_DEVINTERFACE_CDROM.
> Likewise for virtual drives. I've written hacks that seem to work in
> eliminating these from enumeration.
>
> The hack for virtual drives is to use SPDRP_ENUMERATOR_NAME and if it's not
> IDE, USB or SBP(firewire) then it doesn't get enumerated. The memory stick
> hack is searching the drive for the presence of a file with the dot iso
> extension. I don't feel good about either of these.
>
> Can anyone think of something I can use to improve reliability here ?
>
> ( GUID_DEVINTERFACE_CDROM is defined in Ntddstor.h )
>
> bilm
>
>
>
>
>
From: Pavel A. on
"Uwe Sieber" <mail(a)uwe-sieber.de> wrote in message
news:86933tFgc5U1(a)mid.individual.net...
>
> I have never seen a USB drive with a fake CDROM whose
data come out of an ISO file present on this drive...

Here is one: www.i-odd.com
But it's virtual CDROM looks as a real one.
There is no way to tell it's fake when its HDD interface (with the iso
file) is turned off.
-- pa

> Anyway, so far I have such devices a USB devices only.
> So, if the BusType is USB then you can call CM_Get_Parent
> to get the USB device, then CM_Get_Child and CM_Get_Sibling
> to get all the USB device's childs. One of them is
> your CDROM. If you find a DISK too, then it is a USB drive
> with DISK + fake CDROM.
>
>
> Uwe
>
>
>
>
> bilm wrote:
>> If you use as guidance the MS DDK example "EnumCD" and/or KB 305184 to
>> enumerate CD/DVD devices you can get devices other than those that read &
>> write to actual (physical) optical discs.
>>
>> Many USB memory sticks include an ISO file that is apparently recognized
>> as
>> a device in the interface class GUID_DEVINTERFACE_CDROM.
>> Likewise for virtual drives. I've written hacks that seem to work in
>> eliminating these from enumeration.
>>
>> The hack for virtual drives is to use SPDRP_ENUMERATOR_NAME and if it's
>> not
>> IDE, USB or SBP(firewire) then it doesn't get enumerated. The memory
>> stick
>> hack is searching the drive for the presence of a file with the dot iso
>> extension. I don't feel good about either of these.
>>
>> Can anyone think of something I can use to improve reliability here ?
>>
>> ( GUID_DEVINTERFACE_CDROM is defined in Ntddstor.h )
>>
>> bilm


From: Uwe Sieber on
Pavel A. wrote:
> "Uwe Sieber" <mail(a)uwe-sieber.de> wrote in message
>>
>> I have never seen a USB drive with a fake CDROM whose
> data come out of an ISO file present on this drive...
>
> Here is one: www.i-odd.com
> But it's virtual CDROM looks as a real one.
> There is no way to tell it's fake when its HDD interface (with the iso
> file) is turned off.

Thanks, I never came across such a device. I had
U3 style flash drives in mind.
And yes, if it is in pure "CD Mode" then the simulation
is perfect. Reading some random data and measuring the
speed might be the final hack. If it is slow then it
is a real drive...


Uwe
From: bilm on
Uwe,

The ISO thing is just a hack. All U3 USB sticks use it but it works with any
USB stick.

For U3s, the applauncher.exe & autorun.inf files are wrapped in an ISO 9660
file and placed in the root directory. When the stick is inserted, Windows
detects the ISO file system, thinks it's a CD/DVD because they're the only
storage that uses it, the autorun.inf file runs and starts up
applauncher.exe (autorun must be enabled).

--- Excerpt from Wikipedia on U3s at http://en.wikipedia.org/wiki/U3
"A U3 flash drive presents itself to the host system as a USB hub with a CD
drive and standard USB mass storage device attached. This configuration
causes Windows disk management to show two drives:
1. A read-only ISO 9660 volume on an emulated CD-ROM drive with an autorun
configuration to execute the U3 LaunchPad, and;
2. A standard flash drive (FAT formatted) that includes a hidden "SYSTEM"
folder with installed applications."
---

The ISO can contain boot code so folks with newer systems can boot their
computer from their USB stick.

You can wrap any program you want within the ISO. As Pavel's example points
out, the hack can be used on any number of devices.

I was hoping for a WinAPI that examines the hardware characteristics of a
drive (not volume information) and reports the USB memory stick as
a disk drive (removable) not a CD-ROM drive. If you can think of one let
me know.

In the meantime I'm going to send a SCSI MMC command ( www.t10.org ) which
only a real CD/DVD drive can respond to correctly. It will make the startup
enumeration slower but that's the price for increased reliability.

By the way, I want to thank you for some posts you sent about device
notification particularly how to use RegisterDeviceNotification. They really
helped clear up the mystery.

Regards,

bilm

"Uwe Sieber" <mail(a)uwe-sieber.de> wrote in message
news:86933tFgc5U1(a)mid.individual.net...
>
> I have never seen a USB drive with a fake CDROM whose
> data come out of an ISO file present on this drive...
>
> Anyway, so far I have such devices a USB devices only.
> So, if the BusType is USB then you can call CM_Get_Parent
> to get the USB device, then CM_Get_Child and CM_Get_Sibling
> to get all the USB device's childs. One of them is
> your CDROM. If you find a DISK too, then it is a USB drive
> with DISK + fake CDROM.
>
>
> Uwe
>
>
>
>
> bilm wrote:
>> If you use as guidance the MS DDK example "EnumCD" and/or KB 305184 to
>> enumerate CD/DVD devices you can get devices other than those that read &
>> write to actual (physical) optical discs.
>>
>> Many USB memory sticks include an ISO file that is apparently recognized
>> as
>> a device in the interface class GUID_DEVINTERFACE_CDROM.
>> Likewise for virtual drives. I've written hacks that seem to work in
>> eliminating these from enumeration.
>>
>> The hack for virtual drives is to use SPDRP_ENUMERATOR_NAME and if it's
>> not
>> IDE, USB or SBP(firewire) then it doesn't get enumerated. The memory
>> stick
>> hack is searching the drive for the presence of a file with the dot iso
>> extension. I don't feel good about either of these.
>>
>> Can anyone think of something I can use to improve reliability here ?
>>
>> ( GUID_DEVINTERFACE_CDROM is defined in Ntddstor.h )
>>
>> bilm
>>
>>
>>
>>