# Turning Google smart speakers into wiretaps for $100k

Google Home's local API exposed device cert/cloud ID over an open setup-mode Wi-Fi, letting a nearby attacker link their account and use routines to call out and wiretap the mic.

- Payout: $107,500
- Severity: high
- Program: Google
- Credited: Matt
- Disclosed: 2022-12-26
- Write-up quality: 9/10
- Original: https://downrightnifty.me/blog/2022/12/26/hacking-google-home.html
- Library page: https://bugbountylibrary.com/r/blog%3Adownrightnifty-me-blog-2022-12-26-hacking-google-home-html
- Tags: domain:iot impact:data-leak impact:internal-access kind:bounty platform:blog sev:high tech:chromium technique:recon technique:reverse-engineering vuln:access-control vuln:auth-bypass vuln:info-disclosure

**Target:** Google Home Mini smart speaker local HTTP API (port 8443) and Google cloud device-linking API
**Root cause:** The device's local API exposes the device name, certificate, and cloud ID (which together act as a credential) without authentication, and the cloud deviceuserlinksbatch endpoint accepts these to link any Google account. Deauth forces the device into an open setup-mode Wi-Fi where this info is reachable.
**Steps:**
1. Discover device via `dns-sd -B _googlecast._tcp` and nmap port 8443
2. Deauth device with `aireplay-ng --deauth 0 -a [BSSID] -c [MAC] [iface]` to force setup mode
3. Connect to setup network `[name].o`, device at 192.168.255.249
4. GET `https://192.168.255.249:8443/setup/eureka_info?params=name,device_info,sign` to obtain cloud_device_id and certificate
5. POST protobuf to `https://clients3.google.com/cast/orchestration/deviceuserlinksbatch?rt=b` with Bearer token from gpsoauth and device info to link attacker account
6. Create routine via assistant.google.com/settings/routines to run `call [attacker number]` at a set time
7. Routine executes on device, attacker answers and listens to mic feed
**How found:** Noticed how much control a linked account gives (routines, actions) and set out to reverse the linking process. Used mitmproxy with Frida SSL-pinning bypass on a rooted spare phone, observed the Chromecast link flow as a simpler analog, decoded the protobuf deviceuserlinksbatch payload with protoc --decode_raw, and re-implemented it in Python. Then recalled RickMote/setup-mode behavior and tested deauth to reach the local API without Wi-Fi credentials.
**Exploitation:** Attacker within Wi-Fi range deauths the Google Home, connects to its open setup network, harvests device cert/cloud ID from the unauthenticated local API, and links their Google account via the cloud API. They then configure a routine to call their phone, turning the speaker into a remote wiretap; night mode mutes the assistant and LEDs show only solid blue.
**Escalation:** Chained further: install a Local Home SDK app with mDNS scan config targeting _googlecast._tcp.local to reach the device's own Chrome DevTools port 9222, then use CDP over WebSocket to make arbitrary HTTP requests on the victim LAN and read/write arbitrary files on the device.
**Insight:** When a device's cloud-linking credential is derived from locally-exposed identifiers (cert + cloud ID), any path to the local API—including forced setup-mode APs triggered by deauth—becomes an account-takeover primitive. Also: a Local Home SDK app's mDNS scan config can be pointed at the device's own cast service to reach its Chrome DevTools port 9222.