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.

Front	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.

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.

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).

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 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.

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 CAN bus access documents from the head-unit side.)

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.

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).

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.

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.

Buck-boost DC-DC	NXP power/RTC

• 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.

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.

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.

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.

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).

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.

• 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.)

Although the printed manuals say the car has no remote climate, the capability is present in the TBox firmware — it was simply orchestrated by the OEM cloud, which is now gone.

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, which is why it no longer works.
• Pre-checks before it acts: 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: not an ordinary broadcast frame — 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 side confirms the mechanism: it 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 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 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 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:

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 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.

• 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 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.