- Das Rabbit R1 ist ein app-basiertes Gerät, das auf Android 13 AOSP in einer Art Kiosk-Modus läuft, und es wurde ein tethered Jailbreak umgesetzt, der eine Root-Shell ermöglicht, ohne den Bootloader zu entsperren oder den internen Speicher zu verändern
- Der Jailbreak lässt die Verifikation der MediaTek-Bootkette unverändert passieren und ersetzt erst unmittelbar vor der tatsächlichen Nutzung des verifizierten
boot-Images im Speicher per USB durch ein benutzerdefiniertes Image
- Das R1 verwendet einen MediaTek MT6765, 4 GB DRAM und 128 GB eMMC; selbst wenn
ro.boot.verifiedbootstate auf green stand, war per TCP-Bind-Shell ein Zugriff als uid=0(root) möglich
- In den Logs des internen Speichers fanden sich GPS-Positionen, WLAN-Namen, IDs umliegender Mobilfunkzellen, externe IPs, Nutzertoken für die Rabbit-Backend-API sowie Rabbit-Sprach-MP3s und Transkripte; in RabbitOS v0.8.112 wurden das Logging reduziert und eine Option zum Zurücksetzen auf Werkseinstellungen ergänzt
- Rabbit Inc. veröffentlicht den Quellcode für die statisch in den Linux-Kernel gelinkten Treiber des Hall-Effekt-Scrollrads und des rotierenden Kameramotors nicht und verstößt damit gegen GPL2; Stand 22. Juli gab es auf entsprechende Nachfragen keine Antwort
Ausgangspunkt der Analyse des Rabbit R1
- Das Rabbit R1 wurde von Kritikern negativ bewertet, und auf dem Gebrauchtmarkt werden ungeöffnete Geräte bereits unter dem Listenpreis von 200 US-Dollar verkauft
- RabbitOS ist kein separates lokales KI-Modell, sondern eine App, die auf Android 13 AOSP in einer Art Kiosk-Modus läuft und mit der Cloud über eine JSON-API auf Basis von WebSockets kommuniziert
- Zuvor gemeldete offengelegte API-Schlüssel stammten offenbar aus serverseitigem Quellcode und waren nicht auf dem Gerät gespeichert
- In späteren App-Updates wurde ein kommerzielles Obfuskationstool eingesetzt, zudem enthielten sie Erkennung für Analysetools wie Magisk und Frida sowie Logik zur Prüfung, ob es sich wirklich um ein R1-Gerät handelt
- Da statische Analyse allein umständlich geworden war, wurde ein R1 für 122 £ bei eBay gekauft und eine Laufzeitanalyse durchgeführt, wobei die Werks-Firmware möglichst unverändert bleiben sollte
R1-Hardware und grundlegender Sicherheitsstatus
- Das R1 verwendet einen MediaTek MT6765-SoC, 4 GB DRAM und 128 GB eMMC-Speicher
- Für den MT6765 existiert seit 2019 der bekannte Bootrom-Exploit
kamakiri
- Die 128 GB Speicher wirken für ein Gerät, das lokal nicht viele Daten speichern muss, wie eine ungewöhnliche Wahl
- Besitzer des R1 haben bestätigt, dass sich der Bootloader mit
mtkclient entsperren und ein Custom-ROM flashen oder Root-Zugriff erlangen lässt
- Ziel der Analyse war nicht, ein benutzerdefiniertes Android-Systemimage aufzuspielen, sondern das ab Werk installierte Firmware-Image möglichst unverändert zu untersuchen
- Das Entsperren des Bootloaders und die Installation von Magisk bringen mehrere Probleme mit sich
- OTA-Delta-Updates können dadurch kaputtgehen
- Bereits vorhandener Analyse-Schutz könnte dies erkennen
- Künftige Updates könnten Werte wie
ro.boot.verifiedbootstate prüfen und es dadurch erkennen
- Deshalb wurde ein Weg benötigt, der möglichst wenige Änderungen verursacht, um die Angriffsfläche für Erkennungslogik klein zu halten und dennoch lokalen Root-Zugriff zu erhalten
MediaTek-basierte Bootkette
- Die Bootkette besteht aus MediaTek-Logik, ihr Startpunkt ist die im CPU-Silizium fest verankerte Bootrom
- Die Bootrom lädt nach grundlegender Hardware-Initialisierung den
Preloader aus der eMMC-Partition boot0 in den SRAM
- Der Preloader ist signiert, und die Bootrom verifiziert diese Signatur
- Beim R1 ist allerdings möglich, dass tatsächlich nicht verifiziert wird; das müsste noch genauer geprüft werden
- Der Preloader initialisiert den DRAM und lädt drei Images aus den eMMC-GPT-Partitionen in den DRAM
tee: Arm Trusted Firmware, EL3gz: GenieZone Hypervisor, EL2lk: Little Kernel, EL1
- LK implementiert Android Verified Boot 2.0 und
dm-verity
- Ist der Bootloader gesperrt, wird bei fehlgeschlagener Verifikation der Start verweigert
- Ist er entsperrt, erscheint eine Warnung und Flags für den Orange State werden gesetzt
- Schlägt die
dm-verity-Prüfung fehl, bootet das Gerät auch bei entsperrtem Bootloader nicht
- Wenn die Verifikation erfolgreich ist, entpackt LK den Linux-Kernel und startet ihn; der Kernel führt dann
/init aus dem initramfs aus
- Das R1 nutzt A/B-Partitionierung, daher ist
boot je nach aktivem Slot boot_a oder boot_b
- Der Sperr-/Entsperrstatus des Bootloaders wird in der GPT-Partition
seccfg gespeichert
seccfg besteht aus einigen Flags und einem verschlüsselten Hash- Das letzte Byte der Partition
frp beeinflusst, ob das Entsperren des Bootloaders per fastboot flashing unlock erlaubt ist
carroot: tethered Jailbreak ohne Änderungen am Speicher
- Die Root of Trust der Vertrauenskette liegt im Zertifikat-Hash in der CPU-eFuse und im Bootrom-Code, der ihn verifiziert
- Für den MT6765 gibt es zwar den Bootrom-Exploit
kamakiri, beim R1 akzeptieren jedoch schon brom und der USB-Bootloader-Modus des Preloaders ein unsigniertes DA-Image und führen es im Speicher aus, ganz ohne Exploit
- Dafür wurde eine eigene DA-Payload erstellt, die der Preloader in den DRAM lädt
- Der Ablauf sieht so aus
- Ein benutzerdefiniertes Android-
boot-Image wird per USB in den DRAM geladen
- Kurz bevor der Preloader zu LK springt, wird ein Hook installiert
- Anschließend geht es zurück zum Preloader und der normale Bootprozess läuft weiter
- Der Preloader lädt und verifiziert die Images
tee, gz und lk von der eMMC
- Unmittelbar vor dem Eintritt in LK wird der Hook ausgeführt und installiert weitere Hooks und Patches in LK
- LK lädt und verifiziert die ursprüngliche
boot-Partition von der eMMC
- In dem Moment, in dem das
boot-Image aus dem AVB-Code in den Linux-Bootcode kopiert wird, ersetzt der Hook es durch das per USB geladene benutzerdefinierte boot-Image
- Auf dem Bildschirm wird zusätzlich eine benutzerdefinierte Nachricht angezeigt
- Der Kern des Verfahrens ist, dass die zu verifizierenden Daten unverändert verifiziert werden dürfen und die gepatchten Daten erst nach der Verifikation, direkt vor der Nutzung ausgetauscht werden
- Der Flash-Speicher wird überhaupt nicht verändert; der gesamte Jailbreak läuft nur im Speicher ab
- Nach einem Neustart ist das Gerät wieder sauber
- Im Reverse-Engineering-Prozess lässt sich der Originalzustand leicht wiederherstellen
- Das benutzerdefinierte
boot-Image verwendet flashable-android-rootkit
- Es ersetzt die Standard-
/init-Binärdatei und injiziert so eine Payload als User-Space-Dienst mit maximalen Rechten
- Das Tool zum Patchen des Images,
magiskboot, stammt aus dem Magisk-Projekt
- Um
magiskboot unter normalem Linux zu bauen und auszuführen, wurde magiskboot_build verwendet
- Die Payload ist eine einfache TCP-Bind-Shell
- Sie ist nicht unauffällig, und die Rabbit-App könnte sie erkennen
- Bei Bedarf ließe sich das später verbessern
WebSerial-basierte Jailbreak-Tools und Ausführungsergebnis
- Für die Steuerung von MediaTek-Geräten bietet mtkclient zwar bereits die nötigen Funktionen, zum besseren Verständnis des Ablaufs wurde aber ein eigener Python-USB-Client geschrieben
- Später wurde dieser auf js/WebSerial portiert, sodass sich ein physisch verbundenes Rabbit R1 direkt über eine Webseite jailbreaken lässt
- Der Name des Jailbreaks lautet in Anlehnung an ein Rabbit-Wortspiel carroot
- Das experimentelle Tool ist unter r1_jailbreak veröffentlicht
- Nach dem Booten ergab die Verbindung zur TCP-Bind-Shell Folgendes
$ rlwrap nc 192.168.0.69 1337
# id
uid=0(root) gid=0(root) groups=0(root) context=u:r:rootkit:s0
# getprop ro.boot.verifiedbootstate
green
- Das System erkannte den Secure-Boot-Status also als
green und erlaubte dennoch den Zugriff auf eine Root-Shell
- Die SELinux-Domain
rootkit wird von flashable-android-rootkit eingerichtet
Für die Analyse verwendete Geräteschnittstellen und Referenzen
- Auf den iFixit-Zerlegefotos des R1 sind Testpads mit der Beschriftung TX und RX zu sehen; dabei handelt es sich um UART-Testpads
- UART liefert Debug-Logs über die gesamte Bootkette hinweg
- Die brom-Phase läuft mit 115200 Baud
- Die nachfolgenden Phasen mit 921600 Baud
- Der Logikpegel beträgt 1,8 V; am Analysegerät funktionierten auch 3,3 V ohne Schäden
- Der Preloader deaktiviert UART-Logging, wenn die Lauter-Taste nicht gedrückt wird
- Das R1 besitzt keine Lauter-Taste, daher wurde der Preloader gepatcht, um diese Prüfung zu deaktivieren
- Der gepatchte Preloader kann über den USB-Download-Modus der Bootrom gebootet werden
- In der Linux-Kernel-Commandline wurde das folgende Flag gepatcht, um Kernel-Logs über UART auszugeben
earlycon console=ttyS1,921600
- Mit dieser Patch-Kombination wurden die UART-Logs des gesamten Bootprozesses gesammelt
- Wenn man während eines Resets das neben dem Reset-Knopf im SIM-Slot zugängliche Testpad auf GND zieht, kann das Gerät im brom-USB-Modus gestartet werden
- Wichtige Referenzen waren unter anderem
In internen Logs gefundene personenbezogene Daten
- Das R1 hinterließ im internen Speicher unter
Android/data/tech.rabbit.r1launcher.r1/files/logs/ datumsbezogene Text-Logs
- Stand 7. Juli 2024 lagen im Log-Verzeichnis
.log-Dateien von mehreren Tagen, einige davon mehrere MB groß
- Die Logs enthielten unter anderem folgende Daten
- genaue GPS-Positionen
- Namen von WLAN-Netzwerken
- IDs umliegender Funkzellen, die auch ohne SIM-Karte erfasst wurden
- internetseitig sichtbare IP-Adressen
- Nutzertoken zur Authentifizierung gegenüber der Rabbit-Backend-API
- Base64-kodierte MP3s und Texttranskripte von allem, was Rabbit dem Nutzer gesagt hatte
- Ein Teil dieser Daten, darunter GPS-Positionen und IDs umliegender Funkzellen, wurde auch an die Rabbit-Server übertragen
- Das Problem hatte zwei Seiten
- Es wurden übermäßig detaillierte Daten auf einem Gerät ohne nennenswerte Hardware-Sicherheit geloggt
- Normale Nutzer hatten keine Möglichkeit zum Zurücksetzen auf Werkseinstellungen, sodass die Logs faktisch dauerhaft erhalten blieben
- Angesichts des regen Gebrauchtmarkts konnten beim Verkauf, Verschenken oder Entsorgen also Logs früherer Nutzer auf dem Gerät verbleiben
- Mit RabbitOS v0.8.112 wurden laut Sicherheitshinweis das Logging reduziert und eine Option in den Einstellungen zum Zurücksetzen auf Werkseinstellungen ergänzt
- Diese Reaktion erfolgte schnell und gilt als eines der ersten Beispiele dafür, dass Rabbit bei Datenschutz- und Sicherheitsproblemen relativ proaktiv gehandelt hat
Der tatsächliche Umfang der AOSP-Anpassungen
- Rabbit hatte auf Berichte, RabbitOS sei bloß eine App, mit der Aussage reagiert, es handle sich um ein stark angepasstes AOSP mit „lower level firmware modifications“
- Die bislang bestätigten Anpassungen bestehen jedoch hauptsächlich darin, Android-Funktionen zu entfernen, um einen Einzel-App-Kiosk-Modus aufrechtzuerhalten
- keine Navigationsleiste
- keine Benachrichtigungsleiste
- Maßnahmen, die die Aktivierung von ADB verhindern sollen
- Eine App namens
Judy läuft im Hintergrund und deaktiviert ADB, wenn es aktiv ist
- Am 4. Juli veröffentlichte @MarcelD505 einen Kiosk-Escape, der vom WLAN-Captive-Portal-Login-Browser in die Android-Systemeinstellungen führte
- Rabbit blockierte diesen Weg im neuesten Update, indem die Android-Systemeinstellungen-App vollständig vom Gerät entfernt wurde
- Die bislang beobachteten maßgeschneiderten AOSP-Änderungen wirken eher wie das Entfernen von Funktionen als das Hinzufügen neuer Funktionen
- Bislang ist kein technischer Grund bekannt, warum die aktuelle Umsetzung von RabbitOS nicht auch als normale Smartphone-App möglich wäre
Was normale R1-Nutzer beachten sollten
- Wer befürchtet, das Gerät könnte unerwünscht gejailbreakt worden sein, kann es einfach aus- und wieder einschalten
- Wenn es ohne Warnmeldungen normal startet, ist das in der Regel ein gutes Zeichen
- Falls brom jedoch so konfiguriert wäre, ein unsigniertes Preloader-Image von der eMMC zu booten, ist das nicht sicher; dafür wären weitere Tests nötig
- Noch besser wäre es, erneut ein vertrauenswürdiges Stock-Firmware-Image des Herstellers zu flashen, aber Rabbit bietet dafür keine Möglichkeit an
- Lässt man ein R1 unbeaufsichtigt, können die darauf gespeicherten Daten von Personen mit entsprechendem Wissen leicht extrahiert werden
- Vor Verkauf, Weitergabe oder Entsorgung sollte man daher unbedingt zuerst die neu hinzugefügte Option zum Zurücksetzen auf Werkseinstellungen verwenden
GPL-Verstoß und Fazit
- Das Rabbit R1 ist abgesehen vom Scrollrad und der drehbaren Kamera eher ein gewöhnliches MediaTek-Android-Gerät als spezielle Hardware
- Die AOSP-Anpassungen bestehen größtenteils darin, vorhandene Funktionen zu entfernen, um einen Einzel-App-Kiosk-Modus zu erzwingen
- Die Sicherheit der Bootkette ist nicht wirksam genug, um das Gerät sicher unbeaufsichtigt zu lassen
- Rabbit Inc. verstößt gegen die GPL2-Lizenz des Linux-Kernels
- Der Treiber zur Erkennung des Hall-Effekt-Scrollrads ist Closed Source
- Auch der Treiber zur Steuerung des Schrittmotors für die Kameradrehung ist Closed Source
- Beide Treiber sind statisch in das GPL-Kernel-Image gelinkt
- Am 12. Juli wurde Rabbit Inc. um einen Kommentar zum Inhalt und um Auskunft zu Plänen zur GPL-Compliance gebeten, doch Stand 22. Juli lag keine Antwort vor
- Das veröffentlichte tethered Jailbreak-Tool ist ein experimentelles Werkzeug, das Forschern helfen soll, auf ihr eigenes R1 zuzugreifen, und fortgeschrittenen Nutzern künftig möglicherweise erlaubt, die Funktionen des Geräts zu erweitern
1 Kommentare
Meinungen auf Hacker News
Die GPL verlangt, dass auf Anfrage die Lizenz und der Quellcode offengelegt werden. Truth Social kam aber damit durch, nicht einmal die Lizenz offenzulegen, bis bekannt wurde, dass es AGPL-Code verwendet hatte; erst dann wurde der Quellcode veröffentlicht.
Ich frage mich, ob Rabbit auf dieselbe Weise davonkommt.
In der Praxis kann man Verstöße, von denen der Rechteinhaber nichts weiß, nicht verfolgen, und meistens geht es eher darum, den Verletzer zur Einhaltung zu bringen, als um Schadenersatz.
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
Ich dachte, bei Kernelmodulen gebe es auf Linux-Seite unabhängig von der Art des Linkens eine GPL-Ausnahme, solange keine Änderungen am Kernel selbst nötig sind.
Der Inhalt dieser Logs ist ziemlich übel: genaue GPS-Position, Namen von WLAN-Netzen, IDs umliegender Mobilfunkmasten selbst ohne SIM-Karte, die nach außen sichtbare IP-Adresse, User-Token zur Authentifizierung bei der Rabbit-Backend-API sowie Base64-kodierte MP3s und Texttranskripte von allem, was Rabbit dem Nutzer gesagt hat.
Dass ein Gerät, das Fragen wie „Wo ist ein gutes Restaurant in der Nähe?“ beantworten soll, zusammen mit der Anfrage Standortkontext sendet, ist nicht überraschend. Wenn es den Standort aber ohne Grund kontinuierlich streamt, wäre das bedenklich.
WLAN-Namen müssen für die Wiederverbindung gespeichert werden, und dass IP-Adressen in lokalen Logs auftauchen, ist auch nicht besonders ungewöhnlich.
Auch User-Access-Token müssen zwangsläufig auf dem Gerät gespeichert werden, wenn es sich wieder verbinden soll, ohne dass man sich jedes Mal neu einloggt. Token im Klartext in Logs zu hinterlassen, ist allerdings schlechte Praxis; wenn die Logs im selben Speicher wie die betreffende Datenbank oder Konfigurationsdatei liegen, ist das für sich genommen kein völlig neues Problem. Wenn die Logs direkt auf den Server hochgeladen werden, ist das natürlich ein Problem.
Wenn man wollte, dass so ein Gerät nahtlos und magisch funktioniert, muss es ständig zuhören, sehen und den Standort senden. Damit das wirklich gut funktioniert, bräuchte es lokale Inferenz, und ich weiß nicht, warum man Geld für etwas ausgeben sollte, von dem Apple in fünf Jahren eine viel bessere Version bauen wird. Aber wenn man es unbedingt kauft, braucht es genau so eine Arbeitsweise.
Man kann nicht gleichzeitig Big Tech hassen und erwarten, dass ein Startup ohne Daten ein gutes Produkt baut. Wenn Rabbit überhaupt die Chance haben soll, künftig etwas Besseres zu bauen, braucht es solche Daten.
Wenn man das unangenehm findet, sollte man konkret erklären, warum. Das meiste daran ist für sich genommen nicht besonders besorgniserregend.
Witzig. Ich habe bei Rabbit gearbeitet, die Codebase gelesen, wurde von Führungskräften gegaslightet und bin dann gegangen.
Schon die von außen sichtbaren Jailbreaks und Schwachstellen wirken wie die Spitze des Eisbergs.
Dass Rabbit nicht geantwortet hat, liegt vermutlich daran, dass die Anwälte gerade prüfen, wie sie klagen können.
Man hat ihnen praktisch kaum Geschäftszeit gegeben, um tatsächlich zu antworten.
Die RabbitOS-Entwickler könnten dieses Problem patchen, indem sie die eFuse so setzen, dass der Bootloader-Zugriff über USB blockiert wird.
Moto hat das vor ein paar Jahren genauso gemacht, als MediaTek-Geräte für dieselbe Boot-ROM-Angriffsfläche anfällig waren. Wenn ich mich richtig erinnere, wurde diese eFuse in der LK-Phase gesetzt und per normalem OTA-Firmware-Update ausgerollt.
Der Artikel ist großartig.
Die Software sieht nach Müll aus, und auch das Unternehmen wirkt bisher nicht besonders gut.
Trotzdem könnte dieser Formfaktor ziemlich interessante Einsatzmöglichkeiten haben, wenn man darauf zumindest im Kioskmodus einfach Custom-Apps ausführen kann.
Wenn man eine PWA grob daraufsetzen könnte, wäre das viel schneller, als selbst einen ESP32, Akku und Bildschirm zusammenzubauen, und es wirkt wie ein ziemlich ordentliches All-in-one-Gerät.
Idealerweise ließe es sich ohne Google-Dienste sicherer betreiben; etwas in Richtung GrapheneOS wäre in Ordnung.
Ich habe noch nicht danach gesucht, aber mich würde interessieren, ob es Beispiele oder gute Referenzen für die Nutzung als Single-Purpose-Custom-App in dieser Art gibt.
Wenn der Preis auf unter 50 Dollar fällt, zum Beispiel nachdem sie die Server abgeschaltet haben, würde ich zustimmen, dass es dann eine brauchbare Hardwareplattform ist.
Schade, ich hätte mir gewünscht, dass dieses Produkt Erfolg hat.
Ich hoffe, es bleibt künftigen Experimenten mit Hardware-User-Interfaces + AI nicht wie ein Klotz am Bein hängen. Der Bret-Victor-Gedanke, dass wir es besser können, als auf Glasrechtecken zu tippen und zu wischen, leuchtet mir immer noch ein.
Noch bequemer könnte eine Smartwatch Anfragen ans Smartphone weiterleiten.
Auch wenn Humane offenbar kein echtes Problem gelöst hat, respektiere ich bis zu einem gewissen Grad, dass sie wirklich etwas anderes versucht haben. Der Rabbit R1 ist einfach billiger Kram.
Es ist schon etwas witzig, dass die gesamte oder zumindest der größte Teil der anfänglichen Sympathie für Rabbit dem Design von Teenage Engineering zu verdanken war.
Ich hoffe, TE wählt seine Kunden künftig besser aus. Die Person hinter Rabbit ist ein bekannter Betrüger.
Ich könnte den Namen googeln, aber die Suchqualität ist heutzutage so schlecht, dass ich es lassen werde. Ein Link mit genauerer Kritik wäre hilfreich.
Das ist so etwas wie der Juicero unter den AI-Assistenten.
Das Unternehmen dachte nur, die Leute würden absurde Summen für eine Maschine bezahlen, die proprietäre Beutel mit vorgeschnittenen Fruchtmischungen auspresst. Alles funktionierte exakt wie vorgesehen; das eigentliche Geschäftsmodell war einfach unsinnig.
Ich hatte auf einen Open-Source-AI-Assistenten mit Schutz der Privatsphäre gehofft, so etwas wie eine Kombination aus Mycroft(https://en.wikipedia.org/wiki/Mycroft_(software)) und Leon(https://getleon.ai).