What Apple Maps Activity Can be Found Using a Logical Extraction

Saturday, May 7th, 2022

In the Digital Forensics community, logical acquisitions of data are considered to be the least useful of the three acquisition types when used on its own. As the data is interpreted by the operating system and limited by permissions, logical acquisitions gather less data, and that data that is gathered is of lower quality than its more intensive counterparts. However, suppose a logical acquisition is all one has access to? And suppose you wish to uncover location data regarding a user’s whereabouts at a specific time, when that user regularly keeps most location tracing functions on their device deactivated?

            This was the question I wished to answer- “How much geolocation data can I try to pull off this device, limiting myself under these conditions?”

The Short of It-

In short, the answer was “not as much as I had hoped”. While specific processes such as geod/com.apple.Maps, trustd/com.apple.Maps, mDNSResponder/com.apple.Maps, and Maps/com.apple.Maps were did appear at the times Apple Maps was being used, they were not foolproof indicators of its activity. Nor did any of these processes contain geolocation data being used by Apple. Additionally, it is unclear what specifically triggers these processes. The mDNSResponder requests may have had nothing to do with the standard operating procedure of Apple Maps, but were instead the groggy flailings of Apple Maps upon being awakened from Airplane Mode, while geod was the application stumbling around in the dark until banging its shin on the coffee table it definitely should have known was there.
Deactivating specific location features to try and hide ones presence does not slow down Apple Maps in any way. So long as Apple Maps itself has location data enabled, it can find the phone’s position, even if all System Services are disabled. However, this data is not recorded/reflected in a logical acquisition of the iPhone.

The Long of It-


The phone used in this experiment was my own personal device, and data pertaining to my own personal life has been sanitized for the sake of the project. The Phone is an iPhone 12, Model A2172. The Operating System is iOS 15.2.1. The tools used to analyze the data from this device were Magnet ACQUIRE v for the acquisition, and Magnet AXIOM v for the analysis.

Testing Scenarios-

Data was collected in 4 separate phases, at 4 different locations, across 4 different days. These phases were separated by which separate pieces of System Services Location Data were enabled. These Location Data options were altered by going to Settings –> Privacy –> Location Services –> System Services. I wanted to measure what effect toggling these off and on had on what type of data I could gather. On a default iPhone, all these options are on, but as I prefer to leave on only the options I find most necessary, the only Location options available operating on my phone are Cell Network Search, Networking & Wireless, Compass Calibration, Motion Calibration & Distance, and Routing & Traffic.

System Services Location Options
  • For Phase 1, all options were toggled on to receive Location Data.
  • For Phase 2, only Compass Calibration and Motion Calibration & Distance were toggled on.
  • For Phase 3, only Cell Network Search and Networking & Wireless were toggled on.
  • For Phase 4, only Routing & Traffic were toggled on.

            While traveling to each new location, the iPhone was put into Airplane Mode, with the exception of Phase 3, and was deactivated at the start of the data capture time frame. The Apple Maps Application was the tool used to collect that data. Apple Maps was opened for 1 minute, and then closed for one minute. During that closed minute, the Cellular Data, Bluetooth Data, and WiFi Data options were turned on or off to see if any change in data collection would occur. This cycle was repeated for every combination for these three options.  


Testing involved looking at the logical acquisition taken after the last data collection time. AXIOM’s Timeline Analysis window was used to examine the Apple Map Searches and Application Data between the day of the first capture, March 29th, 2022 and the day of the last capture, April 2nd, 2022. For each of the four captures, we can see Apple Maps activity at the very start of the capture, as Apple Maps is opened for the first time. It is important to note that active locations were not searched, nor were any directions plotted during any of these testing phases (at least not deliberately). The app was merely opened.

Phase 1- All On

Phase 1 generated application data on par with Phases 2 and 4, and it seems in each case the deactivation of airplane mode triggered a great deal of background process traffic. Processes like mDNSResponder, geod, trustd, and Maps all booted up within minutes of Airplane Mode deactivation.

  • mDNSResponder is a core part of Apple’s Bonjour Protocol, which is a networking service that allows other Apple Devices to find one another. This process is noted to exist in Phases 1, 2, and 4.
  • geod is a process connected to Location Services whose purpose is somewhat unknown. Given that the naming pattern seen in other processes such as location and trustd, referring to what the background process (or daemon) does, then followed by a “d” standing for that daemon, I think it safe to assume that “geod” refers to some form of daemon in charge of handling geolocation data. What information I could find about it online supported this theory, showing that the geod process, sometimes referred to as com.apple.geod, is a resource intensive, persistent process related to Apple’s Core Location services. It is used in the Weather App, Calendar, Safari Location, and essentially any other time that Location Services are required. This means it is not necessarily tied to Apple Maps, and can be identified with other artifacts. For example, as well as being noted as geod/com.apple.Maps, there are several references to geod/com.apple.datausage.maps. This process is found in Phase 1, 2, and 4.
  • trustd is a background daemon that checks and manages digital certificates as the phone connects to the internet. In Phases 1, 2, and 4, the usage of trustd is at the same time as the usage of geod, implying a relationship between the two.

Maps/com.apple.Maps is the process primarily responsible for running Apple Maps, as near as I can tell. It appears in Phases 1, 2, and 4, but it does not necessarily appear in every case where Apple Maps is being used.

Phase 1: All On
Phase 1: Corresponding AXIOM Data
Phase 2- Only Compass Calibration and Motion Calibration On

The standout here in Phase 2 is the process locationd. configd and mobileassetd are also accessed here, but do not have relevance in terms of location data.

  • locationd is part of the location services daemon that indicates the geographical location of your iPhone for location specific services. This service appears only once, in Phase 2. It is possible this service is connected to Compass Calibration and Motion Calibration, and their absence in Phases 3-4 are why it does not appear again, though that would not explain its absence in Phase 1. It could instead be that locationd, rather than being connected to pure geolocation data, is instead focused on the Compass and Motion Calibration options, providing the phone data on how to orient itself.
  • configd is a background daemon responsible for many configuration aspects of the local system, and maintains data reflecting the current state of the system. It also provides notifications to applications when this data changes, and hosts configuration agents in the form of loadable bundles. It has no relevance to location data, but appears in Phase 2 and 4, likely in response to Airplane Mode coming offline.
  • mobileassetd is another background daemon, involved with the Apple Network Usage Application. It is in charge of managing and downloading assets when other apps ask for them. It is accessed by com.apple.datausage.
Phase 2: Compass Calibration and Motion Calibration On
Phase 2: Corresponding AXIOM Data
Phase 3- Only Cell Network Search and Networking & Wireless On

Phase 3 is an outlier in many regards, with good reason. For one, Phase 3’s data collection took place at a location I required directions to, and thus used the Apple Maps Application to acquire directions to. These directions were not merely opening the Apple Maps Application, as with other Phases, but were plotted courses that I followed to arrive at Location 3. As such, I discovered in my analysis that not only had this data been extracted by AXIOM, it provided active GPS coordinates of my destination. While every time I opened the app it was true that Apple Maps was homing in on my location, this is the only place in the Logical Acquisition that my active GPS coordinates are enshrined into artifacts I can find. Another discrepancy between Phase 3 and its counterparts is that I did not turn on Airplane Mode prior to beginning my capture. While I did deactivate the Apple Maps Directions and close down the application, I neglected in this Phase to activate Airplane mode for the few minutes it took to drive through the parking lot to reach my designated testing area. As such, I inadvertently provided a testing metric I did not mean to: “What Application Data is generated by opening Apple Maps after blinding it with Airplane Mode, vs opening it without?”

As it turns out, a great deal of that data, otherwise noted in Phase 1, 2, and 4, is likely generated on account of the phone reconnecting to the internet. The only traffic that indicated the phone was in use at the Phase 3 recorded times was my accidental opening of the camera, which then accessed com.apple.camera. As none of the other indicators I had connected with Apple Maps were found, I can only assume that data is not connected to Apple Maps being opened, but instead is connected to the sudden deactivation of Airplane Mode, followed by the activation of Apple Maps.

Another discrepancy between Phase 3 and its counterparts is that the one Process I expected to be there in every data collection segment, a reference to Maps/com.apple.Maps, was not in fact present. To the contrary, Maps/com.apple.Maps was not referenced the entire day, despite Apple Maps not only being opened, but even being used on occasions. This goes contrary to my expectations of Maps/com.apple.Maps being the most reliable indicator of Apple Maps activity. Indeed, when making a survey of all Apple Maps activity, of 5/8 periods of identified use of Apple Maps activity did not use Maps/com.apple.Maps. More disconcerting is that the very usage of com.apple.Maps does not seem to be guaranteed when using Apple Maps. As can be seen in the Phase 3 data, com.apple.Maps itself is not accessed. I found this, shall we say, counterintuitive. I do not have a concrete explanation for this, but suspect the disparity may be due the limitations of a Logical Acquisition.

The last discrepancy is due to the previous usage of Apple Maps seeking directions. At 3/31/2022 12:54:01 PM EST, the file AppDomainGroup-group.com.apple.Maps\Maps\MapsSync_0.0.1 was Accessed. This file stores the last 25 recorded Apple Maps searches. It is clear why this file was not opened in any of the other data collection times. What is less clear is why this file was only seen being Accessed nearly an hour after it should have been last modified. Indeed, examining the file itself shows that the two searches at 12:20:00 PM EST and 12:26:12 PM EST on 3/31/2022 were recorded in the MapsSync_0.0.1 file. And yet, there is no reference to the modification of this file, at this time or any, in the recorded Timeline.

Phase 3: Cell Network Search and Networking & Wireless On
Phase 3: Corresponding AXIOM Data
Phase 3: Active GPS Coordinates
Phase 4- Routing and Traffic On

This was the Phase that I expected to have the most artifacts found, with the exception of Phase 1, due to Routing and Traffic’s close connection to Apple Maps. What I found was that its artifacts more or less mirrored Phase 1’s artifacts. configd, geod, trustd, mDNSResponder, and Maps processes all made an appearance. Some miscellaneous items found their way into the capture as well (ignore the Spotify artifacts), but this traffic was most similar to Phase 1, while sharing most of the important features found in Phase 2.

Phase 4: Routing and Traffic On
Phase 4: Corresponding AXIOM Data

What I could not determine is a far longer list than that which I could. For example, the processes that were run by the system did not seem affected by enabling or disabling Cellular Data, WiFi, or Bluetooth. While testing the conditions of turning on or off again said services, the only difference I noted was that it seemed to take Apple Maps slightly longer to focus in on where I was, though it always did so within a few seconds. Even turning all of these off did not affect the outcome. I could not determine whether or not the existence of some artifacts was dependent on what Location Services were enabled, though it would seem that locationd requires the Compass or Motion Calibration options to be active before it can make an appearance. That said, even deactivated, Apple Maps did not seem to have an issue calculating which direction North was.

While my decision to enable Airplane Mode before attempting each capture may have been well meaning, it also blurred the line between what is standard traffic and what is the system reconnecting to the outside world. Phase 3 further jumbles the mix in that Airplane Mode was not enabled for it, and it lacks the majority of the indicator artifacts that were found in the other Phases.

What I did learn is that Logical Acquisitions of this sort cannot identify any locations merely opening the Apple Maps application. The iPhone may collect location information if the user actively seeks out directions to a target and selects “Go” on the directions. However, the phone will not record the GPS location of the user, but instead the location of the destination. These locations are then stored in AppDomainGroup-group.com.apple.Maps\Maps\MapsSync_0.0.1, and are reliably parsed by AXIOM. Even if a user were to plot directions to a point and click “Go”, there is no evidence the user actually followed those directions. In the case of Apple Maps Search Item 7013, those directions were not followed, but were still logged in MapsSync_0.0.1.

I also learned that while not foolproof, certain processes may indicate the usage of Apple Maps, those processes being geod/com.apple.Maps, trustd/com.apple.Maps, mDNSResponder/com.apple.Maps, and Maps/com.apple.Maps. However, whether these daemons are always running when Apple Maps opens, or merely begin running when Apple Maps is started out of Airplane Mode is unknown. In short, I found no user location data connected to Apple Maps that can concretely be determined with a solely logical acquisition of an iPhone 12, iOS 15.2.1.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create your website with WordPress.com
Get started
%d bloggers like this: