ios

Part 3: Step-by-step Tooling for iOS Research (via @bizzybarney)

This is the third and final piece of the Mac and iPhone setup process!  Sorry for the long delay between the last one and this one, but better late than never right?

giphy-3.gif

This guide will help you setup your iDevice with two binaries that can greatly assist with targeted testing and analysis.  My goal is to equip you to do your own research and testing to confidently answer the questions you will surely have as you learn this beautiful dance we call DFIR.  If you currently rely on a commercial tool to extract your iDevice data and then parse the data for you, that is totally normal and this article is absolutely for YOU!  Years ago, @iamevltwin broke my thought process on how to address mobile devices.  My training and education up to that point was great, and I knew a LOT about mobile devices and strategies for finding the evidence I was looking for.  But….I relied on data extraction methods by commercial tools and mostly parsing by commercial tools as well.  While that is acceptable and perfectly fine to do, it can be very time consuming.  Trust me when I say, if @iamevltwin asked me a question, and my response was “I’ll let you know in a few hours”…she would probably throw a steak and cheese egg roll at my head. [*Editors Note: I would never waste a delicious steak and cheese egg roll, instead I would deeply judge and give him the side eye.—S]  So for the sake of never wanting to waste a good egg roll, I learned how to target just the data I want and address it in a very specific way.  

To summarize what we are about to do:

  1. 1. Install and run “fsmon” and “cda” binaries that already have proper entitlements, so you don’t have to make the files.

  2. 2. Very basically learn what they do and how to run them.

  3. 3. Use them to target a specific piece of data on the iPhone.

  4. 4. Extract that specific piece of data to my desktop so I can “GET SHIT DONE” 

**If you are reading this, please make sure you have read and followed the instructions for Part 1 and Part 2 .  If you are jumping in here and trying to follow along, I assume your Mac and iDevice are the same as mine from the end of Part 2.  It is strongly advised that you do this on a secondary, test / research device and not your primary use device.  Nothing we are doing here should break anything, but things happen when you are in a root shell into your device and you have been warned!.**

Download iOS Binaries

I have both binaries you will need already made and entitled, trying to make this process as easy as possible to get you setup for testing!  The link below will take you to a .zip file containing ‘cda’ and ‘fsmon’, which are both Mach-O 64-bit ARM executables.  

The ‘cda’ binary helps locate where an app is storing it’s data! iOS stores most app data behind randomly generated GUID’s in the file system, so finding where a certain app is storing its user data can be a real pain.  This binary makes quick work of telling us exactly the directories we need to pay attention to, and does so in seconds.

The ‘fsmon’ binary is a file system monitor.  Plain and simple, it prints to your screen the changes occurring in the file system.  For research purposes, this is priceless.  If you need to know what happens when you take a photo, send an SMS, install an app, etc. you can run ‘fsmon’ while pressing the buttons on your device and watch your screen light up with what changed!

1. Click this link and download the .zip file. (Not (knowingly) malware, I promise!)

If you want to do it yourself, or are simply curious about what you’re downloading - here are the links to the GitHub repo’s where I got them:

  • cda - “A simple iOS command line tool to search for installed apps and list container folders (bundle, data, group). Thank you, Andreas Kurtz!!

  • fsmon - A file system monitor. Thank you, Sergi Àlvarez & Nowsecure!!

2. Now that you have the binaries, we will put them into a folder on your Desktop for simplicity.  Create a folder on your Desktop named ‘binaries’ and move the .zip file there.  Unzip it so the two binaries are in the ‘binaries’ folder.  It should look like this:

Connect to Test iDevice

Now that we have the files we need, we need to make sure our iDevice is connected to our Mac via USB and we are able to communicate with it.  Following the instructions from the Part 2 article, get connected to your iDevice via USB.  I’m going to show my actions below but if you have any trouble, go back and make sure your system is setup correctly from the previous articles.

My test device is an iPhone X (A1865) on iOS 14.2 that is jailbroken with checkra1n.

1. Open Terminal window on Mac.  Type iproxy 4242 44 and press return.  (If you’re on a device using unc0ver jailbreak you might need to use port 22 instead of 44).

2. Still working within your Terminal window, press command+T on the keyboard to open a new Terminal tab.  In the new tab, type ssh root@127.0.0.1 -p 4242 and press return.  You will be prompted for your password to access the device via SSH.  If you haven’t set a unique password, your default password is alpine.  Nothing appears when you type, so type your password and press return.  You should then see some version of a bash prompt with a # like in the screenshot below:

You’re now essentially in a CLI (command line interface) on your iPhone via your Mac.  What does this mean?  Well, it means you should be careful.  There isn’t an operating system lifeguard to keep you from removing files and directories you didn’t intend to.  If you aren’t familiar with navigating via CLI, that’s ok, do some research.  Look for a Mac Terminal cheat sheet online to expand your knowledge, but I’ll try to be very descriptive with the commands we use here.  

If you’re keeping score, we now have one Terminal window open that we used to iproxy into the iPhone.  We won’t use that window again unless our connection fails and we have to start it up again.  Your second Terminal tab should be a shell into your test iPhone.  

3. In the tab with the shell into your iPhone, type pwd and press return and it will show you your current directory or “Print Working Directory”.  We can see that we are in the directory /var/root.  Now type ls -la and press return to list the files in the current directory you are in.  

**For any of the CLI utilities we use in this exercise, in a Mac terminal shell you can type man <name_of_utility> and press return to see the manual for it, with all of the available flags you can use.  For example, if I wanted to remember how to use ‘ls’ to recursively list all the files in a directory and subdirectories, I would type man ls and press return.  Using the man page, I could see that using ls -laR will (l) list long format, (a) revealing directory entries beginning with a dot (.), (R) and the recursively list subdirectories encountered - respectively.  To leave a man page, just press Q and it will jump back out to your Terminal shell.**

Copy Binaries from Mac to iPhone

Now that we have the files downloaded and on our Desktop, and have a shell into our iPhone - we can move the files onto the iPhone.  

1. From your Terminal shell into your iPhone, press command+T again to open a new Terminal tab.  This new tab is a shell on your Mac, not the iPhone.  Click into the newly opened Terminal tab on your Mac and type the following: scp -P 4242 ~/Desktop/binaries/cda root@127.0.0.1: then press return.  You will be prompted for the password to access the iPhone - not the pin to unlock it, but instead either alpine or the unique password you set if you changed it.  Enter the password and press return.

We are using ‘scp’ to “secure copy” or remotely copy a file between our host Mac and our connected iPhone.  The command we typed and entered would more literally read: “scp (secure copy) -P (port) 4242 (port number) ~/Desktop/binaries/cda (a file named cda located at /Users/<your_username>/Desktop/binaries/) root@127.0.0.1: (root is the username and 127.0.0.1 is our localhost and you have to have the : at the end!).

If it worked successfully, you should see this:

2. To be super, extra sure it worked, you can check the list of file present on the iPhone.  Click into the Terminal tab that is the shell into your iPhone.  Type ls -la again and press return.  Assuming you didn’t leave the /var/root directory, you should see a list of the files present at the root of the file system and you should now see ‘cda’ in your list.

Yay!  One down, one to go.  Let’s do it again but this time let’s send ‘fsmon’ to the iPhone.

3. Click back over to your Mac Terminal tab we just used to send the ‘cda’ file to the iPhone.  We are simply repeating the same thing we just did, but for ‘fsmon’ this time.  Type scp -P 4242 ~/Desktop/binaries/fsmon root@127.0.0.1: and press returnEnter the password and press return.

4. That should work pretty cleanly if the first one did, but let’s check to be sure.  Click into the Terminal tab that is the shell into your iPhone.  Type ls -la and press return.  You should now see ‘fsmon’ in the file list as well.

If you see both files, feel free to pour yourself your favorite beverage and sip that for a moment.  You might need it for the next part..

5. The next thing we are going to do is copy these binaries to a different directory on the iPhone.  Assuming you’re following the directions explicitly, you should still be in /var/root on your iPhone, which is where both binaries should be.  In that shell, type cp ./cda /usr/bin/ and press return.  Nothing appears to happen, but we just copied the ‘cda’ file to the directory /usr/bin/.  Let’s quickly do the same for fsmon, type cp ./fsmon /usr/bin/ and press return.

6. Now that we copied them to the /usr/bin/ directory, lets go there and check it out.  To change directories, we will use ‘cd’ and then simply type where we want to go.  Type cd /usr/bin/ and press return.  Then let’s check this directory and make sure our files copied here correctly.  Type ls -la and press return and you should see a longer list of files here, but make sure you see ‘cda’ and ‘fsmon’.  If you see both, give yourself a high-five for making it this far.  We are now one step away from being able to use these things!!

7. Ok, we now have the binaries where we want them, but we have to give them permission to execute on our device.  Type chmod +x cda and press return, and then type chmod +x fsmon and press return.  You shouldn’t get any visible or affirmative response to entering the command, but we just set both binaries so they can execute, or run on your device.

The Moment of Truth - Do the Binaries Work?

Alright, this is it.  This is the moment where you are going to fist pump and exclaim for joy - or cuss, kick things and go back through the instructions above and figure out what you did wrong.  Let’s hope for shouts of joy.  We will start with ‘cda’ because it is going to tell us which directories we might want to run ‘fsmon’ on to monitor activity.

1. Type cda safari and press return.  I picked Safari because pretty much every iDevice you might be doing this on has it and should yield a result.  You should immediately see results populate on your screen.  My device displayed two different results for the native Safari application, one for com.apple.SafariViewService and the other for com.apple.mobilesafari.  Both results are quite typical for any application you might search for, it commonly displays a path to the Bundle, the Data, and Group (if one exists).  We aren’t going to get too deep into the details of explaining these three paths, but generally, here’s a synopsis:  

  • Bundle - This path is where the actual application files exist.  The code that is the application itself, but not the user’s data.  You can find language packs, plugins, and other stuff here but unless your goal is to reverse engineer the application - you probably don’t need to spend any time here.  Think of these files as the files that are downloaded when you install an application, so it appears on your device - but you haven’t opened it and interacted with it yet so no user data has been generated.

  • Data - Go here.  You want to go here.  User data exists here.  Every application you locate using ‘cda’ will have a Data path.

  • Group - Yeah, you’re going to want to go here too.  User data exists here too.  Not every application uses a ../Shared/AppGroup/ directory to store user data.  Don’t be concerned if you don’t see a Group path for an application, but you also cannot ignore one if you see one.  Some applications store the juicy goodness here!

(Optional) Now that we know ‘cda’ is working, I’m going to use it once more, but this time to address a third party application - Google Voice.  You may not have Google Voice, but feel free to use ‘cda’ to search for a third party application if you have one!  I wanted to show this to you so you can see more than one example of ‘cda’ because it tells us exactly where we need to look to do our research!  In the photo below, you can see I typed cda google voice and pressed return and it displayed a bundle, data, and two different group paths to data for Google Voice.

2. Alright, we are moving on to a pointed example of using ‘cda’ to appropriately leverage ‘fsmon’ to GET SHIT DONE!  But, we first have to make sure ‘fsmon’ is going to work for us.  This binary is simple to use, we just have to start it and tell it which directory we want it to monitor.  One thing I have learned from using it is the less you monitor, the easier it is to see what’s going on.  Before I tell you how to start it I’m going to tell you how to STOP IT!  You will press control+C to stop it after it’s started.  

3. To make sure it’s working, type fsmon / and press return.  This is running the file system monitor on the root of the file system.  (**If you get an error, you might have to type /usr/bin/fsmon / to get it to work.)  As soon as you press return to start ‘fsmon’ just open any app on your phone such as Settings, Mail, whatever it doesn’t really matter.  You should see your screen light up with file system creation, modification, and deletion entries.  Your output is definitely going to look different than mine, that’s expected.  Press control+C and stop it.  Hopefully that worked nicely for you like it did for me, and you can now start to play with it and develop strategies for using it.

Now I’m going to walk you through one approach to using these binaries to target specific data, and then we are going to extract that data from our iPhone out to our Desktop.  

1. I am choosing to install the application, Viber Messenger: Chats & Calls, and I will use ‘cda’ to tell me where it stores data, then use ‘fsmon’ to try to see the results of a specific action.  I navigated to the App Store on my iPhone and searched for Viber, then pressed GET to install it onto my device.  (If you’re wondering, yes, you could technically be running ‘fsmon’ while doing all of this to see what’s happening on the file system!)

Alright, I have Viber installed.  But…before I open it I want to get setup to see what it’s doing.

2. In your shell into your iPhone, type cda viber and press return.  I see that Viber returns a path to its Bundle, as everything will.  It has a Data path, as everything will, but also has one Group path that I need to pay attention to.

Now that I know where Viber might store user data, I am going to monitor the Data path only.

3. For my installation of Viber, the Data path is /private/var/mobile/Containers/Data/Application/FAE649F5-56EB-4859-A4FB-BD88616720DE.  To monitor that path while I setup the application, type fsmon /private/var/mobile/Containers/Data/Application/FAE649F5-56EB-4859-A4FB-BD88616720DE and press return.  Once it is up and running, open the app and set it up.   As you can see in the image below, the file system goes crazy while I start to setup the application, but I’m seeing everything happening.

**If you wanted or needed to monitor the Group path too, you could simply open a new Terminal tab, and open another shell into your iPhone (ssh root@127.0.0.1 -p 4242, return, enter password, return) and run ‘fsmon’ on that Group directory too.**

Ok, you setup the app, and did whatever actions you wanted and you watched it all printing to your screen thanks to ‘fsmon’ doing an amazing job.  I hope you can see how this can assist you in doing research, and quickly honing in on pertinent files and folders as you work.  You make a specific action, and quickly go look at that file and find what you’re looking for.  Make sense?  Easy right?  Let’s target the Viber data and extract it out to our Desktop so we can quickly investigate it!

From the output for ‘cda viber’ I need to get the contents of the Data and the Group paths.  I’m not going to get the Bundle path…ever.  But for the example I’m about to show you below, your paths are going to differ from mine.  If you installed Viber to follow along, your path is not the same as mine, so you will have to copy your Data and Group paths and follow the template I’m giving you to achieve the same outcome.

4. Go back into Terminal but click over to the shell of your Mac, not the iPhone tab.  We are going to use ’tar’ via SSH to make a .tar of the Data and Group directories for Viber on our Desktop.  

In the Mac Terminal shell, type ssh root@127.0.0.1 -p 4242 ‘tar -cvf - <paste_path_to_Data> <paste_path_to_Group>’ > ~/Desktop/Viber1.tar and press returnEnter the password for SSH access to your iPhone (alpine or what you changed it to)  and press return.  You should see a long list of files populate on your screen and you should have a new file on your Desktop named Viber1.tar.

**We preserved timestamps for the data with this .tar command, so if you care about timestamp integrity make sure manage the data you extracted as READ ONLY to not update the timestamps each time you open a file.**

I pasted the exact text I typed into my Terminal window to successfully copy this data out to my Desktop below (to clarify any spaces or issues with the command above):  

bizzybarney@MacBook-Pro ~ % ssh root@127.0.0.1 -p 4242 'tar -cvf - /private/var/mobile/Containers/Data/Application/FAE649F5-56EB-4859-A4FB-BD88616720DE /private/var/mobile/Containers/Shared/AppGroup/1195ECFB-4F5B-4BC0-9E7F-490418D1651C' > ~/Desktop/Viber1.tar

You now have all of the files and folders attributed to Viber’s Data and Group paths on your Desktop.  Crack that thing open and dig in!  You have successfully extracted these files without using any commercial tools to extract a bunch of other data you don’t need or care about, and can start into examining your results in seconds without need to wait for any lengthy parsing process either!  You can easily go back into Viber and take more actions that create new data, then pull these files again and just change the output filename to Viber2.tar or whatever you choose.  If you are doing a full teardown of an application, don’t be surprised if you have pulled the data dozens of times, each time learning a bit more about how the data is being stored.

In the image below, you can see the Data and Group (../Shared/AppGroup/) files and folders for Viber, and I can quickly open the Preferences - com.viber.plist and see the user phone number I entered during setup!

Feel free to practice with the steps outlined above on different applications, and target their specific data.  Also, don’t forget about the native iOS files in /private/var/mobile/Library/ on your iPhone - we can monitor those directories as well and there is an insane amount of awesomeness there!

If you followed all of these steps and arrived here successfully, congratulations!! I know this setup is taxing, and especially difficult if you’re just starting out in CLI.  I hope I can offer encouragement by saying it wasn’t so long ago that I was doing this for the first time.  After lots of practice, failures, and cussing - I am now able to find the data I want to research using ‘cda’, watch the file system with ‘fsmon’, then ‘tar’ out the data I want in just minutes.  

Thanks again to @iamevltwin for hosting this content! Also a huge thanks to the people developing and supporting unc0ver, checkra1n, cda, and fsmon - you make this type of research possible!

Please contact me on Twitter @bizzybarney with any questions or concerns, and I will help as I have time.

Until next time, “Stay classy, forensicators.”

giphy-2.gif

Part 1: Step-by-step macOS Setup for iOS Research (via @bizzybarney)

CLI…WTF

Command line interface (CLI) isn’t for everyone.  Trust me; I get it.  @iamevltwin forced me out of my comfort zone a few years ago and opened my eyes to the power of Terminal (command prompt on Mac).  Now it is pinned to the Dock on every Mac I use, but I still struggle at times and that is okay!  The internet provides plenty of support to help me along when I just can’t make something work.  I use and abuse my Notes application with random commands and ways to accomplish certain tasks in Terminal that I know I will want to recall sometime in the future.  Inevitably though, I find my way back to mac4n6.com to read an article because I am cussing at an iPhone I’m struggling to jailbreak because I forget if the port is 22 or 44.  

I recently bought a new MacBook Pro and the thing is a beast, but as soon as Apple setup was completed I started installing things to set it up for mobile testing.  I figured I would write a set of current instructions on how I setup my Mac, and do so in a way that someone unfamiliar with Terminal can follow along without issues.

DISCLAIMER.  Following these instructions worked for me and will work for you too.  As with anything else, proceed at your own risk but nothing we are doing here is dangerous for your machine if done correctly.  I tried to bold exactly the text you need to type or to highlight a key combination you need to press to grab your eye as you scan this article.

1. Terminal (CLI)

What:

We are going to use it but you don’t have to understand everything we are doing to still achieve the desired outcome.  To find Terminal, hold ‘command+space bar’ and Spotlight Search will appear on your Mac’s screen.  Type ‘terminal’ and select the application from the results.  I choose to pin it in my dock because I use it every day, you might want to do the same.

How: 

  1. Hold command key and press space bar

  2. In Spotlight search type ‘terminal’ 

  3. Select Terminal application and it will open

  4. Right click Terminal in your Dock, mouse up to Options and over to ‘Keep in Dock’ and select it.

2. Xcode

What:

Xcode is Apple’s development platform, and pieces of it are used in regular forensics work on iOS and Mac data.  This takes a while depending on your download speeds, so this might be a good place to grab a drink.  

How: 

  1. Open the App Store on your Mac and search for Xcode.  Download.

3. Homebrew

What:

I am a huge fan of craft beer, so perhaps I appreciate the naming convention here more than others.  Regardless of whether you like craft beer or are yet to learn that you love craft beer 🍻 - you need to install Homebrew to install some stuff Apple doesn’t install for you. 

How: 

  1. In a web browser, go to brew.sh  (DO NOT GO TO homebrew.sh, that is a super sketchy place and is not where you want to be)

  2. When the page opens, look directly under “Install Homebrew”, and copy the entire line: /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

Paste that into a Terminal window and press ‘return’ key.  (If you are asked for a password, it is the user password you enter to access the machine so you need to be an admin!  Also when you type your password nothing shows up on the screen, you aren’t crazy.) 

It tells you what the script will install, and you need to press ‘return’ again to install which will take a few minutes.

4. DB Browser for SQLite

What: 

My preferred SQLite database browser for everyday database research and analysis.  As with Terminal, I keep this one in the Dock of my Mac also

How: 

  1. Simply go to sqlitebrowser.org/dl/ and download and install the appropriate version. 

OR

Homebrew Install Method: You will notice on the download page that Homebrew is listed there with a command to install the application via Homebrew.  Since we already installed Homebrew, you can take a look at how it works by using it to install DB Browser for SQLite!

If you choose to install via Homebrew:

  1. In Terminal, type the following and press ‘return’ - brew cask install db-browser-for-sqlite

5. Hex Fiend

What:

Free hex viewer, and I love it.  I drag and drop files into the application to quickly check file contents every day I’m doing research.  This one also stays in the Dock.

How

  1. Simply go to ridiculousfish.com/hexfiend and download and install.  

OR…I wonder if Homebrew can do this for me?

Homebrew Install Method: 

To check if homebrew has the ability to install a certain utility, you can just type brew search hexfiend and press return

The results tell me there is a Cask named ‘hex-fiend’ so I can install via Homebrew just like we did before.

  1. In Terminal, type the following and press ‘return’ - brew cask install hex-fiend

6. libimobiledevice

What:

We will use the “iproxy” utility, which enables TCP service access to an iDevice.  It allows us to forward ‘localhost’ to the device, thus allowing an SSH connection over USB to jailbroken devices.  If you don’t know what TCP, SSH or ‘localhost’ means - don’t quit here.  Once this is setup and your iDevice is jailbroken, you simply need to type a few things in Terminal and boom!  You’re surfing the file system of a live iDevice!

How:

  1. In Terminal, type brew search libimobiledevice

  2. The results show us ‘libimobiledevice’ is available, so type brew install libimobiledevice and press return

And with that the Mac setup is now complete!  We arranged applications in the Dock for quick access, got Xcode ready to go, setup a SQLite database browser, a hex viewer, and finally the utility we will use to communicate with our iDevice via USB.  But wait..what about my favorite <insert tool name here>?  Personal preference will drive many other installs or setup tweaks, but if you follow these instructions your Mac is ready to do iDevice testing.  

If you successfully followed the instructions above, your iOS testing progress bar is at 51% - congratulations!  Part 2 is coming soon and will visualize and simplify the jailbreak process, getting your iDevice ready for testing.  You will be setup and ready to answer your own questions about the iOS file system, how it behaves, and you can prove or disprove that hunch you have!  

Until next time, “Stay classy, forensicators.”

Apple Pattern of Life Lazy Output’er (APOLLO) Updates & 40 New Modules (Location, Chat, Calls, Apple Pay Transactions, Wallet Passes, Safari & Health Workouts)

I started filling in the gaps to missing APOLLO modules. While doing this I realized there was some capability that was missing with the current script that had to be updated. As far as script updates go the following was done:

  • Support for multiple database name -Depending on the iOS version being used the database names may be different but the SQL query itself is the same. Instead of creating many redundant modules I now have it looking for the different database filenames.

  • Support for multiple queries on different iOS versions- You will now notice that all the modules have been updated with iOS version indicators and multiple SQL queries compatible for that version. Some going back as far as iOS 8! I put in as much legacy support as I had data for. I will likely not add much more unless it is by special request. I can’t imagine there is a whole lot of iOS 8 analysis going on out there, but you never know! I have kept it to major iOS release numbers and have tested with the data I have but it may have changed with a minor point release, if you find this to be true please feel free to let me know!

  • Module Timestamp Rearrangement and Module Cleanup– I’ve started to go through some of the modules and move the items around to make it easier to see what is going on with each record. I’ve mostly just moved the timestamps toward the end since most of them are shown in the Key column. I’ve also removed some superfluous columns and extraneous junk in the queries. I’m really only trying to extract the most relevant data. 

A few notes on script usage change. The script flags have changed, with the added arguments of -p = platform (iOS support only for now), and -v = iOS Version. You may also notice the new ‘yolo’ option – this one will likely be error prone if you are not careful. Use this when you what to run it on any database from any platform. It can also be used with your own custom modules if you don’t have versioning in them.

An example of the module changes is below. Notice the multiple databases listed. In this example, the same location data can be extracted from the cache_encryptedB.db or the cache_encrypted A.db databases depending on the iOS versions. The version information is listed in the “VERSIONS” key, while the specific queries have versions listed in the [SQL Query …] brackets, this is the version that the apollo.py script is following.

The big updates were with the modules, lots of new support! I now have support for 129 different pattern-of-life items! Most of the support is for iOS, however if you run the queries themselves on similar macOS databases you will find that many of them will work. Better macOS support is coming, I promise.

Application Specific Usage:

  • Chat – SMS, iMessage, & FaceTime messages extracted from the sms.db database.

    • sms_chat

  • Call History – Extracted from CallHistory.storedata database.

    • call_history

  • Safari Browsing – Extracted from the History.db database.

    • safari_history

  • Apple Pay/Wallet - Extracted from iOS passes23.sqlite database.

    • Apple Pay Transactions - passes23_wallet_transactions

    • Wallet Passes - passes23_wallet_passes

 Location :

  • locationd - The following modules extract location data from the [lock]cache_encryptedA.db & cache_encryptedB.db databases. This will include various cellular and Wi-Fi based location tables as listed in the module filename.

    • locationd_cacheencryptedAB_appharvest

    • locationd_cacheencryptedAB_cdmacelllocation

    • locationd_cacheencryptedAB_celllocation

    • locationd_cacheencryptedAB_celllocationharvest

    • locationd_cacheencryptedAB_celllocationlocal

    • locationd_cacheencryptedAB_cmdacelllocationharvest

    • locationd_cacheencryptedAB_indoorlocationharvest

    • locationd_cacheencryptedAB_locationharvest

    • locationd_cacheencryptedAB_ltecelllocation

    • locationd_cacheencryptedAB_ltecelllocationharvest

    • locationd_cacheencryptedAB_ltecelllocationlocal

    • locationd_cacheencryptedAB_passharvest

    • locationd_cacheencryptedAB_poiharvestlocation

    • locationd_cacheencryptedAB_pressurelocationharvest

    • locationd_cacheencryptedAB_scdmacelllocation

    • locationd_cacheencryptedAB_wifilocation

    • locationd_cacheencryptedAB_wifilocationharvest

    • locationd_cacheencryptedAB_wtwlocationharvest

  • locationd – These modules extract motion data from the cache_encryptedC.db database. Not specific location data but will show device movement.

    • locationd_cacheencryptedC_motionstatehistory

    • locationd_cacheencryptedC_nataliehistory

    • locationd_cacheencryptedC_stepcounthistory

  • routined – Extracts location data from the cache_encryptedB.db database. If you have a keen eye you will notice the database name is the same as from ‘locationd’. Completely different database with different data stored in two different directories.

    • routined_cacheencryptedB_hint

    • routined_cacheencryptedB_location

Health Workouts – Using the healthdb_secure.sqlite database I’ve extracted much of the metadata from workouts. I’ve also determined some of the workout types (ie: HIIT, Rower, Run, Walk, etc), but have not enumerated all of them yet. Please let me know if you come across others – easier if you do this on your own data and can easily look it up. Same for weather conditions (Sunny, Rainy, etc.).

  • health_workout_elevation

  • health_workout_general

  • health_workout_humidity

  • health_workout_indoor

  • health_workout_location_latitude

  • health_workout_location_longitude

  • health_workout_temperature

  • health_workout_timeofday

  • health_workout_timezone

  • health_workout_weather

Network and Application Usage using netusage.sqlite & DataUsage.sqlite iOS Databases

Two iOS databases that I’ve always found interesting (and probably should test more) are netusage.sqlite and DataUsage.sqlite. These two databases contain very similar information – one is available in a backup (and file system dumps) the other only in file system dumps. These databases are excellent at tracking application and process network usage. 

These databases can provide answers to investigative questions such as:

  • What apps were being used?

  • What apps were used more than others?

  • Did the device communicate over cellular or wi-fi more often and when?

  • What apps were used that are no longer on the device?

These databases are located in the following locations depending on the type of acquisition available.

  • /private/var/networkd/netusage.sqlite

    • Available in File System dumps only.

  • Backup: /wireless/Library/Databases/

    • DataUsage.sqlite

    • DataUsage-watch.sqlite (yes, there is one just for the Apple Watch!)

  • File System: /private/var/wireless/Library/Databases/DataUsage.sqlite 

I’ve created modules for these databases in APOLLO, but you can also use the SQL queries in a standalone environment. I’m still working on how best to represent the timestamp keys and may alter the APOLLO code to accept multiple timestamp keys. This will help some other modules I’ve been working on as well so keep an eye out for that. I also need to work on acceptance of multiple database names, thanks to DataUsage-watch.sqlite.

The first set of modules are netusage_zprocess and datausage_zprocess. These two use the same SQL query as it is the same table, just different databases. These query extracts the process and/or the application bundle id. This query will show two timestamps:

  • TIMESTAMP – I believe this is the most recent timestamp for the process/application.

  • PROCESS FIRST TIMESTAMP – This appears to be the first usage of the process/application.

The first example comes from netusage.sqlite, the second from DataUsage.sqlite. It is notable to show that more information is available potentially from DataUsage.sqlite. Since this database is backed up it has the potential to have very historical data. These examples come from my iOS 11.1.2 dump. NetUsage goes back to November 4,2017 when I first setup iOS 11 on the device. The DataUsage database on the same device goes all the way back to 2013! This was from my iPhoneX which certainly did not exist in 2013. I restore backups onto new devices. I also get many more records from the DataUsage database.

netusage_zprocess

datausage_zprocess

The next set of queries are netusage_zliveproces and datausage_zliveprocess. These modules technically have a copy of the ZPROCESS data so they may be redundant if you are running APOLLO. Again, this is the same query for each database. DataUsage will again have many more entries. The added value from the ZPROCESS queries is the added network data information, Wi-Fi In/Out and WWAN In/Out. I will assume this value is stored in bytes until I can test further.

The major difference that I can tell between the two databases (apart from number of records), is that the DataUsage database does not record Wi-Fi network data. I know for sure I was on Wi-Fi at some point in the last six years! (It shows in NetUsage – remember it is the same device. Check out my Twitter data, its almost horrifying! 🤭)

netusage_zliveprocess

datausage_zliveprocess

Finally, we have an additional query only for the netusage.sqlite database, netusage_zliverouteperf. This query extracts lots of information, some of which I have no idea what it is. The first step into determining this is creating the query! In addition to some timestamps that appear to be stored on a per-hour basis we have the type of network traffic (Cellular or Wi-Fi), bytes and packings coming and going, connection information.

A second screenshot is required to show the rest of the extracted data. Some sort of cellular network identifier (any ideas?) or Wi-Fi (SSID/BSSID) are provided, with additional network-based information.

There is a lot of data going through these pipes!