Firmware-Research Unu Pro

[Zanooda]

Moin,

da ich (wie einige andere hier auch) nur noch eine Keycard für meinen Unu Pro 4kW habe und befürchten musste, bald einen teuren Klumpen Elektroschrott rumstehen zu haben, habe ich mich auf die Suche nach Möglichkeiten begeben, eigene Keycards zu erstellen.
Weil die Karten vom Typ "Mifare DESFire" sind und man sie ohne den Master Key nicht kopieren kann, hatte ich die Hoffnung, eventuell aus der Unu-Hardware etwas schlauer zu werden. Also habe ich mir kurzerhand bei Kleinanzeigen eine DBC-/MDB-Kombo gekauft und aufgeschraubt.

Spoiler: Ich bin jetzt in der Lage, den Roller ohne Keycards und ohne App zu starten und wieder zu verriegeln.

Ich möchte nun hier meine bisherigen Erkenntnisse präsentieren und dazu aufrufen, bei weiteren Experimenten zu unterstützen. Achtung, es wird technisch.

Hardware
Beide Module haben zugängliche UART-Kontakte, auf die sich Stiftleisten auflöten lassen. Die Baudrate ist 115200.
Auf jedem der beiden Module befindet sich ein Female USB Mini-B Anschluss, sie sind mit einem Mini-B auf Mini-B - Kabel miteinander verbunden.

DBC (Dashboard Computer)
- i.MX6 32bit ARM Cortex A9, 800 MHz
- 1GB RAM
- 8GB eMMC

Zusätzlich befindet sich auf der Platine ein NXP PN7150 NFC-Reader. Dieser ist via i2c mit dem MDB verbunden, nicht mit dem DBC - obwohl sie sich eine Platine teilen.

MDB (Main Driver Board)
- i.MX6 32bit ARM Cortex A7, 696 MHz
- 512MB RAM
- 8GB eMMC
- SIMCom SIM7100E LTE-Modem + GPS-Receiver Kombimodul
- Aufgelötete SIM-Karte (vmtl. im MFF2-Format, habe eigene SIM-Karten bestellt und werde einen Tauschversuch unternehmen, um den Roller wieder online und in mein privates VPN zu bekommen)

Software
DBC
- U-Boot 2017.03
- "scooterOS v1.13.0": OSTree-basiertes Linux
- Kernel: Linux dbc-3783732812 5.4.24-2.0.0+g8115d570b280 #1 SMP PREEMPT Tue Sep 21 14:56:23 UTC 2021 armv7l GNU/Linux

3 Unu-spezifische Dienste:
- unu-backlight
- unu-dashboard-ui
- unu_alpha

"unu-backlight" ist ein einfaches Shell-Skript, welches via "cat /sys/bus/iio/devices/iio:device0/in_illuminance_input" den Helligkeitssensor abfragt und entsprechend einen von 3 Helligkeitswerten in "/sys/class/backlight/backlight/brightness" setzt.

"unu-dashboard-ui" ist eine Qt-Applikation und enthält das Tacho-UI.

MDB
- U-Boot 2017.03
- "scooterOS v1.13.0": OSTree-basiertes Linux
- Kernel: Linux mdb-4378251754 5.4.24-2.0.0+g8115d570b280 #1 SMP PREEMPT Tue Sep 21 14:56:23 UTC 2021 armv7l GNU/Linux
- Python 3.8.13 vorinstalliert

Auf dem MDB laufen 12 Unu-spezifische Dienste:
- unu-activation
- unu-battery
- unu-bluetooth
- unu-engine-ecu
- unu-keycard
- unu-modem
- unu-netconfig
- unu-ota-update
- unu-pm
- unu-sam
- unu-uplink
- unu-vehicle

Zusätzlich läuft eine Redis-Instanz, die als zentraler Kommunikationspunkt zwischen den Diensten fungiert.
Bisher habe ich herausgefunden, dass "unu-keycard" den NFC-Reader im Tacho ansteuert und die Kartenvalidierung durchführt. Im Anschluss wird in Redis vermerkt, dass eine erfolgreiche Kartenvalidierung stattgefunden hat - woraufhin "unu-vehicle" den Roller entsperrt.

An dieser Stelle habe ich erfolgreich eingehakt: Wenn man entsprechende Werte händisch in Redis published, startet der Roller.

Ich möchte nun versuchen, den "unu-keycard"-Service komplett zu deaktivieren und den NFC-Reader mit einem eigenen Stück Software anzusteuern. Hier fehlt mir bisher noch das hinreichende Wissen über NFC - ich bin dran.
Denkbar wäre auch, den eingebauten Card Reader stillzulegen und ein eigenes Entsperrmodul via i2c anzubinden: Schlüssel, Keycard... Wer Langeweile hat, könnte sich sicherlich auch eine Sprachaktivierung basteln

Ähnliches lässt sich ggf. auch für den Bluetooth-Part umsetzen.

Sonstiges
- DBC und MDB spannen über das "USB Ethernet Gadget"-Kernelmodul ein LAN auf. Die IPs sind hardcoded: MDB hat 192.168.7.1, DBC die 192.168.7.2.

- Im DBC ist der SSH-Pubkey des root-Users vom MDB hinterlegt.

- Das Navigationsfeature scheint zumindest in Teilen schon implementiert gewesen zu sein. Per binwalk aus dem "unu-dashbord-ui"-Binary extrahierte Bilder enthalten typische Navi-Piktogramme.

- DBC und MDB kennen ihre jeweiligen Seriennummern. Ich vermute (Versuch ist noch ausstehend), dass man durch Anpassung der Seriennummern in den entsprechenden SQLite-Datenbanken sowie durch Hinterlegen des SSH Public Key des MDB im DBC auch "fremde" Kombinationen aus DBC und MDB nutzen kann.

- Der Roller versucht durchgehend, eine Mobilfunkverbindung aufzubauen und Telemetrie zu Unu zu senden. Ich schätze, dass sich der Standby-Batterieverbrauch deutlich reduzieren lässt, wenn man die dazugehörigen Dienste deaktiviert.

- Bremshebel und Blinkerschalter verursachen Input-Events im MDB-Kernel. Die Lampen von Blinker und Bremslicht werden (sofern ich das richtig verstanden habe) per PWM angesteuert.

- Die Kernel-Konfiguration ist unter /proc/config.gz abrufbar.

"But can it run DOOM?"
Vermutlich! Ich werde das mal in einem Moment der Langeweile ausprobieren

An dieser Stelle möchte ich gerne jeden, der sich in der Lage sieht, was zu den Recherchen beizutragen, das zu tun. Egal ob Elektronik-Experte oder Entwickler-Guru - ich freue mich über reges Mitwirken!
Ich hänge momentan im Discord rum, den jemand freundlicherweise für die Community erstellt hat und der bereits im Insolvenz-Thread verlinkt wurde: https://discord.gg/BefNCt9pas

Meine Hoffnung ist, hier eine Lösung zu entwerfen, die ich dann ggf. an Roller-Werkstätten herantragen kann - es wäre wirklich schade, wenn die Unus nach und nach verschrottet werden, nur weil die Keycards kaputt gehen oder verloren sind.

Viele Grüße aus Berlin!

[sheepdog]

Analoge aushilfe,

ich habe mir so einen Case für meine Karten angeschafft. Der Verschleiss wird damit erstmal gestoppt. Entsperren lässt sich der UNU aus dem Case auch.

Der Link zum versandhänler von Steve Bezos wurde in der vorheriger Version dieses Port von der Moderation entfernt, weil er angeblich Spam enthalten hat, daher kann ich bei einer PM auf Anfrage geben.

Screenshot 2024-03-20 162348.jpg (55.89 KiB) 3896 mal betrachtet

[Pfriemler]

Das muss ein Versehen gewesen sein. LInks sind in der Tat kritisch, aber eine genaue Artikelbezeichnung und deren ID (mit der man danach suchen kann) sollten erlaubt sein.

[Thunder115]

Spoiler: Ich bin jetzt in der Lage, den Roller ohne Keycards und ohne App zu starten und wieder zu verriegeln.

Respekt!

[tmrw]

HAMMER! Respekt! Leider kann ich nicht wirklich mithelfen...

[Franky-t]

Absolute Hochachtung ja
Leider bin ich bei dem Thema auch komplett raus, lese aber gespannt mit ... Habe auch nur noch eine Karte

[Zanooda]

Kurzes Update:

Ich konnte soeben erfolgreich erstmalig den Roller mit einem eigenen NFC-Tag starten und wieder abschließen

Dafür habe ich den "unu-keycard"-Service auf dem MDB deaktiviert und durch ein kleines Script ersetzt.

Für die Nachwelt und die Techniker grob aus dem Gedächtnis:
- linux_libnfc-nci sowie libnfc (mit den Treibern für pn71xx) für armhf kompiliert und aufs MDB kopiert. Wichtig: Für glibc 2.31 kompilieren, Ubuntu 20.04 eignet sich hier als build environment.

/etc/nfc/libnfc.conf:

Code: Alles auswählen

device.connstring = pn71xx

/etc/libnfc-nxp-init.conf:

Code: Alles auswählen

....
NXP_NFC_DEV_NODE="/dev/pn5xx_i2c2"
....

Und dann ein kleines Python-Ding mit Hilfe von diesem Wrapper hier erzeugt, was die ausgelesene UID mit einer Liste von UIDs in einer Textdatei vergleicht.

Momentan ist das noch nicht so wirklich sicher: UIDs sind ausles- und kopierbar. Sobald ich hinreichend verstanden habe, wie mans besser macht, baue ich das Konstrukt um.

[Zanooda]

Neuer Tag, neue Fortschritt, neue Erkenntnisse:

Ich habe einen Karten-Anlern-Modus gebaut:
Es gibt eine Karte, deren ID fest als "Master-Karte" im MDB hinterlegt ist.
Wenn man diese Karte an das Lesegerät hat, geht der Roller in den Anlern-Modus: Beide vorderen Blinker leuchten permanent.
Während der Roller nun im Anlern-Modus ist, kann man jede Karte, die der Roller kennen soll, ans Lesegerät halten. Ein erfolgreicher Lesevorgang wird mit einem blinkenden Scheinwerfer-Ring quittiert. Nach der letzten angelernten Karte hält wieder seine Master-Karte an das Lesegerät und das Anlernen wird beendet.

Auf diese Art lassen sich auch verlorene Karten sperren oder temporäre Zugangskarten vergeben: Einfach die verbliebenen Karten neu anlernen und der alte Datensatz wird vergessen.

Zur Technik:
Die Lampen werden, wie bereits oben vermutet, per PWM angesteuert. Unu hat hier den Source Code des Kernelmoduls liegen.
Jede Lampe am Roller wird als /dev/pwm_ledX exposed. Insgesamt gibt es 8 Stück:

Code: Alles auswählen

0: Hauptlicht
1: Ring vorne
2: Bremslicht
3: Blinker VL
4: Blinker HR
5: Kennzeichenbeleuchtung
6: Blinker HL 
7: Blinker VR

In /usr/share/led-curves/fades liegen auf dem Controller 13 vorprogrammierte "Fades", also Dimmsequenzen:

Code: Alles auswählen

fade00_ring_off_to_full.bin  fade02_beam_off_to_full.bin  fade04_brake_off_to_mid.bin   fade06_brake_off_to_full.bin  fade08_brake_full_to_off.bin  fade10_blinker.bin              fade12_license_full_to_off.bin
fade01_ring_full_to_off.bin  fade03_beam_full_to_off.bin  fade05_brake_mid_to_full.bin  fade07_brake_full_to_mid.bin  fade09_brake_mid_to_off.bin   fade11_license_off_to_full.bin

fade10_blinker.bin ist z.B. ein recht zügiges "Licht an" + "Licht aus".

Jeder Fade kann auf jeder beliebigen LED "abgespielt" werden. Beispiel: fade06_brake_off_to_full.bin auf dem Blinker vorne links lässt ihn dauerhaft leuchten.

So lässt sich auch der Anlernmodus visualisieren.

Momentan suche ich noch, wie ich die grüne LED am rechten Tacho-Rand ansteuern kann, bisher versteckt sie sich noch recht gut..

Anderer Fun Fact: Im OSTree versteckt sich noch ein uralter Softwarestand. "Aktuell" ist scooterOS 1.13.0 - es lässt sich jedoch Version 1.0.1 auschecken. Dort sind noch etliche Relikte aus der Entwicklung der Rollersoftware drin: Alte Konfigurationsdateien, Unit Tests, Debug-Kram und auch Software, die später rausgeflogen ist: gdb, strace usw. - praktisch, so muss ich den Kram zumindest teilweise nicht selbst kompilieren

Am Samstag gehts zur Besprechung in eine Werkstatt - sie waren am Telefon extrem interessiert. Ich erhoffe mir Feedback und Anregungen zur weiteren Implementierung.

[Zanooda]

Heute habe ich endlich herausgefunden, wie man die LED im Tacho ansteuert.
Außerdem: Ich weiß jetzt, wie man den Roller via Bluetooth entsperrt! Im Discord hat sich schon jemand gemeldet, der über eine unu-unabhängige Offline-App zum Entsperren und Sperren des Rollers nachdenkt


Zum Technischen:

Die Tacho-LED hängt an einem LP5562 LED Driver, der über i2c mit dem MDB verbunden ist.

Led grün leuchten lassen:

Code: Alles auswählen

i2cset -f -y 2 0x30 0x00 0xc0 0x3f 0x00 0xff 0x00 0xaf 0xaf 0xaf 0x61 i

Led ausschalten:

Code: Alles auswählen

i2cset -f -y 2 0x30 0x00 0x40 0x3f 0x00 0x00 0x00 0x32 0x32 0x32 0x01 i

Damit ist mein Keycard-Ersatz-Skript jetzt in der Lage, das unu Keycard-Skript zu ersetzen: Die grüne LED erlischt beim Booten und leuchtet für 1s auf, wenn eine gültige Karte ans Lesegerät gehalten wird.

Das Thema Bluetooth ist auch einfacher als gedacht:
Solange der Roller eingeschaltet ist, ist er bereit zum Pairing. Nach einem Kopplungsrequest erscheint der Pairing Code im Tacho-Display.
Wenn das Gerät gekoppelt ist, kann man mit einem BLE Explorer, wie bspw. Bluetility für macOS durch die Services und Charasteristics des Rollers navigieren. Dort sieht man bspw. den Zustand des Lenkerschlosses, des Helmfachs und auch Informationen zu den Batterien - hier müsste man noch weiterforschen.

Das Beste ist jedoch: Um den Roller zu entsperren, schickt man

Code: Alles auswählen

scooter:state unlock

und zum Sperren

Code: Alles auswählen

scooter:state lock

an den Roller - mehr braucht es nicht!

Ich kann den Roller also jetzt schon mal mit meinem Macbook entriegeln - mal sehen, ob und wann jemand eine App zaubert

[Schnabelwesen]

Hallo @Zanooda, du bist ja fit und schnell! Es macht richtig Spaß, deine gut verständlichen Erklärung von Dingen zu lesen, die für mich auch eher Böhmische Wälder sind. Wenn am Ende eine Lösung steht, die den Händlern und engagierten Nutzern hilft, wäre das die Rettung.
Viel Erfolg weiterhin, Bertolt