Decoding Google: Converting a Black Box to a White Box

by

Author: Arvin Shivram (brutecat)
Published: November 1, 2024 (with later updates in 2025)
Source: https://brutecat.com/articles/decoding-google/

Summary

This is a methodology writeup, not a single-vulnerability disclosure. brutecat (Arvin Shivram) documents how to turn Google’s opaque internal APIs into a “white box” for security research: locating machine-readable API discovery documents, understanding how authentication works on the web versus Android, and — where no discovery document is available — reconstructing an endpoint’s request schema from its own error messages. The techniques are presented as tested and reproducible, backed by working example requests and open-source tooling. No CVE is assigned; the article is foundational tradecraft that the author reuses in later Google VRP research (it is the companion piece referenced by the “Hacking Google with A.I.” writeup).

Technical Details

Discovery documents. Google publishes Swagger-like discovery documents (e.g. at /$discovery/rest) describing each API’s methods and fields. Public APIs like the YouTube Data API expose them openly; private/internal APIs (e.g. the internal People API) return 403 “API Key or other form of API consumer identity” without a valid key. The author also revisits Ezequiel Pereira’s “visibility labels” finding — appending a label such as PANTHEON to a discovery request unlocks additional, otherwise-hidden endpoints (in one example growing the response from ~214KB to ~329KB).

Web auth. Browser requests to internal Google APIs combine an X-Goog-Api-Key (project context), cookie-based session auth, and a SAPISIDHASH value derived from the SAPISID cookie. Android auth. Android instead uses scoped bearer tokens (ya29.*) minted from a refresh token (aas_et/*); the bearer token itself carries the Cloud project context, so no separate API key is needed. The article walks through obtaining a refresh token via accounts.google.com/EmbeddedSetup (extracting the oauth_token cookie and exchanging it at android.googleapis.com/auth).

X-Goog-Spatula. The author describes this “keyless” header, which supplies Cloud project context via base64-encoded protobuf containing the Android app’s package name, its signing-certificate SHA-1, and a DroidGuard device value. The key observation is that the DroidGuard value was not validated, so an attacker could impersonate any client by supplying that client’s package name and signature — DroidGuard is enforced on newer Android but reportedly cannot be strictly required without breaking Play Services compatibility.

Parameter discovery via errors. For endpoints with no reachable discovery document, sending deliberately malformed ProtoJSON (for example a positional array like [1,2,3,...] instead of an object) causes the backend to leak field names, types, and field indices in its error responses. The author automates this into a tool, req2proto, and demonstrates reconstructing the full schema of YouTube’s Innertube /youtubei/v1/browse endpoint. This works because these services accept a ProtoJSON-over-HTTP fallback that transcodes to gRPC.

Impact

The article is about research capability rather than a discrete exploit: the techniques let a researcher enumerate private/staging Google API surface, mint Android app-context tokens, spoof client identity through the unvalidated X-Goog-Spatula/DroidGuard path, and recover complete request schemas for undocumented endpoints from error output. That mapping and authentication capability is precisely what makes the broader, higher-impact access-control findings in the author’s follow-on work feasible. As a security note in its own right, the unvalidated DroidGuard value in X-Goog-Spatula means client-identity signals based on package name and signature alone could be forged.

Mitigation

These are Google-side design observations, so there is no user-facing patch. The article records incremental Google hardening after publication: comments were stripped from staging discovery documents (update 2025-02-06), and both production and staging YouTube Innertube discovery documents were subsequently removed (update 2025-03-01). The transferable defensive lessons: do not treat discovery documents or verbose error messages as safe to expose (they leak internal schema and endpoints); enforce authorization on backend and staging endpoints rather than relying on obscurity; and validate device-attestation values (DroidGuard) so headers like X-Goog-Spatula cannot be spoofed by copying a legitimate client’s package name and signature.

References

Leave a Comment