Short Version
In this post I look at the applicationState.db SQLite database in detail and ask for help on testing/validating some of the findings.
Long Version
As stated in previous blog posts the applicationState.db located at
/private/var/mobile/Library/FrontBoard/keeps track of app bundle IDs as well as the path and long alphanumeric folder name ID where the app keeps its data. For an example of how this looks in practice see the previous post here.
As I was bouncing around some concepts with Phill Moore regarding my upcoming Magnet User Summit he asked me what would happen to the data in the applicationState.db if an app was deleted. In all my iOS third party app research I have used the database to find the app data directory names but I never thought of finding out what happened to it when an app was deleted. This post is me attempting to find out. Thanks Phill. Here we go.
For an example on how to obtain a file system extraction from a jailbroken iOS device see here.
Testing Platform
For analysis I am using the following device and equipment:
- iPhone SE - A1662
- iOS 11.2.1
- Jailbroken - Electra
- Forensic workstation with Windows 10 and SSH software.
- Connect to jailbroken device via SSH and extract a copy of the applicationState.db file.
- Deleted three apps from the device.
- Connect again and extract a copy of the database after deletions.
- Compare the databases to see what changes, if any, took place after the deletions.
Findings
The applicationState.db SQLite database has 3 tables of interest. The first one is the application_identifier_tab table.
 |
| application_identifier_tab |
It contains the bundle IDs for the apps and a unique ID for each one. I have always used the ID value here to identify where the path and app data folder name in the second table of interest named kvs.
 |
| kvs |
Note how each value in the application_identifier column is the foreign key of the ID column values in application_identifier_tab table. For example when the value for the kvs.application_identifier filed is 110 the bundle ID name in the application_identifier_tab table is com.spotify.client.
 |
| Look at highlighted area |
If you look back at the kvs table notice there is also a column named key. For the 110 ID there are multiple key values like 2, 9, 8 and others. What are these? These values map to the third table of interest, key_tab.
 |
| key_tab |
 |
| Selected blob where key value equal 1 |
 |
| Blob content |
What then do the other blobs contain when the key =/= 1? The key_tab table mentioned previously is the guide. It maps the values to what data it contains. If one looks at the contents of the table, value 1 stands for compatabilityInfo while 13 represents _UnistallDate.
In my test data application ID 112 maps to the com.valvesoftware.steam bundle ID and it has a a key value of 13 which indicates a deletion date binary plist. The extracted bplist blob looks like this:
 |
| Deletion date. Nice. |
Easy right? The bundle ID (app) in question does not have a key value of 1 which tells me that it has no associate app directory folder which is consistent with the app being deleted. So logic follows that if we identify which apps (bundle IDs) don't have a key value of 1 (indicating deletion) and extracting the key value of 13 (giving us the deletion date) we should have a list of deleted apps with the deletion date of each. Neat right? Well the devil is in the details. Of my three deleted apps one (com.microsft.rdc.ios) did not have a key value of 13 hence no deletion date for it. I knew it was deleted since there was no ID value of 1 (and I made the deletion myself). No ID value of 1 then no app directory (I checked and it was gone) for the bundle ID which does remain in the database. When I thought how could I automate this analysis the following questions surfaced:
- Are the key_tab table values the same for all iOS devices? In another phone, would ID 1 still stand for compatabilityInfo and ID 13 stand for _UninstallDate data? If every phone has different key_tab relationships there would not be a way to scale this analysis using a universal SQL query for it.
- Why out of the three deleted apps one had no deletion date recorded?
I made the following queries that identify installed applications (the ones with ID value of 1) and uninstalled applications (the ones without the required ID value if 1 entry and/or the additional ID value of 13). The problem on these queries ties back to question #1. Would the queries still work in another iOS device? My guess is that no, most likely it would not. This is something a reader could test and validate. I plan on doing validation on another iOS device in the near future as well. Here are the queries as stored in the DFIR SQL Query Repository:
https://github.com/abrignoni/DFIR-SQL-Query-Repo/tree/master/iOS/INSTALLED-UNINSTALLED-APPS
iOS Installed AppsiOS Uninstalled AppsiOS Uninstalled Apps (That have deletion dates)
Updated query:
https://github.com/abrignoni/DFIR-SQL-Query-Repo/tree/master/iOS/INSTALLED-APPS
Conclusion
The applicationState.db SQLite database is super useful when one wants to list installed applications and find out which obscure alphanumeric app directory name matches an app of interest in the list. This is really important if one is to identify any apps that automated vendor tools do not parse and to locate the corresponding app data stores in the app directory.
This database seems to track app deletions in some form. For some apps it will have a deletion date and for others it might not. I have yet to find out why.
It is still pending to validate if the ID values for compatabilityInfo, _UnistallDate and others are the same across iOS devices.
PD:
My apologies to Jessica Hyde for my half baked emails on the topic before the creation of this blog post. Sorry...
