iLEAPP: iOS Logs, Events, And Properties Parser

Introducing a Python 3 scripts that merges all my previous iOS digital forensics and incident response scripts (DFIR) into one.

iLEAPP

Many thanks goes to Jessica Hyde (@B1N2H3X) for suggesting I start merging my standalone scripts into a unified tool during OSDFcon. You are the best Jess. Also tons of thanks to Phill Moore (@phillmoore) for helping me with coding one of the artifacts. I'm really grateful for Christopher Vance (@cScottVance) and Geraldine Blay (@i_am_the_gia) for allowing me to create scripts based on their areas of iOS research. Last but never least my respect and appreciation to Sarah Edwards (@iamevltwin)for her trailblazing work in iOS DFIR and for showing me the existence of the Mobile Installation logs.

Name:
    iLEAPP: iOS Logs, Events, And Properties Parser

Download:
    https://github.com/abrignoni/iLEAPP

Purpose:

1. Create a central point for iOS scripts made by the writer.
2. Serve as a open source tool (OST) option to validate commercial DFIR tools.
3. Be a zero cost option to forensic examiners that are tasked with iOS mobile forensics but lack the budget to acquire a full suite of commercial DFIR tools.
4. Enable me to work on my Python coding skills as related to DFIR. 

Features:

• Python 3 script
• Coded and tested in macOS Catalina.
• Script can parse an iOS full file system directory directly from a .tar file or it's decompressed contents. 

Current parsing capabilities:

• Mobile Installation Logs.
• https://dfir.pubpub.org/pub/e5xlbw88
• Nested bplists inside a iOS KnowledgeC.db field.
• https://abrignoni.blogspot.com/2019/03/ios-bplist-inception.html
• https://thinkdfir.com/2019/03/21/updating-the-knowledgec-parser/
• LastBuildInfo.plist
• https://blog.digital-forensics.it/2019/12/checkra1n-era-ep-5-automating.html
• IconState.plist
• https://blog.digital-forensics.it/2019/12/checkra1n-era-ep-5-automating.html
• iOS version 11, 12, & 13 Notifications content
• https://abrignoni.blogspot.com/2019/08/ios-12-notifications-triage-parser.html
• Caveat: iOS 13 notifications are now identified by their app GUID and not the app bundle ID. The app GUID can be matched with the app bundle ID name via the contents of the applicationState.db file. For an example see here. Working on an artifact for iLEAPP that will do that for the examiner.
• ApplicationState.db bundle ID to app GUID parsing and correlation.
• Celular Wireless Information Plists
• https://blog.digital-forensics.it/2019/12/checkra1n-era-ep-5-automating.html

Development:

    The scripts utilized are fully open source and can be used and modified by others. Looking forward to sharing and merging these with other OST DFIR tools.

    I hope to be able to add the following in the near future:

1. Graphical user interface for point-and-click selection of source tar file or extraction directory.
2. Progress bar or indicator of parsing activity to the user.
3. Additional artifacts like applicationState.db query results, KTX snapshot extraction, and all sorts of plists.

Usage:

ileapp.py [-h] -o {fs,tar} pathtodir 

iLEAPP: iOS Logs, Events, and Preferences Parser. 

positional arguments: 

pathtodir Path to directory

optional arguments: -h, --help show this help message and exit -o {fs,tar} Directory path or TAR filename and path(required).

Internals:

    The script has 3 key components.

1. ileapp.py
2. search_files.py
3. ilapfuncs.py

The ileapp.py script has a python dictionary list where the keys represent the parsing function names and the values are the search patterns to be executed. Here is an example the contents of the dictionary.

The flow is fairly simple. 

• The values portion is used to traverse the tar file or logical file system for a match per the saerch_files.py script. If traversing a .tar file a temporary folder is created in the reports folder and the matching file/s are exported and stored there for parsing by the ilapfuncs.py script per the key function name. For a logical file system search no temporary file creation is needed since the file/s are already in a ready for parsing state. 
• The ilapfuncs.py functions perform the analysis and write the proper reports.
• The temporary folder is deleted after parsing. I am still debating if the temporary folder should be left in place for easy report validation.

Any of the key:value pairs can be deleted and/or new ones added. Any new key value pairs will be called by ileapp.py as a function that should be defined in ilapfuncs.py.

CAVEAT:

Some of the artifacts are dependent on knowing which iOS version is being worked on. The ileapp.py scripts depends on the iOS version output from the lastbuild function. If this key is removed from the dictionary of items it will break both the knowledgeC and iOS Notifications functions. It is suggested (to the point of requirement) that the lastbuild key remains in the dictionary and it that precedes all the aforementioned ones.

Conclusion:

Some, if not the majority, of the artifacts these scripts will eventually parse will not be of my discovery or making. One of the reasons I code things others have done, and even done better, is that it enables me to be grow by having something to compare my development with. Many times we think that the way to excellence is to come up with things no one has seen before, to imagine something never thought of. It is my experience that the only way to be better at what we do is to understand that which has already been done. Only then will the unknown be apparent to us. To depend and take advantage of the works of others that have come both before us or are currently with us on our DFIR journey and to contribute in any way we can is the way to successfully work our cases faster, more efficiently, to give justice to those who need it, and to feel joy while doing it. 

To that end, as always, I can be reached on twitter @AlexisBrignoni and email 4n6[at]abrignoni[dot]com.

   

iOS Imgur app - A Realm database example

Short version:

The Imgur app keeps user generated post data in the following Realm database:

/*app folder GUID*/Documents/default.realm

All images accessed via the app, from images posted by the user to those seen as one navigates through the content the app presents, are found in the following location:

 /*app folder GUID*/Library/Caches/com.hackemist.SDImageCache/default

 App screen snapshot can be found at:

/*app folder GUID*/Library/Caches/Snapshots/imgurmobile/*.@3x.ktx

For details on Real databases and how to approach their examinations see here: https://abrignoni.blogspot.com/2019/11/realm-database-storage-primer-for.html
It is of note that Cellebrite Physical Analyzer has a database browser that is compatible with Realm databases.

For details on iOS snapshots and how to visualize them see here:
https://abrignoni.blogspot.com/2019/09/ios-snapshots-triage-parser-working.html
It is of note that Magnet Axiom has the capability of displaying .ktx images natively.

For details on how to access a full file system of an iOS device see following:

1. Checkra1n jailbreak: https://checkra.in/
2. Install OpenSSH via Cydia. See the acqusition section for SSH here: https://abrignoni.blogspot.com/2018/08/finding-discord-chats-in-ios.html

I will update the post with a Checkra1n step-by-step guide that is being prepared by colleage soon.

It is of note that Magnet Acquire, a free tool, allows the creation of a full file system .tar file from a Checkra1n jailbroken device.

Long version

The Imgur iOS app is one of the growing number of software development project that have moved from using SQLite databases to the Real database NoSQL data storage type. For details on how to approach Realm databases see my previous post on the topic here: https://abrignoni.blogspot.com/2019/11/realm-database-storage-primer-for.html

This post is not an exhaustive study of the Imgur iOS app. I use it as an example of the type of app that is used by millions of people that might come across your case work and your tools might not have the default capabilities to address at this moment.

In order to locate a particular application folder, in our case the one for Imgur, within our full file system extraction see Nike iOS app example here: https://abrignoni.blogspot.com/2018/08/ios-nike-run-app-geolocation-self-join.html

After locating the application directory we can exported from the device or from the tar file for analysis. So far these are the steps:

Jailbreak the device using Checkra1n.

macOS only for now.

Install OpenSSH via Cydia.

Open the checkra1n app and install Cydia. then open Cydia and install OpenSSH.

Locate the applicationstate.db file in order to identify where the Imgur user generated data resides. See previous links for steps required.

Connected from macOS to the phone via SSH. Cyberduck app. Username root and password alpine.

Export the application directory.

To figure out which one you want see the applicationstate.db entry for the app you want.

Open the application directory for analysis.

The bottom window shows the application directory folders.

Imgur analysis

The Realm database we are looking for will be located in the Documents directory. As seen in the next image my macOS computer identifies the datastore with a red and bluish icon. This is due to having already installed Realm Studio. This application allows us to access the contents of Realm databases. It can be downloaded here: https://realm.io/products/realm-studio/

Get the default.real file.

Open the file with Realm Studio.

Data

The data seen in the previous image corresponds to me making a post to Imgur using the app. The post includes an image. The left column identifies the objects and the right pane has the corresponding properties. This database separates the data in the post form the image that goes in the post. The image post has an entry in the DraftImage object at the top. This screen shows the post tile and some metadata about the post.

remoteidentifier

The DrafPost object contains two important properties, the remoteidentifieer and the accounintidentifier. The remoteidentifier is the post number used by Imgur in the website URL. The accountindentifier is self explanatory. It is tied to the user.

The DraftImage object has the name of the image in the remoteidentifier field. To confirm one can go to the post and right-click save the image. The name provided will be the same as the one found in the database. The DraftImage object also contains additional metadata as image width and height.

As you can imagine the analysis of a database made of object can get really difficult pretty fast as more objects are created and stored. One technique is to export the data as a JSON file and use Python or other tools to create a report of the contents.

Export file to JSON.

The following is a screenshot of the output of my JSON-to-HTML Python script for the exported JSON data.

Easier to visualize

I find it easier to visualize the data in a nested columns and rows format. The script can be found here: https://github.com/abrignoni/JSON-to-HTML-and-XLS.

One last artifact I wanted to highlight are the application snapshots. These are screenshots of what the app was showing on screen when the user places the app in the background in order to have a different app in the foreground. Be aware that the ktx snapshot is not compatible with regular image viewers outside or macOS and Magnet Axiom.

Snapshot

For details on snapshots see @iam_the_gia's blog post here: https://gforce4n6.blogspot.com/2019/09/a-quick-look-into-ios-snapshots.html

For details on how to identify ktx files and how to convert them to png see the blog post here: https://abrignoni.blogspot.com/2019/09/ios-snapshots-triage-parser-working.html

Conclusions

By generating more test data we can surely identify additional objects and artifacts of interest. The main takeaway from this exercise is the existence of app datastores that go beyond the usual SQLite we are used to. The same thing can be said of JSON and protobuff data stores. The only permanent thing in the digital forensics field is the fact that there will always be change. It is upon us to discover, test, and publicize new changes. Only then our tools will be updated, evidence won't be overlooked, and justice will be served.

As always remember to validate all findings and be aware I can be reached on twitter @AlexisBrignoni and via email 4n6[at]abrignoni[dot]com.