wavedigger for geolocating BSSIDs and cell towers via Apples WLOC database

wavedigger is a Next.js web application that queries Apple's undocumented WLOC location service to resolve Wi-Fi BSSIDs and LTE/5G tower parameters into approximate map positions for authorized research.

Tool	christianrowlands/wavedigger — a TypeScript/Next.js web app that geolocates Wi-Fi access points and cell towers using Apple's WLOC location database
Category	Geolocation OSINT / wireless reconnaissance web application
Primary Use	Resolving a BSSID or LTE/5G tower identifiers (MCC, MNC, TAC, Cell ID/NCI) to approximate coordinates on an interactive deck.gl map, in authorized assessments, labs, and privacy research
Safe Use	Intended for authorized security assessments, wireless labs, and privacy/defensive research — e.g., demonstrating to clients how crowd-sourced location databases expose their access points; test against your own routers or in lab environments
Telemetry Note	Queries hit Apple's gs-loc.apple.com endpoint directly, leaving request logs at Apple; the tool itself is a client-side web app and does not scan or touch target infrastructure

wavedigger sits in a niche of OSINT tooling that has grown steadily since researchers reverse-engineered Apple's crowd-sourced location services: given only a wireless identifier, it asks Apple's database where that radio was last seen. The tool accepts a Wi-Fi BSSID — the MAC address of an access point — or cellular network parameters, and plots the resulting approximate position on an interactive map. It is written in TypeScript on Next.js 15, uses deck.gl with react-map-gl for visualization, and is licensed AGPL-3.0, which matters operationally because anyone running a modified instance as a hosted service must publish their changes. A public instance exists at wavedigger.networksurvey.app, so you can evaluate the capability before self-hosting.

The core of the project is not original protocol research — the author is explicit about that. wavedigger builds directly on the apple-corelocation-experiments work by acheong08 and collaborators, which reverse-engineered Apple's WLOC API: the protobuf definitions, the request/response formats, the coordinate encoding scheme, and the byte prefix required for the server to accept a request. What wavedigger adds is a polished, deployable frontend around that protocol knowledge. This division of labor is common in the geolocation space; the hard part is understanding the undocumented API, and the durable tooling is whatever makes it accessible.

Mechanically, the application sends protobuf-encoded queries to gs-loc.apple.com/clls/wloc, Apple's live location endpoint, and decodes the response back into coordinates. One implementation detail from the README worth internalizing: Apple encodes coordinates as int64 values with eight decimal places of precision, so the client handles conversion to standard floating-point latitudes and longitudes before rendering. The implementation also distinguishes between the default endpoint and a separate China-region endpoint, reflecting Apple's regionalized infrastructure — a detail that tells you the tool's authors actually tested against the real service rather than a mock.

On the Wi-Fi side, the input handling is deliberately forgiving. The search box accepts AA:BB:CC:DD:EE:FF, AA-BB-CC-DD-EE-FF, or bare AABBCCDDEEFF, normalizing whatever you paste. The README is honest about coverage limits: not every BSSID exists in Apple's database, and newly deployed or genuinely private access points may return nothing. That's an accurate description of how crowd-sourced location works — Apple's database is populated by iOS devices passively reporting nearby radios, so an access point only becomes findable once enough Apple devices have observed it and reported it, tied to their own GPS fixes.

The cellular half of the tool is arguably the more interesting capability. For LTE you supply MCC, MNC, TAC, and Cell ID; for 5G NR the equivalent tuple uses NCI instead of Cell ID. NR searches go further than a single lookup — the tool returns the target cell plus surrounding NR cells in the same cluster, which gives you a sense of the local network topology, not just one pin on a map. The roadmap extends this with a TAC-cluster browser that would enumerate every tower in a tracking area without needing a specific identifier, plus JSON/CSV export — features that would turn one-off lookups into systematic dataset collection.

From an authorized-workflow perspective, the legitimate uses are concrete and real. During a client engagement, demonstrating that the BSSID of their office access point resolves to a rooftop-accurate position in Apple's database is one of the most persuasive privacy findings you can deliver — it shows their infrastructure is a trackable beacon regardless of their own security controls. Incident responders can use it in the opposite direction: given a BSSID observed in logs, a seized device's WiFi history, or threat-actor infrastructure, approximate geolocation provides triage context. Wireless researchers studying crowd-sourced databases as a privacy problem have used this class of tool repeatedly to quantify the exposure.

Defenders should understand the detection surface, which is asymmetric. wavedigger never touches the target network — it doesn't scan, associate, or send anything to the access point itself. All activity is outbound to Apple's endpoint, so the access point owner has zero local telemetry of the lookup. The observable footprint is on Apple's side: request logs at gs-loc.apple.com from the querying IP, or, if you use the hosted instance, in that operator's server logs. This is why the privacy research angle is the strongest framing: the exposure isn't a vulnerability in the target's configuration at all, it's a property of the ecosystem, and opting out is essentially impossible for an organization.

Running it yourself is straightforward and worth doing for client work to keep queries off third-party infrastructure. The prerequisites are Node.js 24+ and npm; npm install followed by npm run dev brings up a development server on localhost:3000. Map rendering works out of the box, but you can add a NEXT_PUBLIC_MAPBOX_TOKEN in .env.local for enhanced Mapbox tiles — the only configuration the project needs, which tells you the API client needs no credentials because Apple's WLOC service doesn't require authentication. That absence of auth is precisely what made the reverse engineering reusable, and what keeps this entire class of lookup tools alive.

What to watch for: the project is young, with 193 stars and a roadmap still ahead of it, and it depends entirely on an undocumented API that Apple could alter or gate at any time — history says the apple-corelocation-experiments lineage has needed periodic rework when request formats changed. There's also an inherent accuracy caveat the README implies but doesn't belabor: crowd-sourced fixes are only as good as the devices that reported them, so treat returned coordinates as neighborhood-level estimates, not survey-grade positions. Used with that calibration in mind, wavedigger is a clean, self-hostable, and honest implementation of one of the more consequential OSINT capabilities of the last decade.

Official project repository for christianrowlands/wavedigger.

Download Tool

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.