iOS 16 Breaking Down the Biomes Part 2 - AppInstalls, AppLaunch, & AppIntents

 In my previous post in the "Breaking Down the Biome" series, I covered the basic structure of biome data in iOS as well as mentioned how several things went missing from KnowledgeC in iOS 16. In this post I'm going to cover one of those that went missing,  Application Installs, as well as some data that can correlate as well as still exists in the KnowledgeC.db (but might not always). Something I've noticed in my testing of iMessages for this year's SANS DFIR Summit is that when a message is deleted from the device it may also delete itself from the KnowledgeC database but NOT always removing itself from the Application Intents biome data. You can see some evidence of this in this post where I talk about unending/editing/deleting iMessages in iOS 16. 

Application Installs

There are different ways to track what applications are currently installed and have been previously installed in iOS. One of my favorite ways relies on the use the mobileinstallationlog file which can track when apps get installed AND installed. However, one of the issues with this file is that it can get noisy as it also tracks when containers are created and destroyed which is something Apple tends to do frequently even if the app didn't have any associated activity. It also doesn't seem to be time based and more based on the number of records written/size of the file so data that you might want could be missing depending on the activity being recorded in that file. 

Because of that, I love turning over to the KnowledgeC.db file and looking at the app/install value within the ZOBJECT.ZSTREAMNAME area. Unfortunately, in my testing of iOS 16, that stream name value in no longer present. Similar to last post's ability to turn over to the biome data and look for the "app/inFocus" data, we'll do the same here for the install logs. 

This data can be found in the path: private\var\mobile\Library\Biome\streams\restricted\_DKEvent.App.Install\ and has the same structure as previously mentioned with a metadata plist file and a local folder containing SEGB binary files. The metadata plist file shows us another maxAge value of 28 days (after translating from seconds). 

Since my phone was just set up a few days before, a lot of the first records in this file are corresponding to first party system applications. This could be a good indicator to look for to see if a device was just restored or upgraded. 

Like other biome files, once the SEGB header ends at byte 56, each record following is a 32 byte header followed by the protobuf record. The first four bytes of the header (in little endian) still show the length of the protobuf record and the next record header will begin after the end of the protobuf padded to the next byte divisible by 8. Two records for WhatsApp and Snapchat have been included below. As a note, the install start and finished times are Apple Time values but seem to be rounded to the top of the minute in my tests. 

Application Launch

Previously a lot of tools have tracked "Application Usage" and while that can still be tracked in both KnowledgeC.db and the biome areas, there's another one that can be tracked referred to as "Application Launch" or the AppLaunch function. This function seems to be fairly prevalent in the biome data and mentioned in several database files when tracking syncing information. Similar to the inFocus data shown in the previous post, there is a number of transitions that can be tracked in these records as well. 

The path to the Application Launch biome is: private\var\mobile\Library\Biome\streams\public\AppLaunch\

As with many of the biome data points, the metadata plist files contains much of the same keys about the time to keep the files. In this case this data is 28 days. 

This is a good time to remind folks that not only can you have the "local" biome data but also potentially remote data like in the following screenshot. These folders under remote are tied to device GUIDs assigned as part of the biome's sync.db. 

The protobuf for each AppLaunch looks like this: 

There are several visible "transition types" that start out each protobuf record. The ones I've been able to record so far are listed below: 

• com.apple.SpringBoard.backlight.transitionReason.idleTimer
• com.apple.SpringBoard.com.sitionReason.homescreen
• com.apple.SpringBoard.transitionReason.externalrequest
• com.apple.SpringBoard.transitionReason.appswitcher
• com.apple.SpringBoard.backlight.transitionReason.lockButton
• com.apple.SpringBoard.transitionReason.spotlight

Application Intents

This is probably one of the most important things tracked within the biome data. Once the application is installed, Apple will then track different "intents" of applications, both first and third-party. The data tracked for each application depends on what APIs the application is using so your milage may vary when it comes to seeing if your target application is in the intent data and what it is tracking. Some applications that I have seen in here that have piqued my interest include: 

• com.apple.mobileSMS
• com.apple.mobilephone
• com.toyopagroup.picaboo
• net.whatsapp.WhatsApp
• com.burbn.instagram

For more information on the AppIntent function, Apple has provided a bit of into on the developer documentation here. The short version on AppIntent is that it is providing content/context to certain functions for Siri Suggestions or Siri Shortcuts. This doesn't mean you have to use the Siri voice assistant to make something happen. Think of Siri as your iPhone's version of Alexa in that it's always listening/watching/learning. 

Application Intents record a number of different events for a number of different apps. Some of the more interesting intents that I've seen include: 

• INSendMessageIntent
• INStartCallIntent
• INCreateNoteIntent
• INAddTaskIntent
• INPlayMediaIntent
• INSendPaymentIntent
• INRequestRideIntent
• INStartWorkoutIntent

When it comes to the intent INSendMessageIntent it really is going to depend on what app you're investigating. While Snapchat, Instagram, and Twitter all record intents, they don't really keep the content of the messages within the biome. What you will more commonly get is the participants of the messages, dates and times, and the directionality of the messages though. 

The content of the protobuf for each intent is one of the more complicated ones that I have come across. Within the protobuf you will find information such as the app recorded (bundleID), a date/time of the action, the intent used, and usually a binary plist file saved within. The binary file is often our true jackpot within the protobuf data. 

The first key is going to be our Apple Time value of when the intent occurred. The next refers to the bundleID of the recorded app. In the above graphic, key 4 shows us the intent that was used, in this case the INSendMessageIntent. 

Extracting the binary plist file shows an NSKeyedArchiver style file. These files will contain ANOTHER protobuf (or two) that need parsed out. Depending on the tool you're using to review the plist file, you may need to convert the protobuf from Base64 first, but some tools may do this for you. You'll be looking for the key "<bytes>" that contains the protobuf data. 

Within the above screenshot you can see several key points such such as the value [5] containing the body of the message. The next value [8] contains the service and sender. The value under key [15] shows the sender while the data within key [2] shows the recipient. If the other party is a known contact, there will also be information showing the first and last name as well as the identifier GUID from within the AddressBook database. 

So to recap: 

Biome (SEGB) File --> Protobuf Record --> Binary Plist --> Protobuf Record. Yikes. 

Not all of the protobuf records at the end of the rainbow are pots of gold like the one for messages. The following one is from a Snapchat SendMessage intent. 

In this protobuf we can still track that our user "Paul Pelican" was talking to a user "Al Paca" on Snapchat but that's about as far as it goes. Still, could be valuable within investigations. 

Other intent types such as the INStartCallIntent also contain valuable information about who and when users are talking to each other. This can include calls through the standard phone service as well as VOIP services through third-party applications. 

A final couple thoughts on observed AppIntents. At times, you will find that within the binary plist file there is not a protobuf, but instead ANOTHER binary plist file which contains the final protobuf you're looking to find. 

Wrap-Up

If there's one thing I'm learning from parsing this biome data is that it can really make your head hurt. Tracking applications and when they're installed, when they're launched, and what they might be up to, however, is worth the headache. Remember that similar to when it was kept in KnowledgeC that this data is only going to be tied to approximately the last 28 days (outside of tombstone records which could contain more expired data), but with the switch to the biome storage it is important to look for the remote as well as local binary files to find information from other devices. While the tools don't support all of the biome data as of yet, forensics tools can be a good starting point for parsing this information out of specific biome files. Hopefully the roadmaps laid out above can help you identify more files worth digging into. 

Until next time!