Raw disk access for VirtualBox on Windows

Quite sensibly, Windows does not permit regular users from accessing disks directly (e.g., opening \\.\PhysicalDrive0 and friends). However, I want to back up data from my VirtualBox VM to a hot-swappable SATA drive, and I don't want to have to run VirtualBox as an administrator in order to do so.

1. Install dskacl and SubInACL.

2. Obtain user account Security Identifier (SID).

   > wmic useraccount get name,sid
   Name      SID
   sam       S-1-5-21-2453977617-3005308618-2945189819-1001

3. Identify target disk.

   > cscript.exe /nologo showdsks.vbs -d
   2;"IDE\DISKWDC_WD1001FALS-00J7B1___________________05.00K05\5&23FBD211&0&1.0.0";512;1953520065;

   The first column is the disk number. It is 2 so this disk can be accessed as \\.\PhysicalDrive2. The second column is the device ID. This uniquely identifies this particular disk.

4. Obtain current Security Descriptor Definition Language (SDDL) string. This is the text representation of the Access Control List (ACL) that determines who is able to perform particular operations on the object. Note that the subinacl command must be run as an Administrator.

   > subinacl /noverbose /file \\.\PhysicalDrive2 /display=sddl
   
   +File \\.\PhysicalDrive2
   /sddl=O:BAG:SYD:(A;;FX;;;WD)(A;;FA;;;SY)(A;;FA;;;BA)(A;;FX;;;RC)
   
   
   Elapsed Time: 00 00:00:00
   Done:        1, Modified        0, Failed        0, Syntax errors        0
   Last Done  : \\.\PhysicalDrive2

5. Use the SDDL reference (in particular the ABNF grammar) to understand the SDDL string. The string above decodes as follows:

   SDDL		meaning	notes
   O:BA		Owned by Builtin Administrators group
   G:SY		Primary Group: Local System	Unused since Windows 2000, but still present for compatibility reasons.
   D:		Discretionary ACL
   	(A;;FX;;;WD)	Allow File Execute for Everyone	The mnemnomic for WD is presumably 'world'
   	(A;;FA;;;SY)	Allow File All Access for Local System
   	(A;;FA;;;BA)	Allow File All Access for Builtin Administrators	This is what we want to grant to our target user
   	(A;;FX;;;RC)	Allow File Execute for Restricted Code	"This SID is used to control access by untrusted code"

   Now, I have no idea what it means to 'execute' a hard disk, but I am pretty sure modifying or removing any of those default entries will at best cause Windows to get rather confused, so let's not touch them. We're just going to add a new Access Control Entry (ACE) for our user to the end of the ACL.
6. Make sure that no partitions on the disk are mounted. If so, go to Computer Management → Disk Management and remove any mount points that any volumes on the disk may have.
7. Using the device ID we obtained earlier, our user account's SID, and our new-found knowledge of SDDL strings, apply a new ACL to the disk. It should not surprise you to find out that you must do this as an Administrator!

   > dskacl -i "IDE\DISKWDC_WD1001FALS-00J7B1___________________05.00K05\5&23FBD211&0&1.0.0" -s "O:BAG:SYD:(A;;FX;;;WD)(A;;FA;;;SY)(A;;FA;;;BA)(A;;FX;;;RC)(A;;FA;;;S-1-5-21-2453977617-3005308618-2945189819-1001)" -r -v
   Looking for disk devices...
   Found: IDE\DISKWDC_WD1001FALS-00J7B1___________________05.00K05\5&23FBD211&0&1.0.0
   Access control list successfully changed!
   Reconnecting device to reload security parameters...
   Done!

   Note that we didn't mention \\.\PhysicalDrive2 anywhere. This is because we haven't actually changed the ACE on the drive itself; we just told Windows to record a new ACE for the drive deep within the bowels of the Registry. Next time the disk is inserted, our modified ACE will be used, granting our user access.

   The the -r option tells Windows to additionally immediately reconnect the disk, causing the ACE to be applied. Hence the need to unmount all the disk's partitions in the previous step!

   Consequently, the modified ACE only applies to this particular disk. Neat!

8. If desired, confirm the new ACE was applied by using subinacl, or WinObj.

9. Create a VMDK file which tells VirtualBox how to access the disk. This can be run as the target user, since it should now have access to the drive.

   VBoxManage internalcommands createrawvmdk -filename d:\sam\downloads\wintermute-backup4.vmdk -rawdisk \\.\PhysicalDrive2

10. Add the disk to the virtual machine. Annoyingly this has to be done with VBoxManage; the scripting interface and the VirtualBox GUI don't permit a VM's storage configuration to be modified while the VM is running.

    VBoxManage storageattach wintermute --storagectl "SATA Controller" --port 9 --type hdd --medium d:\sam\downloads\wintermute-backup4.vmdk

    The disk is now available for use inside the VM.
11. When done with the disk, detach it:

    VBoxManage storageattach wintermute --storagectl "SATA Controller" --port 9 --type hdd --medium none

Bish bash bosh, it works! Whoever said Windows was hard to use?

The Rub

The VMDK file we created is only good until Windows decides to make the disk available under a different name, for instance \\.\PhysicalDrive3. I'm assuming whenever you insert a disk it gets assigned the lowest possible drive number, so if you have several disks on the go, you're likely to get them mixed up at some point.

It's probably best to delete the VMDK file after detaching the disk; attaching a VMDK file that refers to a disk with differing geometry to the one that happens to be currently filling the expected \\.\PhysicalDisk{n} slot is at best going to confuse VirtualBox. At worst it will probably cause massive filesystem corruption. So be careful.

CategoryTechnote