Ok, most of you probably know that on NT, there's some "special" filenames you can open, including "\\.\PHYSICALDRIVEx:" and "\\.\x:" to get access to raw disks and partitions. So far so good.
Does anybody know how to figure out which "x:" goes onto which "PHYSICALDRIVEx:", and to list the "x:" mapped on a "PHYSICALDRIVEx:"? This isn't as trivial as it might seem, since on NT a user can map/unmap drives pretty arbitrarily.
QueryDosDevice doesn't really help here, as far as I can tell, since it just shows how the drive maps to a device in the NT device namespace, which win32 can't reach, and doesn't show much anyway.
There's a couple of reasons for wanting to do this. One is for file operations. It's slow having multiple operations going on for a single drive - try doing a file index of two partitions on the same physical drive. But if you have two partitions on two physical drives, you can index them simultaneously at full speed. It would be nice being able to decide which strategy to use instead of asking the user.
Another is finding heads and tails when you plug a couple of large and multi-partitioned external drives into a system which already has a bunch of partitions - this can be a real nightmare :).
And of course I wanted to know this when I was playing with getting my USB stick bootable - I needed to fiddle with the MBR, not the partition bootsector. Ended up having to launch the slow compmgmt.msc , since I couldn't figure it out with code.
Does anybody know how to figure out which "x:" goes onto which "PHYSICALDRIVEx:", and to list the "x:" mapped on a "PHYSICALDRIVEx:"? This isn't as trivial as it might seem, since on NT a user can map/unmap drives pretty arbitrarily.
QueryDosDevice doesn't really help here, as far as I can tell, since it just shows how the drive maps to a device in the NT device namespace, which win32 can't reach, and doesn't show much anyway.
There's a couple of reasons for wanting to do this. One is for file operations. It's slow having multiple operations going on for a single drive - try doing a file index of two partitions on the same physical drive. But if you have two partitions on two physical drives, you can index them simultaneously at full speed. It would be nice being able to decide which strategy to use instead of asking the user.
Another is finding heads and tails when you plug a couple of large and multi-partitioned external drives into a system which already has a bunch of partitions - this can be a real nightmare :).
And of course I wanted to know this when I was playing with getting my USB stick bootable - I needed to fiddle with the MBR, not the partition bootsector. Ended up having to launch the slow compmgmt.msc , since I couldn't figure it out with code.
And of course I wanted to know this when I was playing with getting my USB stick bootable - I needed to fiddle with the MBR, not the partition bootsector. Ended up having to launch the slow compmgmt.msc , since I couldn't figure it out with code.
*nix DD -> Hex Editor -> *nix DD :P
Hi f0dder,
I was under the impression that x: was the disk ordinal which can be obtained by DeviceIoControl using IOCTL_STORAGE_GET_DEVICE_NUMBER.
Edgar
I was under the impression that x: was the disk ordinal which can be obtained by DeviceIoControl using IOCTL_STORAGE_GET_DEVICE_NUMBER.
Edgar
It's a crummy workaround, but I use a free utility called "HP Drive Key Boot Utility" to copy my OS bootloader onto my USB key.
It's got some bugs, such as that if the image you write to the key is really small, it just doesn't bother writing it to the key, but it seems to work as long as the image is >1MB, so I just wrote a quick little program to pad my bootloader with 0s. That could be a problem if you don't want to destroy the disk partitions, though.
Nonetheless, it also let me make a backup image of my key, and I can now test out my bootloader on any computer supporting USB booting, so I was able to ditch floppy booting. It's good enough for me until I decide to risk testing PwnOS booting from harddrive.
I hope that helps.
It's got some bugs, such as that if the image you write to the key is really small, it just doesn't bother writing it to the key, but it seems to work as long as the image is >1MB, so I just wrote a quick little program to pad my bootloader with 0s. That could be a problem if you don't want to destroy the disk partitions, though.
Nonetheless, it also let me make a backup image of my key, and I can now test out my bootloader on any computer supporting USB booting, so I was able to ditch floppy booting. It's good enough for me until I decide to risk testing PwnOS booting from harddrive.
I hope that helps.
Here's an example of using it to find the ordinal of drive D:\
IOCTL_STORAGE_CHECK_VERIFY = 02D4800h
IOCTL_STORAGE_CHECK_VERIFY2 = 02D0800h
IOCTL_STORAGE_MEDIA_REMOVAL = 02D4804h
IOCTL_STORAGE_EJECT_MEDIA = 02D4808h
IOCTL_STORAGE_LOAD_MEDIA = 02D480Ch
IOCTL_STORAGE_LOAD_MEDIA2 = 02D080Ch
IOCTL_STORAGE_RESERVE = 02D4810h
IOCTL_STORAGE_RELEASE = 02D4814h
IOCTL_STORAGE_FIND_NEW_DEVICES = 02D4818h
IOCTL_STORAGE_EJECTION_CONTROL = 02D0940h
IOCTL_STORAGE_MCN_CONTROL = 02D0944h
IOCTL_STORAGE_GET_MEDIA_TYPES = 02D0C00h
IOCTL_STORAGE_GET_MEDIA_TYPES_EX = 02D0C04h
IOCTL_STORAGE_GET_MEDIA_SERIAL_NUMBER = 02D0C10h
IOCTL_STORAGE_GET_HOTPLUG_INFO = 02D0C14h
IOCTL_STORAGE_SET_HOTPLUG_INFO = 02DCC18h
IOCTL_STORAGE_RESET_BUS = 02D5000h
IOCTL_STORAGE_RESET_DEVICE = 02D5004h
IOCTL_STORAGE_BREAK_RESERVATION = 02D5014h
IOCTL_STORAGE_GET_DEVICE_NUMBER = 02D1080h
IOCTL_STORAGE_PREDICT_FAILURE = 02D1100h
IOCTL_STORAGE_QUERY_PROPERTY = 02D1400h
IOCTL_SCSI_PASS_THROUGH = 04D004h
IOCTL_SCSI_MINIPORT = 04D008h
IOCTL_SCSI_GET_INQUIRY_DATA = 04100Ch
IOCTL_SCSI_GET_CAPABILITIES = 041010h
IOCTL_SCSI_PASS_THROUGH_DIRECT = 04D014h
IOCTL_SCSI_GET_ADDRESS = 041018h
IOCTL_SCSI_RESCAN_BUS = 04101Ch
IOCTL_SCSI_GET_DUMP_POINTERS = 041020h
IOCTL_SCSI_FREE_DUMP_POINTERS = 041024h
IOCTL_IDE_PASS_THROUGH = 04D028h
STORAGE_DEVICE_NUMBER STRUCT
DeviceType DD ?
DeviceNumber DD ?
PartitionNumber DD ?
ENDS
DATA SECTION
DrivePath DB "\\.\D:",0
hDrive DD ?
cbReturned DD ?
sdn STORAGE_DEVICE_NUMBER <>
CODE SECTION
Start:
invoke CreateFile,offset DrivePath,0,FILE_SHARE_READ | FILE_SHARE_WRITE,0,OPEN_EXISTING,0,0
mov ,eax
invoke DeviceIoControl,,IOCTL_STORAGE_GET_DEVICE_NUMBER, 0,0, offset sdn, \
SIZEOF STORAGE_DEVICE_NUMBER, offset cbReturned, 0
PrintDec() ; just an output to check on the function
invoke CloseHandle,AFAIK, IOCTL_STORAGE_GET_DEVICE_NUMBER does only work under windows 2000.
Axial: I'm not so worried about limiting to Win2k or newer - 9x support is not an issue at all, since it doesn't support the \\.\ way of opening drives... and the code is mostly for my own use anyway. But if you know another way to do the stuff, shoot :)
The IOCTL stuff seems interesting, I'll check it out when I get back from work. Thanks, donkey.
hackulous: I ended up using some tool too, can't remember if it was HP - certainly wasn't the same brand as my USB key anyway. I'd rather be able to do it myself, though :)
Spook: I have no problem actually accessing the device, the problem is finding out which physical drive a given partition is located on...
The IOCTL stuff seems interesting, I'll check it out when I get back from work. Thanks, donkey.
hackulous: I ended up using some tool too, can't remember if it was HP - certainly wasn't the same brand as my USB key anyway. I'd rather be able to do it myself, though :)
Spook: I have no problem actually accessing the device, the problem is finding out which physical drive a given partition is located on...
9x support is not an issue at all, since it doesn't support the \\.\ way of opening drives...
It doesn't? *confused*
9x support is not an issue at all, since it doesn't support the \\.\ way of opening drives...
It doesn't? *confused*
At least not according to the PlatformSDK...
Hi f0dder,
I had played with DeviceIoControl for possible use in WinExplorer but never got around to using it. The \\.\ method of opening a drive is valid in Win9x as well. But it is not useful except to open vwin32.vxd whose handle can be used with DeviceIoControl and the VWIN32_DIOC_DOS_xxxx control codes. For example you would open the vxd as follows...
invoke CreateFile ,"\\.\vwin32", 0, 0, 0, 0, FILE_FLAG_DELETE_ON_CLOSE, 0
Then use DeviceIoControl to query the device (or write to absolute sectors etc...) of course the only function I was interested in was VWIN32_DIOC_DOS_DRIVEINFO (6) which would give me an analogue to the disk information available in NT based systems. Unfortunately there is little information available on using the INT21 7305h from within Windows so I shelved the effort until some other time.
Edgar
I had played with DeviceIoControl for possible use in WinExplorer but never got around to using it. The \\.\ method of opening a drive is valid in Win9x as well. But it is not useful except to open vwin32.vxd whose handle can be used with DeviceIoControl and the VWIN32_DIOC_DOS_xxxx control codes. For example you would open the vxd as follows...
invoke CreateFile ,"\\.\vwin32", 0, 0, 0, 0, FILE_FLAG_DELETE_ON_CLOSE, 0
Then use DeviceIoControl to query the device (or write to absolute sectors etc...) of course the only function I was interested in was VWIN32_DIOC_DOS_DRIVEINFO (6) which would give me an analogue to the disk information available in NT based systems. Unfortunately there is little information available on using the INT21 7305h from within Windows so I shelved the effort until some other time.
Edgar
Well, sure, you can open VxD's with the \\.\ method - but can you open "\\.\C:" or "\\.\PHYSICALDRIVE1" on win9x that way? - that's what I meant.
No, you can't open \\.\C: or \\.\PhysicalDrive1 on win9x that way. The point about vwin32 is that you can access drives using vwin32. I can't exactly remember how this is done as I've not used win9x in a long while. It's something like after the call to createfile; put the permissions in SI, put the drive number in DL, and put the address of a control block structure into bx then call DeviceIoControl. If I get more time I'll search around and see if I can't find a demo for ya. If you want it to be backwards compatible to win9x, try opening the vwin32 device and check the return value for INVALID_HANDLE_VALUE, if present you should be using \\.\PhysicalDriveN: or \\.\C:
Regards,
Bryant Keller
Regards,
Bryant Keller
I had used the following to try to start up using DeviceIoControl with Win9x but the lack of docs was disconcerting...
http://www.codeguru.com/cpp/w-p/system/misc/article.php/c5765/
Donkey
http://www.codeguru.com/cpp/w-p/system/misc/article.php/c5765/
Donkey