
Reverse Engineering Apple Location Services Protocol - tuupola
https://appelsiini.net/2017/reverse-engineering-location-services/
======
MarHoff
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...](http://allthingsd.com/20110427/apple-breaks-its-
silence-on-location-gate-plans-to-ship-white-iphone-on-thursday/)

And by today standard I really appreciate Apple approach of doing most of the
computation on the phone itself.

------
zkms
Huh, apparently this is a rediscovery:
[https://github.com/microg/NetworkLocation/blob/master/Networ...](https://github.com/microg/NetworkLocation/blob/master/NetworkLocation/protos-
repo/apple_loc.proto)

also I'm wondering, is there a client for that location services protocol that
works on linux?

------
shabble
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...](https://synalysis.com/how-to-decode-apple-binary-property-list-files/)

~~~
tuupola
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.

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

~~~
eridius
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.

~~~
moontear
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.

~~~
MarHoff
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.

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

------
jploh
Great work! Looking for something similar for AirPlay.

