====== TBox teardown ====== Component-level teardown of the Aiways U5 **TBox** (Telematics Box) — the always-on **cellular gateway**. It holds the SIM, terminates the vehicle CAN, and is the box the OEM cloud talked to: it is the FOTA relay that pushes MCU/system updates to the head unit (''getTBoxInfo = 192.168.1.1:50000'', see [[:connectivity]]). Board marked ''XT7018L PA.2'', ''IN060000P0'', dated **2019.09.09**. **⚠ Chip IDs below are read off the photos.** Confidence is called out per part — several markings are **house-coded** (Adayo ''H2…'' numbers) or could not be fully decoded, and those are flagged rather than guessed. ===== Board overview ===== ^ Front ^ Back ^ | {{:tbox_front.png?330|TBox front}} | {{:tbox_back.png?330|TBox back}} | Front: the Quectel LTE module (top, under the QR-coded shield) with three RF cans labelled **MAIN ANTENNA / WIFI-1 / WIFI-2**, the nFore WiFi/Bluetooth module and Micron memory beside it, and a row of **FAKRA** antenna jacks plus the white main harness connector down the right edge. Back: the NXP S32K144 MCU (large QFP, lower centre) and the CAN transceiver. ===== Cellular modem — Quectel AG35 ===== {{:tbox_modem.png?440|Quectel AG35 LTE module}} **LTE Cat-4 automotive module**, Quectel **AG35** — shield marked ''R-C-QUT-AG35-E'', ''FCC ID: XMR201907AG35E'' (XMR = Quectel's FCC grantee code), ''SN: P1A20LA19000906''. The unit's **''IMEI: (redacted — unique to each car)''** is printed on the can. This is the box's uplink; its subscription comes from the **soldered SIM below** (see [[:connectivity]]). //High confidence.// This module is more than a radio. Its chipset bundles the cellular baseband with a full **application processor running embedded Linux** — so this chip //is// the TBox's on-board computer, not just its modem. Software analysis confirms the telematics application (the cloud client, OTA agent and eCall logic) runs here, on Linux. That Linux side has no CAN connection of its own — see the MCU below for what happens next. ===== SIM — Deutsche Telekom (soldered MFF2) ===== {{:tbox_sim.png?400|MFF2 embedded SIM}} The **SIM** — a soldered-down **MFF2 embedded SIM** (M2M form factor, which is why it looks like an IC rather than a card). Carrier: **Deutsche Telekom**, confirmed after desoldering. Markings: ''H2021875'' (lot) / **ICCID ''(redacted — SIM ICCID)''** / ''THA''. Because it is a solder-down MFF2 part, changing carriers means **desoldering it** (as was done here) and fitting a different SIM — directly relevant to running the car's cellular uplink on your own data plan once the OEM subscription lapses (see [[:roadmap]], [[:connectivity]]). //High confidence (confirmed physically).// ===== Main MCU — NXP S32K144 ===== {{:tbox_mcu.png?420|NXP S32K144}} The TBox's own microcontroller — NXP **S32K144** (''FS32K144HFVLL / 0N57U / QGU2034AC''), 100-pin LQFP. Automotive **Arm Cortex-M4F**, ~512 KB flash. //High confidence (clear marking + NXP logo).// Its role is narrower than it looks, but important: this is the **only path from the Linux side to the vehicle CAN bus**. The telematics software (above) reaches it over a serial link and hands it simple commands; the MCU is the one actually wired to the CAN transceiver below and is what would put anything on the vehicle's bus. So there is always a dedicated microcontroller standing between the general-purpose computer and the live CAN bus — the same pattern the head unit uses with its [[hardware:mainboard#mcu_renesas_rl78_r5f10ppjl|RL78 MCU]] (see [[:architecture]]). That "serial link" is specifically **SPI** — ''/dev/spidev5.0'' at **4.8 MHz** — which the driver presents up to Linux as a SocketCAN device (**''can1''**, 500 kbit/s; the raw channels are ''/dev/spichn_0''/''_1''). So although Linux //appears// to have a ''can1'' network interface, it is **not** a native CAN controller wired to the car — it is this SPI link to the MCU. A common misreading is that the TBox reaches CAN over three separate interfaces (SPI, ''can1'' and a UART); in reality the SPI and ''can1'' are **two layers of the one MCU-gatekept path**, and the ''ttyHS0'' UART carries **MCU control/FOTA**, not CAN. ===== CAN transceiver — NXP TJA1042 ===== {{:tbox_can.png?400|NXP TJA1042 CAN transceiver}} NXP **TJA1042** high-speed **CAN transceiver** (''TJA1042 / NXP''), SO-8. This is the TBox's physical tap onto a **vehicle CAN bus** — an independent CAN path from the head unit's MCU. //High confidence.// //(A second route onto the same data is what [[:canbus|CAN bus access]] documents from the head-unit side.)// ===== eCall audio codec — TI TLV320AIC3104 ===== {{:tbox_codec.png?400|TI TLV320AIC3104}} TI **TLV320AIC3104** low-power audio **codec** (top-mark ''AC3104 / TI / AV5Y''), QFN. In a TBox a codec almost always serves the **emergency-call (eCall) voice path** — mic + speaker for an automated 112/emergency call. //Part read is high confidence; the eCall purpose is an inference.// ===== WiFi / Bluetooth module — nFore NF3304 ===== {{:tbox_nfore.png?420|nFore NF3304}} A **shielded RF module** (metal-can lid, the same style as the AG35's own shield) marked **''nFore NF3304 201706''**, sitting next to the Micron memory. nFore Technology's actual business is **automotive WiFi/Bluetooth combo modules**, and software confirms this is exactly that: both the head unit and the TBox's own application are built on nFore's Bluetooth car-kit SDK (hands-free calling, music streaming, contacts sync), and the TBox's Bluetooth configuration names the underlying baseband as a **Broadcom BCM4339** (a WiFi + Bluetooth 4.0/BLE combo chip) reached over a UART — nFore most likely packages that chip into their own automotive-qualified module under this part number. //High confidence (role confirmed via software; exact die inside the module is an inference).// The Bluetooth stack isn't started by any background service — the TBox's software appears to bring it up only on demand. One function name stood out during analysis: a BLE-based **remote wake** feature — suggesting Bluetooth here is meant as a local trigger path, not just for phone pairing. Relevant to any future companion hardware placed near the car (see [[:roadmap]]). ===== Memory — Micron ===== {{:tbox_ram.png?400|Micron memory (FBGA ORAID JWD13)}} Micron FBGA chip (Micron "M" logo) marked ''ORAID JWD13'', beside the nFore module — its working **DRAM or flash**. The FBGA code (''ORAID'') would need Micron's part decoder to resolve exact type/density, so **capacity is unconfirmed**. //Vendor high confidence, exact part low.// ===== Serial transceiver — Sipex SP3232E ===== {{:tbox_rs232.png?380|Sipex SP3232E RS-232 transceiver}} Exar/Sipex **SP3232E** 3 V **RS-232 transceiver** (''SiPEX 3232E 1930L''), TSSOP — level-shifts a UART to RS-232 levels, typically a **diagnostic / debug** serial port. //High confidence.// ===== Power ===== ^ Buck-boost DC-DC ^ NXP power/RTC ^ | {{:tbox_dcdc.png?280|TI TPS63020}} | {{:tbox_pmic.png?280|NXP PF85163}} | * **TI TPS63020** buck-boost converter (''PS63020 / TI'') — makes a stable rail from a battery voltage that can sag/spike. //High confidence.// * **NXP PF85163** (''PF85163 / NXP''), SO-8 — an NXP power/RTC-class device; **exact part not confirmed**. //Low confidence.// * **''H2002235''** (QFN) is a **house-coded Adayo part number**, not a real silicon marking — likely a load switch / protection / small PMIC or PHY, but **not identifiable from the marking alone**. The 12 V input also has an **MCC SMBS36A** transient-protection diode. ===== Antennas & connector ===== RF is broken out to **FAKRA** coax jacks (colour-keyed) plus the internal cans labelled **MAIN ANTENNA**, **WIFI-1**, **WIFI-2** — i.e. cellular main/diversity + GNSS + Wi-Fi. The white connector on the right edge is the **vehicle harness** (power, ignition, CAN, audio for eCall). Exact pinout not yet traced. ===== Operating system & software ===== The Quectel AG35's application processor runs **embedded Linux** (the standard vendor build). The telematics application — the OEM-cloud client, the OTA/FOTA agent, the eCall/bCall logic and the CAN command builder — is a single userspace program on that Linux. The always-on **S32K144 MCU** is the only part wired to the vehicle CAN; the Linux side reaches it over an internal serial link and hands it commands. Because it is an ordinary Linux system it is fully inspectable — and, as it turns out, **wide open**. ===== Getting a root shell ===== Several independent routes exist, from fully remote (over the car's own internal USB link) to bench-level. **None require an exploit** — the doors are already open. Root here means root on the //telematics computer//; the vehicle CAN still sits behind the MCU. ==== Remote, over the USB link (no disassembly) ==== From the head unit, which is the ''192.168.1.50'' peer of the TBox at ''192.168.1.1'' on the ''usb0'' link: * **FTP (port 21) — full root read/write.** The TBox's own start-up scripts launch a busybox FTP daemon **as root, write-enabled, rooted at ''/''**. Logging in with the **standard vendor default account** (''root'' / ''oelinux123'') gives read/write of the **entire filesystem** — no privilege escalation needed. This is the single most useful foothold, and how the firmware, config and logs are read. * One limitation: that FTP daemon **refuses to write device nodes** (only regular files) — so it cannot poke the modem's AT channel directly, but it can freely edit **scripts and config files**, which is enough to arrange code execution on a later boot. * The other open ports on that link are **50000** (the telephony/eCall protocol, see [[:connectivity]]) and **53** (the TBox's own DNS/DHCP). ==== Persistent doors you can open with a single config edit ==== Two changes need only a config-file write over the FTP root — no code execution — and take effect on the next cold boot: * **Add ADB to the USB gadget.** The list of USB interfaces the TBox presents is read from a plain text file; adding ''adb'' to it exposes the (already-present) ''adbd'' to the head unit acting as USB host. * **Bring up the built-in Wi-Fi AP.** The mobile-AP config disables Wi-Fi and the access point at boot with two flags; enabling both brings up the pre-configured AP, after which FTP (and anything else) is reachable **directly over Wi-Fi**, with no head-unit relay. ==== Bench / physical access ==== * **Serial console (UART) — guaranteed root.** The board's debug UART is configured to **permit root on the serial console**, so a 3.3 V UART adapter gives a root shell with no network at all — the cleanest way to get first root on a bench unit. * **ADB over USB**, once enabled as above. **Important — cold boot vs. deep sleep.** The MCU distinguishes a **deep sleep** (suspend-to-RAM: Linux stays loaded, config files are //not// re-read) from a real **power-off** (a cold boot, where config //is// re-read). Config changes only apply after a genuine cold boot. **Do not force this with the module's shutdown command** — it only powers the modem //off//, with no guarantee it comes back by itself, and a dead TBox means no eCall and no telematics with no OEM support to recover it. Make the change and wait for a natural power-off. //(There is also a driver-triggerable restart: toggling the **rear fog light 4×** is observed to reboot the TBox — the cluster briefly shows "Kein Netz". Whether that restart is a full cold boot that re-reads config, or only a warm restart, is **unconfirmed**.)// ===== Remote preconditioning is in the firmware ===== The telematics app contains the remote-control machinery: routines to **check preconditions**, **wake the MCU**, and drive **A/C, rear-defrost and door-lock** remote-control state. The one feature traced end to end is a **mid-trip battery pre-heat** (warm the pack before a fast-charge stop): * **Trigger is cloud-only.** It fires on a command field delivered by the (dead) cloud; **no local trigger exists in the code**. * **Pre-check:** HV system on, DC-DC idle, on-board charger idle, **SoC > 10 %**, **battery minimum temperature < 15 °C**, **range > 20 km** — classic "skip if already charging, already warm, or nearly empty" logic. * **How the command reaches the car:** the TBox sends a **security-gated UDS routine over the diagnostic CAN**, and the MCU relays those bytes to the bus. The only frame the TBox emits on its own is a network-management **wake frame**. The MCU defines a **remote CAN-message descriptor** carrying //which bus//, //data source//, a **"requires HV on"** flag and a **repeat-count + cycle-time** — i.e. the Linux side can ask the MCU to send a parameterised, repeated CAN message gated on vehicle power. Recognised **wake sources** include an **RTC timer**, the charge signal, CAN activity, the modem RING line, USB and ACC — so the TBox can **wake itself on a schedule** with the car parked. **What that means for reviving preconditioning:** you cannot ride the original cloud (see below), so the practical path is **local** — with root on the TBox, invoke its own remote-control routine directly, or replay the UDS command from your own CAN node. ===== The on-board CAN database ===== The TBox filesystem carries the vehicle's **CAN database (DBC)** — the message IDs, bit positions, scaling and value tables for the whole car (VCU, BMS, OBC, BCM, DCDC, ESP, MCU, TBOX…). It is the decoder ring behind the [[:cansignals|signal list]] and the practical key to reading or reproducing any vehicle signal, including pack voltage/SoC, TPMS, and the door/lock/defrost and A/C remote-control frames relevant to preconditioning. ===== The TBox ↔ MCU interface (SCOM) ===== The Linux side talks to the S32K144 MCU over an internal **SCOM** (serial-comms) request/response protocol (''scom_tl_proc_con_req/res'', ''data_req'', ''data_ok/ng_res''). On top of that transport it issues a set of get/set operations. What can be identified from the firmware: ^ Operation ^ Dir ^ Parameter ^ Purpose ^ | ''get_mcu_sw'' / read mcu version | get | — | S32K MCU firmware version | | ''get_mcu_upg_ver'' | get | — | MCU bootloader / upgrade version | | ''ReadBigVersion'' / ''Get_BigVersionInfo'' | get | — | multi-ECU "big version" block | | ''get_pow_voltage'' | get | — | 12 V supply voltage | | ''get_power_state'' | get | — | power / ignition state (ACC / IGN / sleep) | | ''get mcu rtc time'' | get | — | MCU real-time-clock | | ''get_gps_ant'' | get | — | GPS antenna status (open / short / OK) | | ''get_gps_module'' | get | — | GPS module status | | ''NMTBOX_WakeSource'' | get | — | what woke the TBox (RTC / charge / CAN / modem RING / USB / ACC) | | ''get mcu cfg'' | get | cfg id | read a persistent config item by id | | ''get_signal_from_name'' / ''get_signal_value'' | get | signal name | read **any** vehicle CAN signal from the on-board DBC (value + unit + ECU + last value) | | ''setrtc'' | set | time | set the MCU RTC | | ''set_power_state'' | set | state | set power state | | ''set_NM_wakeUp'' | set | wake spec | arm a network-management wake (schedule a future self-wake while parked) | | ''set_signal_flag'' | set | signal | flag a signal for sending | | ''cfg_set_by_id'' / ''scom_mcu_cfg_sync'' | set | cfg id + value | set / sync a persistent config item by id | | ''canMsg_remote'' | set | MsgID + 8 data bytes (+ bus, repeat-count, cycle-time, requires-HV flag) | send a parameterised CAN frame onto the vehicle bus — the remote-control / preconditioning path | | ''WriteBigVersion'' / ''Set_BigVersionInfo'' | set | version block | write the "big version" block — **security-gated** (UDS Security Access) | Persistent config items (''cfg_*'', get/set by id) seen so far: ''CFG_ITEM_ACOTA_VIN'' (VIN), ''CFG_ITEM_ECALL_MODE_TYPE'', ''CFG_ITEM_ECALL_VEH_TYPE''. //These are the operations identifiable from firmware strings; the SCOM protocol's exact message IDs and full parameter encodings are not fully reverse-engineered, so treat this as a working map, not a complete spec. The ''get_signal_from_name'' side resolves against the on-board CAN database (BCM_*, BMS_*, ABM_*, AC_*, VCU_*, …), which holds the full signal list — far more than can be tabled here.// ===== The OEM cloud is dead ===== The consumer-telematics backend is gone: the cloud server does not respond and its ports are closed, and the EU authentication endpoints point at **torn-down load-balancers**. (The separate //dealer-diagnostic// backend is still alive — the consumer cloud was shut down when the EU operation folded, which is why the app and connected features died.) Reviving remote features therefore means working **locally** on the TBox, or ultimately **replacing the backend** — non-trivial because the TBox validates the server with a client certificate and a server-certificate check. Root on the TBox is the lever to redirect or bypass that. ===== Why the TBox matters to this project ===== * It is the **cellular uplink** and the **OEM cloud endpoint** — with the OEM servers dead, this is what a self-hosted backend would need to impersonate or replace. Its **Deutsche Telekom MFF2 SIM is swappable** (by desoldering) to your own data plan (see [[:connectivity]], [[:roadmap]]). * It is the **FOTA relay** that flashes the head-unit MCU (''MCU.bin'') — so a firmware dump might be reachable from here, though updates are delta patches (see [[:hardware:mainboard#mcu_renesas_rl78_r5f10ppjl|the MCU section]]). * It has an **independent CAN tap** and its **own S32K144 MCU** — a second, always-on foothold on the vehicle bus, separate from the head unit.