Recovering data fro...
 
Notifications
Clear all

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

24 Posts
4 Users
0 Likes
7,426 Views
(@deady1000)
Posts: 12
Active Member
Topic starter
 

Hello guys,

First of all, I would like to state that I am not a professional data forensic specialist or something, but rather do it as a hobby. I have a question about rescuing two Bitlocker partitions. I've already tried a lot of things and it looks like I can recover the data by what I know right now.

Please let me explain the situation:

During the decryption of a hard drive that contained a total of three Bitlocker partitions, the system has abruptly been shut down (via command and force). After the restart it looked like this:

The third partition was the first to be successfully decrypted and is correctly recognized as a readable NTFS partition after startup. The data are accessible.

The first partition was the second to be decrypted. This partition was still recognized as a Bitlocker partition, but could not be opened by Windows after the restart.

The second partition was probably only partially decrypted or still fully encrypted. This partition was also recognized as a Bitlocker partition, but could also not be opened by Windows after the restart.

The error-message was something like "The Bitlocker encryption on this drive isn't compatible with the version of windows. Try opening the drive using newer a version of windows.", or something similar. This was obviously not the case because the partitions were encrypted by just this system and were in decryption by the same system before as well. The forced restart must have corrupted the Bitlocker- or the drives metadata which makes it impossible for windows to open it.

___________

So, that was the beginning.
What I did now was the following:

First the good news:
- Because the partitions were still recognized, no data were overwritten.
- The data on both partitions are absolutely not fragmented.
- The Bitlocker-recovery-key exists. (The key packages unfortunately do not, but they are fortunately not really needed here.)

I got a second bigger HDD and the first thing I did was to use "ddrescue" to copy the whole corrupted disk to the other HDD. Of course, the partitions still acted the same.

After that I formatted the first two partitions on the new HDD to NTFS so that they both have the same sizes, etc, but are free from any data.

Now I used "bde-repair" on the two partitions on the original HDD and set the destination to the new partitions on the new HDD which succeeded, or at least the tool was able to use the given recovery-key and found the metadata so it decrypted both partitions onto the new HDD successful.

After doing that "bde-repair" claimed that CHKDSK has to be used on both new partitions but when doing so it won't let me access the partitions afterwards. It just won't work that easily.

At this point I guess many people would just give up, but I'm not done yet.

___________

Current status is, I've got 4 partitions:

- 1x HDD_1_partition1, shown as Bitlocker-Drive, not accessible, Data probably already decrypted
- 1x HDD_1_partition2, shown as Bitlocker-Drive, not accessible, Data probably fully encrypted
- 1x HDD_2_partition1, shown as NTFS, not accessible --> BDE probably tried to decrypt the already decrypted data (Maybe useless partition.)
- 1x HDD_2_partition2, shown as NTFS, not accessible --> BDE probably decrypted most of the data correctly

So, at this point I knew I'm going to need some professional software.

Using "X-Ways Forensics" and "X-Ways WinHex" I could read the 4 partitions.

___________

On the HDD_1_partition1 I'm able to find the unencrypted files from partition1. They can be found via file carving when I specify what I'm looking for, e.g..*exe-Files, .*bin-Files, .*7z-Files. Since I am looking for certain data, I had to edit the signature search file and add headers for which X-Ways Forensics has to search for - with success. They could be recovered manually but without any filename or other metadata. A problem is that the software does detect the signature as beginning of the file but it does not detect the ending of the file, so the *.bin-files all show up as 1MB-Files but should be something between 500MB and 2GB mostly.

On the HDD_2_partition2 I'm able to find the other the unencrypted files, mostly video-files.
"X-Ways Forensics" also shows about 10% of the files even without file-carving and with the correct metadata and even file-names in the file-explorer. They could be recovered without any problems. Using file-carving I can find about 50% of the files without problems, all readable and not corrupted. Filenames and data structures missing.
___________

So, I was thinking, due to the fact the files are all still there (I can see the beginning of the files in the HEX-View), is there a possibility to just copy the used file-space to another fresh NTFS-drive? I mean, block-for-block (or byte for byte) copy from beginning of the first file to the beginning of the free space?

The good thing is that both of the partitions are absolutely not fragmented at all because it is an external drive for backup-purposes and it contains almost only very big files and files never are deleted.

So, I thought it should be not a big deal to just copy and paste the blocks from one partition to another, right? Or wouldn't that be possible?

For example:

- use file carving to find the first file I need on the HDD

- remember that block/byte

- use file carving to find the last file I need on the HDD

- scroll to the ending of the file

- create a new block (would be about 3TB of data... yes... big partitions...)

- copy that block, or use it as source

- paste it, or write the source to a destination

- destination would be a new partition with the same or slightly bigger size

- look for the first block of free space: write blocks here

- use CHKDSK or something else??

--> Data recovered??

___________

Another idea was to repair the partition-details (MBR?), using a healthy partition with the same size, manually and maybe let windows find the files itself afterwards with CHKDSK (??) again, because technically the files are still there.

___________

I'm not sure what's the correct way in this situation.
Files are still there, software is available.
I only need to know what's possible and what not.

What would you guys do?
Even though I'm not one of you I really hope you can help me in this situation.

Thank you very much in advance!

 
Posted : 09/10/2020 10:09 am
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Well:

After doing that "bde-repair" claimed that CHKDSK has to be used on both new partitions but when doing so it won't let me access the partitions afterwards. It just won't work that easily.

this means that you have to run CHKDSK.

BTW which OS is that?

What do you mean (EXACTLY) by "it won't let me access the partitions"?

What (EXACT) error or message are you having?

How (EXACTLY) are you running CHKDSK?

If it is possible to avoid file carving it would be MUCH better, so let' try first understand what is the problem with CHKDSK.

If it isn't possible to solve the run CHKDSK issue, you'd better use a data-recovery oriented program, such a DMDE:

https://dmde.com/

as it may be able, even on a partially corrupted NTFS to recover the files without needing to carve them out.

jaclaz

 
Posted : 09/10/2020 2:23 pm
(@deady1000)
Posts: 12
Active Member
Topic starter
 

Dear jaclaz,

Thank you for your answer. Directly after writing my post I again started a new CHKDSK-run.
But let me first answer your follow-up questions:

__________

- Which OS is that?

It is all about Windows and Microsoft-Bitlocker. The drives are formatted as NTFS. I can also use Linux though.

- How (EXACTLY) are you running CHKDSK?

The first time after the "bde-repair" I used an USB-stick with a Windows-image and booted into the Windows Recovery Environment (command line) to run CHKDSK on the destination partitions (the unencrypted ones). I did it via "chkdsk X: /f". I can't remember 100% but I think it failed with the first disk (probably the one which was already decrypted). Can't remember the error message exactly. When I tried it with the second disk it did something but after all it had no real success.

I think I also tried "chkdsk X: /x /f /r" but that would have taken like several days and at that point I just wanted to check if something had been decrypted. (Coming to that at the end of this post!)

[BTW the drive letters are examples. Of course, I used the correct ones.]

__________

- What do you mean (EXACTLY) by "it won't let me access the partitions"?

Well, the two new partitions from "bde-repair" are shown as NTFS drives but when I try to open them via Windows Explorer an error appears which states "Drive X: access denied". I think windows just doesn't know how to handle it and STILL needs CHKDSK, just as you said. Maybe my CHKDSK-run wasn't enough.

__________

- If it isn't possible to solve the run CHKDSK issue, you'd better use a data-recovery oriented program, such a DMDE [...] as it may be able, even on a partially corrupted NTFS to recover the files without needing to carve them out.

Wow, thanks for that. I'll check it out.

__________

Now to the crucial point:

- If it is possible to avoid file carving it would be MUCH better, so let' try first understand what is the problem with CHKDSK.

You're right, if it would work via CHKDSK, it would be the best.
And I guess I made a mistake here. I probably should have run "chkdsk X: /x /f /r" right?

As I said at the beginning of this post, I started that command right away 2-3h ago and it runs now.
If my calculations are correct the whole process will take 76.1h and 73.4h are still remaining. Calculated speed = 15.3 MB/s; Partition-size = 4TB. So, I guess I'm going to tell you on Monday what happened.
Maybe this will repair second partition which has successfully been decrypted by "bde-repair".

__________

But what about the first partition which has been decrypted by Bitlocker before the system was shut down?
The files are accessible via "X-Ways Forensics / WinHex". I could recover them one by one without metadata or filenames but that would be incredibly bad.

Is there a way to get them out of there and also run something like CHKDSK?

I guess the partition which was created by "bde-repair" won't help here because "bde-repair" (from what I know) tries to decrypt the whole partition with the recovery password but in fact there was nothing to decrypt. I just need the original partition on the original HDD to act like a NTFS partition and not like a Bitlocker-partition because the files are not encrypted anymore.

Any ideas about that?
I think "chkdsk Y: /x /f /r" won’t work here but I'm not 100% sure. I think I already tried that but again I don't know if I did it with "/x /f /r" or just "/f".

Don't want to run "chkdsk Y: /x /f /r" on that partition right now because if something goes wrong this could overwrite some files on the original HDD. Have to wait for the second HDD to finish it's CHKDSK first to copy the original partition onto it via "DD" first. I will also see then if CHKDSK can help me in the first place.

__________

Hope these information help to solve my issue.
Do you think I can recover the files and maybe the folder structures and filenames?

Thank you!

This post was modified 3 years ago by deady1000
 
Posted : 09/10/2020 3:11 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

I meant, is that Windows 7, 8, 8.1, 10, and if 10 which exact version?

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):

https://msfn.org/board/topic/178213-normal-mode-booting-ok-but-bsod-in-safe-mode/?tab=comments#comment-1160391

The access to the partition from a "full" windows may also be connected to authorizations/credentials, from the Window Recovery Environment that should be not an issue (as you are actually "System") but since you mentioned "access denied" in Windows Explorer, that could be connected to permission issues. i.e. *like* seen here:

https://www.easeus.com/storage-media-recovery/drive-is-not-accessible-access-is-denied.html

(but forget about the Easus Data Recovery program)

Anyway, let's wait for the result of your running CHKDSK instance.

jaclaz

 

 
Posted : 09/10/2020 6:45 pm
(@deady1000)
Posts: 12
Active Member
Topic starter
 

Dear jaclaz,

yeah the "access denied"-error really could be connected to the Window Recovery Environment usage. Good hint! Maybe it will work after the current CHKDSK because it's running under regular Windows right now.

The OS I'm using is Windows 10 Pro v2004.

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

Oh I did not know that. Thank you for that!

I'll tell you what happened after the current CHKDSK-run. 69.1h remaining.

_____

Any ideas about the other partition?

That one is shown as Bitlocker-encrypted but WinHex can see (and access) the files when I search for them. So the files are technically decrypted but Windows does not detect that. Is there a way to delete the 'Bitlocker flag' to make it look like a normal NTFS partition, which then can be checked via CHKDSK? Currently I think CHKDSK won't check it because it thinks it is encrypted.

 

Greetings and thank you for your help!

 
Posted : 09/10/2020 7:41 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

About the other partition, it has to be seen.

For all we know, the actual files (to be more exact the extents on which the files reside) may have been decrypted BUT other areas of the volume pertaining to the NTFS filesystem (let's say the $MFT) may have not.

And it is also possible that only part of the files were decrypted.

 

In any case even if everything has been already decrypted, it is more complex than a simple "flag":

https://github.com/libyal/libbde/blob/master/documentation/BitLocker%20Drive%20Encryption%20(BDE)%20format.asciidoc

 

jaclaz

 
Posted : 10/10/2020 8:17 am
(@deady1000)
Posts: 12
Active Member
Topic starter
 

Hey guys,

unfortunately it did not work as intended.

After the "chkdsk Z: /r /x /f" which took nearly 80h it still is not accessible and the output again says:

"4194315 MB total disk space.
283990364 KB in 404 files
3916785 MB available on the data medium".

So there are still ~280 GB video files to find, but the rest like >3TB can't be found by CHKDSK. This is a 4TB partition, which should be about 85% full. In the partition manager the disk is shown as NTFS but when I wanna open it it still shows the same error as here:

Spoiler
image

 

 

Here is a translation (DEEP-L from ger to eng) of the CHKDSK-output:

Spoiler
CODE CHKDSK
Microsoft Windows [Version 10.0.19041.508].
(c) 2020 Microsoft Corporation. All rights reserved.

C:\windows\system32>chkdsk Z: /r /x /f
The file system type is NTFS.
The volume name is Elements B.

Phase 1: The base file system structure is examined...
3072 records are processed.
File examination finished.
Phase duration (file record check): 129.30 milliseconds.
Orphaned data record segment 4 is deleted.
Orphaned record segment 8 is deleted.
Orphaned data record segment A is deleted.

[...] 1276 lines cut out

Orphaned record segment 9FF is deleted.
1277 large data records processed.
Phase duration (recovery for orphaned file record): 0.00 milliseconds.
0 invalid data records processed.
Phase duration (check for wrong file record): 0.63 milliseconds.
Flags for data record segment B are corrected.
File name errors of data record segment B of the system file are corrected.

Phase 2: The file name link is checked...
The incorrect information in data record segment 5 is corrected.
The incorrect information in data record segment B is corrected.
3270 index entries are processed.
Index check finished.
Phase duration (index check): 784.99 milliseconds.
CHKDSK creates a new root directory.
CHKDSK checks non-indexed files to restore the connection to the original directory.
Orphaned file $MFT (0) is restored to directory file 5.
Orphaned file $MFTMirr (1) is restored to directory file 5.
Orphaned file $LogFile (2) is restored to directory file 5.
Orphaned file $Volume (3) is restored to directory file 5.
Orphaned file $AttrDef (4) is restored to directory file 5.
The wrong information in record segment 5 is corrected.
Orphaned file . (5) is restored to directory file 5.
Orphaned file $Bitmap (6) is restored to directory file 5.
Orphaned file $Boot (7) is restored to directory file 5.
Orphaned file $BadClus (8) will be restored to directory file 5.
Orphaned file $Secure (9) is restored to directory file 5.
Further messages about the recovery of orphaned items are skipped.
142 non-indexed files checked.
12 non-indexed files are restored in the original directory.
Phase duration (reconnection for orphaned record): 0.00 milliseconds.
CHKDSK restores remaining non-indexed files.
130 non-indexed files restored.
"Lost/Found" is located at \found.000

Phase duration (recovery for orphaned record): 0.00 milliseconds.
Index $I30 for file B is created.
File for object ID is created.
An index entry is added to index $I30 of file B.
Index $O for file 18 is created.
An index entry is inserted in Index $O of file 18.
An Index Entry is inserted in Index $O of file 18.
An Index Entry is inserted in Index $O of file 18.
4 analysis data sets processed.
An index entry is inserted in Index $O of file 18.
Analysis point file is created.
An index entry is inserted in Index $I30 of file B.
Index $R for file 19 is created.
Phase duration (checking analysis point and object ID): 6.37 milliseconds.
Quota file is created.
An index entry is added to index $I30 of file B.
Index $O for file 1A is created.
Index $Q for file 1A is created.
Default odds entry is added to index $Q in file 1A.

Phase 3: Security descriptors are examined...
Index $SII for file 9 is created.
Index $SDH for file 9 is created.
Invalid security identifier for file 3 is replaced by default security identifier.
A default security descriptor is created for the undefined security ID "100"...
A default security descriptor is created for the undefined security ID "108"...
A default security descriptor is created for the undefined security ID "11D"...
A default security descriptor is created for the undefined security ID "11E"...
A default security description is created for the undefined security ID "11F"...
A default security description is created for the undefined security ID "121"...
Checking of the security descriptions finished.
Phase duration (check for security descriptor): 6.90 milliseconds.
DATA attribute is inserted in file 4.
DATA attribute is inserted in file 6.
Attribute DATA is inserted in file 7.
Attribute DATA is inserted in file 8.
Attribute DATA is inserted in file A.
Attribute DATA is inserted in file C.
Attribute DATA is inserted in file D.
106 Data files are processed.
Phase duration (data attribute check): 3.47 milliseconds.

Phase 4: A search is made for faulty clusters in user file data...
3056 files were processed.
File data check finished.
Phase duration (user file recovery): 27.38 minutes.

Phase 5: A search for faulty, free clusters is performed...
1002729779 free clusters are processed.
Verification of free space is finished.
Phase duration (recovery of free space): 0.00 milliseconds.
MFT (Master File Table) mirroring errors are corrected.
Errors in attribute definition table are corrected.
Errors in the start file are corrected.
Errors in the capital letter table are corrected.
Errors in the file of faulty clusters are corrected.
Errors in the attribute BITMAP of the master file table (MFT) are corrected.
Errors in volume bitmap are corrected.

Corrections were made to the file system.
No further actions are required.

4194315 MB total disk space.
283990364 KB in 404 files
380 KB in 114 indices
0 KB in bad sectors
200095 KB used by the system
65536 KB occupied by the log file
3916785 MB available on the data medium

4096 bytes in each allocation unit
1073744687 Total allocation units on the disk
1002696978 Allocation units available on the disk
Total duration: 27.44 minutes (1646712 ms).

C:\windows\system32>

So what should I try now?

CHKDSK alone won't work on that partition.

The files should still be there. WinHex can find them.

Now time for DMDE?

 

Thank you!

This post was modified 3 years ago by deady1000
 
Posted : 12/10/2020 7:04 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 
Posted by: @deady1000

Now time for DMDE?

Yep.

Point is will it have more chances to find files from the "original" (the bde-repaired one BEFORE running CHKDSK) or on the current filesystem?

Try running it on your current filesystem, if it does not work in a satisfactory way, you can still re-do the bde-repair from the original and try running DMDE before the CHKDSK.

DMDE (unlike chkdsk) does not normally write on disk, so you will need (yet another) large enough disk to store (copy to) the files that may be (hopefully) recovered.

About the access denied, you can try - as in the given link - to change permissions/get ownership.

jaclaz

 
Posted : 13/10/2020 9:00 am
(@deady1000)
Posts: 12
Active Member
Topic starter
 

Alright, I'm now running 'bde-repair' on both partitions again with logged-on Windows for best preconditions.

By the way, I could access the disk again after setting the permissions to 'everyone' but the explorer showed an empty drive but 280GB used space. So that does not bring me further but at least it confirms your suspicion that the Recovery Environment locked it.

After the current 'bde-repair' I'm gonna try DMDE again which at the first time was not able to repair the MFT. I could recover the files without metadata though but that would be inconvenient if there was another way.

I will also try "GetDataBack Pro Data Recovery" and "ZAR X (z-a-recovery)", but ZAR X just crashed at the first try. So I'm not so sure if this is a good tool. GetDataBack on the other hand looked quite useful and seemed to be able to find quite many files, if not even all (still without metadata and I'd have to recover them without structures and without filenames).

 

What do you think is the best or most promising tool to rebuild the MFT of an NTFS?

Would that even be possible?

 
Posted : 13/10/2020 11:45 am
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

It greatly depends on the actual "damage" the $MFT has.

DMDE usually manages to rebuild (virtually) the file-system even if the $MFT is partially damaged (or mis-referenced).

If it does not (and CHKDSK does not work) there are (limited) possibilities to manually fix small incongruences that DMDE automatic detection misses, but as it is obvious this manual work needs specific knowledge and experience.

About other recovery tools, they are all or almost all (good or bad)  "carvers", the one (photorec) may find more (or better) files than DMDE (or viceversa) but this is "generally speaking", in data recovery you try and throw to the corrupted filesystem everything and the contrary of it, sometimes a "niche" or misknown tool may find/extract more data than more known tools.

Personally, I have a soft spot for DMDE, but Photorec is also an exceptionally good tool, all the rest (again in my limited personal experience) rarely work "better" than these two.

A third (IMHO very good) tool (but Commercial only) is File Scavenger, and a fourth (a well very good) is R-Studio.

Then there are an endless list of "popular" software that is unlikely to give you any better results.

And a number of free NTFS related tools (like Joakims' ones) that may be of use, but again only in the hands of someone knowledgeable and expert in the matter.

jaclaz

 
Posted : 13/10/2020 6:49 pm
Page 1 / 3
Share: