Tuesday, March 17, 2020

Trust but verify: Formats, timestamps, and validation

One of the most important aspects of digital forensics is the need to validate tool output. Sadly it is also one of the most overlooked by practitioners. The reason for this is obvious, NO TOOL IS PERFECT. No matter the vendor, no matter how gifted the developer is. No tool is perfect. Heck, nothing is (except the wife of course.) But when perfection, or as close as we can get to, is the goal then we have to test.

One of the easiest ways to conduct a quick sanity check validation is by comparing the output of one tool to the output of another. But what happens when you only have the output of one tool and nothing else? When the extraction is only parsed by the tool set that created it?

You actually do.
For some years now Cellebrite has been using the disk archiver format (http://dar.linux.free.fr/) to collect full file system data from target devices. This format is known as DAR. It goes without saying that UFED4PC and Physical Analyzer (PA) are THE industry leading tools with incredible technology behind it. Anyone that has used their products can attest that they are one step away from magic (and that step I contend is above not below.) Any comments on the tool are done in the context of full praise and illustrate the great work they do as developers, technicians, and experts. Folks that have a zeal for truth and clarity in the service of justice.

Today a new version of PA (7.31.0.222) came out. It addresses a bug on the way creation times where being presented after processing a DAR file with previous PA versions. For full disclosure it is well documented that I am not a big fan of the format, or any other obscure format for that matter.


Then again I am all for progress and advancement if something is better, faster,  and/or more modern. Still with the new there comes risks. I remember back in the day when Microsoft re-did the whole network stack for Windows Vista from scratch and some old network vulnerabilities resurfaced. The point of this analogy is that new implementations will always require extra work and vigilance due to their newness. Both in implementation and application.

The new release addresses many things but mainly, in my opinion, the following:

  • PA was not parsing the creation date from the DAR file.
  • There was some issue with access and modified dates.
Below are a couple of screenshots from the release.
Birth - Creation time
Access and modified
Per the release notes older versions of PA were not presenting the changed category of timestamps as well as giving erroneous dates for the creation category. We infer this from the fact that only the change, modify and access timestamps where supported by DAR as seen above. 

This confused me. If DAR itself only supports 3 types of timestamps, how can just reprocessing, and not re-extracting, fix the problem? I will assume that the release meant to say that DAR extractions do contain all timestamps but that older versions of PA were ignoring the change times and putting a wrong timestamp under the creation label.

Here is how that looks when we compare the new PA version with the previous one. The following is a screenshot of some image metadata parsed from a DAR by PA 7.28.0.203.


As explained in the release there are only 3 timestamps visible. These are created, accessed and modified. There is no changed timestamp. Let's now look at the same image from the same DAR extraction as parsed with PA 7.31.0.222.


Notice how there is now a 4th timestamp, changed. Even more interesting is to note the difference in creation times between PA versions. The following seems to be the issue in the old PA output:
  • The changed time is the modified time.
  • The creation time is the accessed time.
In this particular case the difference between the creation and access times is 17 days. It goes without saying how critical the misplacement of this information can be when dealing with geolocation data or any file type that is tied to user generated activity. From when an image was taken to the time it was last accessed, timestamps can be the determining factor between freedom or incarceration. Just on a timestamp! If your case depended on a key creation timestamp you need to go back, as the release notes, and reprocess that case again. 

Conclusions:
  1. I love Cellebrite. The previous is not a dig at them, their technology, and much less their people. They came out with a fix and release notes about it as one expects from industry leading vendors when the inevitable bug surfaces. They aren't the first, wont be the last, and that is ok. I appreciate and value the cutting edge work they do and how the push the industry forward with newer, better, and faster things.
  2. Trust but verify. This is hard when presented with somewhat of a black box scenario. In this case the only way to test that I could see was to get a test phone, create known data, generate a DAR extraction, jailbreak the device, SSH into the device, and compare timestamps between the device and the tool. Not an easy nor quick task for most users. How can this be approached as a community exercise, since no one person can do this alone, is something we should all think about and share ideas for.
  3. Vendors should not move to a new technology without providing some backward compatibility to more established formats. It could be temporary acting as a bridge to newer ones. For example E01s are still supported even when newer formats, like AFF4, are now around. If the new format is needed because there is no other way to do the thing then the way it was implemented should be shared with the community. For an example see Blackbag (a Cellebrite company) and how they provided the specs to their APFS implementations. Incredible work.
If anything else I hope the previous motivates you to read all release notes that have to do with the tools you depend on for work. As en examiner you need to understand what the tool does, what new things it does, and what things it has failed on and how they were fixed. Own your data. Own your tools. Research, test and validate. And whatever you find, make it known.

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

Tuesday, March 3, 2020

So you have a DAR file...

With UFED support of Checkm8 for iOS extractions Cellebrite uses the DAR (Disk Archiver) format as their archiving file type of choice. It works great and captures the necessary data but it is not easy to work with nor does it have widespread third party support.

Cellebrite? Yes!!! - DAR? ok...
That being said the nice folks at Cellebrite promised additional image support in the not too distant future.

If you speaketh they will listenth
In the meantime you might want to validate the Cellebrite tool output or run a third party tool to generate a particular visualization. What to do?

The solution is pretty easy. First get the DAR binaries for your favorite platform. For this example we will use Windows. The files can be found here:
https://sourceforge.net/projects/dar/files/dar/2.6.8/
Get that (ironic) Windows ZIP
When the files are extracted add dar.exe to your Windows Path so you can access the executable from any command line window. For help on how to do that go here:
https://www.howtogeek.com/118594/how-to-edit-your-system-path-for-easy-command-line-access/
After that is done go to your UFED Checkm8 extraction and identify the file/s that end in .dar.



In my case I decided to move the FullFileSystem.1.dar to the same directory as the dar.exe program to make my extraction command as short as possible. To extract make sure to be in the directory that will hold all the extracted files coming from the dar file, the destination directory. From there run dar.exe with the -x argument and the location of the dar archive. Since I placed it in the same directory as the dar.exe the path is as short as it can be.


Notice how the executable seems to notice the #1 in the filename assuming there are more parts to the dar file. When that warning shows up just press enter and let it move forward. After a little bit you will see files and directory locations fly by the command prompt as everything is being unarchived. When done you should see the following:

Success!!!
As seen in the image with the command line execution, the data is now in the extracted directory. Now you can point third party tools that can traverse directories (Apollo, iLEAPP, KAPE, etc...) and get the needed validations and/or visualizations.

For testing I pointed iLEAPP to the extracted files directory.


Notice the Extraction location and Extraction type entries. The scripts were able to parse all the data with no issues.

As examiners we will be well served to live in the spirit of the survivalist mentality. To always improvise, adapt, and overcome (while documenting of course.) Find a way to get the data, make the correct interpretations, fulfill the mission.


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.

Saturday, February 22, 2020

ALEAPP - Android Logs Events And Protobuf Parser

From the department of unimaginative names comes ALEAPP, the sister script to iLEAPP. For additional information on iLEAPP go here.

ALEAPP will aggregate all my previous Android parsing scripts as well as be the framework for future script development. Previous users of iLEAPP will recognize the same interface and workflow present in ALEAPP. The script can parse logical file systems, tar and zip extractions as well as providing reports in html and csv formats.

ALEAPP can be downloaded from:

https://github.com/abrignoni/ALEAPP

GUI interface
This first release only parses events and accounts from the Wellbeing Android database. I can't thank enough Josh Hickman for sharing his research on the Wellbeing database and allowing me to use it to make the first ALEAPP artifacts. His research is a must read if you do Android digital forensics and can be found here:

https://thebinaryhick.blog/2020/02/22/walking-the-android-timeline-using-androids-digital-wellbeing-to-timeline-android-activity/

The next artifact to be supported will be UsageStats events both in XML and protobuf formats. For details on this artifact go here and here. The standalone script that parses UsageStats can be found here. ALEAPP will absorb that functionality. Many thanks to Yogesh Khatri for his UsageStats research and coding.

The prerequisites for ALEAPP are:

  • Python 3.7.4 and above
  • pip install six
  • pip install PySimpleGUI
The next screenshots illustrate the Wellbeing artifacts output.

The Wellbeing Account report normalizes a protobuf file for account information. The data is shown in both parsed and unparsed formats.

Account data
The Wellbeing Events report has tons of useful data. Josh Hickman's post has all the details. Great investigative data source.

Add captionfdfd
A csv report example.



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

Saturday, February 15, 2020

Initial thoughts on Android 10 parsing

When Josh Hickman (@josh_hickman1) told me he was working on creating an Android 10 full file system image as part of his testing images series I was stoked. After suggesting some apps to test he diligently worked on it and made the image public for all to use. Go get it here. Before I continue I want to thank Josh for putting this work out and to express how useful it is to everybody. Thank you!

After running the image by two commercial digital forensic tools I noted a few things.
  • When parsing the image with commercial DFIR you will see 99% of what you expect to see. This is good and speaks to the maturity of Android as an operating system and the responsiveness of vendors in this space. Still, as expected, a new OS version will break artifact parsers third party apps and native files. It is our job to figure out where the known but now lost items are as well as finding new artifacts we weren't aware of. This is how toolmakers can focus effectively on what needs to be done, it is us doing the work and telling them what's important to us.  For example chat messages from Discord and TikTok seem to be missing even though they are there. In the case of TikTok the old database query to extract chats still works. SQL queries can be found here.
  • One example of a native OS file changing format is the UsageStats files. These keep track of application usage. It is similar to KnowledgeC database entries in iOS. For details see here. Traditionally these UsageStats files where XML formatted. With Android 10 they are now protobuf encoded.All credit goes to Yogesh Khatri since he did all the heavy research work on it. His blog post is required reading. It can be found here. Not only did he identify the change in format he also updated my old UsageStats XML parser to make it protobuf encoded capable. The script can be found here. These protobuf encoded files were not decoded by the digital forensic tools. As said before, this is not a bash on digital forensic tool developers. It is a call to action to the community to test, discover, and help focus our development efforts on the artifacts we need and deem to be relevant.
  • It is rare. Haven't seen it happen on a case yet but never assume you never will. Multiple user accounts on an Android device. Artifacts left behind by a second account seem to be missing or come out jumbled together after parsing. For example if the examiner looks at app data she might find that in one case a parsed report for a database might show data for both accounts while in another artifact the data available is from the currently active account only. It is important that we identify the presence of multiple user accounts on the device and take steps to validate our output accordingly. A quick check for multiple user accounts can be done by looking at the contents of the /data/user_de/ directory. If you see another folder other than folder 0 then you have multiple user account on the device.
Multiple user accounts. Usually account #2 is 10 but who knows why it went to 11.


As an example of how tool design might affect report output I will show how my own UsageStats parser script comingles in one report the data from the two Android user accounts on the device.

After extracting the UsageStats directory the script is run.



Notice it processed 11099 records from the files.
Next I separately processed the data from each user directory. To do so I processed the usagestats directory with either directory 0 or directory 11 present.

Directory 0 and directory 11.
Data processed from user directory 0:


Records processed number went down to 8796.
Now user directory 11:


Records processed number is 2303.
Even without looking at the contents of each report we can determine which account was used the most easily. This insight would have been lost if the data was shown all together in one report.

As examiners we own the data we are tasked with processing and it is our responsibility to verify that any inferences gathered from it are exact and backed up by the source. We are uniquely positioned to identify gaps in knowledge, to work in filling them up, and sharing that knowledge with others that can automate the process to the benefit of the greater community of practitioners. If you feel bored while working in this field you are definitely not paying attention. Your perspective is needed, your expertise is essential. Make it known. 

Saturday, January 11, 2020

Awesome Friends!

iLEAPP wouldn't be possible without the assist of some awesome friends. Heck, they go beyond awesome. They truly are....

I'm the doggo. :-)
From research, coding, and being innovators to listening and discussing all things #DFIR and beyond, the following folks are truly heroic. I owe them a debt of gratitude for all the help and support I've been given. The list is not complete and I will be adding more soon. This blog post will be a link in the main iLEAPP report webpage. Without further ado:


Sarah Edwards
Sarah Edwards

Researcher: iOS Jedi Council Master in KnowledgeC, Powerlog, and literal tons of other relevant databases and artifacts. No iLEAPP without her monumental work.
Coder: Apollo Framework. THE best pattern of life analysis tool anywhere for iOS devices. Period.
Twitter: https://twitter.com/iamevltwin
Blog: https://www.mac4n6.com/
Github: https://github.com/mac4n6




Jessica Hyde
Jessica Hyde

Researcher: UsageStats in Android, IoT Forensics, and the best and most energetic presenter in the multiverse. Her ideas, DFIR philosophy, and suggestions for improvement have been and will continue to be key in the field and to me personally. She is an educator extraordinaire.

Phill Moore
Phill Moore

Researcher: As the person responsible for This Week in 4n6 he needs no intro. Truly my Australian brother from another mother. His GSERPent parser opened my eyes to the importance of applied research that screams to be shared. This is something i've tried to emulate. Lucky enough to work on joint projects and steal find inspiration in his code. 
Coder: KnowledgeC Struct Metadata script now in iLEAPP.

Heather Mahalik
Heather Mahalik

Researcher: World class Grandmaster mobile forensics Sensei. Renowned investigator known for dragging a body across the floor for science she is always at the forefront of the newest iOS artifacts and related forensic techniques. Her work is also an integral part of iLEAPP. Fortunate enough to have been, and to continue being, her student. Osu!!
Twitter: https://twitter.com/HeatherMahalik
Web: https://smarterforensics.com/
Blog: https://smarterforensics.com/blog/



Mattia Epifani
Mattia Epifani

Researcher: iLEAPP leverages TONS of artifacts that come straight from Mattia's research. His blog posts are INDISPENSABLE reading for all things iOS. Hope to meet him in person in a not too distant future. It will be an honor.
Twitter: https://twitter.com/mattiaep
Blog: https://blog.digital-forensics.it/

Geraldine Blay

Researcher: Until not too long ago my DFIR padawan she has now graduated to full, all awards, master. Couldn't be more proud of her work and her tangible results. She is mom to Siri, the best electronic sniffing canine this side of the Mississippi. You both are the best.
Tester: Hope your patience dealing with by buggy beta code doesn't run out any time soon.
Twitter: https://twitter.com/i_am_the_gia
Blog: https://gforce4n6.blogspot.com/

Mike Williamson
Mike Williamson

Researcher: My Canadian brother from another mother. I hope to one day have 1/2 of your skills. Heck 1/4 and I'm set for life. Reverse engineer, mission focused, lucky I can call him friend.
Coder: Yes, yes, yes. I learn and say thanks.
Twitter: https://twitter.com/forensicmike1
Blog: https://forensicmike1.com/

Christopher Vance

Researcher: If you haven't taken a course with Chris you are missing out for real. I will never be able to repay him for letting me complement his deleted apps research that gained us a DFIR Summit 2019 speaking slot. His iOS notifications research has been applied in iLEAPP. I don't know of any other tool that applies it yet.
Twitter: https://twitter.com/cScottVance
Blog: https://blog.d204n6.com/



Brooke
Brooke

Tester: Thank you so much for debugging that unicode error! You are awesome and I have lots of respect for you and the essential work you support. I don't know how you do so much work day in and day out. Much appreciated.
Twitter: https://twitter.com/xbrookego







Jack Farley
Jack Farley
Researcher: Thank you so much for letting me use your connected devices code in iLEAPP. Wish I could code as concise and precise as you.
Coder: Best iTunes Backup Analyzer blog and script I've seen. If you want to understand how these backups work in detail and understandable English his blog IS a must read. Check it out.
Twitter: https://twitter.com/JackFarley248
Web: http://farleyforensics.com/





Shafik Punja
Shafik Punja
Tester: Thank you for making iLEAPP accessible without a magnifying glass. Testing is so important. Thank you for giving some of your time.
Twitter: https://twitter.com/qubytelogic










Cheeky4N6monkey
Cheeky4N6monkey
Researcher: The one and only Cheeky4n6Monkey has been around for quite awhile making the world easier for digital evidence examiners. His work is always a must read and his code is super useful.
Coder: I took a bunch of his code and implemented it in iLEAPP. Attribution as comments in code. Check the out the github. Highly recommended.
Twitter: https://twitter.com/Cheeky4n6Monkey
Githubhttps://github.com/cheeky4n6monkey
Bloghttps://cheeky4n6monkey.blogspot.com/




Edward Greybeard
Contributor: Mysterious, efficient, generous with his time and skills. That's all you need to know.
Github: https://github.com/edward-greybeard









Douglas Kein

Tester: Breaker of code extraordinaire, which is precisely what is needed. Your testing has made the code way more resilient and useful. Thank you so much!!! It helps a ton.

Thursday, January 9, 2020

iLEAPP latest updates for 01/09/2020

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

The iOS Logs, Events, And Properties Parser has been updated by adding the following artifacts:
  • Photos.sqlite
    • Metadata about media files to include deletion timestamps.
    • Thanks to Heather Mahalik for the query.
  • Medialibrary.sqlite
    • Multimedia file list and metadata.
  • Accounts3.sqlite
    • System accounts.
  • Zliveusage & zliveprocess data.
  • Device screen auto lock history.
Fixes:
  • Unicode support for artifact reports.
    • Thanks to @xbrookego for testing and helping debug
  • Error handling for databases that lack tables.
  • Alternating report background row color for readability.
Any errors encountered during usage or request to support additional artifacts please report via Twitter @AlexisBrignoni and/or email 4n6[at]abrignoni[dot]com.

Sunday, January 5, 2020

iLEAPP latest updates for 01/05/2020

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

The iOS Logs, Events, And Properties Parser has been updated by adding the following iOS 12 & 13 artifacts:

  • KnowledgeC
    • Application Usage
    • Application in Focus
    • Application Activity
    • Battery Level
    • Applications Installed
    • Device Locked
    • Plugged In
  • Call History
  • SMS
    • SMS Chat
    • SMS Read
    • SMS Delivered
  • Safari History
  • Query Predictions
  • Powerlog
    • Mobile Backups
    • WIFI Properties
    • Paired Device Configuration
Fixes:
  • Proper report URL pathing. The iLEAPP report can be copied/moved to any directory and the HTML reports work as expected.
  • Added a "temp" directory at the root of the report folder that contains a copy of the data sources used by the scripts. The temp folder is created on .tar and .zip processing reports only.
Any errors encountered during usage or request to support additional artifacts please report via Twitter @AlexisBrignoni and/or email 4n6[at]abrignoni[dot]com.

Tuesday, December 24, 2019

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:
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.



   

Saturday, December 14, 2019

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.