- Rabbit R1 एक app-आधारित device है जो Android 13 AOSP के ऊपर kiosk mode जैसा चलता है, और bootloader unlock या internal storage में बदलाव किए बिना root shell पाने वाला tethered jailbreak लागू किया गया
- jailbreak MediaTek boot chain की verification को वैसे ही पास होने देता है, और verified
boot image के वास्तविक उपयोग से ठीक पहले USB से upload की गई custom image को memory में replace करता है
- R1 MediaTek MT6765, 4GB DRAM, 128GB eMMC इस्तेमाल करता है, और
ro.boot.verifiedbootstate के green होने पर भी TCP bind shell से uid=0(root) access संभव था
- internal storage logs में GPS location, WiFi नाम, आसपास के cell tower IDs, external IP, Rabbit backend API के लिए user tokens, Rabbit voice MP3 और transcripts बचे हुए थे; RabbitOS v0.8.112 में logging घटाने और factory reset option जोड़ा गया
- Rabbit Inc. ने Linux kernel में statically linked hall-effect scroll wheel और rotating camera motor driver source release नहीं किया है, इसलिए यह GPL2 violation की स्थिति में है; 22 जुलाई तक संबंधित सवालों का जवाब नहीं दिया गया
Rabbit R1 analysis की शुरुआत
- Rabbit R1 को critics से नकारात्मक reviews मिले, और second-hand market में sealed products list price 200 डॉलर से कम में बिक रहे हैं
- RabbitOS कोई अलग local AI model नहीं है, बल्कि Android 13 AOSP पर kiosk mode जैसा चलने वाला app है, और cloud से websocket पर JSON API के जरिए communicate करता है
- पहले report की गई exposed API keys के बारे में माना गया कि वे server-side source code से leak हुई थीं, और device के अंदर stored नहीं थीं
- बाद के app updates में commercial obfuscation tool apply किया गया, और Magisk व Frida जैसे analysis tools की detection तथा R1 device होने की verification logic शामिल की गई
- सिर्फ static analysis से tracing झंझटभरी हो गई, इसलिए eBay से £122 में R1 खरीदा गया और factory firmware को जितना हो सके वैसा ही रखते हुए runtime analysis किया गया
R1 hardware और basic security state
- R1 MediaTek MT6765 SoC, 4GB DRAM, 128GB eMMC storage इस्तेमाल करता है
- MT6765 में 2019 से ज्ञात bootrom exploit
kamakiri मौजूद है
- 128GB storage, device की प्रकृति देखते हुए जहां बहुत ज्यादा local stored data नहीं होना चाहिए, एक अजीब choice लगती है
- R1 owners ने पुष्टि की कि
mtkclient से bootloader unlock कर custom ROM flash या root किया जा सकता है
- analysis का goal custom Android system image चढ़ाना नहीं था, बल्कि factory-installed firmware को जितना हो सके unchanged रखते हुए उसके अंदर देखना था
- bootloader unlock कर Magisk install करने के तरीके में कई समस्याएं हैं
- OTA delta updates टूट सकते हैं
- मौजूदा anti-analysis code इसे detect कर सकता है
- future updates अगर
ro.boot.verifiedbootstate जैसी values check करें तो यह detect हो सकता है
- इसलिए बदलाव के points घटाकर anti-analysis logic द्वारा detect होने वाली surface को न्यूनतम रखते हुए local root privileges पाने की दिशा चाहिए थी
MediaTek-based boot chain
- boot chain MediaTek logic से बनी है, और starting point CPU silicon में fixed bootrom है
- bootrom basic hardware initialization के बाद eMMC
boot0 partition से Preloader को SRAM में load करता है
- Preloader signed होता है और bootrom signature verify करता है
- हालांकि R1 में संभव है कि वास्तव में verify न करता हो, इसलिए और confirmation चाहिए
- Preloader DRAM initialize करता है और eMMC GPT partition से तीन images DRAM में load करता है
tee: Arm Trusted Firmware, EL3gz: GenieZone Hypervisor, EL2lk: Little Kernel, EL1
- LK Android Verified Boot 2.0 और
dm-verity implement करता है
- bootloader locked हो तो verification failure पर boot से इनकार करता है
- unlocked हो तो warning दिखाता है और orange state related flags set करता है
dm-verity verification fail हो तो bootloader unlocked होने पर भी boot नहीं होता
- verification pass होने पर LK Linux kernel को decompress करके boot करता है, और kernel initramfs का
/init execute करता है
- R1 A/B partitioning इस्तेमाल करता है, इसलिए
boot active slot के अनुसार boot_a या boot_b होता है
- bootloader lock/unlock state
seccfg GPT partition में stored होती है
seccfg कुछ flags और encrypted hash से बना होता हैfrp partition का last byte fastboot flashing unlock जैसे bootloader unlock allow करने से संबंधित है
carroot: storage को छुए बिना tethered jailbreak
- trust chain का root of trust CPU efuse में मौजूद certificate hash और उसे verify करने वाला bootrom code है
- MT6765 में
kamakiri bootrom exploit है, लेकिन R1 में exploit के बिना भी brom और Preloader का USB bootloader mode unsigned DA images को memory में accept करके execute करता है
- custom DA payload बनाया गया ताकि Preloader उसे DRAM में load करे
- flow इस प्रकार है
- USB से custom Android
boot image DRAM में load की जाती है
- Preloader के LK पर jump करने से ठीक पहले hook install किया जाता है
- Preloader पर लौटकर normal boot process जारी रखा जाता है
- Preloader eMMC से
tee, gz, lk images load और verify करता है
- LK में enter करने से ठीक पहले hook चलकर LK के अंदर additional hooks और patches install करता है
- LK original eMMC की
boot partition load और verify करता है
- जैसे ही
boot image AVB code से Linux boot code की ओर copy होती है, hook उसे USB से upload की गई custom boot image से replace कर देता है
- screen पर custom message भी दिखता है
- मुख्य बात यह है कि data to be verified को वैसे ही verify होने दिया जाता है, और verification के बाद उपयोग से ठीक पहले patched data से replace किया जाता है
- flash storage बिल्कुल modify नहीं होती, और पूरा jailbreak process सिर्फ memory में होता है
- reboot करने पर device clean state में वापस आ जाता है
- reverse engineering के दौरान original state में लौटना आसान है
- custom
boot image flashable-android-rootkit इस्तेमाल करती है
- default
/init binary replace करके maximum-privilege userspace service के रूप में payload inject करती है
- image patch tool
magiskboot Magisk project से लिया गया
- सामान्य Linux पर
magiskboot build और run करने के लिए magiskboot_build इस्तेमाल किया गया
- payload एक simple TCP bind shell है
- यह stealthy तरीका नहीं है और Rabbit app इसे detect कर सकता है
- जरूरत होने पर बाद में improve किया जा सकता है
WebSerial-based jailbreak tool और execution result
- MediaTek devices manipulate करने के लिए mtkclient पहले से जरूरी features देता है, लेकिन behavior समझने के लिए Python USB client खुद लिखा गया
- बाद में इसे js/WebSerial में port किया गया ताकि physically connected Rabbit R1 को webpage से jailbreak किया जा सके
- jailbreak का नाम rabbit pun को ध्यान में रखते हुए carroot रखा गया
- experimental tool r1_jailbreak पर publish किया गया
- boot के बाद TCP bind shell से connect करने का result इस प्रकार था
$ 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
- system secure boot state को
green मानता रहा, फिर भी root shell access allow हुआ
rootkit SELinux domain flashable-android-rootkit ने set किया
analysis में इस्तेमाल device interfaces और references
- R1 की iFixit teardown photos में TX और RX के रूप में marked test pads दिखते हैं, ये UART test pads हैं
- UART पूरी boot chain में debug logs देता है
- brom stage 115200 baud
- बाद के stages 921600 baud
- logic level 1.8V है, और analysis device में 3.3V भी बिना नुकसान काम करता है
- Preloader volume-up key न दबाने पर UART logging disable करता है
- R1 में volume-up key नहीं है, इसलिए Preloader patch करके यह check disable किया गया
- patched Preloader को bootrom के USB download mode से boot किया जा सकता है
- Linux kernel command line में UART पर kernel logs output करने के लिए ये flags patch किए गए
earlycon console=ttyS1,921600
- इस patch combination से पूरे boot process के UART logs collect किए गए
- SIM slot के जरिए accessible reset button के पास test pad को reset के दौरान GND पर pull करने से brom USB mode में boot किया जा सकता है
- मुख्य references ये हैं
internal logs में मिली personal information
- R1 internal storage में
Android/data/tech.rabbit.r1launcher.r1/files/logs/ के नीचे date-wise text logs छोड़ रहा था
- 7 जुलाई 2024 तक log directory में कई dates की
.log files थीं, और कुछ files कई MB की थीं
- logs में ये data शामिल था
- सटीक GPS location
- WiFi network name
- SIM card न होने पर भी collect होने वाले आसपास के cell tower IDs
- internet-facing IP address
- Rabbit backend API authentication में इस्तेमाल user token
- Rabbit ने user से जो कुछ भी कहा, उसका Base64-encoded MP3 और text transcript
- इस data में से GPS location और आसपास के cell tower IDs Rabbit servers पर भी भेजे जाते हैं
- समस्या दो तरह की थी
- meaningful hardware security न होने वाले device पर जरूरत से ज्यादा detailed data logging
- सामान्य users के लिए factory reset करने का कोई तरीका नहीं था, जिससे logs practically permanently रह जाते थे
- second-hand trade active होने की स्थिति में sale, donation या disposal के समय previous user के logs रह सकते थे
- RabbitOS v0.8.112 ने security advisory के जरिए logging घटाई और factory reset settings option जोड़ा
- यह response जल्दी आया, और इसे user privacy व security issues पर Rabbit की अपेक्षाकृत proactive response का पहला case माना गया
AOSP customization का actual scope
- Rabbit ने RabbitOS को simple app बताने वाली reports पर कहा था कि यह “lower level firmware modifications” वाला काफी customized AOSP है
- अब तक confirm हुई customization मुख्यतः single-app kiosk mode बनाए रखने के लिए Android features हटाने के रूप में है
- navigation bar नहीं
- notification bar नहीं
- ADB enable होने से रोकने के उपाय मौजूद
Judy नाम का app background में चलता है और ADB running हो तो उसे disable करता है- 4 जुलाई को @MarcelD505 ने WiFi captive portal login browser से शुरू करके Android system settings app में पहुंचने वाला kiosk escape तरीका publish किया
- Rabbit ने latest update में Android system settings app को device से पूरी तरह remove करके यह route block कर दिया
- अब तक confirm हुए bespoke AOSP changes मौजूदा features जोड़ने के बजाय features हटाने के करीब हैं
- मौजूदा RabbitOS implementation general smartphone app के रूप में असंभव है, ऐसा कोई technical reason अभी तक confirm नहीं हुआ है
general R1 users को किन बातों की चिंता करनी चाहिए
- अगर अनचाहे jailbreak होने की संभावना की चिंता है, तो power off/on कर लें
- अगर warning message के बिना normal boot हो जाए, तो आम तौर पर safe हो सकता है
- लेकिन अगर brom को eMMC से unsigned Preloader image boot करने के लिए configured किया गया हो तो पक्का नहीं है, और additional testing चाहिए
- vendor-provided trusted stock firmware image से reflash कर पाना बेहतर होता, लेकिन Rabbit ऐसा कोई साधन नहीं देता
- R1 को unattended छोड़ने पर device में stored data relevant knowledge रखने वाले व्यक्ति द्वारा आसानी से extract किया जा सकता है
- बेचने, दान देने या dispose करने से पहले नए जोड़े गए settings option से factory reset पहले करना चाहिए
GPL violation और conclusion
- Rabbit R1 scroll wheel और rotating camera को छोड़कर किसी special hardware के बजाय एक सामान्य MediaTek Android device जैसा है
- AOSP customization ज्यादातर single-app kiosk mode enforce करने के लिए existing features हटाने के रूप में है
- boot chain security effective नहीं है, इसलिए device को सुरक्षित रूप से unattended छोड़ना मुश्किल है
- Rabbit Inc. Linux kernel के GPL2 license का उल्लंघन कर रहा है
- hall-effect scroll wheel detection driver closed-source है
- camera rotation stepper motor control driver भी closed-source है
- दोनों drivers GPL kernel image में statically linked हैं
- 12 जुलाई को Rabbit Inc. से article पर comment और GPL compliance plan के बारे में पूछा गया, लेकिन 22 जुलाई तक कोई response नहीं था
- released tethered jailbreak tool researchers को अपने owned R1 तक access देने और future advanced users को device functionality extend करने में मदद के लिए experimental tool है
1 टिप्पणियां
Hacker News की राय
GPL के तहत अनुरोध करने पर लाइसेंस और source code सार्वजनिक करना होता है, लेकिन Truth Social ने AGPL code इस्तेमाल करने की बात सामने आने तक लाइसेंस तक सार्वजनिक किए बिना बात टाल दी, और तभी source जारी किया
उत्सुकता है कि Rabbit भी इसी तरह बच निकलेगा या नहीं
व्यवहार में, जिन उल्लंघनों के बारे में rights holder को पता नहीं होता उन्हें track नहीं किया जा सकता, और आम तौर पर रुचि damages से ज्यादा उल्लंघनकर्ता को compliance में लाने में होती है
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
मुझे लगा था कि kernel modules के लिए, अगर kernel में खुद modification की जरूरत न हो, तो linking के तरीके से फर्क पड़े बिना Linux side पर GPL exception होता है
इन logs की सामग्री काफी गंदी है: सटीक GPS location, WiFi network names, SIM card न होने पर भी आसपास के cell tower IDs, बाहर expose होने वाला IP address, Rabbit backend API authentication के लिए user token, Rabbit ने user से जो कुछ भी कहा उसकी Base64-encoded MP3 और text transcript तक शामिल हैं
“पास में कोई अच्छा restaurant कौन-सा है?” जैसे सवाल का जवाब देने के लिए बनाए गए device का request के साथ location context भेजना हैरान करने वाला नहीं है, लेकिन बिना वजह location लगातार stream करना चिंता की बात होगी
WiFi names reconnect करने के लिए store करने पड़ते हैं, और local logs में IP address दिखना भी बहुत अजीब नहीं है
User access token भी हर बार login किए बिना reconnect करने के लिए device पर store होना ही पड़ता है। हालांकि token को logs में plain छोड़ना अच्छी practice नहीं है, और अगर logs उसी DB या config file जैसी storage में हैं, तो यह अपने आप में पूरी तरह नई समस्या नहीं है। अगर logs सीधे server पर upload होते हैं तो जाहिर है समस्या है
अगर आप चाहते थे कि ऐसा device smooth और magic की तरह काम करे, तो उसे लगातार सुनना, देखना और location भेजना होगा। असल में यह सही से काम करे तो local inference चाहिए, और समझ नहीं आता कि उस चीज के लिए पैसा क्यों दें जिसका 5 साल बाद Apple बहुत बेहतर version बना देगा, लेकिन अगर खरीद ही रहे हैं तो ऐसा तरीका जरूरी है
बड़ी कंपनियों से नफरत करते हुए यह उम्मीद नहीं कर सकते कि startup बिना data के अच्छा product बनाए। Rabbit के पास भविष्य में कुछ बेहतर बनाने की संभावना भी रखनी हो तो उसे ऐसा data चाहिए
अगर यह असहज लगता है, तो साफ बताना होगा कि क्यों। ज्यादातर बातें अपने आप में बहुत चिंता की नहीं हैं
मजेदार है। Rabbit में काम किया, codebase पढ़ा और executives से gaslighting झेलने के बाद quit कर दिया
बाहर से दिख रहे jailbreak और vulnerabilities ही देखकर लगता है कि यह बस iceberg का tip है
Rabbit ने जवाब नहीं दिया शायद इसलिए कि lawyers देख रहे हैं कि मुकदमा कैसे करना है
वास्तव में जवाब देने के लिए business hours लगभग दिए ही नहीं गए
RabbitOS developers USB के जरिए bootloader access रोकने के लिए eFuse set करके इस समस्या को patch कर सकते हैं
Moto ने भी कुछ साल पहले MediaTek devices में इसी bootrom attack surface के vulnerable होने पर ऐसा ही किया था। अगर मेरी याद सही है, यह eFuse LK stage में set हुआ था और सामान्य wireless firmware update से apply हुआ था
लेख बढ़िया है
software कूड़े जैसा दिखता है, और company भी अब तक कुछ खास अच्छी नहीं लगती
फिर भी kiosk mode में भी custom apps आसानी से चला सकें तो इस form factor से काफी दिलचस्प use cases बन सकते हैं
अगर PWA को किसी तरह चढ़ाया जा सके, तो ESP32, battery और screen खुद जोड़कर बनाने से बहुत तेज होगा, और यह काफी अच्छा integrated device लगता है
ideally, Google services के बिना ज्यादा सुरक्षित तरीके से चल सके तो अच्छा होगा, GrapheneOS जैसी दिशा ठीक लगेगी
अभी खोजा नहीं है, लेकिन जानना चाहूंगा कि इस तरह single-purpose custom apps के लिए इसका उपयोग करने के examples या references हैं क्या
अगर कीमत 50 dollars से कम हो जाए, जैसे server बंद कर देने के बाद, तब मैं मान सकता हूं कि यह अच्छा hardware platform है
काश यह product सफल हुआ होता
उम्मीद है कि भविष्य के hardware user interface + AI experiments पर यह बोझ की तरह न रह जाए। कांच के rectangle पर tap और swipe करने से बेहतर किया जा सकता है—Bret Victor वाली सोच से मैं अभी भी सहमत हूं
और भी सुविधा से, smartwatch queries को phone तक relay कर सकती है
Humane ने शायद वास्तविक समस्या हल नहीं की, फिर भी सच में कुछ अलग try करने के लिए कुछ सम्मान मिलता है। Rabbit R1 बस सस्ता कबाड़ है
Rabbit को लेकर शुरुआती goodwill का सारा या ज्यादातर हिस्सा Teenage Engineering design की वजह से था, यह थोड़ा मजेदार है
उम्मीद है TE आगे clients चुनने में ज्यादा सावधान होगा। Rabbit के पीछे वाला व्यक्ति जाना-माना scammer है
नाम search कर सकता हूं, लेकिन आजकल search quality इतनी खराब है कि नहीं करने वाला। अगर आलोचना को विस्तार से दिखाने वाला link हो तो उपयोगी होगा
यह AI assistants की दुनिया का Juicero जैसा है
बस company ने सोचा कि लोग company-exclusive pre-cut fruit mix bags को squeeze करने वाली machine के लिए absurd पैसे देंगे। सब कुछ exactly intended तरह से काम कर रहा था; असली business model ही बेतुका था
Mycroft(https://en.wikipedia.org/wiki/Mycroft_(software)) और Leon(https://getleon.ai) को मिलाकर बने किसी privacy-preserving open source AI assistant की उम्मीद थी