Trying to recover a corrupted .vmdk

[lopuvm]

Hello

Please stay until the end because I'm offering a bounty of .1btc ($100usd ish) on this problem

Foundations:

I have been using a virtualbox vm to run the linux distro kali, I created a 20gb .vmdk hard drive on creation (because I thought .vmdk was virtualbox format) and I've been using that for a few months to do pen testing and some btc mining via a cloud cluster, my host machine is linux mint. For some reason I stored the electrum wallet seeds on the vm in a .txt file.

When installing Kali I set it up as an LVM with LUKS initrd passphrase encryption, by my research in the last few days this works by encrypting files as they're created and doesn't encrypt the whole file system (it does encrypt the whole system but I'm not sure if it works off sectors, individual files, or how..). The kali VM also has a user account and password. I know all the encryption passphrases.

The problem:

I tried to encrypt the VM again through the built in virtualbox tool in the tab for encryption in the VM settings. I set the passphrase and hit encrypt and the process froze at 1% and I had to restart my host (linux mint) Then on reboot of the VM I got an error "no bootable medium found". I started to look around for answers and discovered it's a problem with headers or corruption, around this time is when I found out that virtualbox really prefers .VIM over .vmdk. My bad..

So then I progressed onto looking for solutions. I have found threads detailing .vmdk corruption recovery but most of the methods I have tried haven't worked.

Here are some things I've tried

Gyazo - ef60f26f0c902ef29d387280ec4bd443.png

Gyazo - 1861b09a1afd2f9a4c1ecd539d2d5f30.png

Gyazo - 8e7eb61de610ef832156fa4b3fdf9bef.png ‌(You can see that literally nothing shows up compared to the windows example)

I tried creating a VMware workstation 12 virtual machine which uses a backup of x.vmdk and x-flat.vmdk but upon boot it does .../--\|/--\| (animate that spin) and says No boot filename received .. Operating system not found.

And when I try to mount the .vmdk through the vm settings I get this Error Occurred: Cannot read or parse the partition table on the virtual disk.

I am pretty sure that kali would have used /sda5 as the LUKS encrypted LVM partition, and I just read up on a tool called IMdisk from this post: https://digiforensics.blogspot.com.au/2012/11/no-partition-table-no-problem.html

But I have yet to try it, what interests me more is the HEX browser because maybe I can run the HEX of the (1mb files which a x-flat.vmdk is supposedly made up of?) through a decryptor ..........(please tell me if this is on the right track). I have also just installed ESXi virtual machine in VMware workstation to try and restore the descriptor settings. But I don't know how useful this will be, I mean maybe.

Recreating a missing virtual machine disk descriptor file (1002511) | VMware KB

So yeah. This is where I'm at now, the kali machine had exactly 2btc on it in electrum wallets with a file called gs.txt containing the wallet seeds at /home/ppp/gs.txt

Getting this vm back is quite important to me because it has 90% of my money so.. there's that. I really need a solution, please do not post with negative pointless replies such as I received at virtualbox forums, I mean the replies were fine but sometimes I think, bro, I need help, you're not helping, but oh well. And it's easy for someone else to accept defeat but I really need this, and I'm offering the bounty in case this helps moitivations as I have a feeling it will.

Thank you all, and if you would like to refer me to any professionals I live in Melbourne Australia.

thank you, Nikolaj

[wila]

Hi,

Wait for either Andre or Ulli to help you, they are the main persons here at the forum who can help you with vmdk corruption issues.

I would be careful with others helping out, unless you have a good backup.

First things first is to make sure you have a good backup of your virtual disk before trying to fix it, then supply a list of the files makeing up your VM.

i.e. the output of dir *.* (for Windows), or ls -lisa (for Linux).

Please redirect the command's text output into a file, and attach this file to a reply post.

BTW, just to not create any confusion, according to my calculations 0.05 BTC is approximately usd $50.-

--

Wil

[lopuvm]

I am off to bed but I'll update the bounty to .1btc, it was 4am when I wrote the post and it's now 5am.

Here's the output of ls -lisa in my virtualbox/kali/* folder

Thanks Wil I'll await Andre or Ulli's advice

Nikolaj

[a_p_]

I'd like to help, but in this case I think it's Ulli (continuum‌) who should take a look at that, because he's a data recovery specialist. Since the encryption process froze the host, I think that chances are good that the important files you need can be extracted from the flat file.

According to the file list you posted, the flat.vmdk as well as the descriptor .vmdk file, have an old time stamp!? Not sure if this is a virtual box feature, or whether these files were not even touched, and the issue is caused by some other metadata files.

Anyway, it may help to have a complete file list, including the sub-directories. If kali.vmdk, and kali.vbox* are still unencrypted, then compress/zip these files. and attach them to a reply post.

André

[continuum]

Hi Nikolaj

vmfs-fuse will very likely not help - if I understand right you have a flat.vmdk with a Linux filesystem so your vmfs-fuse command does not really make sense.
vmware-mount also is a sunny weather-tool which probably is not adequate for your task.

Can you please provide the output of
sgdisk -p <flat.vmdk> > results.txt
and also
file <flat.vmdk> > results2.txt
Next I would try
testdisk <flat.vmdk>
But anyway - I suggest that you call me via skype - this type of problems can be solved better with direct contact.
Ulli

[lopuvm]

I have added you on skype and here are those results, I also tried some stuff in testdisk but I wasn't sure which partition table type it was so I tried both Intel and EFI GPT and the results were nothing found for both deep scan and quick scan. But the results from sgdisk look.. promising?

[continuum]

Looks like we just started a long term project :smileyplain: