VM encrypted itself, don't know the password

[erik5678]

Back when Windows 11 was released I tried to encrypt my Windows 10 VM so I could add the TPM, but it failed. Since then I've been running Windows 10, but decided to try the new managedVM.autoAddVTPM = "software" flag when Fusion 12.2.0 was released. It worked and the Windows 11 upgrade tool now only complains about my i7-7700K being unsupported.

Today however when I started Fusion, I got a dialog saying something along the lines of "Encrypting VM" and there was a progress bar. Now I find my Windows 10 VM to be encrypted, and I don't have the password. The password I used when trying to set up encryption before when it failed does not work. Empty password does not work.

I'm not sure what to do now. If I can't remove the encryption from this VM I'm risking losing access to this windows license in the future, and if I restore from a backup of this VM it's going to be old and not have the latest software. The backup is also pre EFI conversion. Is there any way to remove the encryption? It never asks for a password (so far).

[berntrop]

You mention Fusion =>  Have you checked the Apple Keychain for passwords?

See also https://kb.vmware.com/s/article/67634

[erik5678]

I have. There are two passwords stored in there, none of them work for this one.

And since it just encrypted itself out of the blue I never got to provide one either.

[wila · Accepted solution]

Hi,

The popup with "Encrypting VM" is ... weird to say the least.
Was it quick or did it take a while to complete?

If it was fast, then there's a fair chance that it didn't actually encrypt the disks contents.
You can also verify that by checking the actual size of the virtual disk. A fully encrypted VM's disk would be at least the same size as what you set it at. Eg. if your VM has a 60GB virtual disk then it's size would be 60GB as all the data is encrypted, including the empty space.

If it's smaller, then check my article explaining more details about the experimental vTPM feature.

https://www.vimalin.com/blog/what-you-should-know-about-vmwares-experimental-vtpm/

It normally is possible to undo the feature, but it requires more than removing a few lines from the vmx itself.

Hope this helps,
--
Wil

[erik5678]

Hi,

It was quick. Less than 20 seconds.

The disks are not taking up the whole assigned space, so they aren't fully encrypted.

The vTPM article explains it then, but it doesn't explain why this happened severals days after adding the vTPM line to the vmx file. I had rebooted and shut down the VM several times since, but all of a sudden today it did the encryption.

Thanks for the link to the article, now I know what I have to pay attention to going forward 👍🏻

[berntrop]

Very nice article, thank you!

What was VMware thinking to encrypt stuff with a password and then hiding the password from the user.  I think this feature escaped the lab a little too soon.

[YoavL]

I've just encountered the same problem. immediately after adding the line:

managedVM.autoAddVTPM = "software" 

and booting the machine the hard drive got encrypted. I was never prompted to set a password so of course, I don't know the password.

However my machine still boots without asking for encryption password, so I can still use it so far but I can't export it to ovf template and I think I can't copy it either.

Very weird scenario. VMWARE should check this out ASAP since more and more users are losing their data.

[jibunnokage]

Same here... was never prompted for a password for encrypted VM, worked fine for months, just today, prompted for password.

[wila]

@jibunnokage different issue (next time please create your own thread)

You used the Autoaddvtpm experimental feature. Sorry it is me who is confused.. similar subject as another thread.

If I had to guess then you moved your VM and now it won't work anymore (moving it back to the original location might work). But that's just a guess.

See this thread: https://communities.vmware.com/t5/VMware-Workstation-Pro/How-to-remove-managedvm-autoAddVTPM-quot-so... for tips on recovery.

--
Wil

[jibunnokage]

Actually I did NOT move the VM.  After I got your comment, I tested the scenario you suggested.  And yes, that ALSO generated the password prompt.  Fortunately, the VM in question I did not need to keep, it was used for testing, so it was easier to delete and recreate.

As for hijacking the thread, I did not think I was doing that, not my intention, but I see your point.

-Jnk

[erik5678]

My solution was eventually to restore the VM from a backup from before the encryption, clone the disk of the encrypted one using Macrium Reflect, and then restore it to the new unencrypted VM.

I never figured out the encryption password, but as long as the login keychain was unlocked it would boot. If it was not, it would ask for a password. The password was not in the keychain, at least not under any name showing up under vmware, fusion or the name of the VM. There is however a fusion encryption key in there, but no password that can be used to decrypt as far as I can tell.

[jibunnokage]

Same, the real question is why the password prompt when a password is never requested the the point of VM creation/encryption.  The logic of the issue is what is the concern, not the result or recovery.  Clearly having a known good backup, that is accessible (i.e. not encrypted) is key.  But, for enterprise sites where vCenter/ESXi/vSphere is used, the issue should not be as significant.  Transport of VMs, even VMDKs is not an expectation for enterprise sites per se as a one off, outside of VMotion or area storage replication, IMHO.  But where VM Workstation should have that expectation to a limited degree, meaning there is always the possible need to have an transportable VM, say a Live Linux distro for example.  But why you would need explicit encryption for that is a different story. 

The risk is that VMDKs, if not the entire VM, can't be an easy move or copy, and if they are to be password protected after encryption I would expect VM Workstation to have a BRIGHT RED DIALOG WITH FLASHING GREEN LETTERS prompting the user for a password, no?  Ok, so red and green is over dramatic, but not nearly as dramatic as my favorite 'media' VM that has years of iTunes songs collected over 10 years, encrypted and lost due to a stealth password requirement.  Reminds me of the guy that has billions in bitcoin, forgot the password, and he only has like 2 attempts of 10 remaining to guess the password?  Or the bitcoins are lost forever!

[RDPetruska]

---

@jibunnokage wrote:

Ok, so red and green is over dramatic, but not nearly as dramatic as my favorite 'media' VM that has years of iTunes songs collected over 10 years, encrypted and lost due to a stealth password requirement.  Reminds me of the guy that has billions in bitcoin, forgot the password, and he only has like 2 attempts of 10 remaining to guess the password?  Or the bitcoins are lost forever!

---

And this, to me, is the primary reason against digital-only distribution of ANYTHING!  Give me my cassette tapes, LPs, CDs, CD-ROMs, VCR tapes, DVDs, etc.!  If I've bought music, movies, software, games, etc. then I want to retain the ability to use them!

[QMagic]

Okay I must be missing where/how to resolve this issue. 
Looks like this started over a year ago, however, I've not see a fix that actually resolves the issue.
Had to restore system last month and went to Windows 11, had issue with VM not running my Windows 8 & 10 VM's.
Added {  managedVM.autoAddVTPM = "software"  } then VMWare encrypted the VM.

So would someone please kind enough to point me to the solution?

Thanks in advance.

[wila]

Hi,

I've written out the steps here: https://www.reddit.com/r/vmware/comments/qy9wns/comment/hmokzl7/
Let me quote myself from one of my replies...

The steps are basically:

• Create a new VM with a virtual disk of the same size as the encrypted one, make sure it has the same name.

• use the new descriptor file ('MK Win Desktop.vmdk')

• use the old vmdk data files ('MK Win Desktop-s001.vmdk' (001 to 016)

• use the old .vmx file, but remove the lines that start with:

  managedVM.autoAddVTPM

  managedVM.ID

  encryption.encryptedKey

  encryption.keySafe

  encryption.data

If there's no snapshots then you don't need .vmsd (don't copy it in the new vm, delete if there)

Normally also no need for .nvram and .vmxf

That should be all.

As this is one of those type of answers where it is important to get all the details correct, I've just thrown it in a wiki article.
See here: https://wiki.vi-toolkit.com/index.php?title=Fixing_a_VM_that_had_AutoAddVTPM_set

I will update that with whatever detail is still missing.

--
Wil

[syvik]

If you are using VMware 16, here is the solution:

https://www.syvik.com/multidesk/howto.win11.vmware16.en.html

[Technogeezer]

If it is this easy to gain access to an encrypted virtual machine using the "experimental" vTPM of Fusion 12 and Workstation 16, then it's a pretty clear message that the feature should not be used at all.

Care to share details on how you did it?  Or, have you reported this to VMware as a security issue?

[syvik]

I think VMware is aware of this.

It has been fixed in Workstation 17.

You will be prompted to create a password instead of generating a random password.

[jamiljonna]

Not sure why this solution did not pop up here but I just did the following:

1. Created a new custom virtual machine
2. Choose Windows 11 64-bit Arm
3. Leave UEFI Secure Boot unchecked
4. Auto-generate the password and save in keychain
5. Select Use an existing virtual disk
6. Find the useless encrypted VM (for which no password exists); then select Virtual Disk.vmdk
7. Choose Make a copy of the virtual disk

After the copying process the new VM started up right away and worked as expected from the previous stored state.