iOS Location Services and System Services ON or OFF?

Awhile back, I, started working on some research whether the device speed recorded in an iPhone database could be considered reliable evidence for how fast a device was traveling. I was going to discuss some device settings in the blog, but quickly learned the Location Services and System Services settings should be discussed in a bit more detail and decided to write a separate blog about what I found.

After completing some of the research, I asked Ian Whiffin to review what I have found and asked him to add anything I might have missed. Ian, being the iOS location guru, was happy to assist and was willing to co-author this blog with me. Thanks for everything Ian!!

In this blog we will be discussing how to determine if specific application Location Services is ON or OFF and if System Services were turned ON or OFF when the data was acquired. System Services includes the data needed to determine if Significant Locations was ON or OFF at the time of acquisition.

Forensic Question:

After an iPhone data acquisition, can we determine if Location Services was ON or OFF and which System Services were ON or OFF? 

Note: There has been previous research published about these settings, but it appears, based on what we have found, the research is a few years old. Here is a link to a SANS presentation by Sarah Edwards discussing her research for some of these settings:

Test Devices:

• Apple iPhone 6s Plus [A1687] – No Sim Card and no Mobile data
• Apple iPhone 7 [A1778] – No SIM card and no mobile data
• Apple iPhone 7 [A1660] – No SIM card and no mobile data
• Apple iPhone X [A1865] – Has SIM card and mobile data
• Apple iPhone Xs [A1920] – Has SIM card and mobile data
• Apple iPhone 13 Pro [A2483] – Has SIM and mobile data

OS Versions:

• iOS: 11.1.2 (15B202)
• iOS: 14.4.2 (18D70)
• iOS: 14.6 (18F72)
• iOS: 14.7 (18G69)
• iOS: 14.7.1 (18G82)
• iOS: 15.0 (19A346)
• iOS: 15.1 (19B74)
• iOS: 15.3.1 (19D52)

Tools:

• Cellebrite UFED 4PC 7.47.0.247
• Grayshift GrayKey 1.6.16
• Cellebrite Physical Analyzer 7.47.0.58, 7.48.0.49 & 7.48.1.3
• Magnet AXIOM 5.4.0.26185
• ArtEx 1.6.0.0, 2.0.0.4, and 2.2.4.0
• Mushy 2.2.1.0

Artifact Location:

• \private\var\mobile\Library\Preferences\com.apple.locationd.plist
• \private\var\root\Library\Caches\locationd\clients.plist

Extraction Methods that contained both com.apple.locationd.plist and clients.plist:

• Both Full File System and Backup (advance logical) acquisitions contained the plists needed to analyze if Location Services and System Services were ON or OFF.  

Settings > Privacy:

To check if Location Services is ON or OFF, navigate to Settings > Privacy. In Figure 1 Location Services is ON.

After the device data is acquired, how can we determine if Location Services was ON or OFF? The plist of interest is com.apple.locationd.plist.

The plist is located at: \private\var\mobile\Library\Preferences\

Once you have located the plist, you will want to analyze the LocationServicesEnabledIn8.0 key which will have a True or False value.

• True value means Location Services is turned ON
• False value means Location Services is turned OFF

Note: On 5/15/2022, during testing and research as seen in Figure #2.2, I analyzed a FFS acquisition of an iPhone 7 with iOS 11.1.2. During that time, I determined iOS 11.1.2 used 1 or 0 value, in lieu of True / False values to indicate if Location Services was ON / OFF. Based on my testing the values indicate the following:

• 1 = Location Services is ON
• 0 = Location Services is OFF

You will also want to analyze the LastSystemVersion key. This key will list the last/current iOS version, in this case it was iPhone OS14.4.2/18D70.

In Figure 2, Location Services is ON. We can see the com.apple.locationd.plist, the keys previously mentioned and their values. Figure 2.1 is a look at the plist from iOS 15.0.

In Figure 3, Location Services is OFF. We can see the com.apple.locationd.plist, the keys previously mentioned and their values.

Update – 2023-4-23 – Settings > Privacy > Location Services > System Services > Status Bar Icon

Once you have located the com.apple.locationd.plist, you will want to analyze the StatusBarIconStates > SystemService key which will have a True or False value.

• True value means Status Bar Icon States is turned ON
• False value means Status Bar Icon States is turned OFF
• Figure #3.1 is a video of changes being made to the setting on an iPhone X with iOS 14.7
• Based on my testing and research the default setting OFF or set to False

Privacy > Location Services:

After determining Location Services was ON, we will review some of the applications using location services. Clicking on the Location Services button within the Privacy menu will bring us to a menu pictured in Figure 4. The applications listed are those using Location Services and a brief glimpse into the application settings. Notice in Figure 5, the applications pictured are all set to While Using the App. Let’s begin analyzing the Maps application. 

When we click on the Maps application, we are presented with a new set of Location Services settings, seen in Figure 5. The settings for Maps are set to Allow Location Access While Using the App and Precise Location is ON.

Note: Please read through the resources for additional details about the differences when Precise Location is ON or OFF. When it is OFF it is also known as Reduced Accuracy. Here is a link to an Apple Developer page that discusses Reduced Accuracy and plist values.

System Services and Significant Locations ON or OFF

We are going to review the plist that contains the Apple Maps Location Services settings to determine what was set when the device data was acquired. The plist of interest is the clients.plist. This plist is located at: \private\var\root\Library\Caches\locationd\.

The clients.plist contains the settings for applications and system services using location services. During this section, we will be focusing on the application settings for location services. In Figure 6, we have highlighted two applications, Apple Maps – com.apple.Maps and Apple Calendar – com.apple.mobilecal.

After reviewing the Apple Maps (com.apple.Maps) settings, seen in Figure 7, we can see the Maps application is set to Never Allow Location Access. Notice there is not an option to change between Precise Location or Reduced Accuracy.

Within the clients.plist, you will want to find the application or services you wish to analyze. During testing, ArtEx and Mushy were used to view the plist. To view the keys listed under the application, we have to click on the applications, in this instance that was com.apple.Maps. Depending on your plist viewing tool, you should expand the keys belonging to the application you are analyzing. The keys you will want to analyze are Authorization and CorrectiveCompensationEnabled, seen in Figure 8.

The Authorization key is the setting for Allow Location Access. During testing, two key values were encountered. There were also some instances where the Authorization key was missing or hidden:

• 1 = Never
• 2 = While Using the App
• When the Authorization key is missing/hidden = Ask Next Time

Note: The Weather application had two settings that appeared to be similar. The two settings were While Using the App and While Using the App or Widgets. Both settings had a value of 2 in the plist during testing.

The other key we want to analyze is the CorrectiveCompensationEnabled key, which is the setting for Precise Location. During testing, two key values were encountered:

• 1 = Precise Location is turned ON
• 2 = Precise Location is turned OFF or not set.

Note: A value of 2 indicates Reduced Accuracy

Note: During testing there were occasions when both the Authorization key and the CorrectiveCompensationEnabled key were missing/hidden. In some instances, this was because the setting was never changed from the default setting. After changes were made to the settings, the keys would then be listed in the plist. There might be other factors that would cause the keys to be missing/hidden, but those could not be determine during testing. An example of this displayed in Figure 10.

Test 1 Device Settings as seen in Figure 7 and 8:

• Never is selected
• Precise Location is missing/hidden

clients.plist keys:

• Authorization value 1
• CorrectiveCompensationEnabled value 2

Test 2 Device Settings as seen in Figure 9 and 10:

• Ask Next Time is selected
• Precise Location was OFF

clients.plist keys:

• Authorization was not listed
• CorrectiveCompensationEnabled value 2

Test 3 Device Settings as seen in Figure 11 and 12:

• Ask Next Time is selected
• Precise Location was ON

clients.plist keys:

• Authorization missing/hidden
• CorrectiveCompensationEnabled value 1

Test 4 Device Settings as seen in Figure 13 and 14:

• While Using the App selected
• Precise Location was ON

clients.plist keys:

• Authorization value 2
• CorrectiveCompensationEnabled value 1

Test 5 Device Settings:

At the end of testing, the Apple Maps Location Services settings were set as While Using the App and Precise Location was ON. In a final test, the setting was changed from While Using the App to Never. When the change was made the Precise Location toggle switch disappeared but was still in the ON position.

Based on previous testing, the Authorization value should have been 1 and the CorrectiveCompensationEnabled value should have been 2, but that was not the case. The Authorization value was 1, as expected, but the CorrectiveCompensationEnabled value was 1, indicating it was using Precise Location. Further testing was not completed to determine if the Precise Location was being used or not, just wanted to note this variation could appear in your data.  

Now that we have analyzed specific application Location Services, Let’s review what was discovered when testing the System Services settings.

Note: Please review, this link to an Apple support article that discusses some of the different location System Services. 

Location Services > System Services:

In Location Services > System Services there is a list of items, seen in Figure 15. Notice all the services are turned ON. After the iPhone data was acquired, we were able to determine if items listed under System Services were turned ON or OFF. To do this, we must again view the clients.plist Authorization key. During testing, two key values were encountered:

• 1 = OFF
• 4 = ON

In Figure 16, highlighted is the Routing & Traffic system services button. Based on testing, the Routing & Traffic system services button controls the following services in the clients.plist:

• com.apple.locationd.bundle-/System/Library/LocationBundles/Traffic.bundle
• com.apple.locationd.bundle-/System/Library/LocationBundles/AltimeterHarvest.bundle
• com.apple.locationd.bundle-/System/Library/LocationBundles/IonosphereHarvest.bundle
• com.apple.locationd.bundle-/System/Library/LocationBundles/TraceHarvest.bundle

In Figure 17, a screenshot of the clients.plist is opened in Mushy. Notice the com.apple.locationd.bundle-/System/Library/LocationBundles/Traffic.bundle service is expanded and has an Authorization key value of 4, meaning the setting is ON and a CorrectiveCompensationEnabled key value of 1, meaning Precise Location is ON.

When the Routing & Traffic setting is turned OFF, seen in Figure 18, the Authorization key in the clients.plist changed from a value of 4 (ON) to a value of 1 (OFF), see Figure 18 and Figure 19:

During testing, we were able to identify and match up most of the items listed under System Services to their counterpart listed in the clients.plist, as seen in Figure 20. Notice there are some ON/OFF switches that control multiple System Services.

Note: Some of the items listed in the clients.plist are not listed in System Services menu, they are however listed elsewhere in the general settings menu. Some examples of these settings might be the Do Not Disturb setting, Wi-Fi Calling setting and Exposure Notification setting, just to name a few.

Note: In iOS 14.8 Wi-Fi Calling was listed in the System Services menu.

Note: iOS 15.0 update – most of these services were also listed in iOS 15.0 clients.plist along with a few new ones.

After the bulk of this was written, Ian Whiffin, discovered several other key artifacts, namely in cases where location related applications are launched the first time, the user may be given the options of:

• Allow Once
• Allow while using
• Don’t allow

The options for Allow while using and Don’t allow were covered above. But the option of Allow Once wasn’t.

The clients.plist shows a TemporaryAuthorization which can be seen in key 5 below.

Crucially, when the application closes, this key is deleted altogether. This means that the user may have allowed locations temporarily, even though the plist file will not reflect this.

Furthermore, some applications also have an option to Always Allow which means it will and work even if the app isn’t in use. These applications are given the authorization 4, just like system services.

We put together a quick look-up table to help you if required

UPDATE 5/15/2022 Location Services > System Services > Significant Locations:

I would like to update you on something I discovered as the result of additional testing and research. Someone recently posted a comment / question to my iPhone Device Speeds via Cache.sqlite write-up: “I have case and relying on the ZSPEED. Is there a way to determine why the speed was recorded at the specific time/date? Reading your article, I understand the locations must be on, but can I determine what app pulled for that data?” It was a fantastic question and I realized did not cover this question in the write-up. I started by digging into previously published material listed in the reference section and couldn’t find the answer. So, I decided to do some additional testing and research. Here is what I discovered…

Scooters iPhone X iOS 14.7

I tested Scooters iPhone X with iOS 14.7, first. The device had both Location Services and Significant Locations were ON. Reminder, this device has a SIM card and has a data plan.

I reviewed the Cache.sqlite > ZRTCLLOCATIONMO table data and observed the last location recorded.

I then turned Significant Locations OFF, then used Apple Maps to get navigation / directions to a location 30 minutes away. The device plotted the route and appeared to be working as normal. I then captured a live photo and reviewed the asset which included the correct capture location.

I checked the Cache.sqlite > ZRTCLLOCATIONMO table and noticed there weren’t any new locations being stored in the table. I was a little shocked by this, as I expected to see some additional locations being recorded in this table due to the map’s application being used and the camera application recording the location of the live photo capture.

The next day, while Significant Locations was OFF, I again used Apple Maps and navigated to a location 30 minutes away. Everything appeared to function properly. I used some third-party applications to create social media posts, which included location tagging. Additionally, I captured a few assets with the native camera. All appeared to be functioning properly and adding location data to the assets as expected.

A short time later, I got back in front of a computer and began reviewing the Cache.sqlite > ZRTCLLOCATIONMO table location data…

I was again shocked to learn there weren’t any new locations recorded in the table. The last location recorded was shortly before Significant Locations was turned OFF.

Note: When analyzing the database both the WAL and the free pages were reviewed to ensure I wasn’t missing anything. 

I immediately considered there had to be correlation between Significant Locations and the data being stored in Cache.sqlite > ZRTCLLOCATIONMO table.

I turned Significant Locations ON and used Apple Maps to get directions to another location and took a few live photos with the native camera.

When I reviewed Cache.sqlite > ZRTCLLOCATIONMO table several new locations were listed in the table. This confirmed my suspicion that the data stored in ZRTCLLOCATIONMO is related to Significant Locations.

I messaged the location guru himself, Ian Whiffin, and notified him of my test results. Based on his testing, he agreed there is a direct correlation between the Significant Locations ON / OFF switch and the data being stored in Cache.sqlite > ZRTCLLOCATIONMO table.

I performed some additional testing on a device with iOS 15.

Dexter’s iPhone 7 with iOS 15.1

In Figure #24, I used Dexter’s iPhone 7 and performed the same test.

On 5/10/2022 at approximately 4:53:17 PM, I checked the device settings and both Location Services and Significant Locations were ON. I connected Dexter’s iPhone 7 to Scooters iPhone X to share data.

At 4:53:38 PM and 4:53:54 PM, locations were recorded in the Cache.sqlite > ZRTCLLOCATIONMO table, which were accurate for where the device was located. I created a few screenshots to document the device settings and the time.

At 4:58:01 PM, I started a new trip and during that time, while Significant Locations was ON, the device was constantly logging locations in the Cache.sqlite > ZRTCLLOCATIONMO table. See Figure #24 for a video of the locations.

At 5:18:17 PM, I pulled into a parking lot and captured a few photos to document my location. I’m a little late, but may the 4^th be with you!

At 5:21:08 PM, Cache.sqlite > ZRTCLLOCATIONMO table recorded its last location prior to Significant Locations being turned OFF.

At 5:21:16 PM, Significant Locations was turned OFF.

Note: When turning off Significant Locations, not only does it stop recording locations in ZRTCLLOCATIONMO, but it also automatically stops the collection of location points being used to create entries in the ZRTVISITMO table. This is discussed in more detail later, but the clients.plist is recording this via FenceTimeStarted and FenceTimeStopped keys/nodes.

At 5:22:09 PM, a live photo was captured, and it contained location information. Location Services was still turned OFF.

After Significant Locations was turned OFF, new locations were not populated in the Cache.sqlite > ZRTCLLOCATIONMO table.

While scrolling through the device data, you will notice after Significant Locations was turned OFF, we are no longer seeing any cache location data being parsed from Cache.sqlite > ZRTCLLOCATIONMO table.

Significant Locations on Dexter’s iPhone 7 (iOS 15.1) is turned back ON

In Figure #25, on 5/11/2022, at 8:58 PM, Significant Locations was turned back ON and locations started to populate in the Cache.sqlite > ZRTCLLOCATIONMO table on Dexter’s iPhone 7 (iOS 15.1).

A Full File System acquisition was used to acquire the data from Dexter’s iPhone 7 (iOS 15.1) and reviewed via ArtEx.

We again can see, in ArtEx timeline, the last cache location recorded in the ZRTCLLOCATIONMO table was on 5/10/2022 at 5:21:08 PM.

On 5/11/2022 at 5:58:33 PM, the settings were accessed on Dexter’s iPhone 7 (iOS 15.1) and Significant Locations was turned back ON.

We can see on 5/11/2022 at 9:07:20 PM, cached locations, also known as Cache.sqlite > ZRTCLLOCATIONMO table locations, have begun populating on the device again.

In Figure #25, this example is shown again, but this time analyzing the location data stored in Cache.sqlite > ZRTCLLOCATIONMO table. As stated previously, we can observe a gap within the recorded locations between 5/10/2022 at 5:21:08 PM through 5/11/2022 at 9:07:20 PM.

After 9:07:20 PM, cached locations (Cache.sqlite > ZRTCLLOCATIONMO table data) were recorded and parsed into ArtEx timeline as we would normally see with a recently acquired iPhone.

Determining if Significant Locations was OFF or ON at the time of the data acquisition

After reviewing Dexter’s iPhone 7 (iOS 15.1) data, in Figure #26 we will review Scooters iPhone X (iOS 14.7) device data to analyze notable changes made to the clients.plist that may assist with determining if Significant Locations was ON or OFF at the time of the device acquisition.

Reminder: The clients.plist, which stores some of the Significant Locations settings can be found at the following location. During this testing, I used devices with iOS 11.1.2, iOS 14.7, and iOS 15.1:

• \private\var\root\Library\Caches\locationd\

We are going to specifically analyze the following item in the property list, which is the system service related to Significant Locations (cache locations):

• com.apple.locationd.bundle-/System/Library/LocationBundles/Routine.bundle

Using this system service, we can determine if Significant Locations was turned OFF/ ON by analyzing the following notable clients.plist keys/nodes:

• BundlePath
  • /System/Library/LocationBundles/Routine.bundle
• Authorization In this case, the following values will indicate if Significant Locations are ON or OFF at the time of acquisition:
  • 1 Indicates Significant Locations is OFF
  • 4 Indicates Significant Locations is ON
    • Analyze the timestamp keys in this plist for indications of when Significant Locations was turned OFF or ON
• LocationTimeStarted
  • The timestamp will indicate when the device most recently started receiving ZRTCLLOCATIONMO data
• LocationTimeStopped
  • The timestamp will indicate when the device most recently stopped receiving ZRTCLLOCATIONMO data
    • When Significant Locations was turned off a timestamp was recorded in this key, but there are other times when this key would record timestamps. I could not determine what causes the data to be record for each of the different instances observed during testing
• FenceTimeStarted
  • The timestamp will indicate when the most recent fence was stated
• FenceTimeStopped
  • The timestamp will indicate when the most recent fence stopped
• Note: The Fence timestamps being recorded in the clients.plist don’t appear to be used as the entry and exit timestamps for the entries being made in the ZRTVISITMO table. They appear to be indicating when the locations being recorded in the ZRTCLLOCATIONMO table are being used as location data points and are being counted via ZDATAPOINTCOUNT column, which are then used to create entries in the ZRTVISITMO table
• ReceivingLocationInformationTimeStopped
  • This timestamp indicates when Significant Locations was turned OFF via the settings; or if Significant Locations is ON, this timestamp can indicate if there was an extended stoppage in the device receiving ZRTCLLOCATIONMO data.
  • I was unable to determine all the different reasons this stoppage timestamp would be recorded. One example of when the stoppage timestamp would be recorded, was when I would remap the device data using ArtEx or when the device data was acquired using forensic tools. There were other stoppages observed, but again, I am not confident to state why they occurred
• Note: The keys/nodes in this plist may or may not be present. During testing they only appeared when recent changes were made. If you do not have the keys/nodes listed above, no need to worry, there may not have been any recent changes to Significant Locations settings. The keys/nodes listed above, does not include all the keys/nodes that were observed during testing, only some of the notable keys/nodes

Note: Thanks to James (@Mr_EVFA) and some recent testing, I recently learned when a user clears the Significant Location history via device settings, it clears all locations stored in the Cache.sqlite > ZRTCLLOCATIONMO table. I have conducted a few tests related to this and they have been included in Figure #26:

• Settings > Privacy > Location Service > System Services > Significant Locations >
  • Clear History

Based on this testing, the locations stored in the Cache.sqlite > ZRTCLLOCATIONMO table have direct correlation to the Significant Locations ON / OFF switch.

Conclusion:

We are sure you will find other applications and services that have not been discussed, but we hope this will at least assist you with determining if Location Services and what System Services might be ON or OFF when the device data was acquired. Knowing these settings might be able to assist you when analyzing iPhone locations and determining why you might have highly accurate device locations and/or less than accurate device locations.

Resources:

June 5, 2018, Vladimir Katalov

• https://blog.elcomsoft.com/2018/06/apple-probably-knows-what-you-did-last-summer/

December 23, 2018, Sarah Edwards

• https://sarah-edwards-xzkc.squarespace.com/?offset=1545656400308

July 18, 2019, Krista Merry and Pete Bettinger

• https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0219890

June 25, 2020, Ryan NHP

• https://levelup.gitconnected.com/whats-new-with-corelocation-in-ios-14-bd28421c95c4

July 18, 2020, Ian Whiffin

• http://www.doubleblak.com/blogPosts.php?id=14
• https://doubleblak.com/BlogArticles/14/PDF2.pdf

December 10, 2020, Bryan Ambrose

• https://www.datadigitally.com/2020/12/apple-pattern-of-life-lazy-outputer.html?m=1

December 21, 2020, Ian Whiffin

• http://cellebrite.com/en/ios-location-artifacts-explained/

March 26, 2021, Ian Whiffin

• https://www.doubleblak.com/blogPosts.php?id=16

December 2, 2021, – Cellebrite Staff

• https://cellebrite.com/en/episode-15-ibeg-to-dfir-location-data-on-ios-and-android-devices/

Apple Developer Website

• https://support.apple.com/en-us/HT207056
• https://developer.apple.com/documentation/corelocation/requesting_authorization_for_location_services
• https://developer.apple.com/documentation/corelocation/choosing_the_location_services_authorization_to_request
• https://developer.apple.com/search/?q=cllocation
• https://developer.apple.com/documentation/corelocation/cllocationspeed/
• https://developer.apple.com/videos/play/wwdc2020/10660/