I assume by now that most people have heard of the Rabbit R1. Critics unanimously agree that it sucks, and some have accused the company of deliberate deception. Rabbit Inc. reportedly accepts returns, but customers are so eager to get rid of their R1s that even new-in-box units are selling for well below RRP ($200) on secondary markets.
Image source
For Sale: Rabbit R1, Never Used
Rabbit community forum member omorneau aptly summarises (archive) the R1 ownership experience: I spent 2 hours trying to get my R1 to do anything remotely useful. ...] I’d sell mine, but honestly, I’d feel bad for the person buying it. I’d give it away, but would feel bad for the person receiving it. Any ideas? Member smc replies: [A jailbreak is being developed [...]
Well, here we are! In this article, I'll outline the boot process of the R1 and how (and why) I subverted it to create a "tethered jailbreak" that gives you a root shell on otherwise-stock firmware, all without unlocking the bootloader or making any persistent changes to internal storage. I'll also talk about my initial findings from poking around inside the "RabbitOS" firmware.
Motivations
After the headlines caught my attention, I started reverse-engineering a copy of the APK that I found floating around the internet (yes, "RabbitOS" is just an app running in a kiosk-like mode on Android 13 AOSP). There are no local AI models or anything like that, so once you understand the API it uses to talk to The Cloud, you can replace the Rabbit R1 hardware with a small Python script. I reverse-engineered their API and wrote up my findings (it's nothing very exciting, just JSON over a websocket).
By the way, you might've seen headlines about exposed API keys. Those API keys were allegedly leaked from server-side source code and were never stored on-device (I can attest to the latter). A week or so ago, I bought an R1 on eBay for £122 (which is still way more than it's objectively worth). So why did I buy this garbage, in full knowledge of its garbage-ness? Well, in subsequent app updates they started obfuscating their code, and I took it personally!
I love a good game of cat and mouse (or tortoise and hare?), and the game was on. What secrets are they trying to hide from me? They're using a commercial obfuscator, and to be honest, it's quite good, making my purely static-analysis approach tedious. So, I decided it was time to get an R1 in-hand, to poke and prod at. Yes, I'd already figured out the API, but I didn't want to get locked out in future updates. Not because I especially care about being able to interrogate Rabbit's mediocre APIs, but because my pride is at stake. I'd also never looked at the boot security of a modern-ish Android device before, so it was an interesting learning opportunity on that front.
R1 Hardware
The device uses a MediaTek MT6765 SoC, with 4GB of DRAM, and 128GB(!) of eMMC storage. The SoC is an interesting choice for a newly designed product released in 2024 since it has known bootrom exploits (since 2019!). The 128GB of storage is also a weird choice since the device doesn't store much locally. Maybe they intended to develop local ML models and gave up. Or maybe it was just surplus stock being sold at a discount.
R1 owners fairly quickly noticed that although the bootloader is "locked" by default, you can use mtkclient to unlock and reflash it with a "custom ROM" and/or root it. It doesn't even need to use the aforementioned bootrom exploit because the device is permissively configured. However, I'm not too interested in running a custom Android system image; I'm here because I want a closer look at the factory-installed firmware.
Note: Many are calling the reflashing process a "jailbreak", and I'm not going to argue with them. Just be aware that if you see someone talk about jailbreaking an R1, they might be referring to that. Although the first boot stages are wide open, subsequent stages implement Android Verified Boot 2.0. I could unlock the bootloader and install Magisk (a root tool which works by patching the boot partition), but this has several issues:
Local device data would no longer be useful.
Potential system instability.
Difficulty in future updates.
The Boot Chain
All the boot chain logic comes from MediaTek, the SoC vendor. The boot process starts in the bootrom (aka brom), which is immutably etched into the CPU silicon and mapped at physical address 0. The bootrom does very basic hardware initialisation and then loads the next stage (the "Preloader") from the eMMC boot0 partition into SRAM. The Preloader is signed, and the bootrom verifies the signature before executing it. Through some process I don't yet fully understand, LK jumps to ATF, which sets itself up and then jumps to GZ, which sets itself up before returning back to LK, which continues the boot process.
Breaking the Chain of Trust
Secure boot chains all have a root of trust. In this case, the root of trust is a certificate hash baked into the CPU's efuses, along with the bootrom code that verifies it. However, due to the aforementioned "kamakiri" bootrom exploit, the first link of the chain is irrevocably broken. This hardware is fundamentally incapable of hiding secrets from its users (I wish all hardware was like that, to be honest).
I wrote my own DA payload. It gets loaded into DRAM by Preloader and does the following things, in order: LK uses the MMU to provide memory protection, and although the mappings are all identity mappings (virtual address == physical address), it created some headaches for me.
Findings
So, what were they trying to hide from us? To be honest, I haven't found anything particularly interesting yet. The analysis has only just begun! A big reason why I'm sharing my jailbreak is the hope that other people will join me in my analysis. One thing I did notice is that they were logging everything to text files on internal storage.
Image: Emphasizing excessive data logging.
This was concerning because there's simply no need to be logging this much data in this much detail, especially on a device with no meaningful hardware security. Fortunately for everyone else, the latest RabbitOS update (v0.8.112) addressed this issue while I was midway through writing this article. They reduced logging and added a factory reset settings option! Credit where it's due, this was a very quick turnaround, and it's the first time I've seen Rabbit being even slightly proactive with regards to user privacy and security issues, as opposed to merely reacting to news articles written about them.
This reaffirms my belief that consumers should have full ability to inspect and modify the code that runs on the devices they own. When these abilities are denied by a vendor, I take steps to rectify the situation.
AOSP "Customizations"
When the news broke that the RabbitOS was just an app running on Android 13, Rabbit's PR spin on the matter was to call it a "very bespoke AOSP [with] lower level firmware modifications". As far as I can tell, all they've done is disable any and all Android features that could compromise their single-app kiosk mode experience.
Advice for Regular R1 Users
If you're worried that your device may have been "jailbroken" against your will, just turn it off and on again. If it boots up normally without any warning messages on the screen, you're probably safe. Ideally, you'd be able to reflash known-safe stock firmware using vendor-provided firmware images, but the vendor does not make such provisions. You should ask them for it! Never leave your R1 unattended because any data stored on it could easily be extracted by someone who knows what they're doing. If you're planning on selling (or donating, or trashing) your R1 device, you should factory reset it first using the newly added settings option.
Conclusions
So to wrap things up: The Rabbit R1’s firmware is more or less insecure, and their AOSP "customizations" are limited to disabling Android’s core functionalities rather than enhancing them.
Remember these 3 key ideas for your startup:
Transparency in Tech: Always provide full transparency regarding your product’s security and privacy features. Rabbit Inc.'s hidden logs and obfuscation attempts have led to distrust among users and developers. Transparency builds trust.
User Control: Allow users to have full control over the devices they own. Denying access only provokes reverse engineering efforts like this jailbreak. Users should be empowered to make modifications safely.
- Compliance with Licenses: Ensure compliance with open-source licenses like GPL to foster a cooperative and supportive developer community. Violation not only harms the ecosystem but also tarnishes the company's reputation.
Edworking is the best and smartest decision for SMEs and startups to be more productive. Edworking is a FREE superapp of productivity that includes all you need for work powered by AI in the same superapp, connecting Task Management, Docs, Chat, Videocall, and File Management. Save money today by not paying for Slack, Trello, Dropbox, Zoom, and Notion.
For more details, see the original source.
