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.

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, 87 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.

Scenario: You perform a keyword search. FTK returns hits emails with attachments for the keyword you searched for. Since you are a good forensic examiner, you validate the completeness of the results. Unfortunately you notice that several attachments reference emails which are not present.Reason: The keywords hit only on the attachment content, yet not on the email message.

Problem: How do you locate the parent email which contained the attachment with the keyword hit?

Answer 1: Manually review each single item in your search result set. Using the “View the item in a different list – Email tab”. Ok, if you have only a few items.

Answer 2: Wait for a new version of FTK to come out and hope the feature to export parent emails is included. According to AccessData’s support form, it might be in a new release.

Answer 3: Use the attached Microsoft Excel spreadsheet. I recently worked a case where I was in the same situation and needed a somewhat automated tool. So I took it upon myself to write a VB macro that basically compares two columns from the FTK “Copy special…” feature.

Here is how you would use the tool.

Within FTK perform the following steps:

Step 1: Perform your search on emails with attachments within FTK

Step 2: Right-click in your search result pane and select “Copy Special …”

Step 3: Select “All Currently Listed Items”

Step 4: Only check the “File name” and “Attachment Info” column

Step 5: Select “Clipboard” within the Copy destination section.

Step 6: Click “Copy” button

Open the Excel spreadsheet (don’t delete any of the columns)

Step 1: Click on the “FTK Feed” worksheet tab

Step 2: Paste the results you have copied above into the “FTK Feed” worksheet.

Step 3: Within the “FTK Feed” worksheet, select column B2 and sort in “ascending” order

Step 4: Go to the “Locator” tab.

Step 5: Press the button…

The macro will crawl column A and compare it to column B. Column A is considered the “base”, which was extracted from the “Attachment Info” column. It is compared to Column B, which basically contains all files and email messages. If any value from column A is in B, you are lucky. If not, the macro will mark it in RED. This still means that you have to find the message within FTK, yet now you have a list to work with.
I know the tools doesn’t really solve the problem, yet it helps automate the process of locating the missing parent email.

I hope this helps.

Download: Find Parent Email (12.28 KB, 69 downloads), version:

NOTE: Use this tool at your own risk. Make sure you test the results.