Experiment with Apple's public WPS service

Reference: https://www.cs.umd.edu/~dml/papers/wifi-surveillance-sp24.pdf

How it works is explained in Apple's disclosure to congress: https://web.archive.org/web/20101208141602/https://markey.house.gov/docs/applemarkeybarton7-12-10.pdf

Feel free to poke around the code. Most relevant part is the protobuf and the stuff in lib. Experimental CLIs found in cmd, the main ones being the demo api and wloc.

WLOC

URL: https://gs-loc.apple.com/clls/wloc

I ran mitmproxy to find the URL used and later found iSniff-GPS on GitHub which was used as reference for the protobuf. The field names were uncovered by disassembling CoreLocationProtobuf.framework on MacOS. The relevant C code can be found here.

When requesting location services, MacOS/IOS sends a list of nearby BSSIDs to Apple, which then responds with GPS Long/Lat/Altitude of other nearby BSSIDs. The GPS location of the device is computed locally based on the signal strength of nearby BSSIDs.

Apple collects information from iPhones such as speed, activity type (walking/driving/etc), cell provider, and a whole bunch of other data which is used to build their database. This seems to be sent when a phone encounters a BSSID not in the existing database and excludes certain MAC address vendors known not to be stationary (e.g. IOS/MacOS hotspots).

Cell towers

Using the same API as above, we can also request cell tower information. MMC, MNC, CellId, and TacID is sent off and used to find the surrounding cell towers. It seems to have more data than opencellid.org but missing UMTS and GSM (only LTE is available).

Wifi Tile

URL: https://gspe85-ssl.ls.apple.com/wifi_request_tile

This is a new discovery while running MITM on an iPhone for an extended period of time. An endpoint from Apple takes a "X-tilekey" and returns all the BSSIDs and GPS locations of access points in the given region. Investigation is ongoing.

Here's an example color coded cluster between keys 81644851 and 81644861 (Cardiff).

It seems each key denotes a single network of access points. This information seems to be collected from within the networks. The API is labelled as wifiQualityTileURL in the code base.

The tile key is a morton encoded number with what appears to be their own coordinate system (not based on GPS). I have used linear regression to successfully convert between GPS (long/lat) to their coordinates (code).

Update: Linear regression is not the correct solution. It gets worse as you go north/south.

Update 2: This took more work than I'd like to admit. First, I went through all references to tile keys on GitHub. There are behavior discrepancies between gojuno/go.morton and what Apple uses (In the GeoServices private framework). I ended up finding the implementation by heremaps to match and translated that into Golang. Then, based on the output, noticed that the xyz looked similar to OpenStreetMap's tiles. I used the firefox debugger on leafletjs to find the code used to generate the tiles from coordinates. Based on mentions of pixels and other keywords, I found buckhx/tiles in this 8 year old Reddit post. So to chain it together: tileKey → morton unpack → OSM tiles → pixel data → long/lat.

China

Perhaps for data sovereignty reasons, Chinese data is isolated from the main API. However, we are still able to access it from outside.

URLS:

• "https://gs-loc.apple.com" -> "https://gs-loc-cn.apple.com"
• "https://gspe85-ssl.ls.apple.com" -> "https://gspe85-cn-ssl.ls.apple.com"

A quick dig and whois shows that these are hosted within China at a Unicom IP. CNAME records show that Akamai is used for DNS and Kingsoft Cloud as a CDN.

To swap out the APIs, simply add -china to any of the CLIs in cmd.

Credits to JaneCCP for finding this info.

Interactive demo

go run ./cmd/demo-api and head to http://127.0.0.1:1974.

Click on any spot on the map and wait for a bit. It will plot nearby devices in a few seconds.

How it works: It first uses a spiral pattern to find the closest valid tile (limited to 20 to fail fast). Once it finds a starting point, it finds all the nearby access points using the WLOC API. It then takes the closest access point and tries again until there are no closer access points.

Impact

In the umd.edu paper, they were forced to brute force BSSIDs over the course of 2 years to slowly build up their network. This relies on chance and isolated blocks might not be easily found. With the discovery of the tile API, we are able to create a starting point anywhere in the world and begin exploring from there (given the parameters for which an AP is available over that API). I have tested multiple regions (e.g. Gaza, London, Los Angeles) and it seems to work in most populated cities. However, there appears to be less available networks in certain countries (e.g. Brazil), possibly due to privacy laws.

To do

• If Apple uses device data to add new BSSIDs to their database, try to add fake data
• Ichnaea compatibility and add direct support in geoclue (proposal)