BUMP
Does anyone have an idea on why these database entires are time stamped in batchdumps? I am currently assuming it happens when the device gets an internet connection and can render lat longs from the cached mac addresses/cell ID's etc.
Hello all,
We've been trying to do a bit of research regarding this, although we've hit a bit of a wall. After formatting the phone I’ve parsed out the "wifilocation" table of this database.
We're getting hits back (in the roughest sense of the word) which could be used to locate a phone, but not to the precision we'd like. I've included a image here so that you can see the results we're getting.
Google maps was open for the grand total of 6 seconds and somehow 1253 records were made. Some of these points would be near impossible to be wireless devices. The internet is speculating all sorts of wild things to do with cell towers, and I quite like the idea that the phone is downloading this data from remote servers to better establish where it is in a speedy manner, but I'm really trying to bottom this out. If anyone would like to discuss this further, feel free to PM me or post here.
Link to my pretty KML file showing the radius of inaccuracy
http//
I'm still trying to look at the consolidated.db file to ascertain why it appears to write entries in batches.
I think that in addition to Google maps other apps write to the consolidated.db and it could be location services writes to the db.
The database is only added to when an app which has access to "Location Services" is active. Although it'd be very nice to determine under what conditions the service collects this data and what it means in a forensic capacity.
At this time I'd be hard pushed to use it for anything more than "This phone (although yes we want to say user!) was in this very rough area at roughly this time".
If it's possible to tie it down even more, that would be great. I'm based in a large city, and saying that a crime was committed in a specific location and the having the suspect's phone saying they've been within a mile radius of the scene is realistically not going to work and is little more than very "loose" corroborative evidence.
It only really becomes useful in a situation such as
A suspect lives in the north of the country and is accused of kidnapping someone and taking them to London over a certain period of time. They have no reason for normally going to London and yet their iPhone reports it was in London over the dates in question.
If the suspect lives in London and the iPhone retrieves "gps fixes" covering the whole of the city with the same timestamp, the data is almost useless.
You have the TomTom Europe app (if installed). It uses the same file set up as the devices. There is a wealth of white papers and articles on analysing these, but you are primarily looking for a file called MapSettings.cfg. This will contain last GPS fixes, recent destinations, favourites, home location etc.
I have a theory that the consolidated.db file is sort of quasi cache file that contains a list of possible nearby Wifi access points.
With the idea being that it dumps a huge list of Wifi access points into the database on a single occasion (probably the first time a location is requested in that geographic area), this database is then referred to when using location services in that area, the idea being that this reduces bandwidth for location data requests and helps reduce the time that the GPS module uses to locate you also saving battery.
I have no real evidence to confirm this (mainly because I havent had time to test it) but the structure of the file and its contents lead me to believe that this is a possible use for it.
Someone should restore their phone, take it into a field and turn it on then have a look at what Consolidated.db contains, take it from there. Another useful experiment would be to see if the locations of these Wifi access points are accurate, would also be interesting to see if the Google Wifi database API places them at those exact locations.
With the idea being that it dumps a huge list of Wifi access points into the database on a single occasion (probably the first time a location is requested in that geographic area), this database is then referred to when using location services in that area, the idea being that this reduces bandwidth for location data requests and helps reduce the time that the GPS module uses to locate you also saving battery.
I think that’s the theory I'm going with at the moment, the locations are by no mean accurate, and in fact some are impossible. The MAC addresses are very similar which also raises suspicions about the legitimacy of the data.
I've not found any of the addresses I've used within the google database yet, although that would have been very nice if I had…
Well, thats a great theory, I like it a lot.
If the wifi ap locations are being downloaded from a server then the order that they are INSERT'ed into the database should be indicative of the algorithm used to identify the closest APs to the preliminary fix. It may well be worthwhile looking at the order of the aps in the database to see if there are any patterns.
Is there any way we could inject a test AP into the database?
edit Also consider wiresharking the internet traffic to see what its getting.
Of course its apple, so you'll probably need to buy a special cable for 40 quid.
I am currently testing this extensively and am quite confident in saying that 95% of the location data in this database is of limited use and has very little accuracy.
For instance there are cell towers in the database from over 23 kilometers away, cells we have never been connected to.
I have also found that if you restore your device to stock firmware, turn location services off, turn airplane mode on and then connect to a Wifi access point and you will find that the consolidated.db file contains location data. At no point is a map launched or is location services switched on, it just appears to be populate the database simply by connecting. The access point I connect the iPad to is a bridged Wifi connection on my MBP and has never been indexed by Google or any other Wifi location service.
Interestingly the first entry in the WifiLocation table is a Wifi AP that is in immediate proximity to ourselves.
I have carried out all of my testing from an iPad1 running 4.3.1.
I will document my findings fully shortly and hopefully try and solve most of the questions regarding the contents of this file and what it all means.
About file consolidated.db -> http//