From: bilm on 26 May 2010 18:58 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 27 May 2010 23:36 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 28 May 2010 02:21 "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 28 May 2010 03:38 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 29 May 2010 18:00
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 >> >> >> >> |