A fellow examiner at the Lakewood PD had to examine an iPhone and was researching the sms.db format.  Under normal circumstances, the sms.db is a SQLite database, however, and for currently unknown reasons, when loading the sms.db database file into SQLite, it only provided the most recent SMS record.  We were quick to load the database file into a HEX editor and identified that additional SMS records were in fact still present within the file.  This discovery led to my involvement in writing an EnScript to parse the SMS record section within the sms.db database file.

Well, if you need to parse out SMS records from an iPhone sms.db file, you might find the following EnScript useful.

Usage:

1. Copy the EnPack you downloaded into your <EnCase-Install>/EnScript directory. You may want to create a sub-folder called “Custom”, so 3rd party scripts clearly separated.
2. Load the exported sms.db file into EnCase as a single file.
3. Blue-check the sms.db file.
4. Double-click the script “CellPhoneMessages”.
5. The console view will provide status information.

NOTE: No guarantee is made that this EnScript is error free. Please use at your own risk and validate your findings.

Please report any bugs or suggestions to EnScript Support

Developing, maintaining and hosting this content does take time and financial resources.  Your support is much appreciated.

The EnScript can be downloaded here: iPhone_SMS_DB (38 KB, 17 downloads), version: v1.0.63 (Requires EnCase 6.14.3)

ver 1.0.63: February 13, 2010

(+) improved SMS record recognition

ver 1.0.59: December 07, 2009

After receiving another sms.db file from a fellow examiner in Italy, I had the opportunity to update the script with the following:

(+) account international country codes prefixes
(+) improve record identification for parsing
(+) “fuzzy” record parsing if a reference; such as a name is used instead of a phone number.  It is fuzzy, because I am trying to identify a date based on other records, since the record structure does not have a fixed offset for the date.  This makes parsing “non-phone#” records more difficult.  Although it has a high success rate, I hope to improve this feature in the near future.  Records that are “unparsable” are still stored in the log file created.

ver 1.0.58: November 15, 2009

Note: This script should be considered a BETA release, as it was developed based on only one sms.db file. Other sms.db files may contain more complex sms record structures. If you are able to share other sms.db files for research, please contact us.

I just received the new Tableau Forensic Duplicator (TD1) to put it through its paces. So the first test was a to image a 40GB drive. I did so by using the 2GB DD image file options. The imaging with the unit went as expected.

When adding the DD images to EnCase I ran into a little snag however. Wrote a song about it, wanna hear it? Here it goes…

Started EnCase, created case, opened the “Add Raw Image” dialog.

Then went ahead and opened the dialog to add the “Component Files”.

Selected “Image.001″ + SHIFT + selected “Image.021″.

Clicked “Open” in the dialog box, and clicked “OK” to add the raw image.

The result: Nothing, nada, nichts; well if you call Unused Disk Area nothing.

So I tried again. This time by only selecting the first of the raw DD images. No luck either. This time I got at least an error message.

I began to question the Tableau’s DD format. So I fired up FTK Imager and tried loading the image, which worked without any problem.

Not wanting to give up I reached out to EnCase support and it turns out there is a simple, yet very important way to add raw image files.

I did everything right up until selecting the actual raw image files.

The critical thing to remember is the ORDER in which the raw image files appear in the “Component Files” window when adding raw image files. So in my case above, notice that on #1 position it shows “image.021″. Not good.

Solution:

The trick is to actually select the raw DD image files in reverse order such as:

Select “Image.021″ + SHIFT + select “Image.001″.

If you select files any other way, you can drag and drop the various component files within the “Add Raw Image” window if needed.

Hope this helps others.

Hello everyone –

I thought I share a little EnScript I wrote which deals with long file path export issues. The script I wrote basically does the following:

This EnScript plug-in is used to identify and export entries which would exceed the path depths limitations of 245 characters during a normal export. The script will loop through entries that are blue-checked and exports entries which exceed the above limit based on the FullPath column and the specified export path.

The script will export entries that exceed the 245 character limit. Once exported it will also “uncheck” them. This should leave you with items you can safely export using the native EnCase Copy Folder… function.

The script will create a subdirectory called “pathdepth” inside the user specified export folder and export data using the Logical Size of an entry. In addition a log file is created which contains the reference to the original entry details.

Since the script generates a flat export, it renames the files with a prefix to guarantee uniqueness. This prefix is actually the MFT record number on NTFS volumes (File Identifier).

Please report any bugs or suggestions to EnScript Support

Developing, maintaining and hosting this content does take time and financial resources.  Your support is much appreciated.

ver 1.0.31 : 22 September 2009
+ (fixed) total byte size of selected files keeps increasing if going back and forth with new destination path
+ (fixed) split file type extension into own column in export log
+ (fixed) exclude case name in path upon export
+ (fixed) remove CaseName from path calculations
+ (fixed) add original file name to export log
+ (fixed) uniform export format: with MFT FileIdentifier available (file.ext_id.ext), without MFT FileIdentifier availabe (file.ext_hash.ext)

The EnScript can be downloaded here: Long File Path Export (32.93 KB, 88 downloads), version: 1.0.31 (updated 09/22/09) (Requires EnCase 6.11.2)

ver 1.0.9 : 10 October 2008
+ added MD5 hash value to the exported file name if no MFT file identifier is available.
File Identifier is only available if the MFT is within the evidence file. In case of a LEF
that doesn’t have the MFT, it shows a zero.
+ added check if entry is folder. Folders are not considered for export.

This script was written and tested in EnCase v6.11.2. Please keep in mind that his is the first (beta) version.

NOTE: No guarantee is made that this EnScript is error free. Please use at your own risk and validate your findings.