Blackberry IPD files and FTK 3.2

I was curious as to FTK's ability to analyze RIM Blackberry IPD files.  I imported 7 backup files - some were "Autobackups" and others were manually created backup files.  The process of importing them was as simply as pointing to a live directory, and you are given the option of creating a image of the files or working from the "live files".

After the processing was complete (took about 1 minute), here's what the files looked like within FTK:

When you open up each of the IPD archives, you will note 89 different fields; some are populated with information and some are empty.  The fields which have data within them will most often produce HTML files which start with rows_0000000_0000xxx.html.  The .html report can be viewed and read quite readily in the "filtered" or "natural" mode.  There are some other formats as well.  The image below shows the database-type format in which the data appears.

An exception to the "row_000..." format is noted below.  You will note that the directory structures indicates that the parsed data is stored within "blobs".  Each of the 89 fields had a folder titled "blob", although many did not contain any data.  In the absence of any noteable file structure, I would think that this would refer to Binary Large Objects (string of binary with no associated code).  In the example below, the "Content Store" folder had several files.  Several of the files were images, which had file names blob_Data_00000xx, where xx was a number.  The numbers appeared to be incremental.  (image was purposely blurred for privacy).  Other files within the folder include exif data for the images - FTK "Properties" show that these files were created by the FTK carving process.  FTK was able to carve out images from the IPD files, although the number of images I retrieved (4) would suggest that the images were not truly "carved" from any undeleted area.  The properties of the carved images show that they were carved from "Blackberry backup files/blackberrybackup.ipd>>tables>>Content Store>>blobs>>blob_Data00000xx.>>Carved [120].jpeg" (where xx is an incremental number).  The path references a full-size photo, whereas the carved image appears to be thumbnail size.

When you open up the Case Overview tab, you'll see that many of the files have been categorized into the noted fields.

Email was nicely extracted, and displayed in traditional FTK format.  The fields appeared to parse out quite nicely.

And lastly, FTK has always been known for it's indexed search capability.  The following two images reinforce the power of FTK in finding results within the compound IPD file.  I would suspect that use of the Indexing feature will make it easier to identify areas where evidentiary information may be stored; whether the information was parsed out or not.

When you compare the output with that of ABC (Amber's Blackberry Converter), FTK does not parse out nearly the amount of information available from ABC; but, it does appear to provide us a more "forensic" approach to data whereby the data can be more easily validated against the raw data.

I'm am guessing that more fields will be retrievable as versions develop.  Overall, another great improvement in FTK 3.2.