Recovering data fro...
 
Notifications
Clear all

[Solved] Recovering data from a corrupted but decrypted Bitlocker-drive

24 Posts
4 Users
0 Likes
7,427 Views
passcodeunlock
(@passcodeunlock)
Posts: 792
Prominent Member
 

If you still have the original image files of the 2 bitlocker partitions, the next thing you should try is to run dislocker under linux, use the recovery keys and after successful open, create another image of the decrypted partition. Then you can run any kind of NTFS repair tools to fix the MFT, if needed.

 
Posted : 14/10/2020 6:15 am
(@rich2005)
Posts: 536
Honorable Member
 
Posted by: @jaclaz

For next time CHKDSK should NOT be run that way (no matter in how many places you read that you can run it with all those switches).

It should be run this way (three times, with the last one with the /R only if really-really needed):

1) CHKDSK
2) CHKDSK /F
3) CHKDSK /R

I'm curious - what's your reasoning behind this?

 
Posted : 14/10/2020 8:22 am
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 
Posted by: @rich2005

I'm curious - what's your reasoning behind this?

CHKDSK (without parameters) is read only, but in reality it usually already fixes very minor issues with the filesystem (it doesn't - or at least never did in my experience - "damage" the filesystem). Besides it usually runs very fast and provides a minimal report (suggesting - if needed - to run it again with the /F parameter).

CHKDSK /F is the "real thing" and actually (hopefully) fixes the filesystem in most cases, and it takes (of course it depends) a not-so-long time. 

CHKDSK /R (the /R implies /F, so /F /R makes no sense) will - besides attempting to fix the filesystem as above - check each and every sector on disk (and it will take *forever*)[1].

Layman example, in the morning your car doesn't start, suggested procedure:

1) check that the battery is properly connected, if needed tighten the terminals
2) check that the starter engine terminals are fine, check that battery is charged, replace battery if not, check fuses
3) disassemble each and every piece, mechanical and electrical in the engine and transmission, clean it and reassemble it 

Vs.

1) disassemble each and every piece, mechanical and electrical in the engine and transmission, clean it and reassemble it

jaclaz

[1] BTW, even if in some cases /R works where /F was not enough, given the nature of modern hard disk controllers it is rare that a sector "goes bad" and the disk controller does not automatically re-map it to a spare sector

 
Posted : 14/10/2020 9:47 am
(@deady1000)
Posts: 12
Active Member
Topic starter
 
Posted by: @passcodeunlock

If you still have the original image files of the 2 bitlocker partitions, the next thing you should try is to run dislocker under linux, use the recovery keys and after successful open, create another image of the decrypted partition. Then you can run any kind of NTFS repair tools to fix the MFT, if needed.

I tried this with both partitions but Dislocker gives this error:

"[CRITICAL] Cannot parse volume header. Abort."

I double-checked the command, parameters and recovery-password.

Dislocker has just the same problems as Windows Bitlocker, but nice try.

 

The disks have been decrypted via repair-bde again now and I'm running a full-scan with DMDE. After that I'll try File Scavenger, ZarX and GetDataBackPro. I think I just need to do it the hard way with the partition that contains video-files. I'll have to recover them without paths and filenames. (Which really sucks.)

 

But for the other partition that would be almost impossible.

There are many *.exe-Files and enumerated *.bin-Files which all need to be in the same folder to work and I can't distinguish them via filesize. Another problem is that it is still shown as Bitlocker drive but it should in fact be decrypted (most likely 100%). So I need to delete that Bitlocker-information so that CHKDSK can run over and hopefully repair it.

 

Is there a way?

 
Posted : 14/10/2020 9:36 pm
(@deady1000)
Posts: 12
Active Member
Topic starter
 

Little breakthrough here!

 

I used GetDataBackPro and just did a simple Level1-scan (of 4) of the original bitlocker-partition with the video-files. Something amazing happened. GetDataBackPro is able to open that bitlocker-partition (it just tries it) and can even read the original Master-File-Table (MFT). In GetDataBackPro I can see all the folders and video-files with filenames. I can also COPY the MFT and save it to my desktop.

So I did the same thing and opened the 'repair-bde' partition with GetDataBackPro and there I can see, like in other programs a very few correct video files but less than 10% BUT ALSO it shows me the MFT. So I also copied that to my desktop.

When I compare both MFT-files it becomes interesting.

*Check the picture at the end of the post*

So I am assuming that the bde-repair just tried to decrypt the MFT aswell but that is the main problem and it shouldn't have.

 

Now my idea, since both MFTs have the same size. Can I just use WinHex to overwrite the Hex of the MFT on the 'decrypted' drive so that it actually can read it? I think I should give that a try right?

 

Check this out:

bde-repair MFT:
CAPTURE 15.10.2020 00:12:19
File Details
Name:$MFT
ID:1
No:0
ParentNo:5
Allocation:MftEntry
Properties:FILE
Size:3,00 MB
Last modified:05.03.2019 00:48:46
Created:05.03.2019 00:48:46
Last accessed:05.03.2019 00:48:46
Attributes:___sh__
Type:FILE
First cluster:00000003
First sector:6.442.450.584
Resident:False
MFT#:0x0 (0)
Parent MFT#:0x5 (5)
MFT sectors @6.442.450.584(2)

original MFT:
CAPTURE 15.10.2020 00:13:05
File Details
Name:$MFT
ID:1
No:0
ParentNo:5
Allocation:MftEntry
Properties:FILE
Size:3,00 MB
Last modified:05.03.2019 00:48:46
Created:05.03.2019 00:48:46
Last accessed:05.03.2019 00:48:46
Attributes:___sh__
Type:FILE
First cluster:00000003
First sector:6.442.450.584
Resident:False
MFT#:0x0 (0)
Parent MFT#:0x5 (5)
MFT sectors @6.442.450.584(2)

 

 

 

 

EDIT:
It seems to work. After overwriting the MFT I can see every file and Windows does too.

Running CHKDSK now to clean up.

This post was modified 3 years ago by deady1000
 
Posted : 14/10/2020 10:36 pm
passcodeunlock
(@passcodeunlock)
Posts: 792
Prominent Member
 

Before anything, make an image of the decrypted volume as it is, chkdsk might do more mess then good, then you can start digging again...

 
Posted : 15/10/2020 6:03 am
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Very good, so the BDE-REPAIR somehow didn't sense that the $MFT was already decrypted by the previous (interrupted) operation and re-decrypted it (in practice encrypting it).

No idea if this is the case, but it is possible (it would make sense) that when decrypting a volume "normal" bitlocker starts from the $MFT and other NTFS "internal" files and only once they are decrypted starts decrypting files.

If this is the case, the interrupted operation would result in all the metadata valid but possibly some files still encrypted.

But if the BDE-REPAIR does an unconditional decryption, than those files that were still encrypted will result unencrypted after the BDE-REPAIR, so their extents (decrypted) can be recovered from the "other" image and viceversa.

It will probably need some patience and attention, but most probably you can combine the two images also for these files (if any).

jaclaz

 
Posted : 15/10/2020 5:07 pm
(@deady1000)
Posts: 12
Active Member
Topic starter
 

Guys, it's working!!

 

Again, I started GetDataBack Pro on the first original partition and I was able to extract the MFTs (some corrupted and also some in very good condition). In the program I could already see the folder structures and all my files/folders. I saved all the MFTs the program could find and checked them with HxD (hex-editior). Some looked very promising. I tried to recover some files via GetDataBack Pro and tested them and they WORK 100%.

It's really funny that GetDataBack Pro is like the only program that will try to read a partition that claims to be bitlocker-encrypted. With other programs I had big problems to scan this partition in the first place. Since the files are technically not encrypted it is easy for the program to 'rescue' them.

 

Today I got another 8TB HDD and I created 2 new partitions.

Right now I am recovering the files/folders from first original partition via GetDataBack Pro directly on the new HDD/partition1. When this is finished I'll again check the files manually.

 

After that the CHKDSK from the second partition (video-files) on the other bde-repaired-HDD should be finished. Either the files are accessible and I can copy paste them via the Windows Explorer or I'll go into WinHex again and overwrite the corrupted MFT with the original one (see my last post where I extracted the working MFT with GetDataBack Pro). When the MFT is overwritten (repaired), I'll make another scan with WinHex or GetDataBack Pro (shouldn't make a difference) and I'll find all my files which again I then can copy/recover on the new HDD/partition2.

 

This should be the solution.

I'll have both partitions inclusive folder structures and filenames back and should not have a big data-loss. I currently can't say if there are files that are missing due to unfinished decryption though. I guess I just have to check them manually but on the first look I don't miss a thing.

 

I will keep you updated.

This will take a while now since were talking about ~7 TB.

 

This post was modified 3 years ago 2 times by deady1000
 
Posted : 16/10/2020 12:52 pm
passcodeunlock
(@passcodeunlock)
Posts: 792
Prominent Member
 

Good to hear and good luck there!

I tried a small dummy test, hard reset while bitlocker decryption, but nothing bad happened, on the next run, it asked for the password again and opened the container without problems.

If you have time, try to reproduce this! Besides the disaster recovery, I would be interested in finding why this happened and if it will occure, how to deal with it.

I might think that you got some bad sectors on the original harddrive and that is why this happened, but that is only a guess.

 
Posted : 16/10/2020 9:10 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 
Posted by: @passcodeunlock

I tried a small dummy test, hard reset while bitlocker decryption, but nothing bad happened, on the next run, it asked for the password again and opened the container without problems.

 

It is possible that the behaviour simply does not "scale".

OP's fileystem (and data in it)  is "queer" (in the sense that it is different from most common ones), it is extremely large (2 TB or more) with an extremely small number of files, but fairly filled up (85%) as the $MFT is extremely small (3 MB, i.e. roughly 3,000 entries if it is a 512 byte/sector device that implies 1.024 bytes per $MFT record or - in the case of a 4 KB sectored devices - 1/4 of those, only 750 files).

A more "common" NTFS filesystem usually has the $MFT 0.1%-0.2 of size (tens or hundreds of MB for the $MFT) or more AFAICR (as the number of file and their average size is much smaller).

For all we know this behaviour may be repeatable only on a similar filesytem with the hard reset happening at an exact (unknown) moment.

jaclaz

 

 
Posted : 17/10/2020 8:15 am
Page 2 / 3
Share: