How to Attach Encrypted vdi to VM in VBox 5.0

[GlobalTommy]

I have encrypted my vdi, then released it from virtual machine and removed from Virtual Media Manager. When re-attaching to virtual machine using GUI it doesn't detect that this vdi is encrypted and makes vdi unusable.

Could someone please help.

Thanks

[mpack]

Are you adding it back into the same VM?

Why did you disconnect the disk from the only VM which knew how to decrypt it?

As to a fix, this is not a feature I have used, but I imagine that the only fix will involve manual editing of the .vbox file to restore the missing encryption flag and encoded decryption key. You will of course need the original VM (the .vbox file) as a reference.

Obviously, the whole point of the decryption feature is that it not be trivially easy to access the disk contents when you don't have the correct decryption key. Correct meaning, knowing the password which matches the encoded password stored in the .vbox file.

[GlobalTommy]

Thanks for your answer.

I want to move my encrypted vdi on a usb stick between different hosts (attach to different vms). I will try your hack and let you know how it went.

Thanks again

[GlobalTommy]

I have tested this and it doesn't work

Even when I replaced the whole virtual machine folder in "VirtualBox VMs"
I was also looking into changing files in the .VirtualBox folder but there was nothing about the encrypted vdi.

So at the moment I can't attach my encrypted vdi to a machine on other host system.

Looks like my only option is to try to lock my guest windows with microsoft bitlocker (try to encrypt the c:\ - system partition).

What's the advantage of using virtual machine encryption over microsoft bitlocker?

If anyone has any ideas on how to attach that encrypted vdi to new host in vbox it would be much appreciated.

Thank you,
Tom

[mpack]

VirtualBox encyryption should give better performance since it is only encrypting virtual image data, not metadata such as the header and block map. It should also be more portable.

The "hack" I mentioned ought to work. Everything VirtualBox knows about a VM is stored in the .vbox file, so it simply isn't possible for it not to work - if done correctly. But, you have provided no supporting information so I can't comment further. If you want me to comment then I'd need a zip containing the original .vbox file and the one you modified.

[GlobalTommy]

Hi,

I think there has to be one more place where virtual box stores data about encrypted drives because the problem occurs only when vdi is removed from "Virtual Media Manager", not when it's just released from virtual machine.

What I want to do is:
- create vm (and vdi in the process)
- encrypt vdi
- release from the vm
- remove from the virtual media manager
- attach vdi to vm
- start vm (and here is the problem: vbox doesn't detect that the vdi is encrypted. Even if I replace the .vbox file to the one with CRYPT/KeyStore with it)

you will find the zip file here: https://www.dropbox.com/s/o0uemu0x6cbmr ... s.zip?dl=0

Thanks for trying to help

[mpack]

I think there has to be one more place where virtual box stores data about encrypted drives because the problem occurs only when vdi is removed from "Virtual Media Manager", not when it's just released from virtual machine.

If "release from virtual machine" just means removing it from the controller - then this is to be expected. The hard disk remains registered, even if not in use. The registration entry gives a place to store metadata about the drive, including encryption status. As long as the drive remains registered, this metadata will be preserved.

Un-registering the drive will lose all metadata, including the encryption status, the file path, normal vs immutable, etc.

The media register is stored in the .VBox file. Whether you manipulate a VM using File|Virtual Media Manager or through the VMs own control panel, makes no difference: the metadata is stored in the same place.

[GlobalTommy]

Thanks mpack for boosting my confidence in this hack.

I tried again and it worked. Then I tried couple more times and it just works!

What I do is after re-attaching vdi to a vm I go to .vbox file and add CRYPT/KeyId and CRYPT/KeyStore properties to just re-attached hard disk.

Now I can move my encrypted vdi between different vm's and hosts - this is great !!!! uuuuuhahahahahahaaa (evil laugh)

thanks for you help,
cheers

[Bobbbbbb]

Please tell me there is a way to move the vdi without having the vbox file. I regularly backup my vdi disks but I do not backup the vbox files. My computer's hard drive failed and I had to get a new hard drive. I've created a new VM and attached the vdi, but when I boot it just says that no os is found.

Please PLEASE tell me I can fix this. One of my VM's literally holds all my companies information(yes laugh at me for being dumb). This is a huge deal for me right now. Please help.

[mpack]

Is your disk encrypted? If not then your question is off topic here. Please start a new topic and provide full details including a VM log file, and whether the old VM used snapshots - and if so, did you back them up too.

In a quick answer to your question: no, the .vbox is not always necessary, but life can get quite hard without it - especially for people who used encryption or snapshots and didn't do full backups of the VM folder.

[Bobbbbbb]

Sorry, Yes the vdi is encrypted. I did not use any snapshots.

It was a normal install of a linux guest on a windows host. I created a new virtualbox instance and encrypted the vdi using the 256bit AES option. I have my backup system backup my vdi's but not the virtualbox settings(vdi images are on a different drive). My os hard drive crapped out so I bought a new disk and nuked the old one. I copied the vdi images from my backups and reinstalled virtualbox and created a new virtualbox instance and choose the option "use existing disk image" and selected the encrypted vdi.

I (wrongly) assumed that since vdi's are like a container for the filesystem that the encryption stuff would be embedded into the vdi, much like an encrypted container in something like truecrypt.

I'm open to any suggestions to recover my vdi data. If this is the wrong thread to seek help on I will start a new thread.

[scottgus1]

nuked the old one

You might be able to recover if the nuke you used was a mere "Hey I don't need this anymore". If you still have the old drive and could possibly get it attached to another system so you can run undelete software, you might be able to find the .vbox file. Small files can be recovered with such software. It may also be able to recover the data by replacing the part of the drive that has failed (perhaps the circuit board) with an exact working twin. Youtube has some good videos on this kind of recovery hack.

If your "nuke" approached more of a real nuke, as in the drive's in the city dump, or it was physically destroyed, then without the key data mentioned earlier in this thread, it sounds like you're down the river.

Small comfort, but for the future, a backup one can't restore isn't a backup.

[mpack]

If you know exactly what the password was then you ought be able to create a new VM with the same name and password and replace the hdd.

If you don't know the password and can't find out then say goodbye to the data. That is after all the whole point of encrypting a drive.

I have to say that I'm amazed that anyone would deliberately corrupt their own drive (i.e. encryption) containing important data without making damn sure that they understood how to undo the damage (i.e. by testing). Still, at least the data is pretty secure now - I guess that part of the plan was a success.

[Bobbbbbb]

If you know exactly what the password was then you ought be able to create a new VM with the same name and password and replace the hdd.

If you don't know the password and can't find out then say goodbye to the data. That is after all the whole point of encrypting a drive.

I have to say that I'm amazed that anyone would deliberately corrupt their own drive (i.e. encryption) containing important data without making damn sure that they understood how to undo the damage (i.e. by testing). Still, at least the data is pretty secure now - I guess that part of the plan was a success.

I DO know the password.

So I should create a new vm where the vm name is the extact same as the old encrypted one. Then encrypted the new vm's vdi with the same password as the old one. Then delete the new vdi and import the old encrypted vdi. Then attach the old encrypted vdi to the new virtual machine?


I have been desperately trying to recover data from the old drive but so far unsuccessfully. Doing a bit of testing myself on a different computer, it looks like that the keystore is salted? If I create a new vm named test, encrypt the vdi with password "test" then open the vbox file I can see the CRYPT/KeyStore. If I then erase that vm and create and identical vm called test and use "test" as the password....the new CRYPT/KeyStore is different.

[mpack]

Then delete the new vdi and import the old encrypted vdi. Then attach the old encrypted vdi to the new virtual machine?

You would need to (a) replace the vdi file, and then (b) edit the .vbox file so that all references to the UUID of the old drive is replaced by references to the old disk UUID (there should be two references: one where the VDI is registered, and the other where it is attached to a disk controller in the VM). VBoxManage showhdinfo may be able to tell you the old VDI's main UUID, if not then CloneVDI will.

If I create a new vm named test, encrypt the vdi with password "test" then open the vbox file I can see the CRYPT/KeyStore. If I then erase that vm and create and identical vm called test and use "test" as the password....the new CRYPT/KeyStore is different.

Well, you'll have to hope that it works anyway, i.e. that the encryption of the password is separate from how the disk image is encrypted. Because if the disk encryption does depend on which VM encrypted it, then we're done here. However, my own guess would be that the password encryption may use the VM UUID as a key, but the password itself is all that's required to decrypt the disk.