MT6789 (RMX3630 / 2710EX01): Full DA2 XML audit — heapbait patched at transport layer, no viable vector in 14 audited functions

Open
  • Is something wrong?
#409 86 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
devtools, embedded-iot

Research direction

Start with the USB handshake path in mtkclient and compare its device handling with the successful MT6789 case described in issue #364. Reproduce the reported zero echo and inspect the provided kernel logs, USB descriptors, and debug output; the issue does not name specific files or tests. Done means identifying why this firmware's preloader descriptor or handshake prevents progress, or documenting a reproducible cause and supported next steps.

Written by the indexing model from the issue text.

Description

📌 STATUS UPDATE (2026-10-25):
The original wMaxPacketSize=0 report was self-inflicted (mtkclient's
set_configuration() without checking get_active_configuration()). Fixed.
The thread then evolved into a full DA2 XML audit. Result: heapbait is
patched at the transport layer, and 14 audited DA2 functions show no viable
vector. Full summary in the final comment. Untested surfaces: DA1, Preloader,
EFUSE, cert chain, RPMB.

Device / Firmware
  • Model: Realme 10 4G (RMX3630)
  • SoC: MediaTek MT6789 / Helio G99 (hwcode 0x1208, subcode 0x8A00, hw_ver 0xCA00)
  • Firmware: RMX3630_14.0.0.2710(EX01) — Android 14, security patch 2025-12-01
  • Storage: UFS, A/B, Virtual A/B, dynamic partitions
  • Lock state: ro.boot.flash.locked=1, SBC + SLA + DAA enabled, Cmd 0xC8 blocked
  • mtkclient version: v2.1.4 (commit 7cb40e7, also tested on current main)
Problem Summary

On this specific Realme/Oppo unit with the December 2025 security patch, the preloader VCOM enumerates reliably, but the USB handshake never completes. The tool never reaches hwcode identification, DA upload, or any auth/SLA error stage.

This is not a normal SLA/DAA rejection. It fails at the raw serial byte level before any protocol negotiation.

Observed Behavior

Linux (Ubuntu 22.04, VMware + bare attempts):

  • Preloader VCOM (0e8d:20ff) appears reliably when using cable-hold + power-button method (5/5 success rate).
  • Kernel logs show:
    • wMaxPacketSize=0 on both endpoints
    • can't set config #1, error -32 (EPIPE)
    • Couldn't get device configuration
  • libusb can claim the interface and send the startcmd sequence (0xA0 0x0A 0x50 0x05), but the chip returns zero echo.
  • Device eventually boots to Android on its own, then returns to the same broken stub state.

Windows:

  • Same preloader window used to appear (6/6 on 2026-10-20).
  • After installing WinUSB via wdi-simple for VID_0E8D&PID_20FF, the device still binds as HIDClass (bInterfaceClass=0x03).
  • Antumbra/nusb never sees the device at all.
  • mtkclient (via UsbDk) detects the VCOM but fails the identical handshake.
Battery Correlation (strongest remaining variable)
  • Low battery (3–13%): preloader window stays open for minutes (charging gate hypothesis).
  • Higher battery (37–43%): window often skipped entirely or extremely short.
  • High battery (80%+) has not been tested yet.
Comparison with successful cases
  • Same hwcode 0x1208 devices from other OEMs (e.g. Infinix Hot 50 in #364) complete handshake normally.
  • Another Realme 10 (RMX3630) user (DekuzenOkahiro on Penumbra #134) successfully completed handshake + DA1 + Carbonara + DA2 boot using a Realme-signed DA (MT6789_REALME.bin, SHA-256 024d01b8...b811), then hit the known oplus permission wall. His firmware/security-patch date is still unknown.
What has been ruled out
  • Cable / USB port / USB controller (xHCI vs EHCI)
  • mtkclient version (latest upstream)
  • Driver binding (UsbDk, WinUSB, stock MediaTek)
  • Entry method (adb reboot, cold plug, cable-hold + power button)
  • BROM mode (efuse-locked, confirmed)
Request
  1. Has anyone seen the exact wMaxPacketSize=0 + error -32 signature on a 2025-patched Realme/Oppo MT6789?
  2. Is this a known firmware-side USB sabotage / intentional preloader lockdown after certain security patches?
  3. Any suggested debug flags, alternative handshake timing, or ways to force a proper configuration descriptor?

Happy to provide full kernel logs, lsusb -v captures, and --debugmode output if useful.

Thanks.

Dominant language
Python
Stars
1.5k
Forks
309
Avg merge
1d 7h
Merged PRs (30d)
2

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from bkerler/mtkclient

All issues in bkerler/mtkclient

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.