# GoogleFindMyTools reads your own Find Hub trackers and builds custom ones

> GoogleFindMyTools reimplements parts of Google's Find My Device, now Find Hub, network so you can query your own trackers and Android devices, read their end to end encryption keys, decrypt the locations they broadcast, and register custom ESP32 or Zephyr trackers. The README calls the code very experimental, and the last push was on 2026-05-05.

**leonboe1/GoogleFindMyTools** — Framework for tracking and building your own Google Find My Device / Find Hub trackers 🧭

- Repository: https://github.com/leonboe1/GoogleFindMyTools
- Stars: 1,203 · Forks: 166
- Language: Python
- License: GPL-3.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/leonboe1-googlefindmytools

## A reimplementation of the Find Hub network

GoogleFindMyTools is a repository of tools that reimplement parts of Google's Find My Device network, which the README notes is now called the Find Hub network. The code is described as still very experimental, and that sentence is the first thing to take seriously.

What the README claims is possible is specific. It is possible to query Find My Device and Find Hub trackers and Android devices, read out their E2EE keys, and decrypt the encrypted locations sent from the Find My Device network. It is also possible to register your own ESP32 or Zephyr based trackers.

Two things are worth separating in that list. The first three items are about your own account: you authenticate with your own Google credentials and then read the locations of the devices registered to you. That is a privacy and research activity, because the Find My Device network is a closed protocol that Google does not document, and a tool that speaks it lets you see what is actually being broadcast about your own hardware. The last item is about extending the network, which is the more unusual half.

The repository layout maps onto the protocol pieces. NovaApi/, SpotApi/, ProtoDecoders/ and FMDNCrypto/ are the API clients, the protocol decoding and the cryptography. Auth/ holds the authentication state, and KeyBackup/ suggests the keys are stored separately. chrome_driver.py at the top level is the piece that drives the browser during authentication.

## Authentication needs a real Chrome, and the result can be copied

The authentication flow is the part with the sharpest edges, and the README is blunt about it. Before starting, ensure you have Chrome and Python updated, and the warning is emphatic: if Chrome is not up to date, the script will NOT work, guaranteed.

On the first run, an authentication sequence is executed, which requires a computer with access to Google Chrome. The authentication results are stored in Auth/secrets.json, and if you intend to run the tool on a headless machine you can copy this file to avoid having to use Chrome.

The mechanism is visible in the requirements. undetected-chromedriver and selenium are the first two dependencies, which means the script drives a real browser rather than replaying an OAuth flow, and the fact that it needs a browser at all suggests it is reproducing a sequence that involves a human present. google-auth-oauth appears as gpsoauth, and requests, httpx and h2 cover the API calls themselves, with h2 being the HTTP/2 library.

Copying Auth/secrets.json to a headless machine is worth thinking about before you do it. That file is the authentication state for your Google account, and it is the kind of artifact that should live on the same machine as the tool and under the same access controls as the account it represents. The README offers the shortcut for convenience and does not say what the file contains.

For a one-time setup on a workstation, the flow is a clone, an optional virtual environment, pip install -r requirements.txt, and python main.py.

## The crypto side is where the interesting dependencies sit

The requirements list for the cryptography is more than a typical script's, and it tells you what the project is doing.

pyscrypt, cryptography and pycryptodomex cover the symmetric and asymmetric primitives, and ecdsa is there for elliptic curve signatures. http_ece is an HTTP encrypted content encoding library, which is how the location payloads are wrapped for transport. pytz handles the time zone work that timestamps and location data need, and protobuf handles the wire format, with a matching ProtoDecoders directory in the tree for the message definitions.

Then there is frida, at version 16.5.6 or newer. Frida is a dynamic instrumentation toolkit, and its presence in a project that reimplements a mobile protocol is a strong signal about the approach: some of the protocol behaviour is observed rather than derived, by instrumenting a running client and reading what it does. That is a legitimate research technique, and it is also a signal that some of this code may break when the client changes.

beautifulsoup4 is there for scraping, and aiohttp for asynchronous HTTP. The combination of HTTP/2 support, protobuf and frida in one project tells you that talking to Find Hub is not a matter of calling a documented REST endpoint, which is the whole reason the tool exists.

## Building your own tracker, on ESP32 or Zephyr

The more unusual capability is the ability to add hardware to the network yourself.

For an ESP32, the firmware is in the ESP32Firmware directory, and to register a new tracker you run main.py and press r when asked, then follow the instructions on screen. For a Zephyr supported BLE device, an nRF51 or nRF52 for example, the firmware is in the ZephyrFirmware directory, with the same registration flow. Each firmware directory has its own README, and the main README asks you to consider the issues listed in the ESP32Firmware README if you want to register custom trackers.

Why anyone would want to do this is the interesting question. The most plausible reason is that the network's coverage is useful and the official trackers are expensive, so a cheap ESP32 dongle that appears in your own Find Hub list is a way to find a bag or a bicycle. A second reason is research: building your own tracker means observing the registration protocol from the inside.

The BLE angle explains a documented limitation. The README says there is no support for trackers using the P-256 curve and 32-byte advertisements, and notes that regular trackers do not seem to use this curve at all, with the author able to confirm it only with Sony's WH1000XM5 headphones. So the support matrix is not uniform across hardware, and the gap is documented with the specific case that triggers it.

## The known issues are the honest part of the README

The Known Issues section is unusually informative, and it is where an evaluator should start.

The first entry is a lock message, 'Your encryption data is locked on your device', shown if you have never set up Find My Device on an Android device. The solution is to log in with your Google account on an Android device, go to Settings, then Google, then All Services, then Find My Device, then Find your offline devices, and enable either 'With network in all areas' or 'With network in high-traffic areas only'. If 'Find your offline devices' is not shown at all, you need to download the Find My Device app from Google's Play Store and pair a real Find My Device tracker with your device to force-enable the network.

That last step is the one to notice. The network is not active for an account until a real device has joined it, so a purely software approach cannot bootstrap itself. The tool needs a physical tracker or a physical Android device paired first, and that is a real constraint on anyone evaluating it.

The other entries are shorter. There is no support for the authentication process on ARM Linux. If you hit an ssl.SSLCertVerificationError, the README points at a Stack Overflow answer. And the P-256 limitation described above appears among them.

The ARM Linux gap and the hard Chrome version requirement together mean the tool currently has a narrow supported environment. The README also links an iOS app on TestFlight for accessing your Find My Device trackers on the go, which is an indication of how the author uses the data once decoded.

## What this project is not for

The clearest way to describe the boundary is that this is a tool for your own account, on your own hardware, for research and for building your own tracker. It authenticates with your credentials, through your own browser, and reads data about devices registered to you.

That framing also tells you what it cannot do. It is not a way to locate someone else's phone, and nothing in the README describes such a use, and the authentication flow is tied to a real interactive login in Chrome rather than to stolen credentials. Anyone reaching for this hoping to track another person is looking at the wrong tool and asking the wrong question.

The second limit is trust in the data. The tool decrypts location reports using keys it reads from the network, and the protocol is undocumented and reverse engineered, with frida involved in observing client behaviour. A decode that silently produces a wrong location is possible, and the README does not describe any validation or integrity checking of the decrypted payloads beyond what the protocol itself provides.

The third is fragility. This code depends on Chrome being current, on an undocumented mobile protocol, on physical devices to bootstrap the network, and on architecture support that excludes ARM Linux for authentication. Any of those can change, and when they do the failure is likely to look like an error rather than a clear incompatibility message.

The fourth is that it does not replace the official client. It is a research and instrumentation tool that happens to be useful for your own devices, and the README is careful to call the code very experimental. The repository is GPL-3.0 licensed, is not archived, and the last push was on 2026-05-05, with no GitHub releases, so there is no version history to pin.

## Conclusion

GoogleFindMyTools suits a developer who wants to understand or extend the Find My Device network for their own account, or who wants to build a custom tracker that reports into it. It is the wrong tool for tracking anyone else's devices, and the wrong tool for anyone who needs a supported, guaranteed way to locate a lost phone. Before running it, read the Known Issues section, because the authentication flow needs an up to date Chrome and the encryption side has a documented gap around P-256 curve trackers. Verify first that your own account is the one being queried, and treat the tool as the experimental research code the README says it is.

## FAQ

### What does GoogleFindMyTools do?

It reimplements parts of Google's Find My Device network, now called Find Hub, so you can query your own trackers and Android devices, read out their E2EE keys and decrypt the encrypted locations they send. You can also register your own ESP32 or Zephyr based trackers.

### How do I run GoogleFindMyTools?

Clone or download the repository, optionally create and activate a virtual environment, install the packages with pip install -r requirements.txt, install the latest Google Chrome, and run python main.py. The first run performs an authentication sequence that requires Chrome.

### Can I use GoogleFindMyTools on a headless server?

Yes. The authentication results are stored in Auth/secrets.json after the first Chrome-based run, and the README says you can copy that file to a headless machine to avoid needing Chrome there.

### What are the known limitations of GoogleFindMyTools?

The code is described as very experimental, authentication does not work on ARM Linux, Chrome must be up to date or the script will not work, and there is no support for trackers using the P-256 curve with 32-byte advertisements, which the author has only confirmed with Sony's WH1000XM5 headphones.

### How do I build a custom tracker with GoogleFindMyTools?

Use the firmware in the ESP32Firmware folder for an ESP32 or the ZephyrFirmware folder for a Zephyr supported BLE device such as an nRF51 or nRF52. To register a new tracker, run main.py and press r when asked, then follow the on-screen instructions.

## Sources

- [Issues](https://github.com/leonboe1/GoogleFindMyTools/issues)
- [leonboe1/GoogleFindMyTools on GitHub](https://github.com/leonboe1/GoogleFindMyTools)
- [License: GPL-3.0](https://github.com/leonboe1/GoogleFindMyTools/blob/main/LICENSE)
- [README](https://github.com/leonboe1/GoogleFindMyTools/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/leonboe1-googlefindmytools