Deleted truecrypt c...
 
Notifications
Clear all

Deleted truecrypt container

14 Posts
9 Users
0 Reactions
2,104 Views
(@zw1404)
New Member
Joined: 12 years ago
Posts: 4
Topic starter  

So I accidentally deleted a 300GB Truecrypt container on an NTFS-formatted drive. Immediately after I realised my mistake I pulled the plug, plugged the HDD into another machine and made a full raw disk image of it. So I have an image I've been mounting read-only and experimenting with.

I've run the basic/simple file recovery software, but due to the size of the file, the nature of the NTFS file system and the simplicity of these tools, they are not able to restore it (most can't even find it).

I know Encase Forensics is capable of doing a raw disk scan for the tell-tale randomised data that signifies a Truecrypt container. I've even found an Encase script that, as long as your know the container password (which I do), will be able to identify the Truecrypt container header from the raw disk.

My thinking is that if I can find the initial off-set/header I could try to simply recover 300GB from that offset on. I know that the file is likely to have been fragmented and so this will recover a corrupted version of the file, but as long as the header is intact I should be able to mount it and Truecrypt is pretty good at sector-by-sector corruption, meaning I will be able to recover at least some of the contents.

My issue is that I can't justify spending thousands on Encase Forensics, and all the "data recovery companies" I can find are not likely to engage in this technical a level of file recovery. They just run Recuva on the drive, if that doesn't find it then bad luck for the customer.

So does anyone know of some other, more reasonably priced, forensics software that can detect deleted Truecrypt containers? Potentially any other software that is compatible with Encase Scripts might work as well, if that's an easier ask?

Failing that I guess I'll just have to dob myself into the cops for CP. I'm sure they'll be able to recover the Truecrypt file, at which point they'll find it contains no CP and probably charge me with wasting police time/resources. I'd have to spend a couple months in prison, but hopefully they would let me keep the recovered file! lol


   
Quote
minime2k9
(@minime2k9)
Honorable Member
Joined: 14 years ago
Posts: 481
 

In the situation you just described, recovering the file should be fairly straightforward.

When the file is deleted, the file record in the Master File Table (MFT) is marked as deleted.
Assuming the record hasn't been re-used, which in the situation you describe it shouldn't have, you should be able to locate the file easily.

I'm pretty sure FTK imager will show deleted files that still have an MFT entry and this is free to download. JUst import your image into it and go to the file path the volume was in, you should see it there with an icon to say its deleted.

Winhex does a similar thing and is fairly cheap as I remember it.


   
ReplyQuote
Passmark
(@passmark)
Reputable Member
Joined: 14 years ago
Posts: 376
 

300GB is an awful lot of data to not have backed up ??

Was this on a Window boot drive or a data drive? MFT records on the boot drive tend to get overwritten very quickly as there is always background disk activity going on.

What else was on the drive? If it was a blank drive initially, with nothing else on it, there is a much better chance that the data isn't fragmented.

If this was the boot drive I wouldn't think a straight search for randomised data will solve your problem. There is too much data that is compressed. And compressed data will look just as random as encrypted data (except for possible file signatures in the first few bytes).

Just plugging the drive into a new machine can result in disk writes unless you used write protection of some sort. So that is also a possible issue.

You could also try our OSForensics software, but it will only pick up the file if the MFT wasn't overwritten. You could try a manual carve however if you find the start of the file. With 300GB of data to move around, the experimentation process will be slow.


   
ReplyQuote
(@jonathan)
Prominent Member
Joined: 20 years ago
Posts: 878
 

[Warning completely unrelated to topic in OP. Or anything to do with forensics or ediscovery for that matter]

Why do more and more forum posts start 'So'? This is not a dig at zw1404 at all because many do it, but why? Beginning a sentence with it doesn't add anything, and removing it doesn't detract anything.


   
ReplyQuote
(@jonathan)
Prominent Member
Joined: 20 years ago
Posts: 878
 

You may want to see what running Encrypted Disk Detector from Magnet Forensics (free) can do. Good luck.


   
ReplyQuote
Chris_Ed
(@chris_ed)
Reputable Member
Joined: 16 years ago
Posts: 314
 

[Warning completely unrelated to topic in OP. Or anything to do with forensics or ediscovery for that matter]

Why do more and more forum posts start 'So'? This is not a dig at zw1404 at all because many do it, but why? Beginning a sentence with it doesn't add anything, and removing it doesn't detract anything.

So why not create a thread about it?

*insert gigantic winking smileyface*


   
ReplyQuote
jaclaz
(@jaclaz)
Illustrious Member
Joined: 18 years ago
Posts: 5133
 

How big is the "whole disk"?
In such a case, it may be useful to use "negative" logic.
Get DMDE
http//dmde.com/
it may even be able to find the whole file, but if it doesn't use it to "map" ALL other files and delete them (on the image, obviously) writing to them a "pattern" of some kind, all 00's would be fine.
What remains in the end cannot but be the sectors containing the Truecrypt container.
The issue may be if the container is fragmented, of course, and this may also depend on the exact way it was created originally.

jaclaz


   
ReplyQuote
(@zw1404)
New Member
Joined: 12 years ago
Posts: 4
Topic starter  

Thanks for all the advice, very helpful forum!

Unfortunately NTFS has some issues with very large files and the MFT that complicate file recovery. The file shows up as 0 bytes long in any tools that detect it. Preventing a straight deleted file recovery.

Yeah, in hindsight I really should have backed it up. I had planned to and purchased an external hard-drive specifically for this purpose, but as Murphy's law goes the file was deleted prior to the external hdd arriving.

The drive it was on was not the system drive. It did contain other files on the drive prior to the creation of the truecrypt container, and files were written to the drive after the creation of the truecrypt container, so it's likely the drive is fragmented.

OsForensics is actually one of the first tools I used and continue to use, it's quite useful. Unfortunately like the other recovery tools it finds the file but lists it as 0 bytes, which a bit of investigation leads to me believe is due to an issue with very large files and NTFS, not specifically because all the data has been overwritten.

I think people start posts with so because if it was a conversation in RL that's how it would go. We would likely start the conversation with something more light-hearted/small-talk, then segue into the topic at hand with a so. I guess it is entirely vestigial in an online forum post.

Unfortunately Encrypted Disk Detector only detects when entire disks/partitions are encrypted, which I've found a few tools that can do. It is detecting encrypted files from raw disk that is difficult.

Have been giving DDME a shot, it is a very useful tool and I like how it gives a lot of lower-level information. Tried a raw disk carve but wasn't successful, will have to recalculate my sectors and give it another go tonight.

Anyway thanks again for all the help guys!


   
ReplyQuote
Passmark
(@passmark)
Reputable Member
Joined: 14 years ago
Posts: 376
 

For large fragmented files the MFT $DATA record might not contain the file 'runs'. A run represents information about a fragment of the file (Cluster offset & number of clusters).

Instead it might just contain a pointer off to another MFT record where all the runs can be found. So you can get a situation where you can see the name of the file but know nothing about the clusters that were used by the file.

You would need to step through the MFT byte by byte to confirm this was the case.


   
ReplyQuote
(@zw1404)
New Member
Joined: 12 years ago
Posts: 4
Topic starter  

If I load the MFT file into an MFT analyser it tells me that the resident flag is set, so MFT thinks the file is resident within the MFT entry, yet still 0 bytes long. Is this consistent with a situation where the data attribute is pointing to another MFT record?

Hate to be obtuse but I've spent a few hours wrapping my head around MFT flags and am not totally confident of my skills. Here's the raw hex for the MFT entry for this file, if it helps.


46 49 4C 45 30 00 03 00 E9 EC 00 B9 00 00 00 00
04 00 01 00 38 00 00 00 50 01 00 00 00 04 00 00
00 00 00 00 00 00 00 00 04 00 00 00 7C 3E 00 00
96 0C 00 00 00 00 00 00 10 00 00 00 60 00 00 00
00 00 00 00 00 00 00 00 48 00 00 00 18 00 00 00
22 F6 AD 12 D2 5C CD 01 04 B7 02 D7 D8 5C CD 01
7E EC BC 89 DA 5C CD 01 22 F6 AD 12 D2 5C CD 01
20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 17 01 00 00 00 00 00 00 00 00 00 00
78 8F 40 1A 00 00 00 00 30 00 00 00 68 00 00 00
00 00 00 00 00 00 02 00 4A 00 00 00 18 00 01 00
05 00 00 00 00 00 05 00 22 F6 AD 12 D2 5C CD 01
22 F6 AD 12 D2 5C CD 01 22 F6 AD 12 D2 5C CD 01
22 F6 AD 12 D2 5C CD 01 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00
04 03 64 00 61 00 74 00 61 00 00 00 00 00 00 00
80 00 00 00 48 00 00 00 01 00 00 00 00 00 03 00
00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF
40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 01 00 00 00 00 00 FF FF FF FF 82 79 47 11
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 96 0C
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 96 0C


   
ReplyQuote
Page 1 / 2
Share: