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:

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:

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.

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!!

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.

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.

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.

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.


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.

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.

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.

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.

Edward Greybeard
Contributor: Mysterious, efficient, generous with his time and skills. That's all you need to know.

Thursday, January 9, 2020

iLEAPP latest updates for 01/09/2020

iLEAPP download:

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

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

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.

    iLEAPP: iOS Logs, Events, And Properties Parser


  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. 
  • 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:
    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: [-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).


    The script has 3 key components.
The 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 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 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 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 as a function that should be defined in

Some of the artifacts are dependent on knowing which iOS version is being worked on. The 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.

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:
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:
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:
  2. Install OpenSSH via Cydia. See the acqusition section for SSH here:
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:

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:

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:

Get the default.real file.
Open the file with Realm Studio.

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.


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:

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.

For details on snapshots see @iam_the_gia's blog post here:

For details on how to identify ktx files and how to convert them to png see the blog post here:


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.

Wednesday, November 20, 2019

Realm database storage primer for digital forensic examiners

Realm databases are non-relational storage structures that are being used in place of the traditional SQLite stores in many newer/updated mobile apps. As examiners we are faced with locating and parsing these newer data stores. As expected there is always a lag between newer technological applications and commercial forensic third party support. The purpose of this small primer is to enable you to find these Realm databases and access their contents.

Analysis Tools

What is a Realm database?

Some time ago I was made aware of a popular app that all of a sudden was not being properly supported by our usual forensic tools. When one of my colleagues told me that the data was contained within a Realm database I had no idea what he was talking about. A quick Google search lead me to the developer's webpage,

Alternative to SQLite. Interesting...
Realm is an alternative to the commonly used relational SQLite databases we are used to. In this model, called NoSQL, data is saved as objects. Imagine a database cell where you can store and manipulate not only values but a list of values. The way the Realm databases accesses these values makes apps that use this model faster than traditional SQLite stores. For an more detailed explanation of Realm capabilities, like zero copy, live objects, MVCC, and ACID, see here. Like all things in life there are pros and cons to everything. I leave the reader to Google search why a developer would decide to build an app store on Realm or SQLite if interested. For our purposes we just want to find these databases and be able to see their contents.

Sample app that uses a Realm database

Usually I work on apps from the Google Play store to illustrate the extraction and parsing of data. In this case I used a simple Android project whose only purpose is to illustrate the input and output of data from a Realm database. Sadly the generation and extraction of sample data using a fully working app takes time and effort that I currently don't have. Using this simple project and an Android virtual machine I could do the generation an extraction of data in minutes for illustration purposes.

The Android project was made by Dheeraj Andra and it is a simple app that takes as input a name and age. These values are shown to the user on screen after being saved in the realm database. Links to the project are included above. To generate the APK needed to run the app in my Genymotion virtual machine I used Android Studio. With the APK in hand I ran it on my virtual machine. The following is an image of the app in use:

Sample Realm app
At the top the user enters values and these are shown back at the bottom part of the app.

Storage location

As any Android app the data of relevance is contained within the application directory. With SQLite databases the data is usually contained in the databases directory. By contrast this Realm app, as well as others I have come across lately, has no databases directory.

Where is the databases folder?
The data we seek resides in the files folder and the file type we need to extract are the ones that end in the .realm extension.

Get the .realm file!
As explained in some of the links above Realm databases have no need for write ahead logs or rollback journal files. In this example extracting the default.realm file has all the data we seek.

How to view Realm database contents

What do we do with the file after extracted? The database developers have a free tool called Realm Studio. Open the .real file with Realm Studio and you will be able to browse the contents.

As the app has more classes and more data it can be useful to export the contents in JSON format for further analysis. It goes without saying that when an examiner does transformations of the data for parsing and analysis great care has to be taken to validate every single piece of resulting data. The farther we move away from the original format the closer we have to make direct links back to it.

In the previous image the bottom part of the screen shows the contents of the sample realm database while the upper part is the same data in JSON format.

Recently (November 19, 2019) Cellebrite announced that their Database viewer tool product had Realm database support.
I expect other vendors in the space to follow suit. This is important because I forsee Realm databases, as well as JSON and protobuf, to be common in the near future as mobile app data stores.

Last but not least remember that having multiple ways of looking at a data set is important for validation purposes.

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

Monday, October 28, 2019

Recreate Android apps, folders, and widget screen positions from a forensic extraction.

Short version

Android 9 uses the launcher.db sqlite database to keep track of where on the device screens are the app, folders, and widget shortcuts located. For stock Android the database can be found in the following directories depending on the available launcher:
/data/data/ - Quickstep Launcher
/ - Pixel Launcher  
The relevant forensic data in the table named favorites is as follows:

  • Type of shortcut - Icon, folder, widget, etc...
  • Unique ID - Integer value
  • Name
  • Modified time - Epoch timestamp in milliseconds
  • Icon image blob - PNG file

Android home screens can be recreated using the following python3 Android Launcher DB parser script:
Here are the shortcuts as viewed via the device's screen:

Android screen + shortcuts
Here are the shortcut positions and metadata as recreated via the use of the script:

Upper screen

Lower screen

It is of note that not all icons are contained within the launcher.db file. Additional details in the long version of the blog post.

Testing and analysis platform

Macbook Pro 14.1
Genymotion Android VM - Pixel 3 XL Stock Android (Quickstep & Nexus launchers)
SQLite Browser
Python 3 - Numpy + Pandas

Long version 

A few weeks ago I participated in a capture the flag that included an Android device as part of the exercise. One of the questions wanted us to identify the name of a shortcut in a precise screen location within the Android image. As I looked for the answer that made me think on practical uses for this information. Why would anyone care where and on what screen/s are the shortcuts for apps, folders, and widgets on a mobile device? What could that tells us about our case that we would need? What forensic purpose could there be?

On many Windows OS cases showing what directories, LNKs, and files were located on the desktop painted a clear picture of what the user deemed important enough to have easy access to. It speaks of usage, convenience, and to how the user decides to aggregate data. Can the same be said of Android home screens? I believe so. Consider that folders on Android home screens are created by the user long pressing an icon/shortcut and dropping it on top of another shortcut. The name of the folder is user generated if it is not Unnamed Folder. A lot of user activity to place the items where they are. Same thing with widgets. There is a lot of user interaction to generate a widget and place it on the screen. What if these interactions were timestamped?

As stated in the short version at the top the data resides in the /data/data/ and / directories on stock Android devices. The control of how these screens operate is the responsibility of launcher software.

Google Play Store - Launcher Apps
As seen in the previous image, stock Android launchers are not the only game in town. This blogpost limits itself to two the stock types but the device you might be looking into could use any of these other ones. Further research is needed to verify how these other launchers keep its data. My assumption is that to be compatible with Android the databases will most likely be the same as the stock versions. This is something that would need follow up.


Within the path the database of interest is a sqlite database named launcher.db. The favorites table has all the relevant data in regards to position of items on screen as well as when these items were placed in their locations.

The following image will show the most pertinent fields in the table.

Relevant launcher.db fields
To better understand the data the following image shows the main divisions of an Android screen:

Blue area = Home screen. User can swipe left or right to access more screens.
Red area = Home bar. Persisten on all screens. Only has 5 spaces available.

Purpose of storage data per field:

  • _id - Unique identifier for each app, widget, and folder. Integer value.
  • title - Name of the app shortcut or folder. Widgets do not keep a name in this field.
  • container - Number identifies the type of screen. 
    • -101 - Home bar. Bottom row that does not change as the home screens change when you swipe left or right.
    • -100 - Home screen container number. If you have more than one screen that will be identified by the value in the screen field.
    • Positive integer values - These map to the _id number in the previous field. This is important because it shows the items in question reside in a folder with the corresponding _id number.
  • screen - Identifies the homescreen where the apps will be shown. Everytime a new screen is made the number increments by one. The exception is the home bar (container -101.) Apps in the home bar are limited to 5 and each position will be identified with a 'screen' number.
  • cellX and cellY - Used to identify the location of the item to be place on screen. It is a 5x5 grid on the home screen and 1x5 for the home bar.
  • spanX and spanY - Used to determine the ending location of the item on screen. If it is a widget that covers a 3x3 space the combination of cellX and cellY for the starting point and the spanX and SpanY as the end points will allow the mapping of items that span more than one space of the screen.
  • itemType - Used to determine what type of item is on screen. So far I've identified the following:
    • 0 - App
    • 2 - Directory / Folder
    • 4 - Widget that spans more than 1x1 space
    • 6 - Widget spans a 1x1 space
  • icon - Data blob that contains a PNG of the item to be displayed. Be aware some items, like folder and some widgets, might not have data in this field.
  • appWidgetProvider - Widgets do not have values in the title field. This one indicates the bundle id for the app that populates the widget data.
  • modified - Timestamp in epoch milliseconds that tells you when the placement of the icon on screen last occurred. If the user moves the location of an item the modified time changes to reflect when the move happened.
By understanding these relationships we can recreate the mapping of all items. For this purpose I created a python 3 script that can be located here:

Python 3 Script

The script usage is very simple.

1- Extract the launcher.db file from the indicated path.
2- Place it in the same directory as the script

Just place the launcher.db file in the same directory as the script.
3- Run the script by typing: python

4- A timestamped named directory will be created for each run of the script. Within it you will find html representations of all screens and folders. Be aware that folders can be mapped to their corresponding home screens by the matching of their id numbers.

Notice the timestamp for the run
5- At a minimum you will see the icons directory (contains all the extracted PNG files from the db), the Bottom_Bar.html and MainScreen0.html files. In the following image you can see these html files but also additional ones that correspond to folder screens / content. Notice that these are named ScreenDirectory followed the corresponding id value that will be used to map the report to the folder location on the screen.

All the screens + all the folders/directories
Every relevant data point is included in the report to include the icon if available.

The script will do the necessary time conversions as well.


As always further testing and validation are never out of place. Although my script manages unknown item types it will be really useful to identify additional ones so a proper type descriptor can be included. Hopefully this type of reconstruction can give the examiner a window unto how the user managed the device,  how some might have been group in folders, and maybe which app were of most interest to the user by the fact of being in the home screens and home bar.

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