Reverse Engineering Apple Location Services Protocol
appelsiini.net
Reverse Engineering Apple Location Services Protocol
1–10 of 11 posts
Re: Reverse Engineering Apple Location Services Protocol
#2That was at the core of the "locationgate" a few years ago because location of surrounding access point wasn't flushed enough regularly. Hence revealing approximate location to people that can materially access the phone (this was before iOS full disk encryption).
See: http://allthingsd.com/20110427/apple-breaks-its-silence-on-l...
And by today standard I really appreciate Apple approach of doing most of the computation on the phone itself.
Re: Reverse Engineering Apple Location Services Protocol
#3Now I understand the "your location accuracy is improved when turning on WiFi" message! Very interesting.
Does this also mean that location accuracy is NOT improved when no Internet is available and iOS couldn't update its list of known access points around me? This would mean I could save battery while traveling by disabling wifi.
Re: Reverse Engineering Apple Location Services Protocol
#4Huh, apparently this is a rediscovery: https://github.com/microg/NetworkLocation/blob/master/Networ...
also I'm wondering, is there a client for that location services protocol that works on linux?
Re: Reverse Engineering Apple Location Services Protocol
#5Now I understand the "your location accuracy is improved when turning on WiFi" message! Very interesting. Does this also mean that location accuracy is NOT improved when no Internet is available and iOS couldn't update its list of known access points around me? This would mean I could save battery while traveling by disabling wifi.
If you're traveling to somewhere you've never been before, and you have no internet for 100% of the time, then maybe wifi won't be useful. But if you've been there before, the device may still have info about wifi hotspots stored locally (after locationgate I'm not sure how long those are kept, and whether policies were changed again after ubiquitous FDE), which would allow it to still benefit from having wifi turned on even without internet.
Re: Reverse Engineering Apple Location Services Protocol
#6Although it looks like all the interesting content is in the protobuf payload, it looks like the header might not be the NUL-delimited/ASCII control char sequence the author inteprets it as.
Unless it's coincidence, each of the string portions is prefixed by its length in bytes. Since they're all so short[1], it's not obvious if they're 1,2 or 4 byte lengths, or if those are just padding or other flag bytes. It smells almost like the binary plist format[2], but doesn't seem to obviously decode.
This is just casual inspection of only the sequences in the article, so might be wildly wrong, and probably irrelevant.
Brute-forcing the protobuf message without the schema surprisingly effective here though. I didn't realise it left as much structure in there.
[1] NPI
[2] https://synalysis.com/how-to-decode-apple-binary-property-li...
Re: Reverse Engineering Apple Location Services Protocol
#7Now I understand the "your location accuracy is improved when turning on WiFi" message! Very interesting. Does this also mean that location accuracy is NOT improved when no Internet is available and iOS couldn't update its list of known access points around me? This would mean I could save battery while traveling by disabling wifi.
If you're traveling to somewhere you've never been before, and you have no internet for 100% of the time, then maybe wifi won't be useful. But if you've been there before, the device may still have info about wifi hotspots stored locally (after locationgate I'm not sure how long those are kept, and whether policies were changed again after ubiquitous FDE), which would allow it to still benefit from having wifi turned…
Right. But would still be interesting how "far" away the hotspots are downloaded. If I e.g. roadtrip from New York to Chicago with Internet in New York - I wonder how far Wifi Assisted GPS would help me before there isn't any meaningful data anymore.
Re: Reverse Engineering Apple Location Services Protocol
#8Wonderful. We need more of this to understand the whole iOS/macOS services stack.
Re: Reverse Engineering Apple Location Services Protocol
#9Although it looks like all the interesting content is in the protobuf payload, it looks like the header might not be the NUL-delimited/ASCII control char sequence the author inteprets it as. Unless it's coincidence, each of the string portions is prefixed by its length in bytes. Since they're all so short[1], it's not obvious if they're 1,2 or 4 byte lengths, or if those are just padding or other flag bytes. It smell…
You are correct. I have not tested this yet, but they are most likely strings prefixed with their lengths. I was trying to be too smart and assumed they used ASCII control characters.
Re: Reverse Engineering Apple Location Services Protocol
#10Earlier quoted context omitted.
If you're traveling to somewhere you've never been before, and you have no internet for 100% of the time, then maybe wifi won't be useful. But if you've been there before, the device may still have info about wifi hotspots stored locally (after locationgate I'm not sure how long those are kept, and whether policies were changed again after ubiquitous FDE), which would allow it to still benefit from having wifi turned…
Right. But would still be interesting how "far" away the hotspots are downloaded. If I e.g. roadtrip from New York to Chicago with Internet in New York - I wonder how far Wifi Assisted GPS would help me before there isn't any meaningful data anymore.
At the time of the location gate I had parsed my personal buffer and I found out that pretty much all Manhattan was included. I hadn't a roaming plan when visiting New-York so I only got randomly access to internet at free hotspots.
So I guess a good rule of thumb would be to turn off while on the road with no wifi, but keep on in cities (where A-GPS is the most efficient) where you gonna stay for awhile with sporadic hotspot access.
Also classical GPS (while slow to kick-in) is often really good enough in countryside where you don't suffer from building shapes interfering with the signal.