iOS - The Files App

I've been working on a new set of applications but before I begin those, I wanted to take a detour around an application that we've all probably come across from time to time, but had often confused me on where and how it stored its data. This application is the "Files" app that Apple added in iOS 11. With iOS 13 (and iPadOS 13) there were several additional features including the downloads directory. Files has also added abilities to generate iCloud share links and collaborate on files on apps such as Pages, Numbers, or Keynote. In addition, third-party applications can also tie into the Files app for the quick access, sharing, and storage of Files on your iOS device. For more information about Apple's Files app, see this link here. 

In order to find the data for this app I decided to use some of my favorite tricks on an iPad I recently set up and jailbroke as per my recent research device post. The easiest place to find where the Files application SHOULD be storing data is to use one of two tricks: 

1. In a forensic image, consult the applicationstate.db file to find the bundleID com.apple.DocumentsApp
2. In a live running (jailbroken device) use the CDA command line tool to search for the path. For more information on CDA, get it on GitHub here. 

From the above graphic, you can see that on this iPad we're looking for the paths that track back to the listings for Data and Group. Interestingly enough, you can find some files saved on the device twice in these directories depending upon HOW the data got to the Files app. 

Starting with the Containers/Data/Application path, there isn't much there by way of the preferences. There is a folder within the Documents path called Inbox which proves interesting. 

These files were sent via AirDrop to the iPad and then when dropped or "opened" with the Files app (as best as Files could). Files that were downloaded to the "On This iPad" location of the Files application were stored in a different location if they were NOT airdropped. Further testing than just the two files that I captured confirmed this. What is the "On This iPad" area? 

But what happens if a file isn't transferred to AirDrop? Where else can we find the data and the folders that are stored within here? In you look in the above graphic, you'll notice a folder called "Cade." How can we find this information? If we direct our attention to the AppID directory found within the Containers/Shared/AppGroup directory, we can find a database that can be of some assistance. 

The root of this directory holds the database smartfolders.db. This database has several important tables. The filename table can reveal the files that are stored within the "On My iPad" area. 

 However, you may notice that some of the above files are... missing. So where are they? Well, I'll get to that in a minute. First, let's talk about that sneaky fp_folder_item table. What is that I spy in the BLOB data? It's a binary plist, because, OF COURSE IT IS. Upon opening this, it's actually an NSKeyedArchiver style (ew) one that can give us quite a bit of information about the info of the file. 

By flattening, or deserializing, the Plist file, you can see lots of good info like creation and used dates, file path structure (Cade), and even if the content has been modified or a download has been requested! Awesome stuff!

The hotfolders table of the same database will also store information about the Application Libraries that are tied to the Files app's On My iPad storage like Pages or Keynote. 

Okay so now we know about the files, so where are they?! Turns out, they're not going to be found (not all of them anyway) in any of the directories that were tracked by cda. To find this I turned to another awesome little dynamic analysis tool, fs-mon. Seriously, if you have a Jailbroken iOS device, go put fs-mon on it now! You can get it from here. After running fs-mon while interacting with some of the files in my Files app as well as using a good old fashioned: 'find . -name Cade' command I came across another separate location entirely. 

You're going to want to look for a Shared/AppGroup directory that references group.com.apple.FileProvider.LocalStorage. I would recommend instead of looking for this file, look for the folder "File Provider Storage" as it might be a little easier to find. Once there, THIS is where all the files you had stored locally on the "On my iPad" are going to be found. Here we can find the files that we had saved with their directory structure intact as well as a .Trash folder! Score!

This folder is holding the files that I deleted from the "On My iPad" section. Interestingly enough, they do NOT get put into the "Recently Deleted" screen on the Files app. In my testing, only the files that I had deleted from my iCloud Drive did that. 

I think this is a good time to take about the iCloud Drive section. None of the previous paths that I have mentioned are going to have what is stored there. So what is stored there you ask? I'll show you. 

As you can see, some of the files have been downloaded locally and some have not. This will impact what information can be recovered relating to said files. The easiest way to find these files is to do a quick search against your filesystem (either using that 'find' command I mentioned earlier or with your tool of choice in your forensic image). 

Searching my forensic image for "UhOh" using a recursive search turned up a new path!

private/var/mobile/Library/Mobile Documents/com~apple~CloudDocs/UhOh.numbers. Now I've already blogged about this path a little bit when talking about the Downloads for Safari in iOS 13 for the Magnet Forensics blog but I think going from iOS 13.0 to iOS 13.7 is worth a quick revisit. 

Reviewing this folder, you can see there is another .Trash folder to explore, the Downloads directory associated with files downloaded (by default) in Safari for iOS 13, and files that have been downloaded locally, namely OwlberyResume.pdf and UhOh.numbers. The other files within this directory that were kept as online only, instead have hidden files (. before the name) and the extension of .iCloud. These are nothing more than .plist files. The only information in these .plist files are the name and the size to be honest but interestingly enough that with this information we can track the names and sizes of all the files the user has stored in their iCloud Drive even if we don't get the files themselves. 

That path reminds me of how it's done on the macOS system. So it seems to me we should probably check out /private/var/mobile/Library/Application Support/CloudDocs too, One there, you're going to see a pretty close copy to the macOS variant of the same folder. The account.1 file will reveal the DSID or the numeric identifier for the synced iCloud Drive holder. By digging into the session/db folder, you can find the expected client.db and server.db databases that are going to hold information about the files uploaded to iCloud as well as the DEVICES that can upload to iCloud! Score! More information on the files that are being held and where else these files could have originated. 

Looking for evidence of data exfiltration via iCloud Drive on the Files app? Check out the client.db's client_uploads table. Very handy. 

How about that dropbox areas we saw tied to the iCloud Drive? AXIOM and other tools do a good job parsing out the Dropbox.sqlite database for the application. However, I want to take this a step farther. Reviewing the artifact in AXIOM we can see the data for "WorkDocs.dmg" here: 

Hm, not bad, but I want to see if I can find the original file name associated with it. Reviewing the File Provider Storage folder like we did for the original Files app, we can find this: 

Okay, getting closer. I can see that I have the numerical ID for this Dropbox user in the path, but that looks like BASE64 to me. So, CyberChef to the rescue! Heading over there and running the paths through a quick From: BASE64 recipe, I get back exactly what I want. 

And you guessed it, inside that file is the WorkDocs.dmg in its original named glory. Still need to do some more testing to see if flagging a file directly in the location stores it different than flagging it for offline within the Dropbox app. However, I can say that from my testing the File Provider Storage directory only stored BASE64 values referencing files saved for offline storage from the Files app, NOT the Dropbox app's "Make Available Offline" option. Also one last tidbit, when you delete a file from the Files app within the Dropbox, it deletes the file, but not the BASE64 name of the file as a folder. 

Whew! Okay that might be one of the longer ones and was a lot of run to write and test! Got any more questions about the Files app? Let me know! I'm hoping to revisit it a bit at least to test the differences between live file system and iOS backups as I know that original version of iOS 13 had lots of juicy bits. Curious if Apple has shut any doors to us there but we'll save that for next time!