A community research repository documenting the BYD Dolphin's DiLink 3 head unit through ADB exploration, APK decompilation and CAN bus probing, intended for educational and interoperability work on vehicles you own.
| Tool | wheregoes/byd-dolphin-hacking — community reverse-engineering documentation and tooling for the BYD Dolphin 25/26 infotainment system (DiLink 3, Android 10) |
| Category | Vehicle security research / embedded Android reverse engineering |
| Primary Use | Documenting and interfacing with the DiLink 3 head unit — ADB access, sideloading, BYDAUTO_* service APIs, CAN bus behavior, AVAS, NFC keys and OTA mechanisms — for interoperability and security research |
| Safe Use | For authorized research on vehicles and head units you own or have explicit permission to test; the project itself frames everything as educational and interoperability work, with warnings that modifying vehicle software may void warranties or violate BYD's terms |
| Telemetry Note | The head unit ships an IDD-IDPS intrusion detection component on localhost:12406 monitoring wlan0 and rmnet; probing over WiFi ADB and unusual SPI/CAN activity from shell-UID processes is the kind of behavior defenders and OEMs can observe |
Most automotive security repos are scripts; wheregoes/byd-dolphin-hacking is closer to a field notebook. The project documents the infotainment stack of the BYD Dolphin 25/26, running DiLink 3.0 on Android 10 (API 29), and every claim in the README is attributed to one of three methods: ADB exploration, APK decompilation, or CAN bus probing. The authors are explicit that no proprietary BYD documentation was used, which gives the material a credibility that vendor-adjacent writeups often lack. The disclaimer is equally explicit — unofficial, unaffiliated, educational and interoperability purposes only, at your own risk.
The hardware baseline matters for anyone assessing the attack surface. The unit runs a Qualcomm QCM6125 (SM6125 Trinket), ARM64, eight cores, roughly 3.5 GB of RAM, on kernel 4.14.117-perf. The tested firmware is 13.1.32.2507250.1 with MCU 13.5.2.2312260.1, and the README warns that newer BYD updates may change or break the documented behavior — a common problem for vehicle research, since OTA cadence is opaque to researchers. Notably, the driver instrument cluster is a separate Qt/QML system (Qt 5.15.10 / 6.5.5), not an Android surface, which shapes how the whole architecture has to be approached.
The most consequential finding in the spec table is the bootloader state: ro.boot.flash.locked=0 with verified boot reporting orange. An unlocked bootloader on a shipping consumer vehicle head unit means Magisk root is viable via fastboot, and the repo includes a rooting guide treating root as optional rather than required. That framing is honest — the bulk of the findings work from a plain shell — but it also means the integrity story for this platform is weak before any software vulnerability is even considered. For defenders and OEM threat modelers, that single line is arguably the highest-value item in the repository.
Access is straightforward for the owner: ADB over WiFi on port 5555, with the head unit at 192.168.10.10 on the car's own network. A single documented example — adb connect 192.168.10.10:5555 — is all the README needs to establish the entry point; everything else builds on it. Sideloading is documented in a dedicated guide and works without root, with the README noting APK constraints (ARM64, targetSdk ≤ 33, minSdk ≤ 29) and country-specific policy differences — Kazakhstan reportedly enforces a 14-app whitelist, India permits only a maps provider, and Europe/Japan/Australia apply online verification. The repo also records a universal DiLink 3 sideloading master password; we won't republish it here, but its existence across the fleet is itself a finding about BYD's credential hygiene.
The core of the research is the BYDAUTO_* service layer: 75+ BYD packages exposing over 100 custom permissions, most declared with protectionLevel=normal, meaning any installed app can request them at install time. The README describes a client-side permission bypass via BydPermissionContext, a ContextWrapper that overrides enforceCallingOrSelfPermission() and auto-grants BYDAUTO_* permissions — working for air conditioning, door lock, and bodywork domains, but failing for the panorama camera system where the check is enforced server-side over IPC. That split is instructive: it shows BYD doing client-side enforcement where it's cheap and IPC-side enforcement where it visibly matters, an inconsistency a defender can map directly.
The climate control surface is the best-documented functional domain — forty-plus getter and setter methods for temperature, fan, wind mode, start/stop, plus a remote-control feature with a 10–30 minute timer, all reachable through the permission bypass above. The AVAS (acoustic vehicle alerting system) research goes deeper into the MCU's actual behavior: the UI exposes two presets but the MCU accepts indices well beyond that; setBuffer accepts 128-byte PCM frames across multiple feature IDs, though whether the MCU interprets them as audio remains unconfirmed. The README is refreshingly careful about epistemics here, explicitly correcting earlier over-claims — for example, that a return code of 0 indicates acceptance, not a distinct sound, and that the number of real presets isn't discoverable through this API.
From a defensive perspective, the security findings table is the part that deserves the widest circulation. A carplayserv daemon runs as root listening on 0.0.0.0 port 7000 and implements AirPlay/450.14 — the README links this to CVE-2025-24132, a confirmed root remote code execution flaw in the AirPlay SDK fixed upstream in 2.7.1 but, per reporting cited in the README, apparently unpatched by car manufacturers. An intrusion detection component (IDD-IDPS) does exist, monitoring localhost:12406 with clients watching wlan0 and rmnet, so there is some observable telemetry — but an IDS behind an unauthenticated, root-owned network listener is a weak consolation. We deliberately do not reproduce the repository's operational exploitation detail; the README itself contains it for researchers evaluating their own vehicles.
Other findings continue the pattern of unauthenticated trust at the platform layer. The upgrade_server binder service performs no permission check and accepts calls from shell UID without a SecurityException, meaning firmware update flows could in principle be triggered from adb shell given a validly signed package. The SPI bus packet format — [featureId_BE:4][dataLen:1][data:dataLen] — carries no CRC and no HMAC. A broadcast mechanism allows raw CAN frame injection without root or external hardware, with a factory ClusterDebug app acting as privileged proxy, which the README compares to VCDS-style ECU coding; a full UDS (ISO 14229) diagnostic stack was recovered from a decompiled BydDevelopmentTools.apk running with android.uid.system. On the cloud side, the COTA authentication mechanism was reversed — HMAC-SHA256 over a character-shifted secret key — which is the kind of finding that matters enormously for fleet-level risk assessment.
The repo is equally valuable for what it rules out, and the negative results are documented with the same rigor as the positives. The horn is a hardware relay, not software-controllable; AVAS volume is hardcoded in the MCU; hazard-light remote control is gated behind a cloud-authenticated GUID that only exists in root process memory; cabin temperature has no API despite exhaustive probing; and a browser-based download path is deliberately blocked by a DownloadController policy in com.byd.browser, with the README including a full test log correcting an earlier claim that it could be bypassed. That willingness to publish failed avenues and self-corrections is rare and makes the surviving findings more trustworthy.
There are companion artifacts worth knowing about: a separate wheregoes/byd-apps repository holds custom apps built on this research (an engine-sound selector, an AVAS door chime), and the docs directory covers sideloading, rooting, the driver display, the camera system, and AVAS research in depth. With root, additional capabilities open up — direct /dev/spidev_ivi access beyond the 128-byte Java API limit, ALSA mixer control via tinymix, cluster theme replacement by swapping large .rcc resources — while KernelSU is ruled out because the 4.14 kernel predates the GKI requirement. The project is written in Java, sits at a modest star count, and has no license file at the time of writing, which matters if you plan to build on it commercially. As a piece of transparent, self-correcting vehicle research, it's a model of the genre — read it for methodology as much as for BYD specifics.
wheregoes/byd-dolphin-hacking.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.