Google Researchers Hacked the Pixel Phone using Audio Messages

Zero-click attack concept (Android)

The researchers describe a “zero-click” exploit on Android, where the attacker does not need user interaction beyond receiving a message.

• Instead of clicking a link or installing malware, the phone is compromised when it automatically processes incoming audio messages.
• No additional user actions are required beyond message receipt.

Why audio messages created a new attack surface

Android added audio message transcription, creating a new pathway for exploitation:

• When an audio message arrives, the phone silently decodes it.
• Then it transcribes the decoded content.
• Crafted audio can therefore trigger exploitation immediately on receipt.

This turns a previously user-dependent media parsing risk into a zero-click threat.

Research effort and scope

• It took about 8 weeks of full-time work for one researcher to build the decoder-to-root exploit chain.
• Another portion took about 4 weeks for the rest of the chain.

Attacker escalation chain (high level)

1. Memory corruption in a media codec decoder
   • Specifically a decoder bug in the Dolby UDC / EAC3 processing pipeline.
2. Escape from the media codec sandbox
   • The sandbox is a restricted process environment.
3. Pivot into kernel attack through vulnerable media decoding drivers
   • Leveraging flaws tied to hardware acceleration interfaces.

Media codec sandbox limitation

Android’s media codec sandbox is designed to provide fewer permissions than other untrusted contexts, but it still must access media decoding hardware drivers.

• The researchers found driver vulnerabilities.
• These vulnerabilities become particularly dangerous when reachable from the kernel context.

Hardware accelerator / driver angle

The exploit relies on device-specific media acceleration interfaces:

• On Pixel 10, the researchers reference a VPU accessed via device nodes such as /dev/vpu.
• Pixel 9 uses differently named interfaces.

After exploiting driver weaknesses to reach the kernel, the chain enables kernel code execution.

Concrete exploit mitigations (and how they were bypassed)

• ASLR (address space layout randomization)
  • Required many stages / repeated techniques because useful addresses were not predictable.
• SE Linux
  • Blocked common paths like creating executable pages.
  • The researchers used /proc-style interactions to enable execution despite restrictions.
• Return-oriented programming (ROP) constraints
  • Limited overwrite sizes forced “weird” gadget strategies.

Devices and vulnerability framing

• The team tested Pixel 9 and Pixel 10 separately.
• They report multiple CVEs across the chain—described as two on each phone to complete the full path.

Is the attack noticeable?

The researchers distinguish between a controlled demo and real-world attacker goals:

• Real attackers could prioritize invisibility, such as suppressing notifications.
• Because ASLR adds entropy, real exploitation may require sending many audio messages, which could be noticeable unless the attacker is well-resourced or tactically careful.

Real-world threat context

The work references targeted activity against:

• Activists
• Academics
• Politicians

These are described as often involving well-resourced adversaries.

One example mentioned:

• Device compromise logs from a case involving Amnesty International
• Later analyzed as part of Google’s threat analysis
• Included Android driver research

AI usage in the process (practical, not “AI wrote the exploit”)

The researchers state that AI was used to save time on boring tasks, not to generate the exploit end-to-end.

• Example uses include:
  • Generating correct bitwise audio format encoders
  • Producing boilerplate such as system-call header files for compilation
• They explicitly imply AI was not used to automatically generate the full exploit chain.

Defensive recommendations and product security implications

Reduce attack surface (“delete key”)

• Remove unnecessary codec formats or limit processing paths that expose parsers to external inputs.
• They argue transcription was a major driver because it caused decoding at the time the message was received.

Strengthen security via compiler mitigations

• They cite that iOS was not vulnerable due to compiler-added bounds/bounce checking for the shared codec decoder.

Fuzzing and code review

• Even if fuzzing doesn’t find the exact same bugs, it:
  • reduces the chance of similar vulnerabilities surviving
  • improves defensive odds over time

Prioritize risky components (drivers)

• Vendors should identify which components (especially decoding drivers) are riskier and audit them accordingly.

Learning pathway advice (for aspiring researchers)

• Read Project Zero’s “Working at Project Zero” article and Project Zero blog posts.
• Use entry paths like internships/co-ops and learning resources.
• Practice via CTFs and cyber communities/clubs for mentorship and collaboration.
• Consider bug bounty programs as a practical way to learn and gain motivation for vulnerability research.

Main speakers / sources

• Natalie Sanovich — Manager, Google Project Zero
• Seth — Researcher on Google Project Zero (Linux kernel / Android drivers focus)
• Source/hosting speaker (implied): David “Bumble” (interviewer)
• Sponsorship mentioned: ThreatLocker