Two tidbits of information that I want to highlight from this care are:
1) Ensure that your tool(s) recognize the data they are trying to parse
2) SQLite queries can be your friend. Or your enemy. But try to make them your friend
"Ensure that your tool(s) recognize the data they are trying to parse"
This issue came up when I had the joy of parsing several gigabytes of data from iOS backups, going back as far as 2007. Now, as you may or may not know, the iTunes MobileSync backup data structure has gone through several changes during the course of their existence. Originally the data was saved as ".mdbackup" files, which contained some header information at the very beginning of the file. Then iTunes moved on to a combination of .mddata and .mdinfo files, where the header information was contained in the .mdinfo file, and the actual data was contained in .mddata files. Then they did away with file extensions completely, which is where we still are today (The fine folks over at AppleExaminer have a nice post on the older backup structures, you can read it here if you wish.)
Since the backup structure is very widely known and has been around for a long time, I figured that commercial tools available on the market today could handle the backups with no problem. What I was very surprised to find out is that, in fact, processing them is a VERY big problem! On this particular case I used AccessData's MPE+ to process the backups. It did a fine job on the "newer" files, however, the older data (I believe it was not only the .mdbackup files that it had an issued processing and that it was also the .mddata/.mdinfo files, but I didn't take the time to do additional research because once a tool was confirmed as not pulling out the data, I move on to something that can).
In the end, I ended up using MobileSyncBrowser (available for $20) and an old Perl script I wrote when initially performing iOS backup research to ensure the results were valid. MSB is, in my estimation, a very under-appreciated tool that everyone performing mobile forensics should have in their toolkit.
Tweeting about my experiences with MPE+ |
"SQLite queries can be your friend. Or your enemy. But try to make them your friend"
This statement partially falls in line with my aforementioned problems with the iOS backup parsing, but it also applies to SQLite data in general. You should be aware of how to pull at least some, if not all, of the data that your tools "extract" from SQLite databases to ensure they are working properly and not, for example, adding an additional seven days to a time stamp or anything like that. You do not need to know how to get the 100% same result (although, admittedly that can benefit you greatly if you do know how to get the same result) but at least having the capability to run "SELECT * FROM Messages" in a SQLite browser will go a long way in validating tools, techniques, and processes.
On an unrelated note to iOS backups, I also found the parsing the database file "Envelope Index" (and subsequent files) on OS X to with some SQLite to be incredibly helpful. While I am sure there are better ways to parse the data, this statement allowed me to quickly get an idea for email addresses/subjects/dates to be looking for with regards to potential items of interest. I couldn't find any SQLite queries online to extract this data, so if you know of a better way to parse it, please do share!! You can throw some LIKE statements in there toward the end as well, particularly in "addresses.address", to try to find email addresses of interest.
SELECT addresses.address as "Email Address", addresses.comment as "Display Name", DATETIME(messages.date_sent, 'unixepoch') as "Date Sent", DATETIME(messages.date_received, 'unixepoch')as "Date Received", DATETIME(messages.date_last_viewed, 'unixepoch')as "Date Last Viewed", messages.subject_prefix, subjects.subject, messages.snippet FROM recipients LEFT JOIN addresses ON recipients.address_id = addresses.ROWID LEFT JOIN messages ON recipients.message_id = messages.ROWID LEFT JOIN subjects ON subjects.ROWID = messages.subject ORDER BY messages.date_sent ASC
Always ensure that you know what your tools are doing behind the pretty GUI. "Trust but verify" is a term that it used a lot in our field and verifying the results can make a HUGE difference in the overall completeness of your forensic examination!!
Basic Envelople Index SQLite query
Always ensure that you know what your tools are doing behind the pretty GUI. "Trust but verify" is a term that it used a lot in our field and verifying the results can make a HUGE difference in the overall completeness of your forensic examination!!
This was exactly what I needed to parse the contents of the Envelope Index SQL Lite database!! Absolute life saver. Thank you!
ReplyDelete