The DNG Weird Machine: Deconstructing an In-The-Wild Android Image Exploit

The DNG Weird Machine: Deconstructing an In-The-Wild Android Image Exploit

Speakers: Benoît Sevens, Security Researcher, Google TAG

Conference: OffensiveCon

YouTube: https://www.youtube.com/watch?v=UcAcCsEg7PA

Overview

This talk by Benoît Sevens from Google's Threat Analysis Group (now Google Threat Intelligence Group or GTIG) delves into a sophisticated in-the-wild Android exploit targeting the Digital Negative (DNG) image parsing library. The research, initially prompted by a sample discovered and shared by Meta, sheds light on advanced exploitation techniques used against a less-documented Android attack surface. While similar deep-dive analyses often focus on iOS image parsing exploits, this presentation offers a rare glimpse into the Android ecosystem, revealing a powerful exploit chain that leverages a single vulnerability to gain significant access.

The core of the exploit lies in abusing the DNG file format's opcode lists, transforming them into a "weird machine" to manipulate memory and bypass modern mitigations. This allowed attackers to achieve arbitrary memory write primitives, shape the heap, and overcome ASLR to execute arbitrary code. The target was specifically Samsung devices, where a background process called com.samsung.ipservice would automatically process DNG files written to the media storage, turning a seemingly benign image file into a potent attack vector.

The findings underscore the critical importance of robust security in image parsing libraries, especially those operating in privileged contexts or background services. It demonstrates that even a single memory corruption bug, when expertly chained with heap shaping and ASLR bypasses, can lead to highly effective, real-world exploitation. The analysis provides invaluable insights for both developers hardening their code and defenders seeking to understand and mitigate advanced threats on Android platforms.

Background

▶ Watch: Introduction to DNG exploit and Google GTIG (0:00)

The exploit sample at the heart of this analysis was initially discovered by Meta and subsequently shared with Google for deeper investigation. Initial examination of the DNG file revealed suspicious EXIF metadata, specifically an unusually long list of opcodes, some with invalid IDs, immediately raising flags. A quick binwalk scan also exposed a polyglot structure: a valid DNG image at the beginning, followed by a zip file appended to the end. This zip file contained two ELF binaries: a SE Linux policy manipulation library (common for Android post-exploitation) and a lightweight implant.

Analysis of the implant, which was further detailed in Palo Alto Unit 42's "Operation Landfall" report, provided crucial hints about the exploit's target and context. The implant was found to perform checks for specific Samsung firmware IDs, indicating a tailored attack. Furthermore, it attempted to determine its working directory, specifically looking for data/data/com.samsung.ipservice if its effective user ID matched 5004, a UID associated with Samsung's IP service application. This strongly suggested the implant expected to run within the context of this specific Samsung app.

The attack vector, later clarified by Brendan Tizka at Project Zero, revealed how this context was achieved. An attacker would send a crafted DNG image (disguised with a .jpeg extension) to a target phone via an application like WhatsApp. Under certain conditions, WhatsApp would save this image to the Android media storage. On Samsung devices, the com.samsung.ipservice app runs as a background process, periodically scanning the media storage for new files to perform "intelligent functions" like OCR. This background scanning would trigger the vulnerable parsing code within libimagecodec.qcom, a proprietary native library used by the IP service, without direct user interaction (beyond potentially downloading the image). The speaker noted that while there's no evidence of a zero-click auto-download bug in WhatsApp for this specific campaign, the attack would be one-click if user interaction was required to download the image.

The DNG (Digital Negative) format itself is an open-source raw image format developed by Adobe. Unlike compressed formats like JPEG, DNG stores raw sensor data, allowing for high-quality post-processing. A key feature of DNG files is opcode lists, which specify image corrections (e.g., lens distortion, sensor artifacts) to be applied at different stages of the image decoding process (Stage 1: raw bytes, Stage 2: linear reference values, Stage 3: rendered image). The exploit primarily focused on three opcodes: trim bounds (ID 6, crops the image), map table (ID 7, performs a lookup table substitution on pixel values), and delta per column (ID 11, adds a constant to pixels in a specified area). These seemingly innocuous image processing instructions would be weaponized to achieve memory corruption.

Key Findings

▶ Watch: VirusTotal search reveals WhatsApp exploit distribution (4:00)

The in-depth analysis of this in-the-wild exploit revealed several critical findings, demonstrating a sophisticated understanding of Android's memory management and a proprietary image parsing library.

Firstly, the core vulnerability was identified as a single bug: a lack of bounds checking on the color plane parameter within the delta per column opcode handler (opcode ID 11) in the libimagecodec.qcom library. This allowed an attacker to specify an arbitrarily large color plane index, resulting in an out-of-bounds write relative to the image's raw pixel buffer.

Secondly, the exploit ingeniously transformed this arbitrary increment primitive into an arbitrary value write at a controlled offset. By leveraging a special DNG delta value that maps to minus infinity (supported by the Kura library), the attackers could first zero out an unknown memory location (unknown + -infinity = 0) and then write a desired value to it (0 + desired_value = desired_value) in a second operation. This elevated the primitive significantly.

Thirdly, the attackers developed a highly effective heap shaping strategy tailored for the Scudo allocator, which is default on Android 12+. Despite Scudo's design for resilience, the exploit exploited its LIFO (Last-In, First-Out) behavior on Android (where quarantine is disabled for performance) and its "transfer batch" allocation mechanism. By strategically allocating and freeing thousands of "filler" opcode objects, the exploit could deterministically place the vulnerable raw pixel buffer immediately before a critical KuraDNGImage object, setting the stage for corruption.

Fourthly, the exploit featured an advanced ASLR bypass without an initial read primitive. This was achieved through a type confusion attack. The exploit would corrupt the lower two bytes of a trim bounds opcode's Vtable pointer to point to the Vtable of a map table opcode. When the corrupted trim bounds opcode was subsequently processed, the DNG parser would mistakenly invoke the map table handler. This handler would then interpret the Vtable pointer of a subsequent trim bounds object (located at a convenient offset) as its lookup table, effectively turning the binary's Vtable into a source for data. This allowed the attackers to read arbitrary function pointers from libimagecodec.qcom and even a libc pointer from the Global Offset Table (GOT), enabling full ASLR bypass.

Finally, with arbitrary write and ASLR defeated, the exploit constructed a ROP chain that ultimately invoked the system() function with a crafted shell command. This command was responsible for pinging a C2 server and then leveraging the initial polyglot DNG file to unzip and LD_PRELOAD the implant, gaining persistent execution within the com.samsung.ipservice context. The overall impact was significant: full access to the Android media storage, with the potential for further privilege escalation.

Technical Deep Dive

▶ Watch: Binwalk discovers polyglot TIFF/Zip file structure (6:00)

The journey into the exploit's technical intricacies began with static analysis of the DNG file. The EXIF metadata revealed an extraordinary number of opcodes – thousands, far exceeding typical DNG files. Crucially, opcode ID 23 appeared frequently, despite the DNG specification only defining 14 valid opcodes. To analyze this volume, the researchers utilized DNG Validate, a tool from the DNG SDK (used in the Android Open Source Project's reference implementation), which could print opcodes and their parameters in a verbose mode. This confirmed that opcode lists 1 and 2 contained mostly unknown opcodes, while opcode list 3 contained the "juicy" ones: trim bounds, delta per column, and map table.

To dynamically analyze the exploit's effects, a fuzzing harness previously published by Project Zero and Black Hat researchers was adapted. This harness allowed the DNG file to be fed to the libimagecodec.qcom library in a controlled debugging environment (GDB). By hooking the opcode handler and taking memory snapshots between opcode executions, the researchers could diff memory to observe the precise changes made by each instruction of this "DNG weird machine."

The vulnerability itself was located in the delta per column opcode (ID 11). This opcode is designed to add a constant value (delta) to pixels within a specified rectangular area and across a given range of color planes. For instance, in a stage three image, color planes typically correspond to red, green, and blue (0-2). The exploit, however, specified an abnormally large color plane value, such as 5125. The libimagecodec.qcom implementation, critically, lacked proper bounds checking for this parameter. This allowed the calculation of an offset far beyond the legitimate boundaries of the pixel buffer, resulting in an out-of-bounds write.

Illustrating this, consider a 4x4 image, which might occupy 96 bytes in memory (4*4 pixels 3 colors 2 bytes/color). A trim bounds opcode could logically crop this to a smaller area, but the Kura library would still allocate a minimum of 48 bytes. However, by leveraging the delta per column bug with an excessively large color plane, the exploit could write into memory regions outside the allocated heap object for the image data, potentially corrupting adjacent heap metadata or other objects.

The initial primitive was an arbitrary increment at a controlled offset. To upgrade this to an arbitrary write, the attackers exploited a feature of the DNG specification: the delta parameter supports a reserved value that maps to minus infinity. The Kura library correctly handles this. The strategy was:

1. Trigger the delta per column bug once with delta = -infinity. Any unknown value X at the out-of-bounds location becomes 0 (X + (-infinity) = 0).
2. Trigger the bug a second time with delta = desired_value. Since the location now holds 0, 0 + desired_value = desired_value. This effectively achieves an arbitrary write of a controlled value at a controlled offset.

With this powerful primitive, the focus shifted to heap shaping for the Scudo allocator. Scudo groups allocations by size into different heap regions. The relevant allocations for the exploit (e.g., KuraDNGImage objects, trim bounds opcodes, unknown opcodes, and the stage three raw pixel buffer) all fell into a "red heap region" with an object size of 0x30 bytes. Scudo uses transfer batches, linear memory regions from which allocations are randomly handed out. However, on Android, Scudo's quarantine mechanism is disabled for performance, making its free list behave like a LIFO (Last-In, First-Out) stack.

The heap shaping sequence was meticulously crafted:

1. The Kura library first allocates a stage 1 KuraDNGImage object.
2. It then allocates all opcodes from all three lists. This includes 20,000 unknown opcodes (size 0x30), which serve as heap filler to consume transfer batches.
3. After processing opcode list 1, these 20,000 unknown opcodes are freed. Due to LIFO, the last freed unknown opcode's memory slot will be the first to be reused.
4. A stage 2 KuraDNGImage is allocated, taking this prime spot.
5. Stage 1 KuraDNGImage is freed.
6. Opcode list 2 is processed and its opcodes freed.
7. A stage 3 KuraDNGImage is allocated, taking the spot of the last freed opcode from list 2.
8. Critically, the stage 3 raw pixel buffer is allocated sequentially to the stage 3 KuraDNGImage. While their relative order isn't guaranteed initially, the exploit uses a clever trick.
9. During opcode list 3 processing, the first opcode is a trim bounds. This opcode, even if it doesn't change the size, causes the Kura library to reallocate the raw pixel buffer and free the old one. The new raw pixel buffer is then allocated into the spot previously occupied by the freed stage 2 KuraDNGImage. This ensures the new raw pixel buffer is deterministically placed before the stage 3 KuraDNGImage object in memory.

With the raw pixel buffer now preceding the KuraDNGImage object, the out-of-bounds write primitive can corrupt the KuraDNGImage's metadata. Specifically, the exploit targeted the size parameter of the raw pixel buffer within the KuraDNGImage object. By corrupting this size to an arbitrarily large value, subsequent opcodes (like map table) could operate out-of-bounds on the "enlarged" raw pixel buffer, providing a powerful arbitrary read/write primitive.

The most intricate part was the ASLR bypass, as there was no initial read primitive. This was achieved via type confusion:

1. The exploit uses the arbitrary write to corrupt the lower two bytes of the Vtable pointer of a trim bounds object.
2. It changes these bytes to point to the Vtable of a map table opcode.
3. When the DNG parser processes this corrupted trim bounds object, it mistakenly dispatches to the map table handler.
4. The map table opcode expects a pointer to a lookup table. Conveniently, the offset of the lookup table pointer within a map table object aligns with the Vtable pointer of the next trim bounds object in memory.
5. Thus, the map table handler uses the Vtable of an adjacent (unmodified) trim bounds object as its lookup table. This Vtable is part of the libimagecodec.qcom binary, which is loaded at a randomized ASLR base.
6. When the map table performs its "lookup," it effectively reads values from the libimagecodec.qcom Vtable (which contains function pointers) and writes them to a controlled output location within the "enlarged" raw pixel buffer. This creates a powerful read primitive spanning 2 * 65,000 bytes (65,000 2-byte entries).
7. This read primitive allows the exploit to leak function pointers from libimagecodec.qcom itself and, crucially, a libc pointer from the Global Offset Table (GOT), which is within the reachable memory range.
8. With these leaks, the attackers could calculate the base address of libc and locate the system() function.
9. Finally, a ROP chain was constructed. An arbitrary write was used to corrupt the Vtable of another opcode object, causing the DNG parser to jump to the ROP chain when that object's handler was called. The ROP chain would ultimately call system() with a crafted shell command.

The final payload command was designed to:

• Ping a C2 server.
• Scan the filesystem for its own polyglot DNG image file.
• Unzip the appended payload.
• Use LD_PRELOAD to load the implant into the com.samsung.ipservice process.

Demo / Proof of Concept

▶ Watch: Overview of the embedded post-exploitation implant binaries (6:50)

While no live demonstration of the full exploit chain was presented, the speaker detailed the methodology used to analyze and debug the exploit. The researchers leveraged existing fuzzing harnesses, previously published by Project Zero and Black Hat, as a controlled environment to trigger the vulnerability within the libimagecodec.qcom library. This allowed them to attach a debugger (GDB) and meticulously observe memory changes between opcode executions, essentially stepping through the "DNG weird machine" instruction by instruction. This rigorous analytical approach served as the proof of concept for understanding the exploit's mechanics, rather than a direct, end-to-end live demonstration.

Defensive Implications

▶ Watch: Implant specifically targets Samsung Android firmware IDs (8:00)

The analysis of this in-the-wild DNG exploit offers several crucial defensive implications for Android ecosystem security:

1. Vulnerability Patching: The specific bug, a lack of bounds checking in the delta per column opcode within libimagecodec.qcom, was assigned a CVE and fixed in April 2025. Timely patching of such critical vulnerabilities, especially in proprietary or less-audited libraries, is paramount.

1. Attack Surface Reduction in Background Services: Samsung's com.samsung.ipservice application, a background process intended for "intelligent functions," inadvertently exposed a critical attack surface. By automatically parsing untrusted media files (even those with incorrect extensions like .jpeg for a DNG file) written to media storage, it created a scenario where a single bug could lead to significant compromise without direct user interaction. Developers and OEMs should rigorously audit such background services and consider sandboxing or more restrictive parsing environments for untrusted input.

1. Complex File Formats as "Weird Machines": The DNG format's opcode lists, designed for image corrections, were effectively abused as a "weird machine." This pattern, also observed in iOS image processing exploits, highlights that complex file formats with extensive parsing logic can provide powerful primitives for heap shaping and post-corruption exploitation. Security researchers and developers should pay particular attention to these "built-in" computational capabilities when auditing such formats.

1. Mitigation Efficacy:

• ASLR Bypass: The exploit successfully bypassed ASLR using a sophisticated type confusion technique to create a read primitive. This demonstrates that while ASLR remains a significant hurdle, determined attackers can overcome it, especially in environments lacking other robust mitigations.
• Control Flow Integrity (CFI): The absence of CFI in the Skia library (or libimagecodec.qcom) at the time of the exploit simplified the ROP chain construction. Implementing CFI would have made the ASLR bypass and subsequent code execution significantly harder, as it would prevent arbitrary jumps to gadgets.
• Scudo Allocator: While Scudo is designed for heap resilience, its configuration on Android (LIFO behavior, disabled quarantine) allowed for deterministic heap shaping. This suggests that even advanced allocators need careful configuration and potentially additional hardening layers to resist sophisticated heap manipulation. Memory tagging, as discussed hypothetically by the speaker, could have prevented the initial out-of-bounds write.

1. Threat Intelligence and Monitoring: The discovery of this exploit on VirusTotal underscores the importance of actively monitoring public malware repositories. Threat analysts can create signatures (e.g., for DNG files with an unusually high number of opcodes, like >5) to proactively identify similar samples.

1. Impact of "Single Bug" Exploits: This case exemplifies that even a single memory corruption bug, when expertly exploited, can yield powerful capabilities (full media storage access) without requiring complex, multi-stage exploit chains. Defenders should not underestimate the impact of seemingly isolated vulnerabilities in critical attack surfaces.

Key Takeaways

• DNG Opcodes as a "Weird Machine": The DNG file format's opcode lists, intended for image corrections, can be abused as a powerful "weird machine" to achieve sophisticated memory manipulation and exploitation primitives.
• Critical Vulnerability in delta per column: A lack of bounds checking on the color plane parameter in the libimagecodec.qcom library's delta per column opcode handler allowed for an initial out-of-bounds write, which was then escalated to an arbitrary value write using the "minus infinity" delta trick.
• Advanced Heap Shaping and ASLR Bypass: The exploit demonstrated sophisticated techniques for heap shaping against the Scudo allocator (leveraging LIFO behavior and transfer batches) and an ASLR bypass via type confusion to create an arbitrary read primitive, enabling full code execution.
• Samsung IP Service as a Critical Attack Surface: The com.samsung.ipservice background process on Samsung devices inadvertently exposed a proprietary native image parsing library (libimagecodec.qcom) to untrusted media storage content, creating an easily reachable, privileged attack surface.
• Mitigation Gaps: The success of this in-the-wild exploit highlights gaps in existing mitigations, particularly the absence of Control Flow Integrity (CFI) and the practical limitations of Scudo's hardening in its Android configuration. Memory tagging, if implemented, could have prevented the initial bug.
• Potent "Single Bug" Impact: Even a single memory corruption vulnerability, when expertly chained, can lead to highly impactful in-the-wild exploits, capable of granting extensive access (e.g., full Android media storage) to sensitive user data.

About the Speaker(s)

Benoît Sevens is a Security Researcher, formerly part of Google's Threat Analysis Group (TAG), which has since been rebranded as Google Threat Intelligence Group (GTIG or GTech). His team's primary role is to track in-the-wild exploitation, with a particular focus on zero-day exploits. Benoît has contributed to significant research in the field, including published analyses on iOS exploit kits such as Coruna and Dark Sword. His work focuses on understanding and dissecting advanced, real-world threats to improve platform security.