Wednesday, 23 September 2020

iOS 14 - Tracking App Clips in iOS 14

 iOS 14 brought a couple of new features I've been wanting to test. In past years I've evaluated Android's "Instant Apps" feature and of course when Apple added this with iOS 14's App Clips I had to see what was being stored. 

So what are App Clips anyway? For that I'll direct you over to Apple's website here. Apple's App Clips are mini-versions of applications that a user can quickly download and interact with without installing the full version of the app. These App Clips can be distributed to users in several ways from being embedded into web pages, NFC tags, QR codes, or even by using apps like Messages or Maps. 


When a user gets a notification they can download an App Clip it'll open up on their device after a brief download screen. From there they can interact with a minimal version of the application. Depending on the app, you'll get access to features the developers want you to have with obviously a big and constant incentive to download the full version of the application. Below are some screenshots of the process of finding an available App Clip (one via the Maps app and one via Safari), installing them, and using them. 


Hm, Panera sounds good for dinner, but I don't have the app. So instead, I can just use the Maps app to direct me to the Panera App Clip instead. 


The App Clip will appear as though it's running. It will generate its own KTX snapshots and be a running process within the device. 


However, you won't find the app listed on the Home Screen or iOS 14's new App Library either. Even if you accidentally close it you can't just use Spotlight to launch it again. 


Here's the Kontax Cam app. You can launch it directly from the website. 


All tested App Clip downloads look just like this. A blurry background and the text will slowly fill up with white as a progress bar. 


Most App Clips will constantly display a notification encouraging you to get the full version of the app. Here, you can see the app would allow me to take a photo but not actually save or do anything with it until I did. App Clips will transition your information to the full version of the app if you download it. 


So where can we find out what App Clips are even installed? There's some forensic artifacts to discuss but on a live-running device we can go to the Settings -> App Clips page to see the clips that are currently installed on our device. You can also click on each app clip to see the permissions that have been granted to that specific App Clip as well like Camera access or Geolocation access. You can also use the "Remove All App Clips" to get rid of them from your device. 

NOTE: According to Apple's statement under that "Learn More..." they say that data associated with the app clip is deleted after 10 days of non-use. Clips are automatically deleted after 30 days of non-use. 

One More Note: The above graphics were from my iPhone, while the screenshots and research below were done on a separate iPad device running iOS14/iPadOS14. Mostly because this is currently the only iOS14 device in which I can get a full filesystem image at the time of this writing. 

From a forensic image perspective, what can we track for these applications? It's going to depend on your level of access, as always. I noticed that from within my testing that NONE of the App Clips I tested (there were about 4 in this device as the number of apps using these are still limited) kept data within an iTunes-style backup. I was able to track that certain clips were used by using both iTunes-style backups and SysDiagnoseLog data, but not the data itself. 

Tracking the Data -  Installation and Storage

The first step in tracking these app clips is to see what the user has installed. Because of the way iOS tracks installed applications depending on your image type, we have to look in multiple placed. 

Info.plist / Manifest.plist - In a quick image, both the info.plist and manifest.plist file did not have any App Clips listed. 


ApplicationState.db - In both the quick and full image, the ApplicationState.db file tracked the clips being installed as well as their "true" path. In my testing, none of the App Clips data or bundles were in the iTunes-style backup. 




Each App Clip had the same bundle ID of the full application only with .clip added to the end of it. 

mobile_installation.log.0 - Full image or found within the sysdiganoselogs. These logs can show the applications that are installed and could go to show App Clips that are used and then deleted over time.


 Tracking the Data - Usage

Outside of tracking what App Clips are actually installed, the same methodology we would apply for regular apps seem to apply. The ApplicationState.db and mobile_instalation_log.0 data points gave us the right directories for finding anything that's stored. This will obviously change from app to app, but should at least point us in the right direction. Other standard artifacts that would be used to map when the apps are used like KnowledgeC and PowerLog are tracking these App Clips just the same. 


I did notice that right before the App Clip was triggered in KnowledgeC the service "com.apple.ClipViewService" would pop right before while the App Clip is being loaded. 

Tracking information for the "ClipServices" led me down to a new path found only in full filesystem image: private\var\mobile\Library\com.apple.ClipServices.clipserviced\. The ClipData.db database found here stores information about the App Clips installed and permissions approved by the end user. 

A quick and easy SQLite query for parsing this information is: 
SELECT "bundle_id", 
"user_notification_consent", 
"location_confirmation_consent",
"allows_location_confirmation_after_launch",
datetime('2001-01-01', "last_user_notification_request_time" || ' seconds') AS Last_Notification_Request_Time,
datetime('2001-01-01', "last_version_check_time" || ' seconds') AS Last_Version_Check_Time,
datetime('2001-01-01', "last_install_time" || ' seconds') AS Last_Install_Time,
"parent_app_name",
"parent_app_store_url"
from app_clips; 





App Clips can ask special permissions that may extend beyond the standard TCC.db. This may prove to be another prime location to find this data. 

As more applications release their App Clip variants, I expect this database to grow in importance. I would expect that using KnowledgeC and PowerLog can help show how these app clips are getting onto the device. Only time will tell how important these clips are to investigations, but at least we have a good way of tracking them on the device!

No comments:

Post a comment