Differences

This shows you the differences between two versions of the page.

--- hardware:tbox [2026/08/10 01:14] – external edit 127.0.0.1
+++ hardware:tbox [2026/08/12 13:37] (current) – [Remote preconditioning is in the firmware] steini
@@ Line 18: / Line 18: @@
 Front: the Quectel LTE module (top, under the QR-coded shield) with three RF cans labelled
-**MAIN ANTENNA / WIFI-1 / WIFI-2**, the nFore gateway chip and Micron memory beside it, and a row of
+**MAIN ANTENNA / WIFI-1 / WIFI-2**, the nFore WiFi/Bluetooth module and Micron memory beside it, and a
-**FAKRA** antenna jacks plus the white main harness connector down the right edge. Back: the NXP
+row of **FAKRA** antenna jacks plus the white main harness connector down the right edge. Back: the
-S32K144 MCU (large QFP, lower centre) and the CAN transceiver.
+NXP S32K144 MCU (large QFP, lower centre) and the CAN transceiver.
 ===== Cellular modem — Quectel AG35 =====
@@ Line 63: / Line 63: @@
 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 =====
@@ Line 81: / Line 89: @@
 automated 112/emergency call. //Part read is high confidence; the eCall purpose is an inference.//
-===== Gateway/comms processor — nFore NF3304 =====
+===== WiFi / Bluetooth module — nFore NF3304 =====
 {{:tbox_nfore.png?420|nFore NF3304}}
-Large QFP marked **''nFore NF3304 201706''**, sitting next to the Micron memory. nFore Technology
+A **shielded RF module** (metal-can lid, the same style as the AG35's own shield) marked
-makes networking / gateway silicon, so this is **likely the communications/gateway processor**
+**''nFore NF3304 201706''**, sitting next to the Micron memory. nFore Technology's actual business is
-(handling the link between the modem, CAN and the host) — but **the exact function of NF3304 is not
+**automotive WiFi/Bluetooth combo modules**, and software confirms this is exactly that: both the
-confirmed**. //Marking is legible; role is an educated guess.//
+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 =====
@@ Line 94: / Line 111: @@
 {{:tbox_ram.png?400|Micron memory (FBGA ORAID JWD13)}}
-Micron FBGA chip (Micron "M" logo) marked ''ORAID JWD13'', beside the nFore processor — its working
+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.//
@@ Line 120: / Line 137: @@
 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 =====