In the first post of this week I detailed a lot of the paths you might want to use if you're using a full filesystem image of an iOS device. I also detailed several ways to find this information using a live test device. In this post I want to circle around and talk about what you can hope to find from the Files app in the more common "Quick" image format or the iTunes-backup formatted image type. A lot of the same areas are going to be there, just under some different names.
Tracking the Files App Storage:
Instead of using the ApplicationState.db file to go and find the APPID paths, we really just need to rely on the bundleID for the Files app. There's a couple of ways we can track this, so I'll start from zero. Let's say you know the name of the App is "Files" but don't already know the bundleID. How can we find it? Unlike the Google App Store, there's no easy web store we can go to and just search for apps. What we need to do is perform a little google-shenanigans by searching for something like "iOS Files App Store." Doing so will return the online App Store preview page as the first result. You can click here to see this one. The URL for this is going to be: https://apps.apple.com/us/app/files/id1232058109 and that's going to be important to us. The numerical identifier after "id" in the above URL is what we need. So we're going to copy that piece out.
Next we're going to navigate to the following URL: https://itunes.apple.com/lookup?id=[IDValue] replacing that value we took from the previous URL and putting it where you see "IDValue." Navigating to this page is going to trigger a download within your browser of a text file.
Opening said text file, we want to look for the word, bundleID. I've copied some additional information so you can see what's around it but here's what we're looking for:
"artistName":"Apple", "genres":["Utilities"], "bundleId":"com.apple.DocumentsApp", "sellerName":"Apple Inc.", "version":"1.3.3"
Okay, now the cheater method. You could also just go to https://offcornerdev.com/bundleid.html and just search for your app too.
Now that we have our bundleID, we want to turn back over to our iTunes backup style image and head over to the Manifest.db. Every forensic tool seems to handle these iTunes-style backups a bit differently, so by heading to the Manifest.db we can at least learn the core information about where we want to go.
Now that we know the bundleID, I'm just going to search for this ID in my file explorer to navigate through my directories. By going to the main "AppDomain-com.apple.DocumentsApp" directory we're going to find the data mentioned in the previous post for the 'Inbox' folder, aka, the files that were AirDropped to our device and accessed using the Files app.
Some of the data was also stored in the "Shared/AppGroup" directory structure of our full filesystem image. So we're going to need to tweak our search a little bit. We know that there was a database that was a lot of help called "smartfolders.db" so we're going to turn back to the Manifest.db file and look for it there. That's going to return a domain of "AppDomainGroup-group.com.apple.DocumentManager" [whew what a mouthful]. The smartfolders.db is the only thing in this directory but still acts the same as it did in our full filesystem image.
The next thing to track the directory where the files were stored that weren't AirDropped, as well as the directory structure and .Trash folder we found earlier. To do this I'm going to cheat a bit and use the Manifest.db file again to just search for my test folder "Cade."
Another bit of a mouthful but it looks like we need to hunt down "AppDomainGroup-group.com.apple.FileProvider.LocalStorage" to find our data tracking back to the 'On My iPad' storage of the Files app. This keeps the File Provider Storage folder with the directory store built by the user and the .Trash folder intact. So yes, files the user THOUGHT they deleted, are still very much there.
How about the iCloud Drive stored data we found earlier? This information is going to be stored in the HomeDomain under "HomeDomain-Library/Application Support/CloudDocs" but not all that we want is here. The client.db and server.db that will list out information that will be stored in iCloud Drive, files that were uploaded from this device, and the devices that can sync with this iCloud Drive are all here. For the Mobile Documents we need to head up a level within the same domain. As with some of the previous paths, some of the information is missing but the really good stuff is here. Within the HomeDomain-Library/Mobile Documents directory you can find the com~apple~CloudDocs folder that's going to store our files stored in iCloud Drive, the .Trash folder, and the Downloads folder for Safari.
The only thing completely missing is going to be the data we found that was attached to the Dropbox tied to the Files app. While some data was still available within the Dropbox app that shows us the names of files that may be in the user's Dropbox and some user information for what account is signed in, the physical files themselves were missing from the Quick image.
One of my colleagues, and proud to say friends, Alexis Brignoni mentioned that it would be helpful to create a chart at the end of the post that would highlight the paths for the artifacts to help people retain a quick access list for easy access. I completely agree and will strive to end each of my artifact-based posts with a quick chart of the paths mentioned!
Operating System: iOS [13.7]
App Name: Files
Image Type: Full Filesystem
Image Type: iTunes-style Backup / Quick Image
Post a Comment