analysis

On the First Day of APOLLO, My True Love Gave to Me - A Python Script – An Introduction to the Apple Pattern of Life Lazy Output’er (APOLLO) Blog Series

in , ,

I originally released APOLLO at the Objective by the Sea conference in early November. Since then I’ve received a surprising amount of positive feedback about various analysts using this tool or the accompanying SQL queries on their file system dumps to help a variety of investigations.  

It now time for a proper introduction. I will present this to you in what I’d like to call “The Twelve Days of APOLLO” a holiday themed (very, very loosely) blog series starting today! 

Why

APOLLO stands for Apple Pattern of Life Lazy Output’er. I wanted to create this tool to be able to easily correlate multiple databases with hundreds of thousands of records into a timeline that would make the analyst (me, mostly) be able to tell what has happened on the device.

iOS (and MacOS) have these absolutely fantastic databases that I’ve been using for years with my own personal collection of SQL queries to do what I need to get done. This is also a way for me to share my own research and queries with the community. Many of these queries have taken hours, even days to research and compile into something useful. 

My goal with this script is to put the analysis function the SQL query itself. Each query will output a different part of the puzzle. The script itself just compiles the data into a CSV or SQLite database for viewing and filtering. While this database/spreadsheet can get very large, it is still more efficient that running queries on multiple databases and compiling the data into a timeline manually.

Because this script is all based on investigator provided queries it is highly customizable. If an investigator only wants health data, they can elect to run only those query modules. Each query can be customized by the investigator relatively easy, if you don’t need that column – remove or comment it out! I’ve uploaded many queries that I think most investigators would find useful. It is my hope that other investigators create their own and share them with the community.

How

The script is a simple Python script that intakes what I’m calling modules. Each module is a single SQL query that pulls out specific data from a database. The module will also have some metadata about what the SQL query

The module is a text file that contains a few required items:

  • DATABASE – The exact name of the database to perform the SQL query on.

  • ACTIVITY – What this particular record is categorized as.

  • KEY_TIMESTAMP – The timestamp to be used as the key for timelining.

  • SQL Query – The query that is performed on the database. They query should extract one specific type of record from the database, thus a database may have many modules for very specific outputs.

Depending on what the user is looking for they can run one, some, or all the modules and it will output to either a CSV or SQLite database file.

Example Usage

The script is a simple python script that only takes only a few arguments. 

python apollo.py -output {csv, sql} <modules directory> <data directory>

There are two output options, a CSV file or a SQLite database. Please let me know if other outputs are required. Following that, the path to the module’s directory and the path to the data directory. The data directory can be a single directory full of the databases needed to parse or a full file system dump – the script will find the databases by name in the module.

An example of the output is seen below. Each SQL query run will have different output for that particular query and database in the output column. In the example we see everything from health steps/distance, to location, to application usage. The Key column contains the timestamp that each record is organized on, the Activity contains the type of record. The database and module columns contain which database and module parsed that information.

Challenges 

One of the main challenges with these Pattern of Life databases is access. Most of the really good forensically useful POL data is not easily accessible, particularly with iOS devices. With macOS devices we may need to deal with FileVault encryption or database level encryption. This script assumes you have good data to work with. Some databases may be available some may not be.

Feedback

While I primarily created this script for my use (don’t we all), I am open to feedback. If instead of using ConfigParser module files you want something else, let me know. If you need different output formats, let me know. I will consider all feedback.

I would appreciate all the help I can get. I’ve primarily tested these queries with a focus on iOS 11, however I know many will work on older versions and some have been tested with available data from iOS 12 (iOS Health). I’ve also tested running the script on macOS with Python 2.7 installed, it may not run as expected on other platforms. (FWIW: I will upgrade to python3 when macOS does.)

The script was just updated to be more efficient by Sam Alptekin of @sjc_CyberCrimes. Sam made the script much faster when running against full file system dumps. He was able to take it down from hours to run to mere minutes. Thanks Sam!

The Next Eleven Days

Each day will have a different topic that will guide you through the usefulness of the APOLLO framework. I focus primarily on iOS in these articles, but many of the queries can be ported over to macOS as well. I do intend to work on this in the future however I will discuss more on improvements later.

I will cover all sorts of topics in the next couple of weeks.

  • Device State

  • Media

  • Health

  • GUI Artifacts

  • Network and Communications

  • Connections

  • Application Usage

  • So much more!

Get APOLLO here and take it for a spin!

Day 2: On the Second Day of APOLLO, My True Love Gave to Me - Holiday Treats and a Trip to the Gym - A Look at iOS Health Data

Day 3: On the Third Day of APOLLO, My True Love Gave to Me – Application Usage to Determine Who Has Been Naughty or Nice

Day 4: On the Fourth Day of APOLLO, My True Love Gave to Me – Media Analysis to Prove You Listened to “All I Want for Christmas is You” Over and Over Since Before Thanksgiving

Day 5: On the Fifth Day of APOLLO, My True Love Gave to Me – A Stocking Full of Random Junk, Some of Which Might be Useful!

Day 6: On the Sixth Day of APOLLO, My True Love Gave to Me – Blinky Things with Buttons – Device Status Analysis

Day 7: On the Seventh Day of APOLLO, My True Love Gave to Me – A Good Conversation – Analysis of Communications and Data Usage

Day 8: On the Eighth Day of APOLLO, My True Love Gave to Me – A Glorious Lightshow – Analysis of Device Connections

Day 9: On the Ninth Day of APOLLO, My True Love Gave to Me – A Beautiful Portrait – Analysis of the iOS Interface

Day 10: On the Tenth Day of APOLLO, My True Love Gave to Me – An Oddly Detailed Map of My Recent Travels – iOS Location Analysis

Day 11: On the Eleventh Day of APOLLO, My True Love Gave to Me – An Intriguing Story – Putting it All Together: A Day in the Life of My iPhone using APOLLO

Day 12: On the Twelfth Day of APOLLO, My True Love Gave to Me – A To Do List – Twelve Planned Improvements to APOLLO

AirDrop Analysis of the UDP (Unsolicited Dick Pic)

in , ,

I saw this article “NYC plans to make AirDropping dick pics a crime” on Friday and it got me thinking. What exactly are the cops going to find if they do an analysis of a device, either the sender or the receiver? 

I’ve already done my fair share of analysis when it comes to the Continuity technology with Apple devices with Heather Mahalik at the SANS DFIR Summit in 2017. This article gave me a good reason to do a revisit on how AirDrop artifacts between mobile devices.

Testing Scenario

I’m using the scenario of sending of dick pics in the middle of Times Square as an example. I have two test phones, an iPhone 7 and an iPhone 6. The iPhone 7 belongs to “David Lightman” and the iPhone 6 belongs to “Jen Mack”.  Each device is on iOS 11 for this test. Instead of UDPs, Jen is going to be sending David USP’s instead, or Unsolicited Squirrel Pics – I suppose I need to keep this family friendly right?

AirDrop works over ad-hoc Peer-to-Peer networking over Bluetooth and Wi-Fi. When a user attempts to AirDrop someone a file it will determine who is within range and who is currently receiving AirDrop connections. This may be set to Contacts Only or Everyone (or Receiving Off for those who don’t want UDP’s, smart choice). Poor David has the setting to Everyone, he’ll get some surprises!

To send the squirrel photo to David, Jen used the native Photos application’s sharing feature to select a device to AirDrop the USP to. The only device within range that has AirDrop turned on and in a receiving mode is David Lightman’s iPhone.

Jen selects his phone and sends the picture. On David’s device he receives a pop-up, he can choose to Decline or Accept. 

AirDrop ID

Important to this analysis is an AirDrop ID. On devices this can be found in /private/var/mobile/Library/Preferences/com.apple.sharingd.plist. The keyword ‘sharingd’ is very important in this scenario as much of the Continuity artifacts can be found by searching for that process name. This plist file should be available in an iTunes backup and from any commercial forensic utility. 

Jen’s AirDrop ID is 3DAA769F9F23.

David’s AirDrop ID is E7D713098E3B, also take note of that the DiscoverableMode is set to Everyone. (Jen does not have this key, hers was set Contacts only.)

Artifacts from the Receiver’s (David Lightman) Device

Assuming that the receiver is the individual who would likely make the complaint to the cops, we will look at this iPhone first to determine what artifacts will persist and if they are show attribution to a certain device and/or owner.

Very few artifacts on the devices will actually show this connection happening. Let’s take a look at some of the main artifacts that I would explore if I had the case.

Unified Logs  

Logs can show lots of data and in great verbose detail. Unfortunately, these Unified Logs do not get backed up on iOS devices. The only way to extract them from the device is to get a physical file dump of the device (Jailbreak/Cellebrite CAS/GrayKey). (UPDATE: 12/04/18 - It has come to my attention from a commentor that these unified log files can be collected using the sysdiagnose process on iOS devices. I’ve tested this and they are in fact there. Funny enough, per Apple Documentation, it wants you to copy this archive off the device using AirDrop. 🤷🏻‍♀️ Not entirely the most forensically sound method but hey, data is data - get it with whatever means your legal team will allow. Thanks ‘G’!)

In this example on David’s iPhone, you can see the sharingd process start to scan, attempting to find peers (Continuity connections). During this process you will also see lots of wirelessproxd and bluetoothd activity as well since AirDrop uses Bluetooth and Wi-Fi services. You will also see references to AWDL or Apple Wireless Direct Link.

Follow the logs down a bit and you’ll start to run into some potentially identifying information. We are now starting to see records containing Jen’s device name “Jen Mack’s iPhone”. Pay close attention to the first record highlighted and you’ll see what looks like a MAC address, however it is neither the Bluetooth nor the Wi-Fi addresses. This address is generated different every time a connection is made, therefore not an ideal data point for attribution. 

Going back to the device’s name. This may lead you in the right direction, however anyone can name their device anything they want. I can call my iPhone X “Samsung S9” for instance, no identifying information and frankly a device that doesn’t even do AirDrop.

The next couple of highlighted sections (in red), show the start of the AirDrop connection. We can see an incoming request and start seeing records that include the AirDrop ID of Jen’s iPhone, 3DAA769F9F23. This is where I think attribution may be possible. This ID seems consistent across connections and different devices in my experience. It may be possible to tie this to an Apple ID or specific device. I have yet to find this connection however – it’s not part of the Serial, UDID, or various MAC addresses that I can tell. More research is needed here.

Next, in purple, is more metadata about the file transfer to include transfer status, media type, originating device name, source application, and associated transfer GUID.

In between these metadata records, it shows that it is transferring a file to /var/mobile/Downloads/com.apple.AirDrop/BA40D8CF-54E6-4B09-8F2F-717FB638174E/Files. Whether the user chooses Accept or Decline, the photo still gets transferred to the device.

Finally, the user receives an alert about the AirDrop’ed photo. Following this record is more details on how the user is alerted to the connection audibly and physically with alert tones and vibrations.

This particular AirDrop connect was “Declined” by David. This can be seen in the records below where the ‘selectedAction’ now shows Decline and a clean-up process has started. Highlighted in teal is the AirDrop connection closing.

If the user Accepted the AirDrop’ed photo, the logs would look like the following. The file would have been ‘accepted’ in the metadata records. Finally, since it is a photo – the default application Photos wants to import it into its files and databases. The AirDrop connection is also closed at this time.

Photos Database

Since the photo gets transferred into the user’s Photos database we can look there for hints. This is one file that does get backed up by iTunes and commercial forensic utilities. The Photos database is located /private/var/mobile/Media/PhotoData/Photos.sqlite on the physical device. 

The filename on Jen’s device was IMG_0007.JPG before it got renamed to IMG_0110.JPG on David’s phone. The original filename can be found in the ZADDITIONALASSETATTRIBUTES table in the ZORIGINALFILENAME column.

It is worth noting that the imported photo will carry the same EXIF data as the original on Jen’s device, in fact it is exactly the same photo (hashes should match). The file size and some timestamps get carried over into the Photos database. Other metadata items can be used to determine a photo from another device are the Height/Width, assuming it is from a different family of devices the pixels may be different.

In the ZGENERICASSET table, we have the same Height/Width, however some timestamps are updated to match the time of import via AirDrop. The ZDATECREATED timestamp matches the original creation of the photo. The ZCLOUDASSETGUID matches the GUID seen in the last few entries in the logs above. There does not appear to be any attribution data in this database.

Artifacts from the Sender’s (Jen Mack) Device

In the rare event that the Sender’s device was acquired, the related artifacts are below.

Unified Logs

Much of the logs look similar to the receiver. The sample below shows the sharingd process connecting to David’s AirDrop ID, E7D713098E3B and shows his iPhone device name. Again, the MAC address does not appear to be consistent and will change on every connection.

A few more lines down we can see some file conversion for the photo, IMG_0007.JPG (which apparently wasn’t needed). This is followed by an AirDrop transaction with the AirDrop ID of David’s iPhone.

Conclusion

The lack of attribution artifacts at this time (additional research pending) is going to make it very difficult to attribute AirDrop misuse. At best, if the cops are provided each device, they can pair the connections up – however this will require access to file system dumping services like Cellebrite CAS, GrayKey from GrayShift or performing a jailbreak to get the most accurate analysis. If the devices are named appropriately (ie: If Jen Mack’s iPhone was actually named ‘Jen Mack’s iPhone’) this may make an analysis easy, however I can see an instance where this can be abused to imitate someone else.

Curious about the USP, here you go. This was an advertisement in the DC Metro system, that for some reason whenever I saw it I giggled. 🤷🏻‍♀️

Do it Live! Dynamic iOS Forensic Testing

in ,
fuck-it-bill-fubar-well-do-it-live.jpg

Testing and forensics go hand in hand. You cannot be sure about a certain artifact on what it contains or what certain pieces mean without testing (and not just once, but over and over and on multiple devices and operating systems!) I probably do this more than most forensic investigators but it is something I obsess about. If I’m not absolutely sure, I test – always. Even then I will caveat it to very specific instances of my testing platform. I hope this article will help most investigators and researches up and running with dynamic iOS testing.

Requirements & Prerequisites:

  • Jailbroken iOS Test Device (the newer iOS the better, generally!)

    • iPad, iPhone, iPod Touch – doesn’t matter.

  • Familiarity with your jailbreak, every jailbreak is different and may provide different sets of utilities.

  • Patience – Testing is neither quick nor easy and can be downright infuriating sometimes.

Connecting to Your iOS Device

Most newer jailbreaks will come with some sort of SSH server on them, determine how to connect to it via SSH. All examples in this article will be performed on MacOS (big surprise) however it shouldn’t be impossible to do this on other platforms. I’ve written a couple of articles on accessing jailbroken devices:

To connect to your iOS device, you can use normal access via Wi-Fi, but this may lead to stability issues when copying off large amounts of data or general connection issues. You may want to access the device off the network instead. I like to use a utility from the libimobiledevice suite of tools called iproxy. This allows me to access it via a USB lightning cable and no network. This uses usbmuxd to create a TCP tunnel over USB. More info/similar tools here if you need it.

Run iproxy in a separate terminal window or set it up as a Launch Agent.

Usage: iproxy 4242 22 [UDID]

  • Local Port 4242 – You can use whatever port you like, I like 4242 (It’s the answer to everything.)

  • Device Port 22 – Default SSH port for most jailbreaks, except for Meridian that likes to be fancy and run on 2222 (customize as required).

  • Device ID (UDID) is optional but useful if you are connected to multiple devices at a time.

Nothing will be displayed apart from “waiting for connection” until you connect a device. Once you do, you’ll see the devices UDID and port number in the iproxy output.

In another terminal window, SSH into it using the local port you setup with iproxy. You can use localhost or 127.0.0.1, whatever your personal preference is. As for the username you have two choices – root or mobile, root is obviously root and mobile is a limited user account. I always choose root but worth knowing about both. Also FWIW, make sure you change the default iOS password of these accounts from ‘alpine’ with passwd if it’s connecting to any network at all.

Executing Non-Native Binaries

Depending on which jailbreak you are using, certain utilities may not be made available to you. With any luck the basics will be provided by the jailbreak using Jonathan Levin’s binpack. If you want to upload your own, you’ll have to sign them and provide entitlements to run them on the device.

One tool that I really like for file monitoring (discussed later) is fsmon by NowSecure. I’ve attempted to build this from source for iOS but once uploaded I get an error that I don’t know how to fix (granted I didn’t research it much). Instead I pulled the binary from the DEB package provided here https://github.com/nowsecure/fsmon/releases.

I can unarchive the DEB archive using The Unarchiver (My favorite unarchive on macOS!). I then unarchive the data.tar.gz using The Unarchiver or native utilities to get the ‘/usr/bin/fsmon’ binary.

The fsmon binary is Fat or Universal binary meaning it can have multiple architectures stuffed into a single file. This particular binary has arm_v7 (32-bit) and arm64 (64-bit) Mach-O binaries.

We will need to thin this binary to a single architecture to get to run on our device. I chose arm64 for this since I have a 64-bit device (iPhone 7). You can thin/sign/entitle on the Mac too using jtool but just in the event you are not working from one (and why not!? I’m sitting here judging you right now.) I’ll upload the binary to the device and run the same commands.

Using scp I can upload this binary. For my particular jailbreak I needed to create a symlink (ln -s) to the scp binary provided by Jonathan’s binpack before I could use it.

Using scp with the CAPITAL P argument (why the port flags are not consistent between SCP and SSH is beyond me) and our iproxy port of 4242 to copy fsmon to root’s home directory, /var/root.

Now if we try to run it from root’s home directory, it will fail (“Operation no permitted”) since binaries on newer iOS’s can only run from certain directories. That’s not the only problem, it also needs to be signed and entitled.

First let’s deal with only one binary, in order to sign and entitle we need to extract the 64-bit binary from Fat binary. We can do with a couple tools. If you are on macOS and have lipo (get it? fat binary…lipo…thin…sorry, this makes me giggle every time.) I will output to a file named fsmon64 so I know it is the 64-bit binary and upload it to the device.

lipo fsmon -thin arm64 -output fsmon64

Since I’ve uploaded mine to the device already, I don’t have lipo on the device I will use Jonathan’s jtool instead.

jtool -arch arm64 -e arch fsmon

This will extract the 64-bit binary to a file named fsmon.arch_arm64 into the current directory. You will have to change the permissions to execute it (chmod 700), but we still need to deal with signature and entitlements. As shown below it has an adhoc signature and no entitlements.

To get the signature and entitlements from any binary you can run the following jtool command, example below is from the dd binary. Notice it has a Platform Binary signature and the “platform-applications” entitlement.

jtool --sig --ent <binary>

If I tried to execute the fsmon binary in /var/root, I’ll still get the “Operation not permitted” error. If I move it to a directory, I should be able to execute from I’ll get a different error, “Killed: 9”, next step is fixing the signature and entitlements.

Extract the entitlements from another (working) binary on the device using jtool and save this to a file named ent.xml for use later.

jtool --ent /jb/bin/dd > ~/ent.xml

Using jtool again, lets sign fsmon.arch_arm64 as a platform application and provide the binary the entitlements we just extracted. Verify it worked with (--sig/--ent) and execute it. Yay, working binary! (Feel free to rename as necessary, again I use fsmon64 or just fsmon.) On newer versions of jtool, ‘platform’ is no longer required.

jtool --sign platform --inplace --ent ~/ent.xml /jb/bin/fsmon.arch_arm64

Reviewing Directories and Files

Quick iOS partition review - take a look at the /etc/fstab file. There are two primary partitions (and a baseband one if you’re into that kinda thing.) The first mounted on / is the system partition where the operating system files are contained. It is theoretically read only as noted by the ‘ro’, however recall that we just put the fsmon binary in /jb/bin. When it comes to jailbreaks that ‘ro’ is more of a reminder of what it is on stock devices. The data partition mounted on /private/var is where all the user data is, this is the primary partition that you’ll be using for your forensic analysis. All native and 3rd party application plists, databases, and other files are located there.

In order to find data associated with a particular application I can use the find command and the bundle ID associated with an app. 

find /private/var -ipath *net.whatsapp.Whatsapp*

In the example below, I started looking for WhatsApp data. This is a good initial triage of the applications data, this doesn’t get me all the files but it helps direct me to the related directories. You’ll notice that GUID in the file path, this will be different for all applications across all devices and will change.

Going to the following directories and perusing the data will help me determine what type of data a certain application stores and how it stores it.

  • iCloud Artifacts:

    • /private/var/mobile/Library/Caches/CloudKit/com.apple.bird/57T9237FN3.net.whatsapp.WhatsApp

  • /private/var/mobile/Library/Application Support/CloudDocs/session/containers/57T9237FN3.net.whatsapp.WhatsApp

  • The combination of the ‘Shared App Group’ and ‘Data Application’ directories will generally hold most of the user data associated with an application.

    • /private/var/mobile/Containers/Shared/AppGroup/133904F3-EAA0-48E9-905C-90BB93A7DDA2/

    • /private/var/mobile/Containers/Data/Application/97AD4FDE-2089-455A-8B21-06E4E2225626/

  • It is worth mentioning that if you are looking for the Applications bundle the Bundle ID will not get you there, instead look for the name of the App.

    • /private/var/containers/Bundle/Application/6B6D4621-845A-4EE7-AECF-D68CC00E5C4E/WhatsApp.app/

Finding the right directory/directories for the app in question can be time consuming. One of my favorite tools that solves this issue is cda. Using the same method above, I’ll upload this binary to my device.

As shown below, all you need to provide cda is a search term. I provided it the term ‘whatsapp’ and it provided me the same directories (more even) as above. If you’re not quite sure what you are looking for yet, provide it a single period ‘.’ and get a listing by Bundle ID. It is worth noting that this will only provide app data, if you are doing research on native iOS data you won’t get it using this – time to dig in and find it the hard way.

Looking into one of the WhatsApp directories, I start to get a feeling for what data an application is storing. You will normally find SQLite databases, plist files, media, log files and other files related to an application. ~90% of what you’ll be looking at are SQLite databases and plist files, so I’ll focus on those for this part of the article.

Starting with SQLite databases, we can use sqlite3 (provided by the binpack) on the device to triage the database. My process is to look at the database names first and see if anything is obvious. If I’m looking at a chat app, I’ll look for keywords like chat, message, etc. I’ll focus on WhatsApp’s ChatStorage.sqlite database for this example – seems like a reasonable choice for chat messages. Using sqlite3, I’ll dump the table listing and peruse it for anything interesting. Seems to me that ZWAMESSAGE would contain the chat messages!

Using a SQL SELECT statement I can dump the contents of this table; however this is where sqlite3 may not provide the best analytical view. In this case I might use scp to copy it off the device and use a GUI based SQL viewer to create queries and join multiple tables. (FWIW, I like DB Browser for SQLite). Need a SQLite reference guide, check out the one Heather Mahalik and I created for our classes (FOR585 – Advanced Smartphone Forensics, FOR518 – Mac Forensic Analysis and Incident Response).

I will still use sqlite3 for per-message testing to answer different questions.

  • What does xyz flag in this column mean? Are 0 and 1 the only values?

  • If I send a piece of media, what does it look like in the database? Is it stored in a different table?

  • Message direction or contact information which column stores that?

I will run the same query over and over testing different flags in different columns as I populate data manually on the device. Does this take time? Sure does! But it’s the only way to be sure. Applications are known to change database schemas and values as their application updates.

sqlite3 ProTip: Ctrl+D to quit out of the sqlite3 shell

Next let’s dive into those pesky plist files. For third party applications I will usually start in the applications Preferences directory. The Preferences directory will usually contain a configuration plist file containing some useful bits like usernames, servers, usage timestamps, keys, and passwords. Yes, plaintext, non-obfuscated passwords! 🤷🏻‍♀️

The example below is one for Whatsapp (specifically the one located in the Shared App Group directory. There may be multiple for each application.) I’m using jlutil (Jonathan’s interpretation of plutil, the native macOS utility, to view this plist.)

Another option is plconvert which will convert it to a text file representation and show a less-than-helpful representation on standard out. It will also output to an XML file, here named tmpfile by myself. I consider this slightly less “clean” as it will leave these converted files everywhere on the system, but it’s all personal preference. I will say the plconvert is more useful from a timestamp interpretation and data BLOB stance.

File Monitoring

Say you’re testing a application that has the ability to take photos using the iPhone camera. Where are those photos stored? Or how about if you toggle one of the switches in the Settings application, where is that stored? In a database or a plist file?

An easy way to figure this out is to use a file system monitor, it should at least point you in the right direction. As shown above I prefer to use the fsmon utility from NowSecure, however Jonathan’s binpack includes fs_usage which provides the same data. I prefer the layout of fsmon’s output.

In the example below, I took a picture of my sidekick Elwood with the Camera app on the iPhone while running fsmon. (I’d like to say he helped with this article, but he just slept all day next to me. Cats don’t make the best research assistants.) In the fsmon output you can see that when I took a picture, the “Camera” process saves the picture in a few temp files before it finally saves it in the DCIM directory as an HEIC file (the newer iOS image format) and creates a thumbnail image for the Camera app, PreviewWellImage.tiff.

I hope this helps everyone getting started doing their own iOS forensic research!

(In the rare event anyone wants to see my sidekick Elwood…here is the pic I took. Super Lazy.)

Slides and Script! From Apple Seeds to Apple Pie & Introducing APOLLO: The Apple Pattern of Life Lazy Output'er

in , , ,

I had the privilege and honor to present at the first ever Objective by the Sea Mac Security Conference yesterday in Maui (hardship, right?). It was only the first day and it was absolutely spectacular, I may have to make this one a regular! I can easily recommend attending this conference.

I presented From Apple Seeds to Apple Pie - an Apple Pattern of Life talk (mostly focused on iOS devices). You can find the slides in my Resources section.

I also just released a (very) beta version of APOLLO (Apple Pattern of Life Lazy Output’er) on my GitHub page. The TL;DR of the script: Take all the creepy databases that Apple writes events to, perform individual SQL queries on them to pull out investigative useful data, and combine them into another SQLite database for easier/quicker analysis and correlation.

This script and its modules are still in the testing phases so please be careful when using this on real cases. Expect more modules and testing to be released, I’m holding some back due to some timestamp issues and other are partially written up.