Reverse Engineering Apple Location Services Protocol | Hacker News Reader

Reverse Engineering Apple Location Services Protocol

appelsiini.net

161 pointstuupola10 comments

That 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.

Huh, 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?

Although 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...

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.

Now 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.

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.

Wonderful. We need more of this to understand the whole iOS/macOS services stack.

Great work! Looking for something similar for AirPlay.

Reply on news.ycombinator.com