Bauteilbezogener Teardown der T-Box (Telematics Box, die Telematikeinheit) des Aiways U5 — des dauerhaft aktiven Mobilfunk-Gateways. Sie beherbergt die SIM, hängt als Endpunkt am Fahrzeug-CAN und war die Gegenstelle der OEM-Cloud: Sie ist der FOTA-Vermittler, der MCU-/System-Updates an die Head-Unit weiterreicht (getTBoxInfo = 192.168.1.1:50000, siehe Konnektivität). Beschriftung der Platine: XT7018L PA.2, IN060000P0, datiert 2019.09.09.

⚠ Die Chip-Bezeichnungen unten sind von den Fotos abgelesen. Die Sicherheit der Zuordnung ist pro Bauteil angegeben — mehrere Aufdrucke sind hausintern kodiert (Adayo-H2…-Nummern) oder ließen sich nicht vollständig auflösen; das ist dann gekennzeichnet und nicht geraten.

Vorderseite	Rückseite

Vorderseite: das Quectel-LTE-Modul (oben, unter dem Schirmblech mit QR-Code) mit drei HF-Schirmkappen mit der Beschriftung MAIN ANTENNA / WIFI-1 / WIFI-2, daneben das nFore-WiFi/Bluetooth-Modul und der Micron-Speicher, sowie am rechten Rand eine Reihe FAKRA-Antennenbuchsen und der weiße Hauptkabelbaumstecker. Rückseite: der NXP S32K144 MCU (großes QFP, unten Mitte) und der CAN-Transceiver.

LTE-Cat-4-Automotive-Modul, Quectel AG35 — Schirmblech beschriftet mit R-C-QUT-AG35-E, FCC ID: XMR201907AG35E (XMR = Quectels FCC-Grantee-Code), SN: P1A20LA19000906. Die IMEI: (entfernt — für jedes Fahrzeug einmalig) dieses Exemplars ist auf die Kappe gedruckt. Das ist der Uplink der Box; ihr Mobilfunkvertrag kommt von der aufgelöteten SIM darunter (siehe Konnektivität). Hohe Sicherheit.

Dieses Modul ist mehr als ein Funkmodul. Sein Chipsatz vereint das Mobilfunk-Basisband mit einem vollwertigen Applikationsprozessor, auf dem ein Embedded-Linux läuft — dieser Chip ist also der Bordrechner der T-Box, nicht bloß ihr Modem. Die Software-Analyse bestätigt: Die Telematikanwendung (der Cloud-Client, der OTA-Agent und die eCall-Logik) läuft hier, unter Linux. Diese Linux-Seite hat keine eigene CAN-Verbindung — was danach passiert, steht beim MCU weiter unten.

Die SIM — eine fest aufgelötete MFF2-Embedded-SIM (M2M-Bauform; darum sieht sie aus wie ein IC und nicht wie eine Karte). Netzbetreiber: Deutsche Telekom, nach dem Auslöten bestätigt. Aufdruck: H2021875 (Charge) / ICCID (entfernt — ICCID der SIM) / THA.

Weil es ein aufgelötetes MFF2-Bauteil ist, heißt Netzbetreiberwechsel: auslöten (wie hier gemacht) und eine andere SIM einsetzen — direkt relevant, wenn du den Mobilfunk-Uplink des Autos auf deinen eigenen Datentarif umstellen willst, sobald der OEM-Vertrag ausläuft (siehe Roadmap, Konnektivität). Hohe Sicherheit (physisch bestätigt).

Der eigene Mikrocontroller der T-Box — NXP S32K144 (FS32K144HFVLL / 0N57U / QGU2034AC), 100-poliges LQFP. Automotive-Arm Cortex-M4F, ~512 KB Flash. Hohe Sicherheit (klarer Aufdruck + NXP-Logo).

Seine Rolle ist enger als sie aussieht, aber wichtig: Er ist der einzige Weg von der Linux-Seite zum Fahrzeug-CAN-Bus. Die Telematik-Software (oben) erreicht ihn über eine serielle Verbindung und übergibt ihm einfache Befehle; verdrahtet mit dem CAN-Transceiver unten ist allein der MCU, und er allein würde etwas auf den Fahrzeugbus legen. Zwischen dem Universalrechner und dem lebenden CAN-Bus steht also immer ein eigener Mikrocontroller — dasselbe Muster wie bei der Head-Unit mit ihrem RL78 MCU (siehe Architektur).

Diese „serielle Verbindung“ ist konkret SPI — /dev/spidev5.0 mit 4,8 MHz — die der Treiber nach oben hin als SocketCAN-Gerät darstellt (can1, 500 kbit/s; die rohen Kanäle sind /dev/spichn_0/_1). Linux scheint also eine Netzwerkschnittstelle can1 zu haben, aber das ist kein nativer, ans Auto verdrahteter CAN-Controller — es ist diese SPI-Verbindung zum MCU. Ein häufiges Missverständnis: die T-Box erreiche CAN über drei getrennte Schnittstellen (SPI, can1 und einen UART). Tatsächlich sind SPI und can1 zwei Schichten desselben, vom MCU bewachten Pfades, und der UART ttyHS0 trägt MCU-Steuerung/FOTA, nicht CAN.

NXP TJA1042 High-Speed-CAN-Transceiver (TJA1042 / NXP), SO-8. Das ist der physische Abgriff der T-Box an einem Fahrzeug-CAN-Bus — ein vom MCU der Head-Unit unabhängiger CAN-Pfad. Hohe Sicherheit. (Einen zweiten Weg zu denselben Daten dokumentiert CAN-Bus-Zugriff von der Head-Unit-Seite aus.)

TI TLV320AIC3104 Low-Power-Audio-Codec (Aufdruck AC3104 / TI / AV5Y), QFN. In einer T-Box dient ein Codec fast immer dem Sprachpfad des Notrufs (eCall) — Mikrofon + Lautsprecher für einen automatischen Notruf an die 112. Das Bauteil ist mit hoher Sicherheit gelesen; der eCall-Zweck ist ein Rückschluss.

Ein geschirmtes HF-Modul (Blechkappe, im selben Stil wie das Schirmblech des AG35) mit der Beschriftung nFore NF3304 201706, direkt neben dem Micron-Speicher. Das eigentliche Geschäft von nFore Technology sind WiFi-/Bluetooth-Combo-Module für Automotive, und die Software bestätigt genau das: Sowohl die Head-Unit als auch die Anwendung der T-Box selbst bauen auf nFores Bluetooth-Car-Kit-SDK auf (Freisprechen, Musik-Streaming, Kontaktsynchronisation), und die Bluetooth-Konfiguration der T-Box nennt als darunterliegendes Basisband einen Broadcom BCM4339 (einen WiFi- + Bluetooth-4.0/BLE-Combo-Chip), angebunden über einen UART — nFore verpackt diesen Chip höchstwahrscheinlich unter dieser Teilenummer in ihr eigenes automotive-qualifiziertes Modul. Hohe Sicherheit (Funktion per Software bestätigt; der genaue Die im Modul ist ein Rückschluss).

Der Bluetooth-Stack wird von keinem Hintergrunddienst gestartet — die Software der T-Box bringt ihn offenbar nur bei Bedarf hoch. Ein Funktionsname fiel bei der Analyse auf: ein BLE-basiertes Remote-Wake (Fernaufwecken) — das legt nahe, dass Bluetooth hier als lokaler Auslösepfad gedacht ist und nicht nur zum Koppeln von Telefonen. Relevant für jede künftige Begleit-Hardware in der Nähe des Autos (siehe Roadmap).

Micron-FBGA-Chip (Micron-„M“-Logo) mit dem Aufdruck ORAID JWD13, neben dem nFore-Modul — der Arbeitsspeicher, also DRAM oder Flash. Für den FBGA-Code (ORAID) bräuchte man Microns Teilenummern-Decoder, um Typ und Dichte genau aufzulösen; die Kapazität ist also unbestätigt. Hersteller mit hoher, genaues Bauteil mit geringer Sicherheit.

Exar/Sipex SP3232E 3-V-RS-232-Transceiver (SiPEX 3232E 1930L), TSSOP — setzt einen UART auf RS-232-Pegel um, typischerweise eine serielle Diagnose-/Debug-Schnittstelle. Hohe Sicherheit.

Buck-Boost-DC-DC	NXP Power/RTC

• TI TPS63020 Buck-Boost-Wandler (PS63020 / TI) — erzeugt eine stabile Versorgungsschiene aus einer Batteriespannung, die einbrechen oder überschießen kann. Hohe Sicherheit.
• NXP PF85163 (PF85163 / NXP), SO-8 — ein NXP-Bauteil aus der Power-/RTC-Klasse; genaues Bauteil nicht bestätigt. Geringe Sicherheit.
• H2002235 (QFN) ist eine hausintern kodierte Adayo-Teilenummer, keine echte Silizium-Beschriftung — wahrscheinlich ein Lastschalter, eine Schutzschaltung, ein kleiner PMIC oder ein PHY, aber allein aus dem Aufdruck nicht identifizierbar. Am 12-V-Eingang sitzt außerdem eine Transientenschutzdiode MCC SMBS36A.

Die HF-Signale sind auf FAKRA-Koaxbuchsen (farbcodiert) herausgeführt, dazu die internen Schirmkappen MAIN ANTENNA, WIFI-1, WIFI-2 — also Mobilfunk-Haupt-/Diversity-Antenne + GNSS + Wi-Fi. Der weiße Stecker am rechten Rand ist der Fahrzeug-Kabelbaum (Spannungsversorgung, Zündung, CAN, Audio für eCall). Die genaue Pinbelegung ist noch nicht ermittelt.

Auf dem Applikationsprozessor des Quectel AG35 läuft ein Embedded-Linux (der Standard-Build des Herstellers). Die Telematikanwendung — der OEM-Cloud-Client, der OTA-/FOTA-Agent, die eCall-/bCall-Logik (Notruf und Pannenruf) und der Baukasten für CAN-Befehle — ist ein einziges Userspace-Programm auf diesem Linux. Der dauerhaft aktive S32K144 MCU ist der einzige Teil, der am Fahrzeug-CAN verdrahtet ist; die Linux-Seite erreicht ihn über eine interne serielle Verbindung und übergibt ihm Befehle. Weil es ein gewöhnliches Linux-System ist, lässt es sich vollständig untersuchen — und ist, wie sich zeigt, sperrangelweit offen.

Es gibt mehrere unabhängige Wege, von voll remote (über die interne USB-Verbindung des Autos) bis hin zum Zugriff auf der Werkbank. Keiner braucht einen Exploit — die Türen stehen schon offen. Root heißt hier Root auf dem Telematikrechner; der Fahrzeug-CAN sitzt weiterhin hinter dem MCU.

Von der Head-Unit aus, die auf der usb0-Verbindung unter 192.168.1.50 liegt und die T-Box unter 192.168.1.1 erreicht:

• FTP (Port 21) — voller Root-Zugriff, lesend und schreibend. Die Startskripte der T-Box selbst starten einen busybox-FTP-Daemon als root, mit Schreibrechten und mit Wurzel auf /. Ein Login mit dem Standardkonto des Herstellers (root / oelinux123) gibt Lese- und Schreibzugriff auf das gesamte Dateisystem — ohne jede Privilegien-Eskalation. Das ist der mit Abstand nützlichste Einstiegspunkt, und so werden Firmware, Konfiguration und Logs gelesen.
• Eine Einschränkung: Dieser FTP-Daemon weigert sich, Gerätedateien zu schreiben (nur reguläre Dateien) — er kann den AT-Kanal des Modems also nicht direkt ansprechen, aber Skripte und Konfigurationsdateien frei bearbeiten, und das reicht, um Codeausführung bei einem späteren Boot einzurichten.
• Die weiteren offenen Ports auf dieser Verbindung sind 50000 (das Telefonie-/eCall-Protokoll, siehe Konnektivität) und 53 (DNS/DHCP der T-Box selbst).

Zwei Änderungen brauchen nur einen Schreibzugriff auf eine Konfigurationsdatei über den FTP-Root — keine Codeausführung — und greifen beim nächsten Kaltstart:

• ADB zum USB-Gadget hinzufügen. Die Liste der USB-Schnittstellen, die die T-Box anbietet, wird aus einer einfachen Textdatei gelesen; trägt man dort adb ein, wird der (bereits vorhandene) adbd für die Head-Unit als USB-Host sichtbar.
• Den eingebauten Wi-Fi-AP hochfahren. Die Mobile-AP-Konfiguration schaltet Wi-Fi und den Access Point beim Booten mit zwei Flags ab; aktiviert man beide, kommt der vorkonfigurierte AP hoch, und danach ist FTP (und alles andere) direkt über Wi-Fi erreichbar, ohne Umweg über die Head-Unit.

• Serielle Konsole (UART) — garantiert Root. Der Debug-UART der Platine ist so konfiguriert, dass er Root auf der seriellen Konsole erlaubt; ein 3,3-V-UART-Adapter gibt dir also eine Root-Shell ganz ohne Netzwerk — der saubere Weg zum ersten Root auf einem ausgebauten Gerät.
• ADB über USB, sobald es wie oben aktiviert ist.

Wichtig — Kaltstart vs. Deep Sleep. Der MCU unterscheidet einen Deep Sleep (Suspend-to-RAM: Linux bleibt geladen, Konfigurationsdateien werden nicht neu gelesen) von einem echten Power-off (einem Kaltstart, bei dem die Konfiguration doch neu gelesen wird). Konfigurationsänderungen greifen erst nach einem echten Kaltstart. Erzwinge den nicht mit dem Shutdown-Befehl des Moduls — der schaltet nur das Modem ab, ohne Garantie, dass es von selbst wiederkommt, und eine tote T-Box heißt kein eCall und keine Telematik, ohne OEM-Support zur Rettung. Nimm die Änderung vor und warte auf ein natürliches Power-off. (Es gibt auch einen vom Fahrer auslösbaren Neustart: 4× die Nebelschlussleuchte zu schalten startet die T-Box beobachtbar neu — das Kombiinstrument zeigt kurz „Kein Netz“. Ob dieser Neustart ein vollständiger Kaltstart ist, der die Konfiguration neu liest, oder nur ein Warmstart, ist unbestätigt.)

Die Telematikanwendung enthält die Maschinerie für Fernsteuerung: Routinen, um Vorbedingungen zu prüfen, den MCU zu wecken und den Fernsteuerungszustand für Klimaanlage, Heckscheibenheizung und Türverriegelung zu setzen. Das eine durchgängig nachvollzogene Feature ist eine Batterie-Vorheizung während der Fahrt (den Akku vor einem Schnellladestopp aufwärmen):

• Der Auslöser ist ausschließlich die Cloud. Er hängt an einem Kommandofeld, das die (tote) Cloud liefert; im Code gibt es keinen lokalen Auslöser.
• Vorprüfung: HV-System an, DC-DC im Leerlauf, On-Board-Charger im Leerlauf, SoC > 10 %, Batterie-Mindesttemperatur < 15 °C, Restreichweite > 20 km — klassische „überspringen, wenn schon geladen, schon warm oder fast leer“-Logik.
• Wie der Befehl ins Auto kommt: Die T-Box schickt eine per Security Access geschützte UDS-Routine über den Diagnose-CAN, und der MCU gibt diese Bytes auf den Bus weiter. Der einzige Frame, den die T-Box selbst aussendet, ist ein Netzwerkmanagement-Wake-Frame.

Der MCU definiert einen Deskriptor für Remote-CAN-Botschaften, der welcher Bus, Datenquelle, ein Flag „HV muss an sein“ und einen Wiederholungszähler + eine Zykluszeit trägt — die Linux-Seite kann den MCU also bitten, eine parametrierte, wiederholte CAN-Botschaft zu senden, abhängig vom Powerzustand des Fahrzeugs. Zu den erkannten Aufwachquellen gehören ein RTC-Timer, das Ladesignal, CAN-Aktivität, die RING-Leitung des Modems, USB und ACC — die T-Box kann sich also bei geparktem Auto selbst nach Zeitplan aufwecken.

Was das für die Wiederbelebung der Vorkonditionierung heißt: Auf der ursprünglichen Cloud kannst du nicht mitfahren (siehe unten), der praktikable Weg ist also lokal — mit Root auf der T-Box ihre eigene Fernsteuerungsroutine direkt aufrufen, oder den UDS-Befehl von deinem eigenen CAN-Knoten aus nachspielen.

Im Dateisystem der T-Box liegt die CAN-Datenbank (DBC) des Fahrzeugs — die Botschafts-IDs, Bitpositionen, Skalierungen und Wertetabellen für das ganze Auto (VCU, BMS, OBC, BCM, DCDC, ESP, MCU, TBOX…). Sie ist der Dekodierschlüssel hinter der Signalliste und der praktische Schlüssel dazu, jedes Fahrzeugsignal zu lesen oder nachzubilden — Paketspannung/SoC, TPMS und die für die Vorkonditionierung relevanten Frames für Tür/Verriegelung, Heckscheibenheizung und Klimaanlage inklusive.

Die Linux-Seite spricht mit dem S32K144 MCU über ein internes SCOM-Protokoll (serial comms) mit Request/Response (scom_tl_proc_con_req/res, data_req, data_ok/ng_res). Auf diesem Transport setzt sie eine Reihe von get/set-Operationen ab. Was sich aus der Firmware identifizieren lässt:

Bisher gesehene persistente Konfigurationselemente (cfg_*, get/set per ID): CFG_ITEM_ACOTA_VIN (VIN), CFG_ITEM_ECALL_MODE_TYPE, CFG_ITEM_ECALL_VEH_TYPE.

Das sind die Operationen, die sich aus Firmware-Strings identifizieren lassen; die genauen Message-IDs des SCOM-Protokolls und die vollständigen Parameter-Kodierungen sind nicht vollständig reverse-engineert, also nimm das als Arbeitskarte und nicht als vollständige Spezifikation. get_signal_from_name löst gegen die CAN-Datenbank an Bord auf (BCM_*, BMS_*, ABM_*, AC_*, VCU_*, …), die die vollständige Signalliste enthält — weit mehr, als hier in eine Tabelle passt.

Das Endkunden-Telematik-Backend ist weg: Der Cloud-Server antwortet nicht und seine Ports sind zu, und die EU-Authentifizierungs-Endpunkte zeigen auf abgebaute Load-Balancer. (Das separate Händler-Diagnose-Backend lebt noch — die Endkunden-Cloud wurde abgeschaltet, als das Europageschäft abgewickelt wurde, und darum sind App und Connected-Funktionen gestorben.) Ferngesteuerte Funktionen wiederzubeleben heißt daher: lokal auf der T-Box arbeiten oder letztlich das Backend ersetzen — nicht trivial, weil die T-Box sich beim Server mit einem Client-Zertifikat ausweist und das Server-Zertifikat prüft. Root auf der T-Box ist der Hebel, um das umzuleiten oder zu umgehen.

• Sie ist der Mobilfunk-Uplink und der Endpunkt der OEM-Cloud — da die OEM-Server tot sind, ist sie genau das, was ein selbst gehostetes Backend nachbilden oder ersetzen müsste. Ihre MFF2-SIM der Deutschen Telekom ist tauschbar (durch Auslöten) gegen deinen eigenen Datentarif (siehe Konnektivität, Roadmap).
• Sie ist der FOTA-Vermittler, der den MCU der Head-Unit flasht (MCU.bin) — ein Firmware-Dump wäre von hier aus also vielleicht erreichbar, auch wenn Updates Delta-Patches sind (siehe den MCU-Abschnitt).
• Sie hat einen unabhängigen CAN-Abgriff und ihren eigenen S32K144 MCU — ein zweites, dauerhaft aktives Standbein am Fahrzeugbus, getrennt von der Head-Unit.