After being asked about this recently, I decided to go ahead and write a quick post about it to answer these questions.
Reminder Locations (GeoFences)
Found in ~/private/var/root/Library/Caches/location/consolidated.db which should be available in all FFS/AFU/BFU extractions.
The consolidated.db database is used by the iOS GeoFence API and ANY application that creates a geofence to be monitored will be saved in here. Therefore, it's possible that you may find records in this table that I don't cover here. Apologies for that.
Here, I will cover the most common fences you will come across and why they seem to cause so much confusion.
Firstly, lets discuss what a geofence actually is.
A geofence is essentially a location, defined by latitude, longitude and radius. The location radius is constantly being monitored for breaches of the radius, either Entry in to or Exit from the area.
|
An Entry Fence is when the device starts outside the radius and it is therefore monitoring for entry into the radius.
An Exit Fence is when the device starts inside the radius and it is monitoring for exit from the radius. |
Seems pretty simple right? Let's keep going and take a look at the Fences table. The most important fields are:
BundleID |
The BundleID (basically the App) that has requested the geofence to be monitored. |
Name |
The geofence name (this may be the process name or a GUID.
More about GUID's later. |
Timestamp |
The time that the GeoFence was created. |
Latitude |
The centre latitude of the location radius. |
Longitude |
The centre longitude of the location radius. |
Distance |
The location radius in metres. |
Desired Accuracy |
Doesn't appear to be used. |
MonitorFlags |
The type of geofence
1 = Entry Fence
2 = Exit Fence
3 = I believe that this is both Entry and Exit fence
34 = Appears to just be for DND fence?
|
OnBehalfOfBundleID |
Usually blank, but may contain more information about the requesting app. |
Moving on, what types of enties can you expect to see listed in this database?
1) Store Locations
This is the easiest to explain and the most pointless from a forensic point of view.
Imagine installng an app related to a store. Lets take the Sephora app as an example.
Upon opening the app for the first time, Sephora create a geofence on your device around a load of shops nearby that are licenced to sell their make-up. In my case, I had 19 new geofences created (Note that Apple limit each app to 20 geofences).
|
|
An example of the Store Locations and the resulting geofences |
It matters not that this device has never been anywhere near these stores. My device wants to now monitor when or if I do so that it can spring to life with tips or offers etc.
As mentioned above, the timestamp of the GeoFence is the time it was created, not the time it was breached. So because all 17 Sephora GeoFences were created at the same time, they present with the same timestamp.
Some stores, such as Ikea, are really easy to spot that something is amiss. The stores are so far apart that it's clear the device couldn't have possibly been there all at the same time. But stores such as the ones shown here present a new challenge. There fences are so close together it makes it appear that the data could be good and it's easy to misinterpret.
In any case, Store Locations are unlikely to be useful to your investigation and should probably be excluded in most cases.
2) Reminder Locations
Reminder Locations are where things start to get a little more tricky.
|
An example of Reminders |
There are typically places that ARE relevant to the owner of the device and that can make this tricker to see how useless this data probably is.
There are two scenarios you may find.
a) "Remind me when I arrive at xxx"
This may be used for example to say "Reminder me to do X when I get near home" or "Remind me to call X when I get to work".
You can see that the locations being fenced are relevant to the user. But again, the location is being monitored for entry and is not where the user currently is. They could literally be anywhere else in the world and create a geofence around their home.
You may also notice that on the example screenshot above, the Distance can be as small as 100m or as large as 5km or more. In the case of the 5km, I created a pretty generic "Remind me when I get to [town]" and it chose the location as the middle of the town and the radius for me.
b) "Remind me when I leave"
This is a little bit more useful and could be used for something like "Remind me to do X when I leave home".
In these cases, the user must at least be within the area that the fence is created. The time is obviously the time the fence was created, not the time they arrived there but thats fine. At least we can use this record to put the user in a location at a time.
The really bad news is that this record will be deleted once they leave so you may never actually see this on your extractions.
3) Do Not Disturb Until I Leave
This is an option that the user can set to enable Do Not Disturb Mode until they leave their current location. For example, you can configure your device to be in DND mode until you leave Home.
Really though, it doesn't matter if the location you are at is a frequent location or not. It will just create a 100m geofence around where you currently are, wherever that happens to be.
|
An example of a DND geofence |
Similar to any Exit Fence, you at least know where the user was at the time the fence was created, but it will also be deleted upon leaving the location.
4) Frequent Location Monitoring
This is the one that is potentially the most useful, but is also the most confusing.
GeoFences are used to monitor for the entry into and exit from Frequent Locations. This results in constant creation and deletion of geofences.
|
An example of the Frequent Location Monitoring
You will see either
RTVisitMontor.RealTimeHighConfidenceExitFenceForCurrentVisit or
RTVisitMonitor.RealTimeEntryFenceForNextPredicted |
This is the best way I could think to demonstrate it. Use the grey buttons to move forward and backward.
< |
|
> |
So you see, again, it is the EXIT fences that may be useful because we know where the user was when the geofence was created. Entry fences are ultimately guesses as to where the device may be heading next and, as shown in the slideshow, there could be multiple predictions being made. It may guess that you are going Home or to the local Bar. Both will have the same creation time but could be no-where near each other.
Ultimately, predicted locations serve no forensic purpose and should be ignored.
I have had a couple of cases I assisted with in recent months where it was the EXIT fence that could be used to determine that the user had visited a crime scene.
There was a huge caveat to being able to do this though. The suspect thought they were being smart and disabled Location Services WHILE THEY WERE AT THE CRIME SCENE.
Imagine this scenario:
- Suspect visits an address which they have been to many times before. An EXIT fence is created monitoring for them to leave.
- While
there, they decide to disable Location Services so as to hide the fact they were at that location while they commit a crime.
- They leave the location.
- Ordinarily, when they leave the location, the Exit Fence fires causing the destruction of the record. But because Location Services was disabled, the Exit Fence never fired and the record was therefore not deleted.
While lucky for examiners in this case, it does demonstrate how easy it could be to manipulate the data by turning on/off Location Services and/or WiFi.
GeoFence Name / GUID
Now we've covered the different types of geofences, it's a better time to cover the GUID mentioed above in the Fences table definition.
The GUID can usually be used to cross-reference the item back to the requesting app. If you recall, the Reminders all have unique GUIDs as the geofence name. If I look in the Reminders database, I can find which reminder item owns each of the geofences.
|
|
The top image shows the geofences. The bottom image shows the Reminders.
Notice that the Name field in consolidated can be matched to the Unique Identifer in the Reminders. |
This may also count for other types of geofences too and may be worth taking a look for if the record does appear relevant.
Wrapping Up
Overall, I don't consider Consolidated.db a good source of location data. If anything, I think it muddies the water of where the device has been by creating lots of guesses or unrelated locations. However, it shouldn't be overlooked as you may get lucky and find some useful nuggets hidden in there if all the stars align.
|