dbrant

Recovered photos looking “cut off” or “half gray”?

Numerous users of DiskDigger have contacted me regarding recovered photos that sometimes appear to be “cut off” somewhere in the middle, with the rest of the photo replaced by a single “color,” or meaningless shapes and colors, like the picture below. What’s the reason for this mysterious phenomenon? The explanation has to do with file fragmentation. Files stored on your hard drive (or memory card, USB drive, etc.) are organized using a file system, such as FAT or NTFS. These file systems allow for files to be fragmented, meaning that portions of a single file can be scattered across different locations on the drive. For a quick explanation of why files might get fragmented, refer to the figure below. When your disk is empty, and you start writing files to it, the files will be stored consecutively (“file 1”, “file 2”, “file 3”, etc.), as we might expect. Now, suppose we delete “file 2”, which would leave a “hole” between “file 1” and “file 3.” And now, suppose we write a new file (“file 4”), which happens to be larger than “file 2” was. A portion of “file 4” will be written into the hole left behind by “file 2”, and the rest of the file will be written to the space beyond all the previous files. In the above figure, “file 4” consists of two fragments. The sizes and locations of the fragments are indexed in the file system structures that appear at the very beginning of the disk. So, what are the implications of this when a fragmented file is deleted? As we know, the act of deleting a file doesn’t actually wipe the contents of the file from the disk. Therefore, we can be sure that the actual contents (or fragments) of the file will remain intact, until they’re overwritten by new data, since the deleted file is now treated as empty space, up for grabs. However, what happens to the file system structures that keep track of the locations and sizes of the fragments? This depends on the file system: Under the FAT family of file systems, the fragment locations are recorded in the File Allocation Table, which is the namesake of the file system! The bad news is that, when a file is deleted, its File Allocation Table entries are wiped permanently. It’s still possible to locate the beginning of the first fragment of...

Read More

DiskDigger Pro for Android!

I’m pleased to announce the release of DiskDigger Pro for Android! This new version of DiskDigger is capable of recovering (carving) over 20 different types of files from your Android device’s internal memory, or an external memory card. This includes support for .JPG photos, .MP3 and .WAV audio, .MP4 and .3GP video, raw camera formats, Microsoft Office files (.DOC, .XLS, .PPT), and more! As with the non-Pro version of DiskDigger for Android, this app requires root privileges on the Android device. The non-Pro version of DiskDigger will remain available (for free!) on the Google Play store, and can still be used for recovering .JPG photos. So what are you waiting for? Go to the Google Play store on your Android device, and install DiskDigger Pro...

Read More

The problem with recovering text files

This is a question I get a lot, so I thought I would expand on it more formally: “Why can’t DiskDigger recover plain text (.txt) files in ‘deeper’ mode?” To begin, let me remind everyone that DiskDigger can recover text files in “deep” mode, where it scans the structure of the file system and recovers files based on clues provided by the file system. This makes “deep” mode capable of recovering any type of file, including text files, while only being able to recover these files from a healthy file system. However, in “deeper” mode, things are very different. Since DiskDigger no longer relies on the file system to parse the structure of files on the disk, it can only detect files based on byte sequences known to exist in certain types of files.  For example, all PNG image files begin with the byte sequence 89 50 4E 47. Therefore, DiskDigger can look at every sector of the disk, and if it begins with this sequence of bytes (files must be sector-aligned), it knows that there’s a PNG file at that location. The same is true for many other types of files, like .JPG, .DOC, .MOV, etc.  It’s also true for files that are built from text, but have a consistent structure, such as .HTML, .XML, .RTF, etc. So now we come to the problem with pure text files. Unlike other types of files, text files do not contain any identifiable sequence of bytes. They only contain… well… text!  There’s no underlying binary structure. This makes it nearly impossible for DiskDigger to “pick out” a text file from all the other random content on a disk. Despite all this, there are a few remote possibilities for recovering text files which are an active area of development in DiskDigger. None of these are perfect, but they may eventually lead to a solution for recovering some text files: Some text files may be encoded in Unicode (specifically UTF-16). In this case, the text file will have a starting byte signature, which is either FE FF or FF FE. Unfortunately this signature is far too short to meaningfully identify UTF-16 files, and will produce too many false positives. Since many text files are encoded in ASCII or UTF-8, and written in English, we can expect them to contain only characters between 0x20 and 0x7F (along with \n and \t). We can then...

Read More

Recovering QIC-150 tapes: a case study

A friend of mine recently found something very intriguing:  several backup tapes from his old Amiga 500 computer from around 1995.  Since he no longer has the original Amiga machine, he no longer has a way of reading the tapes, and thus no way of rediscovering the old documents, letters, or any other memories that were lost when the old computer was thrown away. Without hesitation, I offered to help recover the data from the tapes, not only for the challenge of it, but also because I have never dealt with Amiga computers or Amiga-formatted media, and this would be a great opportunity to familiarize myself with a significant part of computing history, even if it has already come and gone.  This is a brief chronicle of the steps I took to recover the data, just in case someone else in the future (including myself) needs to perform a similar task. One of the most pleasurable aspects of this experience was how easily everything came together, owing mostly to the abundance of information on the web regarding every step of these kinds of processes. Hopefully the information in this article will contribute to that abundance. The tapes were QIC-150 cartridges (specifically Sony D6150). After rummaging a bit through my attic, I realized that I actually own a tape drive that’s capable of reading QIC-150 tapes. The drive is an Archive Viper 2150S, which uses a SCSI interface: Since the drive is SCSI, I would need a SCSI host adapter card to interface with it. Luckily, after rummaging a bit more, I found an Adaptec AHA 2940UW adapter which looked like it would be perfect for the job: I installed the adapter into an old PC that “still” has a PCI bus (how far we’ve come!), connected the drive to it with a 50-pin SCSI ribbon cable, and put a terminator on the end of the cable (I could have also used 8-pin SIP resistors for which the drive has sockets).  The jumpers on the drive were already set to have a SCSI ID of 0, so I didn’t have to make any physical changes to the drive or the adapter. I booted up the PC, and was happy to see that the Adaptec card was correctly reporting the Viper 2150S as being connected with an ID of 0. So far, so good! The computer booted into Windows XP, and...

Read More

DiskDigger 1.5.5.1507 released

The latest version of DiskDigger is now available for download! Go to the DiskDigger website to check out the new features and download the updated program.

Read More