iOS - Tracking Traces of Deleted Applications

In July of 2019 I had the great honor and pleasure to present at the annual SANS DFIR Summit with the always awesome Alexis Brignoni (https://abrignoni.blogspot.com/). We decided to tackle the issue of "Once a user deletes an app, what's left?" Turns out, while the container that holds the data is gone, there are lots of traces that remain of that application. Since Alexis has already covered the Android artifacts in his blog, I'll use this post to explain some of the iOS research I did on that side.

Let's start with talking about if your app is actually deleted or just "Offloaded." Offloading apps is a feature of iOS 11 that allows a user to remove an app from their device but keep all of the documents and data relating to the application. When a user installs an app on iOS, the data is delivered to two separate "containers" which are just folders.

In this example, by checking the ApplicationState.db which is found in an iOS device at \private\var\mobile\Library\FrontBoard\applicationstate.db or in an iTunes-style backup at HomeDomain-Library\FrontBoard\applicationstate.db you can see that the Twitter app (com.atebits.tweetie2) was installed at /private/var/containers/Bundle/Application/15FFD685-5154-4C07-B332-95F3F7521A48/Twitter.app while the data for the Twitter app was installed at /private/var/mobile/Containers/Data/Application/1562A7BD-D4FA-4838-88FC-3F48C009EBD0. If the Twitter app would be "Offloaded" by the user or by the OS because a setting was enabled to remove apps that are not frequently used, the entire folder that Twitter.app is in would be deleted but the other folder (1562A7BD-D4FA-4838-88FC-3F48C009EBD0) would still be there. Once the app is offloaded, the entry in ApplicationState.db is removed. 

So how do we figure out if there are offloaded apps? The easiest way is to check the IconState.plist properly list file (or just look at the phone itself). 

In the above screenshot you can see that 3 apps (GarageBand, Keynote, and Numbers are offloaded apps while Lime is fully installed). If the user tried to open any of the offloaded apps, they would see the app start to download from the App Store. 

By using the IconState.plist, users should compare Bundle IDs for apps that are listed in IconState.plist that don't appear in applicationstate.db. 

Okay! Back to the topic at hand: those traces and tracking them. Once confirmed that an app is deleted, we start with its Bundle ID. That is the absolute key to finding data about an app. A quick search in your favorite forensic tool of choice will show where the data appears and was used to track a lot of the artifacts mentioned below.

UninstalledApplications.plist
This one is an obvious stop. Only available in a full file-system style image, it lives in private\var\installd\Library\MobileInstallation\. This file will show the BundleID of apps and then the date when the app was LAST deleted from the device. If the app is reinstalled, then deleted, it's only tracking the last deleted date. 

This one tracks data for a LONG time. I've found data in here at least 9 months old. It doesn't transfer from device to device and it is device-specific. I've also found that this file isn't ALWAYS here, however, once a user purchases a paid app or has a credit card tied to their AppStore then it seems to populate. 

Mobile Installation Logs

Alexis already did a phenomenal job on this one and even built a tool for it. So i'll direct you over to his blog on this one. https://abrignoni.blogspot.com/2019/01/ios-mobile-installation-logs-parser.html

Some notes about it, it seems to be record restricted versus time restricted. I've only ever found a 0.log and a 1.log file. After filling these, it seems to start to reuse the logs instead of just constantly keeping more files. This will track when containers are created or deleted but also iOS likes to move around its containers at times and it tracks those as well. 

DAAP.sqlitedb

Normally DAAP for Apple stands for Digital Audio Access Protocol and it's used for their sharing media across a local network. In this case, the DAAP.sqlite db lives in private\var\mobile\Library\Caches\com.apple.appstored\ and stores applications that were purchased by the AppleID (or potentially their family). It doesn't just include apps that were on the device, just apps that were purchased. 

It seems to have been added in iOS 12 and tracks some great info. 

In the above screenshot, us.zoom.videomeetings (Zoom) was deleted. It's the same app that you can see in the screenshot from UninstalledApplications.plist that was deleted on 7/8/19. 

AppPurchaseHistory.6.sqlitedb

This database is very similar to DAAP. One thing to note is that it's also found in older versions of iOS. It can be found at private\var\mobile\Library\Caches\com.apple.storeservices\. 

There's several other artifacts you can look at including: 

• ScreenTime
• PowerLog.PLSQL (don't forget archived copies)
• KnowledgeC.db
• DataUsage.sqlite
• netusage.sqlite

One last thing to consider is that some apps may call into other databases using APIs. For example, if you make a call from an app, it may make an entry in the CallHistory.storedata database. More recent versions of iOS will go back and remove entries from the database when the app is deleted but it's always worth a good carve through the database to check and see if there are any mentions of the bundleID. 

For more information about the artifacts, go check out the presentation over on the SANS website here: https://www.sans.org/cyber-security-summit/archives/file/summit_archive_1564167956.pdf

I'll be sure to update this post when the video goes live too!