Tags

, , , , , , , , , ,

After I got curious about bcrypt, I wanted to determine whether the plaintext would still be recoverable using forensics software. If I wanted to recover the contents of an encrypted file, this is how I’d go about it.

So, here I used a 1GB USB drive that is a couple of years old, just because it’s quicker to image and recover files from. The files I copied onto the USB drive were three JPG images, each marked in a way that I could later tell which were erased by bcrypt and BleachBit. The files had an average size of around 720KB.

the-test-files

Wiping the Files
First file was straight-up deleted, and I emptied the ‘recycle bin’ just to be sure. This file I expect would be recovered later. The second one I ‘shredded’ using BleachBit. The third one I encrypted and erased using bcrypt.

I made sure the file erasure operations for BleachBit and bcrypt were completed before proceeding.

All that’s visible in a file manager is an encrypted .jpg.bfe file, and the data recovery software should only discover another file called ‘std-delete.jpg‘.
Of course, in the real world where the device is used afterwards, we’d expect all three files to be completely overwritten as the device is filled with new data. If anything’s recovered, it’s largely because the blocks weren’t properly overwritten.

Imaging the Volume
Before imaging the volume, we need to determine its mountpoint and filesystem blocksize, so first I used the ‘df‘ command. This revealed the mountpoint as /dev/sdc1.

Now I need the blocksize, just to ensure the image is a bit-for-bit clone that includes the slack space:
#blockdev --getbsz /dev/sdc1

The command returned the value ‘512’, which is used for imaging the volume using dd:
#dd if=/dev/sdc1 bs=512 of=/home/michael/bcrypt-bleachbit-test.img

Sleuthkit/Autopsy
Autopsy found the image name and metadata for the deleted file, but couldn’t display the image itself. As you can see in the screenshot below, Autopsy also managed to read most the unencrypted data that should have been erased by bcrypt.
If this was a document, the full plaintext content would easily be accessible.

autopsy-analysis

What Autopsy didn’t discover was the file ‘shredded’ by BleachBit.

[Update: The Windows version of Autopsy recovered the BleachBit file, and most the bcrypt file’s content.]

File Carving
Everything that was deleted from the device in the past, and the file erased by BleachBit were recovered using foremost. The bcrypt plaintext file wasn’t recovered.

recovered-by-foremost

EnCase
Again, EnCase recovered most the unencrypted content that was erased by bcrypt. I half-expected this result, as EnCase recovers files by their metadata, which BleachBit modifies before overwriting the file’s space. Although I couldn’t view the file as an image, most the data could be read, and again this would have been enough to determine the content of a document file.

encase-portable-bcrypt

Conclusion
An important thing to note is I’ve only demonstrated that it’s possible to recover the data with software tools under certain conditions – it was a USB storage device that wasn’t used after the files were erased. What I have demonstrated, though, is that it’s dangerous to assume that BleachBit or bcrypt will make a file unrecoverable. Both tools are good for hiding data, if your adversary isn’t likely to spend 24 hours imaging the drive, piecing together wiped data and sifting through thousands of files.
If there is a real motivation to recover the data, you’re better off encrypting the entire device/volume, and physically destroying it when no longer required.

Advertisements