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.



Updated Windows Registry and Mac resources & Jad's Software....updated

As several sites have rightfully pointed out....Accessdata has made a huge jump ahead with their recent release of FTK Imager v3.0.  (not to mention FTK 3.2 and their most recent "Volatile tab.")   Just finished testing it today by mounting physical images and using VFC to virtually boot XP and Win7 systems.  Flawless!    While wandering around their site (actually looking for updated RSR files to add to their most recent Registry Viewer version), I stumbled across two additional documents that I believe are very worthy of a good read - or at least printing out as a permanent reference.

Registry Quick Find Chart - a very recently updated 34-page reference documenting Registry locations for the standard 5 Registry files.  The document has a few new columns in the document - one which lists what versions of Windows the reference pertains to (ie: XP, Vista or Win7) and a second column that states when the Registry reference is updated (immediately, when document opened, at logon...)    This document would also be great starting reference to initiate further research on Registry locations and extractable artifacts.  D/L it....know it....print it and keep it handy!

Mac System Artifacts - another reference document which provides 7 pages of Mac Artifact locations.  With FTK's amazing ability to parse out the Mac OS (including Plists), this document is another one to print off.  Updated in 2010.

Jad has also updated three of his applications:
Internet Evidence Finder (IEF) - updated to v3.6 to handle recent updates to Facebook Live chat.  Commercial - Cdn $49.00; Free for Law Enforcement.
FChat - updated to v1.20.    Commercial - Cdn $29.99
FJF - Facebook JPG finder - updated to v1.2.1.  Currently free for use.

Kindle 3G Wireless Reading Device - forensically speaking

Having just acquired the new model of Kindle, I got to wondering what kind of information was stored on the device and if necessary, how would I go about accessing this information in the most forensically-sound manner possible.  Here's what I found.

1.  Using a Digital Intelligence Tableau Ultrablock USB write-blocker, I connected my forensic computer to the device through the micro-USB cable that was provided with the Kindle. 
2.  Realizing that it was necessary to power on the device, I did so.  I noted the date/time to compare this with the date/time stamps that were likely to change upon boot. 
3.  When powered on, I immediately checked to ensure the 3G/Wireless was turned off.  Select "Menu", toggle the five-way controller up to "Turn Wireless Off" and select the five-way controller (center button).  Alternatively, I could conduct the acquisition within our Faraday tent.
4.   Using FTKImager v2.9.0.5, identified the physical drive attributed to the Kindle.

5.  As noted, the drive recognized as "Kindle Internal Storage" with a size of 3240MB.  I noted that this differs from the stated size of the device (4GB).  Specifically, Amazon states the device has "Storage 4GB internal (approximately 3GB available for user content)."  I then acquired the physical drive as a RAW (DD) format to allow a more robust selection of analysis tools.

Here's what the partition looks like:

And contents of the "documents" directory:

6.  Made note of the filesystem, and VBR header - as noted in the following screenshot.

The filesystem is FAT32, formatted with mkdosfs - DOS formatting within a Linux environment.  From looking at the USER partition which was available, I'm asking whether the SYSTEM partition is ARM Linux Kernel (?).

While admittedly, my Kindle had not been populated with a lot of user interaction, the Kindle definitely does not appear to readily give up information.  It was obvious what books and documents were on my Kindle, and what the last document I accessed was, but as far as other artifacts,  my brief analysis was not overly productive.  I have surfed the Internet, opened several websites and likely populated the device with considerable Internet History.  I could not readily locate any of this history.

Just for heck of it, I through Jad's Internet Evidence Finder at it - nothing.   I'm thinking that a GREP search for Internet History might have more success.  I'm also interesting in running a search for my Wireless Access Point SSID and see what other artifacts might show up.

Other things I found:
- IMEI (3G) information on the device.
-  lots of deleted information.
- a significant number of dictionary terms (including in the unallocated space).

Eric Huber has a posting on the Kindle at A Fistful of Dongles - more great information.

More to come....perhaps I'll see how a boot CD such as Caine interacts with the device.  I'm going to continue to see what the imaged USER image is willing to give up in terms of forensic artifacts.  ps..EnCase will also be involved.

Any thoughts or ideas are welcome.