Taking a gander at iOS apps on an M1 Mac
I wanted to share some initial research I did over the rainy long weekend. I recently got access to a MacBook Pro with the M1 chip and so naturally I wanted to take a look at how running iOS apps natively on macOS works, where the app data ends up on the HDD, and of course, to see if Frida works on it or not. 🙂
Given the large number of iOS apps that you can presently install via the App Store, it’s definitely conceivable that we might start seeing instances of this on Mac extractions, so I thought it might be helpful to have a frame of reference for where iOS app data is located.
For this research, I decided to install Private Photo Vault (which continues to bring a ton of traffic to my site to this day haha), but I suspect the story will be similar for other apps.
First things first, let’s find PPV on the App Store. One note is that you need to click on the iPhone & iPad Apps filter, which seems obvious now but didn’t immediately jump out when I started this before my coffee activated.
Okay great, it’s installed. It shows up on the LaunchPad just like any other installed app, neat.
OK great, let’s launch the app and set it up, and take a photo. The app seamlessly integrates with the MBP’s front facing camera (which still produces pretty awful looking pictures compared to iPhone).
First I’ll check if Frida sees the process by running
frida-ps | grep Vault.
We see two processes of interest including Photo Vault and Keychain (Photo Vault):
More on my adventures with frida in a moment, but let’s take a moment to search for the data. With the help of the find command (and knowing by heart at this point what files and folders PPV generally leaves in the filesystem on iDevices), I located the data for the app at:
/Users/(name)/Library/Containers/(Installation GUID)/Data/Library
As seen in the below screenshot, within this folder we have similar contents as PPV on iOS, except with a ton of other folders too!
So what is going on here? If we do an ls -l it becomes clearer:
Any of the items starting with l are symlinks! In fact, if we step up a folder to /Data we can see Desktop, Downloads etc. and all of the folders we expect to see in ~/ for our user, are here again, as symlinks.
I’m sure there’s a good reason for this, but it’s something to be aware of when traversing these app directories as it can spam us pretty bad when using the find or ls command 🙂
Fortunately, when we create a tar file with the contents of the Data directory, it does not fully traverse the symlinks. Here I did: tar cvf ~/Desktop/ppv_macos.tar .
And as you can see, the symlinks are still present but listed as ~20 byte files instead of directories.
And 7-zip considers them dangerous and doesn’t bother to create them when you do a full extraction:
Frida
I now wanted to see if I could attach with Frida. First attempt, I got an error saying my user account didn’t have permissions to attach. I remembered seeing this before, and after googling I found it indeed it had to do with SIP (System Integrity Protection) being enabled. To disable, one must shutdown and then restart into recovery. Note that on M1 Macs, instead of holding Cmd+R and booting, you actually just hold down the power button until the boot options screen appears. After booting to recovery a good ol’ csrutil disable from the terminal still does the trick.
After rebooting, I went to startup PPV again and was met with this sad message:
So, it looks like some additional work will be required in order to deal with this. I did find this tweet from @SparkZheng though, so looks like it is possible with resigning?, but I haven’t had time to go further just yet.
Notwithstanding that, if you don’t have yourself a test iDevice but do have an M1 Mac and are interested in accessing filesystem artifacts without having to do repeated extractions, this could definitely be a timesaver.
