Has the user ever used the XYZ application? aka traces of application execution on mobile devices

A common question during a forensic investigation of a digital device is: "Has the user ever used the XYZ application?".

As always when answering this question, it is important to create and follow a solid process.

In this blog post, I want to share a possible process that everyone should customize based on their needs and roles.

The ability to answer the question depends on the acquisition that was obtained from the device. In this blog post, I will address the scenario where you have a full file system acquisition (or physical, for older devices).

Check whether the XYZ application is installed

First, check whether the XYZ application is still installed on the device at the time of the acquisition.

On an iOS device, there are several easy ways to check this. To name just a few of the most common:

• Check if the XYZ bundle is available under \private\var\containers\Bundle\Application\<GUID>
• Check whether the XYZ App Sandbox folder is available under \private\var\mobile\Containers\Data\Application\<GUID>
• Check whether the XYZ App Shared folder is available under \private\var\mobile\Containers\Shared\AppGroup\<GUID>
• Analyze:
• Mobile installation logs
• ApplicationState.db
• containers3.sqlite

This can also be checked in various ways on an Android device:

• Analyze the "/app" and "/data" folders in the "Userdata" partition and look for folders and APKs related to the package of interest.
• Analyze:
• packages.list
• packages.xml
• frosting.db
• localappstate.db
• gass.db

If the XYZ application is installed

If the application is still installed, the next step is to analyze all relevant files in the application's sandbox. 

The first stage will probably be your tools, after that, you will need to dig deeper, analyze the files manually, and create your own queries/parsers.

On iOS devices, you can analyze various native artifacts to find and confirm traces of app usage. Some of the most commonly analyzed artifacts are:

• iOS notifications (useful for finding potentially deleted messages)
• Power logs (and backups)
• InteractionC
• KnowledgeC
• Biome 
• Screen time
• Net usage 
• Data usage
• TCC (permissions)
• Crash logs
• Store.db (historical use of the app by the iCloud user)

There are usually fewer traces on Android devices, but still a lot of information:

• Application permissions (packages.xml)
• Application run-time permissions (runtime-permissions.xml)
• Digital Wellbeing
• App ops
• Privacy Dashboard (Android 12 and higher)
• Firebase Cloud Messaging
• PkgPredictions.db (Samsung devices only)
• notification_log.db (Samsung devices only, up to Android 10)
• Application activity/tasks
• Usage stats
• Network stats
• Battery stats
• Graphic stats
• library.db

It is also a good practice to search for:

• App screenshots stored on the device: common file formats on iOS are KTX (for automatically generated screenshots) and PNG (for user-generated screenshots), while on Android the common file formats are PNG and JPG.
• Analysis of the images and videos saved by the app on the device: for iOS devices this typically involves analyzing the files in the camera roll and analyzing the Photos.sqlite database; for Android devices, this means analyzing the emulated SD card used by apps to store files (i.e. multimedia)

You should also analyze received SMS messages to look for messages that the user received after installing the specific app or due to 2FA authentication.

Last but not least, especially for chat/messaging and browser apps, you can analyze the main database and search for missing rows to look for possibly deleted messages and the approximate timestamp.

If the XYZ application is not installed

If the application is not installed, you should normally do so: 

• Check if the application has ever been used on this system
• Possibly recover some data from the application

It is important to emphasize that on modern devices that use file-based encryption, once an app is uninstalled, the contents of the app sandbox are deleted and cannot be recovered.

Therefore, it is important to understand and verify which artifacts are retained after uninstalling an app.

This topic has already been covered in various presentations and blog posts. The most interesting are:

• Mobile Forensics: Discovering the Undiscovered, 2020 by Scott Vance
• Tracking Traces of Deleted Applications, SANS DFIR Summit 2019 by Alexis Brignoni and Scott Vance
• iOS - Tracking Traces of Deleted Applications 2019 by Scott Vance
• Analysis of application installation logs on Android systems, 2019
• Every Step You Take: Application and Network Usage in Android, SANS DFIR Summit 2018 by Jessica Hyde

For iOS devices, based on my experience and previous testing, I suggest the following list as a starting point:

1. Analyze the "Mobile Installation Logs" and check which apps have been uninstalled and compare them to the list of actually installed apps
2. Search for SMS messages related to app usage (e.g. activation and 2FA messages)
3. iOS notifications
4. Screenshots created manually by the user that relate to the specific app
5. Photos.sqlite
6. InteractionC  
7. Power logs (and backups)
8. KnowledgeC
9. Biome
10. Screen time
11. Net usage 
12. Data usage
13. TCC (Permissions)
14. Store.db
15. Raw keyword search for the app bundle and the app common name
16. Syslog archive from a Sysdiagnose

On Android devices, I recommend this as a starting list:

1. Analyze "localappstate.db" and "gass.db", and check which apps were installed via the Google Play Store and compare them to the list of actual installed apps
2. Search for SMS messages related to app usage (e.g. activation and 2FA messages)
3. Files stored on the emulated SD card
4. Screenshots created manually by the user that relate to the specific app
5. Digital Wellbeing
6. Firebase Cloud Messaging
7. PkgPredictions.db (Samsung devices only)
8. notification_log.db (Samsung devices only, up to Android 10)
9. Usage stats
10. Battery stats
11. Graphic stats
12. Library.db
13. Raw keyword search for the app bundle and the app common name

Testing and validating the process

To test and validate the proposed procedures, I conducted an experiment. This is only a single test on two specific devices, so do not assume that you will find similar results in all real-world cases. This is especially true for Android devices, for which each individual manufacturer may have their own customizations and packages.

I had an iPhone 7, running iOS 15.7, and an Android device from Samsung, running Android 10 updated from Android 9 with Full Disk Encryption.

I installed two messaging apps on both devices: Telegram and Signal. 

The apps were used for a few days and exchanged messages between the two devices. 

I gave both apps all permissions on both devices and I enabled incoming notifications.

After a few days of use, I performed a full file system acquisition of the iPhone and a physical dump of the Samsung device with both apps still installed.

I then rebooted both devices and uninstalled both apps. I turned the devices off and back on and then I acquired them again. 

After a week of using both devices with other apps, I did another full file system acquisition of the iPhone and a physical dump of the Android device.

I plan further acquisitions after 14 days and after 30 days: this post will be updated as soon as the acquisitions are available.

I parsed all the acquisitions with various tools and did a thorough keyword search using the common names of the apps (Telegram and Signal) and the package/bundle names (for iOS "ph.telegra.Telegraph" and "org.whispersystems.signal", for Android "org.telegram.messenger" and "org.thoughtcrime.securesms").

Analysis of the iOS device

First, I did a keyword search on the results generated by the tools, just to see the differences. Following are some comparison images with AXIOM and PA in the three different acquisitions: App still installed, App just installed, App uninstalled 6 days ago.

Tool: Cellebrite Physical Analyzer

Keyword: ph.telegra.Telegraph
Comparison between the 3 acquisitions.

Tool: Cellebrite Physical Analyzer

Keyword: org.whispersystems.signal
Comparison between the 3 acquisitions.

Tool: Cellebrite Physical Analyzer

Keyword: Telegram
Comparison between the 3 acquisitions.

Tool: AXIOM
Keyword: ph.telegra.Telegraph
Comparison between the 3 acquisitions. 

Tool: AXIOM
Keyword: org.whispersystems.signal
Comparison between the 3 acquisitions. 

Tool: AXIOM
Keyword: Signal

Tool: AXIOM
Keyword: Telegram

Mobile Installation Logs

The first step was to analyze mobile installation logs and search for traces of uninstalled applications. This information was available in both acquisitions after the applications were uninstalled.

Tool: AXIOM
Artifact: Mobile Installation Logs - Signal Installed and Uninstalled

Tool: iLEAPP
Artifact: Mobile Installation Logs - Telegram Installed and Uninstalled

Tool: iLEAPP
Artifact: Mobile Installation Logs - Signal Installed and Uninstalled

SMS Messages

Then I checked the SMS messages received on the phone that are related to the activation or use of the apps. Below are some examples of the tested scenario.

Tool: OXYGEN
Artifact: SMS Message - Telegram

Tool: OXYGEN
Artifact: SMS Message - Signal

iOS Notifications

Then I analyzed iOS notifications as they contain metadata (timestamp and sender of the message) and data (message text). Notifications, if enabled, are only available for received messages. In the tested scenario, the notifications were available for both apps and in both acquisitions, after the apps had been uninstalled.

Tool: Cellebrite Physical Analyzer
Artifact: iOS notifications - ph.telegra.Telegraph

Tool: Cellebrite Physical Analyzer
Artifact: iOS notifications - org.whispersystems.signal

Tool: AXIOM

Artifact: iOS notifications - ph.telegra.Telegraph

Tool: AXIOM
Artifact: iOS notifications - org.whispersystems.signal

Tool: iLEAPP
Artifact: iOS notifications - ph.telegra.Telegraph

Tool: iLEAPP
Artifact: iOS notifications - org.whispersystems.signal

I did not take any screenshots or save any images or videos during the test, so I could not check the camera roll and photos.sqlite.

interactionC.db

When analyzing the interactionc.db database, I found differences between the two apps tested: entries related to interactions on Telegram were deleted when the app was uninstalled, while entries related to interactions on Signal were not deleted when the app was uninstalled. Deleted Telegram entries were still recoverable after uninstalling the app in both cases. In previous tests, for example, I found that when using the "Clear all chats" function in WhatsApp, the entries in the interactionc.db file are not deleted. So I would say that each app can have different effects on the interactionc.db.

Tool: OXYGEN
Artifact: Deleted interactionC entries - ph.telegra.Telegraph

Tool: OXYGEN

Artifact: interactionC entries - org.whispersystems.signal

Tool: Cellebrite Physical Analyzer

Artifact: interactionC entries - org.whispersystems.signal

Tool: iLEAPP

Artifact: interactionC entries - org.whispersystems.signal

Current Power Log

To check the use of the application, the Current Power Log database is the most interesting. This database stores data for a few days (usually 3-5), but backups are created by iOS automatically and during iOS updates. When testing, I found several references in the acquisition done immediately after uninstalling the app, and even more (duplicated, because of the backups) in the acquisition after 6 days.

Tool: AXIOM
Artifact: Power Log - Application State - ph.telegra.Telegraph

Tool: AXIOM
Artifact: Power Log - Application State - org.whispersystems.signal

Tool: AXIOM
Artifact: Power Log - Process Data Usage - ph.telegra.Telegraph

Tool: AXIOM
Artifact: Power Log - Process Data Usage - org.whispersystems.signal

Tool: AXIOM
Artifact: Power Log - App Usage - ph.telegra.Telegraph

Tool: AXIOM
Artifact: Power Log - App Usage - org.whispersystems.signal

Tool: AXIOM
Artifact: Power Log - Camera State - ph.telegra.Telegraph

Biome

Most of the data stored in Biome was removed when the applications were uninstalled, but "Notification" (with metadata only and not text) and "Text Input Sessions" were still available after the applications were uninstalled, even after 6 days.

Tool: iLEAPP
Artifact: Biome - Notifications - ph.telegra.Telegraph

Tool: iLEAPP
Artifact: Biome - Text Input Sessions - ph.telegra.Telegraph

Tool: iLEAPP
Artifact: Biome - Text Input Sessions - org.whispersystems.signal

KnowledgeC

Entries related to a specific bundle are deleted from the knowledgeC.db database when the application is uninstalled. You may still be able to find information about installed and uninstalled applications.

Tool: OXYGEN
Artifact: KnowledgeC - ph.telegra.Telegraph

Tool: OXYGEN
Artifact: KnowledgeC - org.whispersystems.signal

Screen Time

Similarly, entries in the Screen Time database (RMAdminStore-Local-sqlite) are deleted when an app is uninstalled. Deleted rows were recovered in the acquisition made just after uninstalling apps, but not in the acquisition made after 6 days.

Tool: OXYGEN
Artifact: Screen Time - ph.telegra.Telegraph

 

Tool: OXYGEN
Artifact: Screen Time - org.whispersystems.signal

Net Usage

The Net Usage database contained information about the uninstalled apps in the acquisition done immediately after the reboot, but the information was not available in the acquisition done after 6 days.

Tool: iLEAPP
Artifact: Net Usage - ph.telegra.Telegraph

Tool: iLEAPP
Artifact: Net Usage - org.whispersystems.signal

TCC

The TCC database, which contains information about the application's permissions, is normally deleted (entries are removed) when an application is uninstalled. However, in the tested scenario, the kTCCServiceLiverpool permission granted to the Telegram application was still present after the application was uninstalled.

storeUser.db

The database storeUser.db, which is available in the App Store cache, contains two interesting tables:

• current_apps, which lists the currently installed apps including a timestamp that appears to be related to the app installation time
• purchase_history_apps, which lists all the apps purchased by the Apple account set up on the device

These tables can be used to prove that a user has used an app, even on a different device or a previous installation of the device under investigation. You can compare the contents of the two tables, to see which apps were purchased by the user but are not currently installed on the device being analyzed. Be careful: the fact that an app was purchased and is not installed does not mean that it was installed and then uninstalled on the current device you are analyzing. The app could have been used on another device with the same Apple account.

Raw Keyword Search with bundle/app name

It's also a good idea to do a raw keyword search using the bundle and application name to find other potentially relevant information.

In my tests, I found traces of the bundle name in these files and folders as well:

• /private/var/db/diagnostics/
• /private/var/db/uuidtext/
• /private/var/Library/Logs/CrashReporter/*.ips
• /private/var/mobile/Library/AggregateDictionary/ADDataStore.sqlitedb
• /private/var/mobile/Library/Application Support/CloudDocs/session/containers/<bundle_name>
• /private/var/mobile/Library/Application Support/CloudDocs/session/db/server.db
• /private/var/mobile/Library/Application Support/CloudDocs/session/db/client.db
• /private/var/mobile/Library/Caches/CloudKit/CloudKitMetadata
• /private/var/mobile/Library/Caches/CloudKit/<bundle_name>/
• /private/var/mobile/Library/Caches/com.apple.appstored/Cache.db
• /private/var/mobile/Library/Caches/com.apple.appstored/fsCachedData/
• /private/var/mobile/Library/Caches/com.apple.ctcategories.service/Cache.db
• /private/var/mobile/Library/Caches/com.apple.ctcategories.service/fsCachedData/
• /private/var/mobile/Library/Caches/com.apple.parsecd/installed_app_whitelist_url
• /private/var/mobile/Library/com.apple.siri.interference/siriremembers2.sqlite3
• /private/var/mobile/Library/DuetExpertCenter/_ATXDataStore.db
• /private/var/mobile/Library/DuetExpertCenter/_ATXNotificationStore.db
  
• /private/var/mobile/Library/DuetExpertCenter/notificationsAndSuggestionDB.db
• /private/var/mobile/Library/Spotlight/applications.mdplist
• /private/var/mobile/Library/SyncedPreferences/com.apple.kvs/com.apple.KeyValueService-Production.sqlite

*****[UPDATE 14 DAYS AFTER UNINSTALL ]*****

14 days after uninstalling I was still able to find traces in:

• Mobile Installation Logs
• SMS Messages
• iOS Notifications
• InteractionC (Signal still allocated, Telegram recovered)
• Power Logs (fewer traces than in previous acquisition)
• KnowledgeC (app install/uninstall)
• Biome (Notifications and Text Input Sessions)
• TCC (Telegram only)
• storeUser.db
• Most of the files mentioned in the "Raw keyword search for the app bundle and the app common name" section 

Analysis of the Android device

Similar to the iOS device, I searched the results of the various tools by keyword. Here are some comparison images with AXIOM and PA in the three different acquisitions: App still installed, App just installed, App uninstalled 6 days ago.

Tool: Cellebrite Physical Analyzer

Keyword: org.telegram.messenger
Comparison between the 3 acquisitions.

Tool: Cellebrite Physical Analyzer

Keyword: Telegram
Comparison between the 3 acquisitions.

Tool: Cellebrite Physical Analyzer

Keyword: org.thoughtcrime.securesms
Comparison between the 3 acquisitions.

Tool: Cellebrite Physical Analyzer

Keyword: Signal
Comparison between the 3 acquisitions.

Tool: AXIOM

Keyword: org.telegram.messenger
Comparison between app installed and app just uninstalled

Tool: AXIOM
Keyword: Telegram
Comparison between app installed and app just uninstalled

Tool: AXIOM
Keyword: org.thoughtcrime.securesms
Comparison between app installed and app just uninstalled

Localappstate.db and Gass.db

The first step is to analyze the localappstate.db and the gass.db and search for traces of uninstalled applications by comparing the list of actually installed apps with the list of applications available in these databases. The localappstate.db tracks the Google account used to download the application, the first install date and time, and the last updated date and time, while the gass.db tracks the version and the SHA-256 hash of the last installed APK.

Tool: Cellebrite Physical Analyzer

Artifact: Localappstate.db - Gass.db - org.telegram.messenger

Tool: Cellebrite Physical Analyzer

Artifact: Localappstate.db - Gass.db - org.thoughtcrime.securesms

Tool: AXIOM

Artifact: localappstate.db - org.telegram.messenger

Tool: AXIOM

Artifact: localappstate.db - org.thoughtcrime.securesms

Tool: aLEAPP
Artifact: localappstate.db - org.telegram.messenger

Tool: aLEAPP

Artifact: localappstate.db - org.thoughtcrime.securesms

Tool: aLEAPP
Artifact: gass.db - org.telegram.messenger

Tool: aLEAPP

Artifact: gass.db - org.thoughtcrime.securesms

SMS Messages

Then you can check the SMS messages received on the phone that are related to the activation or use of the apps. Below are some examples of the tested scenario.

Tool: AXIOM

Artifact: SMS - Telegram Code - mmssms.db

Tool: AXIOM

Artifact: SMS - Telegram Code - message_content.db

Tool: AXIOM

Artifact: SMS - Signal Code - mmssms.db

Files stored in the emulated SD Card

Files saved by an application on the emulated SD card are not deleted when the application is uninstalled. In the test scenario, the images sent/received by Telegram were still available.

Tool: Cellebrite Physical Analyzer

Artifact: Multimedia files stored in the emulated SD Card - Telegam

Tool: AXIOM

Artifact: Multimedia files stored in the emulated SD Card - Telegam

Digital Wellbeing

Digital Wellbeing tracks application usage and application notifications and may contain traces even after an application has been uninstalled. In the case tested, Digital Wellbeing was stored in the dwbCommon.db database, but different manufacturers may implement this Android feature differently.

Tool: Cellebrite Physical Analyzer

Artifact: Digital Wellbeing - Application Usage - org.telegram.messenger

Tool: Cellebrite Physical Analyzer

Artifact: Digital Wellbeing - Notifications - org.telegram.messenger

Tool: Cellebrite Physical Analyzer

Artifact: Digital Wellbeing - Application Usage - org.thoughtcrime.securesms

Tool: Cellebrite Physical Analyzer

Artifact: Digital Wellbeing - Notifications - org.thoughtcrime.securesms

Tool: aLEAPP

Artifact: Digital Wellbeing - Application Usage - org.telegram.messenger

Tool: aLEAPP

Artifact: Digital Wellbeing - Application Usage - org.thoughtcrime.securesms

Firebase Cloud Messaging

Firebase Cloud Messaging is a cross-platform messaging solution that lets a developer send messages at no cost. As described by CCL Solutions, it "presents a golden second opportunity to recover data that might otherwise be unrecoverable".

Tool: aLEAPP

Artifact: Firebase Cloud Messaging Queued Messages Dump - org.telegram.messenger

Tool: aLEAPP

Artifact: Firebase Cloud Messaging Queued Messages Dump - org.thoughtcrime.securesms

PkgPredictions.db

On Samsung devices, the PkgPredictions.db file contains timestamps for the start execution of each package, including the activity name. In my experience, this database typically persists for 7-14 days, so it's always worth checking the name of each package.

Tool: aLEAPP

Artifact: Package Predictions - org.telegram.messenger

Tool: aLEAPP

Artifact: Package Predictions - org.thoughtcrime.securesms

notification_log.db

On older Samsung devices, the notification_log.db file contains a "log" table that records application usage including the event type (i.e. message) and associated timestamp.

Tool: Cellebrite Physical Analyzer

Artifact: notification_log.db database - org.telegram.messenger

Tool: Cellebrite Physical Analyzer

Artifact: notification_log.db database - org.thoughtcrime.securesms

Usage Stats

Usage stats can provide information about application usage (application events) and package usage (last active time and total usage in seconds over the last day/week/month/year), The information is not removed when the application is uninstalled and is proven to be the most persistent usage artifact.

Tool: AXIOM

Artifact: Usage Stats - org.telegram.messenger

Tool: AXIOM

Artifact: Usage Stats - org.thoughtcrime.securesms

Battery Stats

Battery stats are probably the most underrated and least analyzed artifact on Android devices, even though they contain a large amount of information about system status (on, off, battery level), system usage and application execution. Battery stats can be stored in different paths depending on the manufacturer, but can easily be found by searching for "batterystats" in files and folder names. The best way I know of to analyze battery stats is to extract them from the system via a bug report and analyze them with Google Battery Historian. I also suggest you reading this interesting blog post titled "At Your Service: Timelining Android Usage with System Services"

Tool: OXYGEN

Artifact: Battery Stats

Graphic Stats

Graphic Stats can be used to track application usage by analyzing each subfolder and searching for the desired package. This information does not seem to be really persistent.

Tool: OXYGEN

Artifact: Graphic Stats

Library.db

The library.db stores the history of applications purchased by the Google user on the device. This database is not linked to the specific device, but to the Google account. As soon as the user logs in for the first time, this database is populated, even with applications that have never been installed on the device. In testing, I set up a freshly reset Google Pixel device with the same user account and the database was immediately populated with data, including Telegram and Signal, even if these apps were never installed.

So this database is important to understand what apps the Google user has used over time, but be careful about attributing usage to the specific device you are analyzing.

Tool: AXIOM

Artifact: library.db - org.telegram.messenger

Tool: AXIOM
Artifact: library.db - org.thoughtcrime.securesms

Tool: aLEAPP

Artifact: library.db - org.telegram.messenger

Tool: aLEAPP

Artifact: library.db - org.thoughtcrime.securesms

Raw Keyword Search with package/app name

It's also good practice to do a raw keyword search using the package and the common name of the application to find other potentially relevant information. In my tests, I found traces of the package name in these files and folders as well:

• \data\com.google.android.googlequicksearchbox\databases\portable_geller_<Gmail_username>.db
• \data\com.google.android.googlequicksearchbox\databases\portable_providers_<Gmail_username>.db
• \data\com.google.android.gms\files\reports\state_dump.txt
• \data\com.android.vending\caches\streamdatastore.db
• \data\com.android.vending\databases\auto_update.db
• \data\com.android.vending\databases\data_usage.db
• \data\com.android.vending\databases\install_queue.db
• \data\com.android.vending\databases\install_source.db
• \data\com.android.vending\databases\prefetch_recommendation_store.db
• \data\com.android.vending\databases\xternal_referrer_status.db
• \data\com.android.vending\app_commerce_acquire_cache\
• \data\com.samsung.android.sm.devicesecurity\databases\APP_INFO_TBL
• \data\com.samsung.android.sm.devicesecurity\databases\device_security.db
• \data\com.sec.android.provider.badge\databases\badge.db
• \log\package_dump.txt
• \log\dumpstate_lowbattery_NN.log
• \log\dumpstate_app_native.zip
• \log\dumpstate_sys_watchdog.zip
• \log\acore\0_dumpcore_all.txt
• \misc\stats-data\
• \system\batterystats-daily.xml
• \system\package-cstats.list
• \system\ipm_input_data.txt

*****[UPDATE 14 DAYS AFTER UNINSTALL ]*****

14 days after uninstalling I was still able to find traces in:

• localappstate.db 
• gass.db
• SMS Messages
• Files stored on the emulated SD card
• Firebase Cloud Messaging
• Digital Wellbeing
• PkgPredictions.db
• Usage stats (only one reference per package)
• Battery stats
• Library.db
• Some of the files mentioned in the "Raw keyword search for the app bundle and the app common name" section

Conclusions

Based on my personal experience and on testing, here is a starting checklist for the analysis of application usage. I'll be happy to improve this list based on future tests or suggestions from readers.

Suggested steps on iOS

1. Verify if the app is still installed or not
• Check if the XYZ bundle is available under \private\var\containers\Bundle\Application\<GUID>
• Check whether the XYZ App Sandbox folder is available under \private\var\mobile\Containers\Data\Application\<GUID>
• Check whether the XYZ App Shared folder is available under \private\var\mobile\Containers\Shared\AppGroup\<GUID>
• Analyze:
• Mobile installation logs
• ApplicationState.db
• containers3.sqlite
2. If the app is still installed analyze:
1. Mobile Installation Logs (App install/uninstall time)
2. Data from the specific app parsed by different tools
3. Every and each file in the App Sandbox
4. SMS Messages related to app activation/usage (i.e. 2FA messages)
5. iOS Notifications (verify possibly deleted messages, including content)
6. Screenshots automatically/manually generated and related to the specific app (i.e. Telegram chat screenshot)
7. For chat/messaging app, analyze the main database and search for missing rows (verify possibly deleted messages, approximate timestamp)
8. Photos.sqlite (search for file saved by the app of interest)
9. InteractionC (verify possibly deleted messages, only metadata)
10. Power logs and backups (interaction with the App)
11. Biome (interactions with the App)
12. KnowledgeC (interactions with the App)
13. Screen Time
14. Net Usage / Data Usage
15. TCC (Permissions)
16. CrashLogs
17. storeUser.db (historical usage of the app by the iCloud user)
18. Raw keyword search for the app bundle and the app common name
19. Extract and analyze syslog archive from a Sysdiagnose
3. If the app is not installed:
1. Mobile Installation Logs (App install/uninstall time)
2. SMS Messages related to app activation/usage (i.e. 2FA messages)
3. iOS Notifications (verify possibly deleted messages, including content)
4. Screenshots automatically/manually generated and related to the specific app (i.e. Telegram chat screenshot)
5. Photos.sqlite (search for file saved by the app of interest)
6. InteractionC (verify possibly deleted messages, only metadata)
7. Power logs and backups (interaction with the App)
8. KnowledgeC (app install and uninstall)
9. Screen Time
10. Net Usage / Data Usage
11. TCC (Permissions)
12. CrashLogs
13. storeUser.db (historical usage of the app by the iCloud user)
14. Raw keyword search for the app bundle and the app common name
15. Extract and analyze syslog archive from a Sysdiagnose

Some personal and final thoughts on iOS, based on the tests conducted and previous experiences. During testing, I found that the entries in Biome, KnowlegeC, TCC and ScreeTime are deleted when the app is uninstalled. Entries in interactionC were deleted when Telegram was uninstalled, but not when Signal was uninstalled. Deleted rows could be recovered from all these databases, especially if the app was recently deleted.

The chances of recovering content from the uninstalled app are limited to screenshots, photos saved by the app in the camera roll, files saved by the app anywhere on the device (e.g. the Files" app) and notifications: these files are not deleted when the app is uninstalled. Entries in the Power logs database are also not deleted when the app is uninstalled, so this database and its backups may be relevant for identifying interactions with the app. The database that stores information the longest is the "storeUser.db" as it relates to the iCloud account and not specifically to the device you are analyzing.

If you have no way to get a full file system, you are limited when investigating deleted apps: you can still extract and analyze the camera roll, photos.sqlite, interactionc, data usage, tcc and SMS messages, but notifications, knowledgec, screen time, net usage, and power log are not available. In this case, it is mandatory to create and extract a sysdiagonose that gives you access to the mobile installation logs, power logs (current only, no backups) and syslog data.

Suggested steps on Android

1. Verify if the app is still installed or not
• Analyze the "/app" and "/data" folders in the "Userdata" partition and look for folders and APKs related to the package of interest.
• Analyze:
• packages.list
• packages.xml
• frosting.db
• localappstate.db
• gass.db
2. If the app is still installed analyze:
1. Data from the specific app parsed by different tools
2. Every and each file in the App Sandbox
3. SMS Messages related to app activation/usage (i.e. 2FA messages)
4. Screenshots automatically/manually generated and related to the specific app (i.e. Telegram chat screenshot)
5. Media stored in the emulated SD card
6. For chat/messaging app, analyze the main database and search for missing rows (verify possibly deleted messages, approximate timestamp)
7. Package permissions
8. Package run-time Permissions
9. Package tasks
10. Privacy Dashboard
11. AppOps
12. Digital Wellbeing
13. Firebase Cloud Messaging
14. PkgPredictions.db
15. notification_log.db
16. Usage stats
17. Network stats
18. Battery stats
19. Graphic stats
20. Library.db
21. Raw keyword search for the app bundle and the app's common name
22. Extract and analyze a bugreport
3. If the app is not installed:
1. Analyze "localappstate.db" and "gass.db", and check which apps were installed via the Google Play Store and compare them to the list of actually installed apps
2. Search for SMS messages related to app usage (e.g. activation and 2FA messages)
3. Files stored on the emulated SD card
4. Screenshots created manually by the user that relate to the specific app
5. Digital Wellbeing
6. Firebase Cloud Messaging
7. PkgPredictions.db (Samsung devices only)
8. notification_log.db (Samsung devices only, up to Android 10)
9. Usage stats
10. Battery stats
11. Graphic stats
12. Library.db
13. Raw keyword search for the app bundle and the app common name
14. Extract and analyze a bugreport

Some personal and final thoughts on Android, based on the tests conducted and previous experiences. During testing, I found that package permissions, package runtime permissions, package tasks, privacy dashboard, appops, and network stats are deleted when an app is uninstalled. 

The chances of recovering content from the uninstalled app are limited to screenshots, files stored by the app on the emulated SD card, and Firebase cloud messaging: these files are not deleted when the app is uninstalled. Two relevant artifacts that need to be analyzed to investigate usage traces are usage stats and battery stats: especially the latter still require a lot of research and are not supported by the tools. The database that stores information the longest is the "library.db" as it relates to the Gmail account and not specifically to the device you are analyzing.

If you have no way to get a full file system, you are very limited when investigating deleted apps: you can still extract and analyze the files in the emulated SD card and SMS messages, but localappstate.db, gass.db, digital wellbeing, firebase cloud messaging, PkgPredictions.db, notification_log.db, Usage stats, Battery stats, Graphic stats, and Library.db are not available. In this case, it is mandatory to create and extract a bugreport that gives you at least access to usage stats and battery stats data.

And that's all for the last post of 2023! See you next year!