Well, I just wasted hours of my life that I’ll never get back.
“But Mike,” you say concerned, “Whatever do you mean? How can I help?”
You see, I foolishly tried to install a copy of Windows 8 64 bit as my OS to use with Cellebrite’s Physical Analyzer and MSAB’s XRY Complete. And I got…bubkes.
Oh the software seemed to run right, yes indeedy. But the dongles wouldn’t work. Neither WIBU or HASP.
“Mike, did you check to see if Win 8 was supported by Cellebrite or MSAB?”
I thought I’d give it a shot. I wanted it to work. I figured as long as I was updating my wheezy XP box, I’d go to the latest OS….
…and I got burned. No soup for me.
Ahh, well at least I’m a good example. Three things though
1. Dongle vendors UPDATE YOUR DRIVERS
2. DON’T TRY TO USE WIN 8 for PA or XRY (yet!)
3. Don’t be like me – RTFM!
Have a good one
I’ve been on the road now for about 14 days teaching the Teel Tech Smart Phone course with Dr. Gary Kessler. His help, suggestions and mentoring have been invaluable.
We are currently teaching the course in Veenendaal NL at Data Expert to groups from the Dutch Police. During the four classes Gary and I have been co-teaching he has developed a Perl script to reverse engineer and study SQLite records.
In its current iteration the parser will accept any binary file and scan it assuming it contains sqlite records. This means you can carve out sections of unallocated space containing possible SQLite record fragments and reverse engineer the structure. This is helpful for decoding orphan records.
The file is invoked as per the graphic below
You can download the perl script here-
I hope this helps you in your forensic quests.
Det. Bob Elder posted an excellent article on a recent success they had up in the Great White North with an HTC Wildfire and JTAG. Read it here
Way to go Bob and Co., thanks for sharing!
My man Bob “I’ve got Hockey Hair” Elder has written an fantastic post on performing a jtag examination on Android Phones.
Check it out – its completely awesome!
Check it out! ViaForensics has just enhanced ViaExtract with the ability to brute force swipe passcodes. Its available to licensed users. Check it out at the below link.
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.
Having noted the schema of the message table within the sms database, lets take a look at a record in a hex viewer.
The record is structured as is show in the below graphic.
In addition the record uses the values in the below table to represent the values of the bytes.
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.
The next byte is the length of our record header including this byte – which is 19 bytes.
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 0×27 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.
The next byte, 0×4 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.
The next byte, 0×81 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
To find the length of the header we now refer to the table and do our calculation as normal
This is indeed the length of the text message. The message is straight hex to ascii.
The next byte in the header is 0×1 and in the schema refers to the flags row. The value in this case is 0×02 which means that it is an incoming text.
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 (0×11 = 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.
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.
Josh Lowenshon just published an article on Cnet’s Apple Talk reporting that marketing firm Distimo says that Google ”will be 40,000 applications short of evening out with Apple’s overall volume by the end of June, and will catch up completely in July.”
Since there seems to be so much attention right now on geo location data on Android and iOS devices, I’d thought I’d write a little piece on the location of the Google Maps navigation app data on Android.
There is a big requirement to getting at the Google Map data however – your phone needs to be rooted. Don’t worry though, extensive how-tos exist on the internet and you might luck out and have a solution in one click – with SuperOneClick.
SuperOneClick written by CLShortFuse is available on shortfuse.org or on the XDA Developers forum. I have tested it and it really does work on most phones. The software is at version 1.9.1, is super easy to use and is well documented on the XDA forum.
Of course you need to hear the warning: you can brick the phone by rooting it.
Not only that but although all the commercial vendors place an agent on an Android device to gather information, rooting the phone changes the firmware so it is fundamentally way more intrusive. Things to ponder.
Once you have your phone rooted, you need to navigate to the /data/data directory and find the com.google.android.app.maps directory. You will need a method of doing that. I suggest using the Android SDK and adb. You can find out how to install the SDK at http://developer.android.com/sdk/index.html. I’ll write up a how-to on using adb in another post but you should be able to figure out how to navigate to the directory and use adb to pull out the directories you are looking for to your local computer. You will need a functional knowledge of some linux commands however.
Once in the com.google.android.app.maps directory head over to the databases directory and pull out the SQLite databases in there. The ones in particular you are looking for is da_destination_history and search_history.db
Good luck in your forensic endeavors.
Nice mention for Katana Forensics, MSAB and Cellebrite!
Yes, you read the title right, for only four dollars you can get a tool to research Android phones. The tool – Root Explorer – is from Speed Software and readily available in the Android Market. There is one caveat though- it requires like it’s name implies for your phone to be rooted.
While rooting your Android Phone is beyond the scope of this post, I’ll give you a peek at the tool to whet your appetite.
Here’s the description from the App Market listing -
Root Explorer is the ultimate file manager for root users. Access the whole of android’s file system (including the elusive data folder!).
Features include SQLite database viewer, Text Editor, create and extract zip or tar/gzip files, multi-select, execute scripts, search, remount, permissions, bookmarks, send files (via email, bluetooth etc), image thumbnails, APK binary XML viewer.
Wow, that seems pretty cool doesn’t it? Turns out it is, as we shall see below.
I have root explorer installed on an HTC Incredible on the Verizon network. Here is a screenshot of the entire filesystem as seen by root explorer.
I recommend clicking on menu when first starting Root Explorer and setting a few preferences before using it for research.
Most of the preferences are self explanatory, however you may wish to change the zip/tar directories to one of your own choosing. Also if you are researching a particular directory and don’t wish to constantly scroll through the file system to find the place you are looking for, it make sense to set your home directory to the one you are currently interested in.
The main directory we will find most of the interesting data is /data/data/. This is the directory that holds all the applications in the file system including contacts, call records and SMS.
Perhaps we are looking for the contacts on the phone but are not sure what directory we need to look in. Root Explorer has a search function that will find all instances of a keyword in the present directory.
As the above search results screen capture shows the com.android.providers.contacts directory contains the contacts (people app) of the phone and a whole lot more. The subdirectory databases contains a SQLite database – contacts2.db- with the data we are interested in.
Root Explorer has additional options it can perform on the file by long clicking to bring up another menu. In addition to routine file operations such as rename, copy and move, you can view file permissions and extended information about the file.
Perhaps even more exciting are the other options that are available by scrolling -Add Bookmark , Send, View as text, Open in text editor, Zip this file and Create Tar.
By clicking on the contacts2.db file Root Explorer will launch a built in SQLite viewer first listing all the tables in the database.
The tables can then be further selected for viewing.
If SQLite Editor from Speed Software is purchased (around $3 USD), additional functionality is enabled such as record filtering.
Finally Root Explorer allos you to look at thumbnails and to examine text based files (such as XML)
Root Explorer is an invaluable tool for the mobile forensic researcher- and for around four dollars can you afford not to have it?