virtualbox.org

Hi,
I have an inaccessible .vdi hard drive and here is what happened.
My VM (KDE Neon) crashed on Ubuntu host because of insufficient file space. With 'Virtual Media Manager' I tried to move the .vdi hd to another location. That failed because of insufficient space on new location (my fault). After freeing some more space, I found the .vbox config file to be at 0 bytes and .vbox-prev missing some part. Anyway, I could recreate that config file.
The problem is now, that i cannot access my encrypted hard drive anymore. Is there a setting in .vbox for encryption?
This is only a rough description. I hope someone could help me here. Let me know if you need further info. Thanks!

The only hope would be if you had a backup of the VM's .vbox file when the VM was working with the encrypted drive.

There is a key code stored in the .vbox file which works with your password to use the encrypted drive. If that key code is gone from the .vbox file, then the encrypted drive file is dead.

That is quite unfortunate. I don't have a backup of the config file.
In a different thread 'Handling of encryption of individual virtual disks' from 2019-08-23 fth0 brought this to my attention:

fth0 wrote:[..] Additionally, they are kept in RAM inside the VBoxSVC process, which runs in the background while one of the frontends is running (VirtualBox GUI, VBoxManage, ...), and terminates several seconds after the last frontend is terminated.[...]

I can restart a saved session of that VM without entering any password. The screen, mouse, etc. works but I cannot run any program in there. Seems for me, that the memory image is still intact yet not encrypted.
Can one somehow extract keystore info from that image?

holgermw wrote: Can one somehow extract keystore info from that image?

If that was possible then it wouldn't be very effective encryption. In any case the data encryption keys are not stored in any disk image.

If you can start the VM then I recommend running a disk imager from inside the VM, writing the image to a network folder. The image will be unencrypted, because it wasn't written by VirtualBox. You can then create a new VM from it. Now the trick is finding a semi-decent disk imaging app for KDE Linux.

holgermw wrote:I found the .vbox config file to be at 0 bytes and .vbox-prev missing some part. Anyway, I could recreate that config file.

When neither the VirtualBox Manager nor any VM is running, the .vbox and the .vbox-prev files usually have the same content. The KeyId and the KeyStore are stored in the MediaRegistry > HardDisks > HardDisk section and are easily recognizable as such.

What you've quoted from me could be used under special circumstances (at the time I wrote this, at least): If you deleted a VM, but kept the encrypted .vdi file, then the KeyStore was still held in the running VBoxSVC process. As long as the VBoxSVC process was kept running, you could create a new VM, add the encrypted .vdi file to it, and the KeyStore was automatically added to the new .vbox file. Do you have a comparable situation?

mpack wrote:If that was possible then it wouldn't be very effective encryption.

I beg to differ (if I understand you correctly). The KeyStore is encrypted and cannot be regarded as secret information by itself. While VirtualBox saves the KeyStore in the .vbox file, but not in the .vdi file, TrueCrypt/VeraCrypt save the equivalent information in the image header. The security doesn't come from the KeyStore, but from the passphrase in combination with the PBKDF2 algorithm.

I have also seen encryption keys get put in the Virtualbox.xml file for encrypted disks that were not attached to a VM at the time the disk was encrypted. This behavior appears to have been added after it was discovered that a disk not attached to a VM got encrypted by command-line, then the VboxSVC died off before the disk file got attached to a VM, thus losing the encryption key and completely hosing the disk file.

The reference to 'memory':

holgermw wrote:they are kept in RAM inside the VBoxSVC process

refers to the host PC's memory, not the VM's memory, so the key cannot be found in the saved state you can start.

Suffice it to say that an encrypted VM requires careful handling and good backups. From the manual: https://www.virtualbox.org/manual/ch09. ... encryption

Since the DEK is stored as part of the VM configuration file, it is important that it is kept
safe. Losing the DEK means that the data stored in the disk images is lost irrecoverably. Having
complete and up to date backups of all data related to the VM is the responsibility of the user.

The VM configuration file is the .vbox file (and the .vbox-prev file, after the VM has been started a couple of times).

If you don't have the .vbox or .vbox-prev with the encryption key, then you cannot recover data from the encrypted drive.

Thanks for the hint fth0. I think i would have such compatible situation. However, I was testing the .vdi with a new VM and it did not find automatically the KeyStore info. ("FATAL: No bootable medium found! System halted.") Do I have to use specific settings here?
Thanks mpack. I can access the VMs GUI (simple apps, such as clock, weather report, etc.) but I'm not able to run any program inside the VM.
So, I guess...

scottgus1 wrote:[...] If that key code is gone from the .vbox file, then the encrypted drive file is dead.

Also thanks scottgus1. I also checked VirtualBox.xml(-prev), but did not find anything related to encryption.
Certainly, my backup strategy needs to be adjusted...

If you keep the disk file inside the VM's folder with the .vbox file, then back up the whole guest folder, then you'll have the .vbox with the encryption key. A separate .vbox file backup with the encryption key is also a good idea, since occasionally as-yet-undiagnosed glitches happen and the .vbox file doesn't re-write properly.

holgermw wrote:I think i would have such compatible situation. However, I was testing the .vdi with a new VM and it did not find automatically the KeyStore info. ("FATAL: No bootable medium found! System halted.") Do I have to use specific settings here?

Not that I'm aware of, but that doesn't really mean anything. I've just made a few tests in the past.

On one hand, I think the management of encrypted disks in VirtualBox suffers from keeping the KeyStore and the virtual hard disks separate. On the other hand, I'm not so sure who really needs this feature. If security is a concern, I'd use full disk encryption on the host drive(s), so that the virtual hard disks are implicitly encrypted.