Category: Hex Dumps

Profile Forcing

The phrase “profile forcing” refers to using an extraction profile of mobile model numbers in and around the model you are seeking to examine when that model is either officially unsupported or for some reason won’t work with the existing profile. Though not a sure thing, this has proved to be a successful attack on problematic phones and yielded information on what might have been a lost cause otherwise.

I used this tactic just today when trying to grab a physical image of a Samsung GT-s5322A. It was officially not supported for a physical or logical download in XRY and Cellebrite. In fact, the phone was being problematic with the NSPRO box as well. As my frustration mounted, I reached for the UFED again and tried a physical dump using the s5230 profile.

Suddenly a beam of light shot from the sky, the clouds parted, and a heavenly choir began to sing…

Well, the extraction started and I did the Geek dance of joy…over 250 MBs of juicy data – yum!

When using this method always be sure to validate the findings and report the success to the vendor so they can do additional research and add it into their profiles for others to enjoy equally in their forensic endeavors.

Mahalo nui loa Cellebrite for making me look like a rock star in Saudi Arabia today!

Advertisements

SQLite Records

I am facinated by SQLite.  But before you say “Mike you really need to get out more and get a life! ” consider this -the two most popular smartphone operating systems of today,  iOS and Android, use SQLite databases to store important information such as contacts, SMS, and call records. That’s a lot of users – both victims and perpetrators. Have you ever wondered how the SQLite structures its records? An understanding of the SQLite record architecture  is crucial to validating the output of forensic tools and for knowing where to look for evidence – including that elusive brass ring, deleted information.

SQLite database images always begin with a well know 16 byte signature which in ASCII is represented by “SQLite format 3” followed by a null byte. The database image header is 100 bytes in length. A full discussion of the database image header can be found on the official SQLite page. Amongst other things a well formed serialized database image will have a database schema or table layout. Knowing the schema of tables is a key bit of knowledge as it will provide the guide to the record header and subsequent record contents.

We will be using a record from the sms database of a first generation iPhone running iOS version 3.13 as an example for this post. Below is a screen shot taken of the schema of the message table using my favorite Mac SQLite editor Base.

Schema

Schema

Having noted the schema of the message table within the sms database, lets take a look at a record in a hex viewer.

SQLite Record

SQLite Record

The record is structured as is show in the below graphic.

SQLite Record Structure

SQLite Record Structure

In addition the record uses the values in the below table to represent the values of the bytes.

Header Values

Header Values

So let’s take our example and work through the record header. The first byte of course is our record length – in this case the record is 110 bytes long. The second byte is our key.

Record Length and Key

Record Length and Key

The next byte is the length of our record header including this byte – which is 19 bytes.

Record Header Length

Record Header Length

The next byte is null which indicates that the value is not included in the record. This would have been the ROWID from the schema. The next byte corresponds to the address row in the schema. The byte 0x27 is odd and greater than 13. According to our table this corresponds to text and the byte length is derived by taking the decimal value subtracting thirteen and then dividing by two.

39 -13 = 26 / 2 = 13

We can see from the below graphic that the address or telephone number is indeed 13 bytes in length.

Address Length

Address Length

The next byte, 0x4 corresponds in the schema to the date of the SMS. This is a four byte value and is stored in epoch time. The value here is 1296980309 and translates to Sun, 06 Feb 2011 08:18:29 GMT.

Date and Time Stamp

Date and Time Stamp

The next byte, 0x81 is, as is indicated in the schema, the text message – but it is unique. SQLite uses a compression method based on Huffman coding to store values greater than 127 bits. In this instance the byte in the record header indicating the text message is \x81 or 129 and therefore greater than 127. Since the method uses 2 bytes up to a decimal value of 16,383, we can assume the next byte \x0D is also for the length of the text message. The method to calculate the length of the text message is as follows – where X = the first byte value and Y = the second byte value –

(X-128) x 128 + Y

Calculated out this comes to the below

(129-128) x 128 + 13
\x142

To find the length of the header we now refer to the table and do our calculation as normal

(N-13)/2
(129)/2
64

This is indeed the length of the text message. The message is straight hex to ascii.

Message Length

Message Length

The next byte in the header is 0x1 and in the schema refers to the flags row. The value in this case is 0x02 which means that it is an incoming text.

Flags

Flags

The last byte of significance in this record occurs at offset 17 in the record and as our table indicates is a value greater than 13 (0x11 = decimal 17). Since the calculation is N-13/2 the value we have here is 2 bytes and this refers in the schema to the country. In our example this is 0x6A 0x6F or “jo” for Jordan.

Country

Country

I hope that you find this post useful in your forensic endeavors. This post would not have been possible without the generous help and counsel of DC Shafik Punja of Calgary and Sheran Gunasekera of ZenConsult Pte Ltd.

Research regarding Huffman encoding in SQLite records was  conducted using Murilo Tito Pereira’s article “Forensic analysis of the Firefox 3 Internet history and recovery of deleted SQLite records” published by Elselvier.

Cellebrite UFED Physical Analyser 2.0

Cellebrite just recently announced the release of their solution for performing dumping and analysis of mobile devices – Physical Analyser Pro 2.0.

Physical Analyser Pro is sporting a slick new UI, enhanced searching functionality, plugin chaining , enhanced decoding for iPhones and promises to be a huge leap forward in taking cell phone examinations to deeper level. Of particular interest to the community is bound to be support for working with chip off dumps.

When Cellebrite announced the release, there was a rumor that the update was only available as a new purchase. Chris Shin and Jason Rogers of Cellebrite quickly set the record straight – Physical Pro Analyser 2.0 is available as a firmware update with a current subscription.

I’ve attached the release notes for review – a syopsis of some key features follows – and plan to do a detailed review of the product for the community in the upcoming week. All in all it looks like just what the community needs!

Key Features of UFED Physical Pro Upgrade include:
· Deep access to internal memory and data inaccessible by logical methods (deleted text messages, call history, pictures, phonebook and videos)

Phone lock code/user password extraction
Open Source Plug-in support: author, collaborate on, and utilize custom search and value parsing algorithms
Plug in chain manager
Intelligent string finder
Python scripting
Hierarchical “tree” view for efficient and fast navigation
Advanced search capabilities both to novice and expert users
Customizable search, parsing and report functions
Exclusive physical support for Samsung and LG devices
Proprietary, forensically sound (read only) boot loaders for most supported devices
Phone internal data (ex. IMSI history, past SIM cards used, past user lock codes, Memory card and Bluetooth history where supported)

Latest Supported Features for Physical Pro !

iPhone deleted SMS, Phonebook , and Call Logs extraction
Visualization of GPS Data –Direct link (KML file) to Google Earth and Google Maps for tracking purposes
Windows Mobile devices Email and deleted mail extraction
Blackberry devices Email extraction/ (Blackberry Messenger, Blackberry PIN)
Physical Extraction of IDEN Phones ( over 30 models )
· iPhone decoding: includes calendar, call logs, contacts, text messages, email, locations (Wi-Fi and Cell Tower), MMS, notes, web history, web bookmarks (favorites), Skype (contacts, calls and chat), Facebook contacts, navigation applications, Bluetooth and more

Android, iOS iPhone, (Allows bypassing of user lock code) and Windows Phone 7 Physical dump capability coming soon

Physical Analyzer 2.0 Release Notes

Open Source iPhone Tool

I am very excited about this open source tool for reading iPhone backups and the iPhone!
iPhone Analyser!!!!

This thing kicks ass and IT’S FREE. Its doing as good a job if not better than some commercial tools. Did I mention its free??

All you need is a Java framework running and you have iPhone extraction bliss!

Some of the cool features include SQL view and HEX! Check it out and make it better for everyone!

Highly reccomended!

Converting Binary Logs in Flasher Research

I have been playing around with the Advanced USB Port Monitor after reading Bram Mooij’s great article in DFI mag.

I was running into an issue though when I used the port monitor to sniff the traffic from an Octopus box – the monitor kept crashing when I tried to view the data that was transfered. I knew I used the method outlined by Bram correctly since the output of the port monitor was several megabytes larger than the output of the box, however I couldnt get to the hex dump since the program crashed.

The solution lay in converting the binary log file created by the monitor into a text file with just the transferred hex. This is accomplished by selecting “Tools -> Convert binary log file” from the upper menu. A dialog box will then appear.

Binary Log Conversion

Select the log you want to convert and the output directory. Now select “unlimited” in Bytes per dump, “if transfered data exists” under Process Data, and Output Hex data, Output ASCII data, Align and Transferred data only. The resulting output should look something similar to the below.

Convert Output

Binary Conversion Output

Adjust the output settings as you need. I hope this helps you in your forensic endeavors.

New Tool On The Block

I was just turned onto a brand new tool in the mobile forensics game; Phone Image Carver. Phone Image Carver is the latest creation of the Austrailian Software Development company GetData. For those who don’t know about GetData they have excellent carving and recovery tools and are the makers of Mount Image Pro which has many useful forensic uses.

According to the website-

Phone Image Carver is an easy to use sector by sector data carver for phone dumps or cell phone image files. Currently supports:

Hex;
DD;
Bin;
RAW
Easily recover more than 300+ file types using reliable automated file carving scripts.

Most interesting and at $69.95, this should be a handy edition to your mobile forensic toolkit.

The lads at GetData have graciously offered me a test spin of the tool to get up to speed on it (I should also disclose that they mention yours truly’s papers in the Help File; without recompense). I look forward to giving the application a knock about and reporting on it here.

Watch this space!