====== T-Box-Teardown ====== 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 [[:de:connectivity|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. ===== Platinenübersicht ===== ^ Vorderseite ^ Rückseite ^ | {{:tbox_front.png?330|T-Box, Bestückungsseite}} | {{:tbox_back.png?330|T-Box, Lötseite}} | 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. ===== Mobilfunkmodem — Quectel AG35 ===== {{:tbox_modem.png?440|Quectel AG35 LTE-Modul}} **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 [[:de:connectivity|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. ===== SIM — Deutsche Telekom (aufgelötete MFF2) ===== {{:tbox_sim.png?400|MFF2 eingebettete SIM}} 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 [[:de:roadmap|Roadmap]], [[:de:connectivity|Konnektivität]]). //Hohe Sicherheit (physisch bestätigt).// ===== Haupt-MCU — NXP S32K144 ===== {{:tbox_mcu.png?420|NXP S32K144}} 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 [[de:hardware:mainboard#mcu_renesas_rl78_r5f10ppjl|RL78 MCU]] (siehe [[:de:architecture|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. ===== CAN-Transceiver — NXP TJA1042 ===== {{:tbox_can.png?400|NXP TJA1042 CAN-Transceiver}} 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 [[:de:canbus|CAN-Bus-Zugriff]] von der Head-Unit-Seite aus.)// ===== eCall-Audio-Codec — TI TLV320AIC3104 ===== {{:tbox_codec.png?400|TI TLV320AIC3104}} 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.// ===== WiFi-/Bluetooth-Modul — nFore NF3304 ===== {{:tbox_nfore.png?420|nFore NF3304}} 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 [[:de:roadmap|Roadmap]]). ===== Speicher — Micron ===== {{:tbox_ram.png?400|Micron Speicher (FBGA ORAID JWD13)}} 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.// ===== Serieller Transceiver — Sipex SP3232E ===== {{:tbox_rs232.png?380|Sipex SP3232E RS-232-Transceiver}} 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.// ===== Spannungsversorgung ===== ^ Buck-Boost-DC-DC ^ NXP Power/RTC ^ | {{:tbox_dcdc.png?280|TI TPS63020}} | {{:tbox_pmic.png?280|NXP PF85163}} | * **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**. ===== Antennen & Stecker ===== 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. ===== Betriebssystem & Software ===== 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**. ===== So bekommst du eine Root-Shell ===== 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. ==== Remote, über die USB-Verbindung (ohne Demontage) ==== 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 [[:de:connectivity|Konnektivität]]) und **53** (DNS/DHCP der T-Box selbst). ==== Dauerhafte Zugänge, die eine einzige Konfigurationsänderung öffnet ==== 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. ==== Zugriff auf der Werkbank / physischer Zugriff ==== * **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**.)// ===== Fern-Vorkonditionierung steckt in der Firmware ===== 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. ===== Die CAN-Datenbank an Bord ===== 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 [[:de:cansignals|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 Schnittstelle T-Box ↔ MCU (SCOM) ===== 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: ^ Operation ^ Richtung ^ Parameter ^ Zweck ^ | ''get_mcu_sw'' / read mcu version | get | — | Firmware-Version des S32K-MCU | | ''get_mcu_upg_ver'' | get | — | Bootloader-/Upgrade-Version des MCU | | ''ReadBigVersion'' / ''Get_BigVersionInfo'' | get | — | „big version“-Block über mehrere ECUs | | ''get_pow_voltage'' | get | — | 12-V-Versorgungsspannung | | ''get_power_state'' | get | — | Power-/Zündungszustand (ACC / IGN / sleep) | | ''get mcu rtc time'' | get | — | Echtzeituhr des MCU | | ''get_gps_ant'' | get | — | Status der GPS-Antenne (open / short / OK) | | ''get_gps_module'' | get | — | Status des GPS-Moduls | | ''NMTBOX_WakeSource'' | get | — | was die T-Box geweckt hat (RTC / charge / CAN / modem RING / USB / ACC) | | ''get mcu cfg'' | get | cfg id | ein persistentes Konfigurationselement per ID lesen | | ''get_signal_from_name'' / ''get_signal_value'' | get | Signalname | **jedes** Fahrzeug-CAN-Signal aus der DBC an Bord lesen (Wert + Einheit + ECU + letzter Wert) | | ''setrtc'' | set | Zeit | die RTC des MCU stellen | | ''set_power_state'' | set | Zustand | Powerzustand setzen | | ''set_NM_wakeUp'' | set | Wake-Spezifikation | einen Netzwerkmanagement-Wake scharfschalten (künftiges Selbstaufwecken im geparkten Zustand planen) | | ''set_signal_flag'' | set | Signal | ein Signal zum Senden markieren | | ''cfg_set_by_id'' / ''scom_mcu_cfg_sync'' | set | cfg id + Wert | ein persistentes Konfigurationselement per ID setzen/synchronisieren | | ''canMsg_remote'' | set | MsgID + 8 Datenbytes (+ Bus, Wiederholungszähler, Zykluszeit, Requires-HV-Flag) | einen parametrierten CAN-Frame auf den Fahrzeugbus senden — der Pfad für Fernsteuerung/Vorkonditionierung | | ''WriteBigVersion'' / ''Set_BigVersionInfo'' | set | Versionsblock | den „big version“-Block schreiben — **per Security Access geschützt** (UDS Security Access) | 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.// ===== Die OEM-Cloud ist tot ===== 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. ===== Warum die T-Box für dieses Projekt zentral ist ===== * 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 [[:de:connectivity|Konnektivität]], [[:de:roadmap|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 [[:de:hardware:mainboard#mcu_renesas_rl78_r5f10ppjl|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.