Category Archives: forensic tool

Android, forensic tool, iOS, Open Source, Uncategorized

My Handy Smartphone Toolbox

2 Comments

I realize it’s been awhile and these tools have really changed since my last post in 2015.  Have they changed for the better? Not necessarily. Some tools update so quickly that they lose the basics. For that reason, please test and validate your tools and never trust what is advertised. Your goal should be to determine how the artifacts were placed on the device, not that the artifact exists on the phone. By this I mean – how did it get there? Did the phone suggest it, the user searched for it or was it synced to the device?  This level of analysis is something your tool cannot do for you, which is why you probably read blogs like this and learn what you can trust and where you must apply your smartphone skills.

One of the most common questions I am asked is “which tool is the best?” Guess what? There isn’t just one! And I strongly recommend you use more than one, especially for analysis and sometimes even for acquisition (read my blog on iOS 11 from Oct. 2017).  These tools are picky and seem to like one device better than another and parsing is not the same across the board. You must know the tool strengths and be able to defeat the weaknesses.  To help you out, I am listing the tools that I prefer and my reasons why. These tools are not perfect and they DO NOT have a “Find Evidence” button. Is your tool missing from this list? Offer me a demo and I will try to find time to test it and give feedback. 🙂

As I stated in the last blog I wrote on this topic, I am not going to delve too much into acquisition tools and methods. There are so many out there. Some of the ones I rely on to get my data are Cellebrite UFED (not for iOS devices), Cellebrite Physical Analyzer (for iOS devices), Oxygen, iTunes and my good ‘ole Mac.  I always tell my students to try everything when you have a smartphone on your desk. You don’t know how that device was used and what settings are already enabled behind that locked device. You may surprise yourself when you are able to grab everything with the click of the “acquire evidence” button on your tool of choice. However, it’s not always that easy so verify that you have unencrypted data even if you get a dump.  Additionally, I recommend you always get a physical dump and logical or backup to help you parse the data.  Make sure you test your tools and test them often. Don’t let one hurdle knock you down.

The list below doesn’t include all smartphone tools, but simply the ones I rely upon. If you have others you like, please comment and share. I love hearing what others are using because I don’t have time to test every tool and keep up with the quickly released updates. So, help me out here.

The Heavy Hitting Commercial Solutions (Not in any particular order):

*NOTE: DO NOT RELY ON YOUR TOOL TO TELL YOU HOW DATA WAS PLACED ON THE DEVICE—THAT REQUIRES YOUR KNOWLEDGE! VERIFY ALL LOCATION ARTIFACTS!!!

  • Magnet – IEF Mobile – Great for Internet evidence and parsing 3rd party application data. One of the best iOS app parsers out there. AXIOM is now the up and coming tool, but does have some growing pains, so test it for yourself.  In both of these tools, the Custom/Dynamic App finder is so useful as location additional databases of interest that you should examine for relevance.  This tool easily ingests image files from other tools.
  • Physical Analyzer – Probably the best analytical platform out there specific to smartphone tools. It doesn’t parse everything, but it gives us a platform for analysis where we can leverage it find the evidence with some manual carving and hex searches. PA doesn’t seem to omit files it doesn’t understand, which seems to be happening in other tools.  Best physical search feature for locating data in raw hex, other than in file system dumps of iOS devices. The new fuzzy models plug-ins are fantastic as they identify databases commonly associated to 3rd party applications that aren’t parsed by the tool. This tool easily ingests image files from other tools.
  • MSAB XRY/XACT – One of the only tools that consistently provides access to the raw files (databases, xml, dat, plists, BLOBs, etc.) during a logical acquisition. Guess what, to recover data that the tools don’t parse you need the raw files. This tool give you access to them! XRY is strong at parsing strange backup files from smartphones, such as those created with Samsung Kies.
  • BlackLight – Great tool that can run on a Mac or PC! Primarily supports iOS devices, but I have seen students force load Windows Phones and Android devices into the tool to use it as a file system examination platform. However, it was designed to support iOS devices.  Haven’t you heard that you should examine a Mac with a Mac? A wise examiner once told me that and it still resonates with me. This tool uniquely pulls out Google Maps and Apple Maps searches that the other tools commonly misinterpret. If you hear me talk about BlackLight, you know that I rave about the Windows hard drive support. Strange that the Mac guys are doing so well on Windows. 😉
  • Oxygen – This is one of my new favorites because I am constantly examining 3rd party applications. This tool highlights files the applications use and where they are stored. Guess what? That list is now your cheat sheet. Pretty sweet! I also love the built in PLIST Editor (hex and xml views) and the SQLite editor.  This is the best tool for BlackBerry and BlackBerry 10 devices. It acquires the event log and provides a secure way to create a BB backup file. Also counts out all those nasty little databases for you. I wrote a recent blog on Oxygen, so read it if you want more details on this tool. Just like most of the others, there are growing pains, so test it and validate that it’s showing you all of the data.
  • Elcomsoft – I use the Phone Password breaker to crack locked BlackBerry device, BlackBerry and iOS Backup files. I also use this tool to pull cloud data. It’s awesome! Runs on both a Mac and PC.

The Other Guys (Not free, but not as expensive as the heavy hitters):

Not in any particular order…

  • Andriller – This tool can crack passcodes for locked Android devices and provides logical parsers for iOS, Android and Windows 3rd Party Application files. Free for LE and well worth it for everyone else. The fee is small the results are huge! https://andriller.com/
  • Sanderson Forensics tools – Great SQLite support! The SQLite Forensic Toolkit is so useful in recovering deleted data and for converting those pesky timestamps. I love how this tool shows you how the queries are run and what’s happening when you press a button. New to SQLite forensics – start here!  Stay tuned for Pauls’ new SQLite Forensics book (it’s fantastic and is not a sales pitch for his tool!)  Paul will provide a free demo upon request. http://www.sandersonforensics.com/forum/content.php

Open Source and Other Solutions:

Parsers developed by the community. These people are rock stars and often give back by developing scripts to help us sift through application and smartphone data. Check out their blogs and githubs to get the latest scripts that I rely on to parse the massive amounts of data the commercial tools just don’t support.

  • Mari DeGrazia (http://az4n6.blogspot.com/)
    • SQLite-Deleted-Records_Parser – A must have for unveiling deleted data in SQLite databases.
  • Adrian Leong (http://cheeky4n6monkey.blogspot.com/)
    • His blog rocks! Adrian hits on hard topics. Read it! (HEIC/HEIF on iOS 11 is one of his latest). Also, all of his scripts have been tested to work in the SANS SIFT.
    • Honestly, he has so many scripts out there – go check them out! (Facebook Messenger, SQLite parsers, coordinate converters and more!)
  • Jon Baumann was a student of mine recently who decided to build scripts to fix the things that were broken in the tools. LOVE THAT! https://github.com/threeplanetssoftware/
    • His new sqlite-miner script parses databases containing BLOBs that contain human-readable data. Not only does it identify the contents, it parses them and exports them!
  • Autopsy – The Android Analyzer module hasn’t been updated in a while, but it still supports parsing some items from Android devices. It also gives you access to the File System directory tree faster than any commercial tool out there. Most tools make you wait to see the file system during parsing – not Autopsy. Also, the keyword searching and carvers are top notch. http://sleuthkit.org/autopsy/
  • iBackupBot – Great for parsing iOS backup files. Works on both Macs and PCs. Make sure you have the latest version that supports iOS 10 and 11.

As I always say, I am sure I have forgotten to give credit to some where it’s due, so I am requesting that you help me out. What tools really help you and how? Is there one script that you found and cannot live without? Do you use something more robust than a Java decompiler for mobile malware? Is there something parsing double Base64? Don’t know what that means??? Take FOR585 and Cindy Murphy, Lee Crognale and I will teach you. Our course is offered almost every month and all over the world. Check it out for585.com/course.

Keep digging in that Hex! The data is there and it’s your job to find it.

forensic tool, iOS, Uncategorized

Time is NOT on our side when it comes to messages in iOS 11

5 Comments

Image result for apple iPhone X meme

This is going to be a series of blog posts due to the limited amount of free time I have to allocate to the proper research and writing of an all-inclusive blog post on iOS 11. More work is needed to make sure nothing drastic is missing or different and to dive deeper into the artifacts that others have reported to me as currently being unsupported by tools.

From what I have seen thus far, I am relieved that iOS 11 artifacts look very similar to iOS 10. This is good news for forensicators who see iOS devices and have adapted to the challenges that iOS 10 brought.  Prior to writing this, I was referred to a blog post on iOS 11, that was an interesting read (thanks Mike). I suggest you also check it out as it pinpoints what is new in iOS 11 in regards to features: https://arstechnica.com/gadgets/2017/09/ios-11-thoroughly-reviewed/5/

Understanding what the OS is capable of doing helps us determine what we need to look for from a forensic standpoint. From what I have seen so far, the major artifact paths have not changed for iOS 11. Key artifacts for normal phone usage appear to be in the same locations:

  • Contacts- /private/var/mobile/Library/AddressBook/AddressBook.sqlitedb
  • Calls-/private/var/mobile/Library/CallHistoryDB/CallHistory.storedata
  • SMS – /private/var/mobile/Library/sms.db
  • Maps – /private/var/mobile/Applications/com.apple.Maps/Library/Maps/History.mapsdata – Still missing? Refer to my blog post from Dec.

When I test an update to a smarphone OS, I normally start with basic user activity (create a new contact, place some calls, send messages, ask for directions, etc.) and then I dump my phone and see what the tools can do.  For this test, I created both encrypted and unencrypted iTunes backups,  used PA Methods 1 and 2 and did a logical extraction with Oxygen Detective. What I found is that not all tools parsed the data in the same manner, which is to be expected. (I also plan to test more methods and tools as time allows and for my FOR585 course updates.)

To get this post done in a timely manner, I found one item that has always been parsed and jumped out as “missing” or not completely supported.

iMessages and SMS  in iOS 11 were the first items that jumped out as “something is off…” and I was right.  I sent test messages and could not locate them in the tools as easily as I have done in the past. I normally sort by date, because I know when I send something.  Up until this release of iOS, we could rely on our tools to parse the sms.db and parse it well. The tools consistently parsed the message, to/from, timestamps, attachments and even deleted messages from this database. Things have changed with iOS11 and it doesn’t seem that our tools have caught up yet, at least not to the same level they were parsing older iOS versions.

One of the most frustrating things I find is that the tools need access to different dumps in order to parse the data (as correctly as it could for this version). For example, Oxygen didn’t provide access to the sms.db for manual parsing, nor did it parse it for examination when the tools was provided and iTunes backup. This had nothing to do with encryption, because the passcode was known and was provided.  UFED isn’t the same as PA Method 1 and 2 (you have heard this from me before), but it’s confusing because most don’t know the difference.  This is what it looked like when I imported the iOS 11 backup into Oxygen.  Believe me, there are more than 3 SMS/iMessages on my iPhone.

However, I when I dumped my iPhone logically using Oxygen Detective, it parsed the SMS and provided access to the sms.db. When I say “parsed” the sms.db, I am not referring to timestamp issues at all, those will be addressed in a bit. Here is what my device looked like when I dumped it and parsed it in Oxygen.

Spot the differences in the messages? Yep, you now see 48,853 more! Crazy… all because the data was extracted a different way.  I also tested adding in the PA, Method 1 image and those message numbers were different, but the sms.db was available and parsed. You really have to dump these devices in different ways to get the data!

Bottom line – add the sms.db to something you need to manually examine for iOS 11 to ensure your tool is grabbing everything and parsing it. The rest of this blog is going to focus on just that – parsing the sms.db in regards to changes found in iOS 11.

Let’s take a look at what is the same (comparing iOS 11 to iOS 10):

  • SMS and iMessages are still stored in the sms.db
  • Multiple tables in this database are required for parsing/joining the messages correctly

What is different (comparing iOS 11 to iOS 10):

  • Additional tables appear to be used?
  • The timestamp is different for iOS 11 – SOMETIMES!

Here is what I found (so far). The tools are hit or miss. Some tools are parsing the data, but storing the messages in a different location, others are parsing the message content, but not the timestamp… you catch my drift…  What I recommend? Go straight to the database and take a look to make sure the tool(s) you rely on are not missing or misinterpreting the messages (wait… didn’t I just say that – YES, I did.)

Thetimestamp fields for the sms.db are all over the place now. What I am seeing is that the length of the Mac Absolute value varies between two formats and both of these formats can be stored in the same column. This is why the tools are struggling to parse these dates.   Additionally, the tables in the sms.db differ in how they are storing the timestamp. So, if your tool is parsing it correctly, excellent – but still take a look at the tables.

Here are some examples of what this mess looks like. The column below is from the chat table in the sms.db. Notice how it has the traditional Mac Absolute value ( number of seconds since 01/01/2001), while others are a 18 digit Mac Absolute values and some are 0 (sent messages).

Additionally, I was seeing some that were 18 digits that were not appended with 00s at the end. The “conv start date” on the left column is from the messages table in sms.db and this timestamp has not changed. As expected, your tools handle this one nicely. The table on the right column is from the chat_message_join table, and this caused a little havoc as well due to the variety of timestamps in the column. Converting this wasn’t fun! Thanks Lee for your help here. You, my friend, ROCK!

When I first ran my SQL query, I noticed this one pesky date that wasn’t converting. This is because it was the timestamp highlighted above and I needed to beef up my query to handle this.  If you see a date that looks like the one below, something is up and you aren’t asking for the data to be rendered correctly. The query below will handle this for you.

Don’t believe me that this causes issues yet, take a look at how it looked in one tool.

The dates and times are not parsed correctly.  I found that the dates and times appear to be consistent when the tools are parsing the 9 digit Mac Absolute timestamps from specific tables. Otherwise, expect to have to do this yourself.  Here is where it was correct, but this wasn’t the case for all of my messages sent using iOS 11.

If you need a sanity check, I always like to use the Epoch Converter that I got for free from BlackBag to make sure I am not losing my mind when dealing with these timestamps. Below, you can see it was parsing it correctly (Cocoa/Webkit Date). Also, I love that it gives you both localtime and UTC.

This leads me to the good news -below is the query that will handle this for you. This query is a beast and “should” parse all sms and iMessages from the sms.db REGARDLESS  of the iOS version, but only columns that I deemed interesting.  (Note that I state should, because this has only been run across a few databases and you should report any issues back to me so they can be fixed.) Take this query and copy and paste it into your tool of choice. Here, I used the DB Browser for SQLite because it’s free. I limited some columns to the ones I care about the most, so you should make sure this query isn’t missing any columns that may be relevant to your investigation.

 

SELECT
message.rowid,
chat_message_join.chat_id,
message.handle_id,
message.text,
message.service,
message.account,
chat.account_login,
chat.chat_identifier AS “Other Party”,
datetime(message.date/1000000000 + 978307200,’unixepoch’,’localtime’) AS “conv start date”,
case when LENGTH(chat_message_join.message_date)=18 then
datetime(chat_message_join.message_date/1000000000+978307200,’unixepoch’,’localtime’)
when LENGTH(chat_message_join.message_date)=9 then
datetime(chat_message_join.message_date +978307200,’unixepoch’,’localtime’)
else ‘N/A’
END AS “conversation start date”,
datetime(message.date_read + 978307200,’unixepoch’,’localtime’) AS “date read”,
message.is_read AS “1=Incoming, 0=Outgoing”,
case when LENGTH(chat.last_read_message_timestamp)=18 then
datetime(chat.last_read_message_timestamp/1000000000+978307200,’unixepoch’,’localtime’)
when LENGTH(chat.last_read_message_timestamp)=9 then
datetime(chat.last_read_message_timestamp +978307200,’unixepoch’,’localtime’)
else ‘N/A’
END AS “last date read”,
attachment.filename,
attachment.created_date,
attachment.mime_type,
attachment.total_bytes
FROM
message
left join chat_message_join on chat_message_join.message_id=message.ROWID
left join chat on chat.ROWID=chat_message_join.chat_id
left join attachment on attachment.ROWID=chat_message_join.chat_id
order by message.date_read desc

Here is a snippet of what this beauty looks like. (Note: this screenshot was taken prior to me joining attachments – aka MMS).

I always stress that you cannot rely on the tools to be perfect. They are great and they get us to a certain point, but then you have to be ready to roll up your sleeves and dive in.

What’s next – applications, the image/video files that apparently aren’t parsing correctly, interesting databases and plists new to iOS 11 and the pesky maps. That one is still driving me crazy! Stay tuned for more iOS 11 blogs and an upcoming one on Android 7 and 8.

Thanks to Lee, Tony, Mike and Sarah for keeping me sane, sending reference material, testing stuff and helping me sort these timestamps out. Like parenting, sometimes forensicating “takes a village” too.

Image result for keep charging forward meme