scripts

iOS Location Mapping with APOLLO – Part 2: Cellular and Wi-Fi Data (locationd)

My previous article showed a new capability of APOLLO with KMZ location file support. It worked great…for routined data, but there was something missing. What about the cellular and Wi-Fi locations that are stored in databases? Well, turns out I need to test better. I fixed the locationd modules to have the activity as “Location” versus “LOCATION”. Case sensitivity is apparently thing in Python…my bad. 🤷🏻‍♀️😉

I should also mention with the fixes, my total location data points for a iOS 12.1.1 device jumped to ~57,000! I should note this is not inclusive of workout locations. Those are a bit different as they are stored as separate records, one for latitude and one for longitude. In the future I might attempt to pair these up for KMZ support.

The previous article showed the routined (user/device patterns) data, I have found these locations to be quite accurate. To be fair, I have not looked at all (40k+) of them specifically, only spot checked. When I visualized the locationd data, I saw some interesting outliers.

The first module I found particularly interesting is the output from the locationd_cacheencryptedAB_celllocation module. Most of the locationd output is kept for about a week. This particular week I traveled from DC to Portland via Chicago for DFRWS and then back to DC (again via Chicago). You will notice that there are some data point clusters around DC, Chicago and Portland as expected – but there are a few scattered data points in the Midwest. I do not remember for sure if my device was in Airplane Mode, but this may be an artifact of potentially being able to access cell towers during my flight. (The locationd_cacheencryptedAB_ltecelllocation module output showed a similar pattern.)

The next module, locationd_cacheencryptedAB_ltecelllocationlocal, shows my path home from fairly accurately. These locations tend to be kept for less time. I was going north on 95, past the DC Beltway (near Springfield, VA) and onto Glebe Road towards Arlington, VA. It may be hard to see in the screenshot but the airport to the right near the Potomac is DCA. Just north of that is the Pentagon and Arlington Cemetery.

Finally, we have the output from the locationd_cacheencryptedAB_wifilocation module. This one has a few more outliers that I have a hard time explaining. I was DC and Chicago in this screenshot but not in Buffalo (NY), Pennsylvania, or NYC.

These are good examples of not completely believing and relying on what you see in the data. I can only imagine forensics cases relying heavily on this data. While I have found routined data points to be far more accurate, locationd on the other hand does have its oddities. Perhaps it is something with how the data is populated or the coordinates being reported by cell towers and/or access points. This requires additional investigation. TL;DR – Don’t assume what you are looking at is the end all be all of the data – always investigate further and correlate with other information.

In other news, if anyone knows more about how this data is populated – I’d love to know. Drop me a note!

iOS Location Mapping with APOLLO - I Know Where You Were Today, Yesterday, Last Month, and Years Ago!

I added preliminary KMZ (zipped KML) support to APOLLO. If any APOLLO module’s SQL query has “Location” in its Activity field, it will extract the location coordinates in the column “Coordinates” as long as they are in Latitude, Longitude format (ie: 38, -77). These are more a less an upgrade/replacement from my previous iOS location scripts. (FYI: Those will not likely be updated further.)

You can find more details on the different modules and outputs here. The APOLLO output will also show counts of how many location data points were extracted from each module. An example from my own data contained 41,262 points! Due to the amount of data points and how applications like Google Earth might handle them I’ve decided to split them by module to be loaded separately. It’s not ideal, but my goal is not to crash Google Earth. (FWIW, I’m still working on other solutions, if you have experience in this area - drop me a line.) The most troublesome module (by a large magnitude) is routined_cache_zrtcllocationmo since it keeps track of extremely granular locations for about the last week. Mine had ~38,000 coordinates!

Let’s take a look at some examples! This data was collected on 07/18/2019 on iOS 12.1.1 to give you an idea on timeframe.

This one is from is from the routined_cloud_visit_inbound_start module. The earliest coordinate is from a few months prior from my trip to Amsterdam to teach FOR518 - Mac and iOS Forensic Analysis and Incident Response.

These are some of my “Significant Locations”, you can click on any coordinate and gather more detail. This is the same output that is captured in the APOLLO database or CSV file. 

The next example is from routined_local_learned_location_of_interest_entry. Here you can see some of my travels since 2017! These contain the “Learned Locations of Interest”. You will probably see a bit more historical location data. Looks like I need to visit the middle of the US more!

Last but not least is the massive amount of data points from the routined_cache_zrtcllocatiomo module. This will show nearly exact, granular location for about the last week before collection. Here is my trip to Portland, OR for DFRWS! Not many guesses as to how I got to downtown Portland from the airport is there! (This is the module that produces many, many datapoints. It took patience with Google Earth to even get this screenshot, this is your warning.)

I hope this adds a bit of visual context to some of the APOLLO output, let me know if you have different ideas on how to represent some of this data! Pictures can certainly tell a story where it might otherwise get lost in the noise.

New Presentation from MacDevOpsYVR 2019 - Launching APOLLO: Creating a Simple Tool for Advanced Forensic Analysis

I had the pleasure last week to attend MacDevOpsYVR in Vancouver, Canada. While I barely saw the city, I got to hang out with some awesome Mac Sys Admins and Dev Ops people. I’ve not been to a conference outside of Security/Forensics before so it was a delight to see the types of presentations and insight these fine folks had to offer.

The presentation includes how my APOLLO project has evolved over the last few months since it was introduced in November, 2018. I also go though some of my real life pattern-of-life examples from my iOS 12 device. We talked about everything including to my health, moving bodies (and chopping them up!), taking selfies, and how much I will spend for good food. Once the video is released I will be sure to upload a link to it, it will certainly provide more (humourous) context to the slides. [Edit 06/18/2019 - Video here!]

A unique addition to normal conference presentations was the use of a graphic recorder (Ashton of Mind’s Eye Creative) to provide additional context to the presentations. She records in real time key points of each presentation and does an absolutely fantastic job at it. This allows for additional context for discussions after the presentation with fellow attendees. Example of my talk is below:

As always, my presentations are always available on my Resources page.

Direct Link to the presentation is here!

iOS 12 APOLLO Updates

Many modules were updated to specially support iOS 12 including those below. Many were already available on iOS 12 (Powerlog, Passes, SMS, etc) without a jailbreak. As always, let me know if I missed something! Remember the ‘yolo’ option can always be used to attempt to get those entries if official support in the module has not been added.

  • Routined - Looks like Apple changed the database schema to change/remove much of the location reverse geolocation protobuf BLOBs that were in the Cache.sqlite, Local.sqlite, Cloud.sqlite databases. Queries have been updated to account for this.

Still working on a few other queries like Screen Time as well as a few more programatic updates.

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