- Rabbit R1 เป็นอุปกรณ์ที่ทำงานบนแอปซึ่งรันเหมือนโหมด kiosk บน Android 13 AOSP และมีการทำ tethered jailbreak เพื่อให้ได้ root shell โดยไม่ต้องปลดล็อก bootloader หรือแก้ไขที่เก็บข้อมูลภายใน
- การเจลเบรกปล่อยให้การตรวจสอบของ boot chain ของ MediaTek ผ่านไปตามปกติ แล้วแทนที่อิมเมจ
boot แบบกำหนดเองที่อัปโหลดผ่าน USB เข้าไปในหน่วยความจำ ในจังหวะก่อนที่อิมเมจ boot ที่ผ่านการตรวจสอบแล้วจะถูกใช้งานจริง
- R1 ใช้ MediaTek MT6765, DRAM 4GB และ eMMC 128GB และสามารถเข้าถึง
uid=0(root) ผ่าน TCP bind shell ได้แม้ในสถานะที่ ro.boot.verifiedbootstate เป็น green
- ในล็อกของที่เก็บข้อมูลภายในมีข้อมูลตำแหน่ง GPS, ชื่อ WiFi, ID สถานีฐานใกล้เคียง, IP ภายนอก, โทเค็นผู้ใช้สำหรับ Rabbit backend API, ไฟล์ MP3 เสียงของ Rabbit และข้อความถอดเสียงหลงเหลืออยู่ และใน RabbitOS v0.8.112 มีการลดการเก็บล็อกและเพิ่มตัวเลือกรีเซ็ตเป็นค่าโรงงาน
- Rabbit Inc. ไม่ได้เผยแพร่ซอร์สของไดรเวอร์ hall-effect scroll wheel และไดรเวอร์มอเตอร์กล้องหมุนที่ลิงก์แบบ static กับ Linux kernel จึงอยู่ในสถานะ ละเมิด GPL2 และ ณ วันที่ 22 กรกฎาคม ยังไม่ได้ตอบคำถามที่เกี่ยวข้อง
จุดเริ่มต้นของการวิเคราะห์ Rabbit R1
- Rabbit R1 ได้รับคำวิจารณ์เชิงลบจากนักวิจารณ์ และในตลาดมือสองมีสินค้ายังไม่แกะกล่องขายต่ำกว่าราคาปลีก 200 ดอลลาร์
- RabbitOS ไม่ใช่โมเดล AI ภายในเครื่องแยกต่างหาก แต่เป็นแอปที่รันเหมือนโหมด kiosk บน Android 13 AOSP และสื่อสารกับคลาวด์ด้วย JSON API บน WebSocket
- มีรายงานว่าคีย์ API ที่ถูกเปิดเผยก่อนหน้านี้รั่วจากซอร์สโค้ดฝั่งเซิร์ฟเวอร์ และไม่ได้ถูกเก็บไว้ในตัวอุปกรณ์
- หลังจากนั้น การอัปเดตแอปได้นำเครื่องมือ obfuscation เชิงพาณิชย์มาใช้ และมีตรรกะตรวจจับเครื่องมือวิเคราะห์อย่าง Magisk และ Frida รวมถึงตรวจสอบว่าเป็นอุปกรณ์ R1 หรือไม่
- เมื่อการติดตามด้วย static analysis อย่างเดียวเริ่มยุ่งยาก จึงซื้อ R1 จาก eBay ในราคา £122 และดำเนินการวิเคราะห์ runtime โดยคง firmware จากโรงงานไว้ให้มากที่สุดเท่าที่ทำได้
ฮาร์ดแวร์ R1 และสถานะความปลอดภัยพื้นฐาน
- R1 ใช้ SoC MediaTek MT6765, DRAM 4GB และที่เก็บข้อมูล eMMC 128GB
- MT6765 มี bootrom exploit ชื่อ
kamakiri ที่รู้จักกันมาตั้งแต่ปี 2019
- ที่เก็บข้อมูล 128GB ดูเป็นตัวเลือกที่แปลกเมื่อพิจารณาลักษณะของอุปกรณ์ที่ไม่ได้มีข้อมูลในเครื่องมากนัก
- เจ้าของ R1 ยืนยันแล้วว่าสามารถใช้
mtkclient เพื่อ unlock bootloader และแฟลช custom ROM หรือ root ได้
- เป้าหมายของการวิเคราะห์ไม่ใช่การใส่อิมเมจระบบ Android แบบกำหนดเอง แต่คือการตรวจดู firmware ที่ติดตั้งจากโรงงาน โดยคงสภาพไว้ให้ใกล้เดิมที่สุด
- วิธี unlock bootloader แล้วติดตั้ง Magisk มีปัญหาหลายอย่าง
- OTA delta update อาจเสียหายได้
- อาจถูกตรวจจับโดยโค้ดป้องกันการวิเคราะห์ในปัจจุบัน
- หากอัปเดตในอนาคตตรวจค่าอย่าง
ro.boot.verifiedbootstate ก็อาจถูกตรวจพบได้
- ดังนั้นจึงต้องหาทางได้สิทธิ์ root ภายในเครื่อง โดยลดจุดที่มีการเปลี่ยนแปลงให้เหลือน้อยที่สุด เพื่อลดพื้นผิวที่ตรรกะป้องกันการวิเคราะห์จะตรวจจับได้
Boot chain บน MediaTek
- Boot chain ประกอบด้วยตรรกะของ MediaTek และจุดเริ่มต้นคือ bootrom ที่ฝังอยู่ในซิลิคอนของ CPU
- bootrom จะทำ initialization ฮาร์ดแวร์พื้นฐาน แล้วโหลด
Preloader จากพาร์ทิชัน eMMC boot0 เข้า SRAM
- Preloader มีการเซ็นลายเซ็น และ bootrom จะตรวจสอบลายเซ็น
- อย่างไรก็ตาม ใน R1 มีความเป็นไปได้ว่าจะไม่ได้ตรวจสอบจริง จึงต้องยืนยันเพิ่มเติม
- Preloader initialize DRAM และโหลดอิมเมจสามตัวจากพาร์ทิชัน GPT ของ eMMC เข้า DRAM
tee: Arm Trusted Firmware, EL3gz: GenieZone Hypervisor, EL2lk: Little Kernel, EL1
- LK ใช้ Android Verified Boot 2.0 และ
dm-verity
- หาก bootloader อยู่ในสถานะ locked เมื่อการตรวจสอบล้มเหลวจะปฏิเสธการบูต
- หากอยู่ในสถานะ unlocked จะแสดงคำเตือนและตั้งค่า flag ที่เกี่ยวข้องกับ orange state
- หากการตรวจสอบ
dm-verity ล้มเหลว จะไม่บูตแม้ bootloader จะอยู่ในสถานะ unlocked
- เมื่อการตรวจสอบผ่าน LK จะคลายบีบอัด Linux kernel แล้วบูต และ kernel จะเรียกใช้
/init จาก initramfs
- R1 ใช้ A/B partitioning ดังนั้น
boot จะเป็น boot_a หรือ boot_b ตาม slot ที่ active
- สถานะ lock/unlock ของ bootloader ถูกเก็บในพาร์ทิชัน GPT
seccfg
seccfg ประกอบด้วย flag หลายตัวและ hash ที่เข้ารหัสไว้- byte สุดท้ายของพาร์ทิชัน
frp มีส่วนเกี่ยวข้องกับการอนุญาต unlock bootloader เช่น fastboot flashing unlock
carroot: tethered jailbreak ที่ไม่แตะที่เก็บข้อมูล
- root of trust ของ trust chain คือ hash ของใบรับรองที่อยู่ใน CPU efuse และโค้ด bootrom ที่ตรวจสอบมัน
- MT6765 มี bootrom exploit
kamakiri แต่บน R1 แม้ไม่ใช้ exploit โหมด USB bootloader ของ brom และ Preloader ก็รับอิมเมจ DA ที่ unsigned แล้วรันในหน่วยความจำได้
- สร้าง DA payload เองเพื่อให้ Preloader โหลดเข้า DRAM
- ลำดับการทำงานมีดังนี้
- โหลดอิมเมจ Android
boot แบบกำหนดเองเข้า DRAM ผ่าน USB
- ติดตั้ง hook ก่อนที่ Preloader จะ jump ไป LK
- กลับไปที่ Preloader แล้วดำเนินกระบวนการบูตปกติต่อ
- Preloader โหลดและตรวจสอบอิมเมจ
tee, gz, lk จาก eMMC
- hook ทำงานก่อนเข้า LK และติดตั้ง hook กับ patch เพิ่มเติมใน LK
- LK โหลดและตรวจสอบพาร์ทิชัน
boot เดิมจาก eMMC
- ในจังหวะที่อิมเมจ
boot ถูกคัดลอกจากโค้ด AVB ไปยังโค้ดบูต Linux, hook จะแทนที่ด้วยอิมเมจ boot แบบกำหนดเองที่อัปโหลดผ่าน USB
- มีการแสดงข้อความแบบกำหนดเองบนหน้าจอด้วย
- แก่นของวิธีนี้คือปล่อยให้ข้อมูลเป้าหมายการตรวจสอบถูกตรวจสอบตามเดิม แล้วค่อยแทนที่ด้วยข้อมูลที่ patch แล้ว หลังตรวจสอบเสร็จและก่อนถูกใช้งานจริง
- ไม่แก้ไข flash storage เลย และกระบวนการเจลเบรกทั้งหมดเกิดขึ้นเฉพาะในหน่วยความจำ
- เมื่อรีบูต อุปกรณ์จะกลับสู่สถานะสะอาด
- ในกระบวนการ reverse engineering จึงย้อนกลับสู่สภาพเดิมได้ง่าย
- อิมเมจ
boot แบบกำหนดเองใช้ flashable-android-rootkit
- แทนที่ไบนารี
/init พื้นฐานเพื่อ inject payload ที่เป็นบริการ user space สิทธิ์สูงสุด
- เครื่องมือ patch อิมเมจ
magiskboot นำมาจากโปรเจกต์ Magisk
- ใช้ magiskboot_build เพื่อ build และรัน
magiskboot บน Linux ทั่วไป
- payload เป็น TCP bind shell แบบง่าย
- ไม่ใช่วิธีที่แอบซ่อน และแอป Rabbit อาจตรวจจับได้
- หากจำเป็นสามารถปรับปรุงในภายหลังได้
เครื่องมือเจลเบรกบน WebSerial และผลการรัน
- สำหรับการควบคุมอุปกรณ์ MediaTek นั้น mtkclient มีฟังก์ชันที่จำเป็นให้อยู่แล้ว แต่ได้เขียน Python USB client เองเพื่อทำความเข้าใจการทำงาน
- ต่อมาพอร์ตไปเป็น js/WebSerial เพื่อให้เจลเบรก Rabbit R1 ที่เชื่อมต่ออยู่จริงได้จากหน้าเว็บ
- ตั้งชื่อการเจลเบรกว่า carroot โดยอิงมุกคำว่า rabbit
- เครื่องมือทดลองเผยแพร่ไว้ที่ r1_jailbreak
- ผลหลังบูตแล้วเชื่อมต่อผ่าน TCP bind shell มีดังนี้
$ 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
- ระบบรับรู้สถานะ secure boot เป็น
green แต่ยังยอมให้เข้าถึง root shell ได้
- SELinux domain
rootkit ถูกตั้งค่าโดย flashable-android-rootkit
อินเทอร์เฟซของอุปกรณ์และเอกสารอ้างอิงที่ใช้ในการวิเคราะห์
- ภาพ teardown ของ R1 จาก iFixit เห็น test pad ที่ระบุว่า TX และ RX ซึ่งเป็น UART test pad
- UART ให้ debug log ตลอดทั้ง boot chain
- ช่วง brom ใช้ 115200 baud
- ช่วงหลังจากนั้นใช้ 921600 baud
- logic level คือ 1.8V และในอุปกรณ์ที่ใช้วิเคราะห์ 3.3V ก็ทำงานได้โดยไม่เสียหาย
- Preloader จะปิด UART logging หากไม่ได้กดปุ่ม volume-up
- R1 ไม่มีปุ่ม volume-up จึง patch Preloader เพื่อปิดการตรวจสอบนี้
- Preloader ที่ patch แล้วสามารถบูตผ่าน USB download mode ของ bootrom ได้
- ใน command line ของ Linux kernel ได้ patch flag ต่อไปนี้เพื่อส่ง kernel log ออกทาง UART
earlycon console=ttyS1,921600
- ด้วยชุด patch นี้จึงเก็บ UART log ของกระบวนการบูตทั้งหมดได้
- หากดึง test pad ข้างปุ่ม reset ที่เข้าถึงได้ผ่านช่อง SIM ลง GND ระหว่าง reset จะบูตเข้า brom USB mode ได้
- แหล่งอ้างอิงหลักมีดังนี้
ข้อมูลส่วนบุคคลที่พบในล็อกภายใน
- R1 ทิ้งล็อกข้อความแยกตามวันที่ไว้ใต้
Android/data/tech.rabbit.r1launcher.r1/files/logs/ ในที่เก็บข้อมูลภายใน
- ณ วันที่ 7 กรกฎาคม 2024 ไดเรกทอรีล็อกมีไฟล์
.log หลายวัน และบางไฟล์มีขนาดหลาย MB
- ล็อกมีข้อมูลต่อไปนี้
- ตำแหน่ง GPS ที่แม่นยำ
- ชื่อเครือข่าย WiFi
- ID สถานีฐานใกล้เคียงที่เก็บแม้ไม่มี SIM card
- IP address ที่เห็นจากอินเทอร์เน็ต
- โทเค็นผู้ใช้ที่ใช้ยืนยันตัวตนกับ Rabbit backend API
- MP3 ที่เข้ารหัส Base64 ของทุกสิ่งที่ Rabbit พูดกับผู้ใช้และข้อความถอดเสียง
- ในข้อมูลเหล่านี้ ตำแหน่ง GPS และ ID สถานีฐานใกล้เคียงถูกส่งไปยังเซิร์ฟเวอร์ Rabbit ด้วย
- ปัญหามีสองอย่าง
- เก็บล็อกข้อมูลละเอียดเกินไปบนอุปกรณ์ที่ไม่มีความปลอดภัยฮาร์ดแวร์อย่างมีนัยสำคัญ
- ผู้ใช้ทั่วไปไม่มีวิธี factory reset ทำให้ล็อกแทบจะคงอยู่ถาวร
- ในสถานการณ์ที่ตลาดมือสองคึกคัก ล็อกของผู้ใช้ก่อนหน้าอาจหลงเหลือเมื่อขาย บริจาค หรือทิ้งอุปกรณ์
- RabbitOS v0.8.112 ลดการเก็บล็อกและเพิ่มตัวเลือกการตั้งค่า factory reset ผ่าน ประกาศด้านความปลอดภัย
- การตอบสนองนี้เกิดขึ้นอย่างรวดเร็ว และถูกประเมินว่าเป็นกรณีแรกที่ Rabbit รับมือกับประเด็นความเป็นส่วนตัวและความปลอดภัยของผู้ใช้ค่อนข้างเชิงรุก
ขอบเขตจริงของการปรับแต่ง AOSP
- Rabbit เคยอธิบายต่อรายงานที่ว่า RabbitOS เป็นเพียงแอปธรรมดาว่าเป็น AOSP ที่ปรับแต่งอย่างมากและมี “lower level firmware modifications”
- การปรับแต่งที่ยืนยันได้จนถึงตอนนี้ส่วนใหญ่เป็นการลบฟังก์ชัน Android เพื่อคง single-app kiosk mode
- ไม่มี navigation bar
- ไม่มี notification bar
- มีมาตรการพยายามป้องกันการเปิดใช้ ADB
- แอปชื่อ
Judy รันอยู่เบื้องหลังและจะปิด ADB หากพบว่า ADB กำลังทำงาน
- วันที่ 4 กรกฎาคม @MarcelD505 เผยแพร่วิธี kiosk escape โดยเริ่มจากเบราว์เซอร์สำหรับ WiFi captive portal login แล้วเข้าไปยังแอป Android system settings
- ในอัปเดตล่าสุด Rabbit ปิดเส้นทางนี้โดยลบแอป Android system settings ออกจากอุปกรณ์ทั้งหมด
- การเปลี่ยนแปลง AOSP แบบ bespoke ที่ยืนยันได้จนถึงตอนนี้ใกล้เคียงกับการ ลบฟีเจอร์ มากกว่าการเพิ่มฟังก์ชันเดิม
- ยังไม่พบเหตุผลทางเทคนิคที่ทำให้มองได้ว่า RabbitOS ที่ใช้งานอยู่ในปัจจุบันเป็นไปไม่ได้ที่จะทำเป็นแอปสมาร์ตโฟนทั่วไป
สิ่งที่ผู้ใช้ R1 ทั่วไปควรกังวล
- หากกังวลว่าอาจถูกเจลเบรกโดยไม่ต้องการ ให้ปิดแล้วเปิดเครื่องใหม่
- หากบูตได้ตามปกติโดยไม่มีข้อความเตือน โดยทั่วไปอาจถือว่าปลอดภัย
- แต่หาก brom ถูกตั้งค่าให้บูตอิมเมจ Preloader ที่ unsigned จาก eMMC ก็ยังไม่แน่นอนและต้องทดสอบเพิ่มเติม
- หากสามารถแฟลชกลับด้วยอิมเมจ stock firmware ที่เชื่อถือได้จาก vendor จะดีกว่า แต่ Rabbit ไม่ได้จัดเตรียมวิธีดังกล่าวไว้
- หากปล่อย R1 ไว้โดยไม่มีคนเฝ้า ข้อมูลที่เก็บอยู่ในอุปกรณ์อาจถูกดึงออกมาได้ง่ายโดยผู้ที่มีความรู้เกี่ยวข้อง
- ก่อนขาย บริจาค หรือทิ้ง ควรใช้ตัวเลือกการตั้งค่าที่เพิ่มเข้ามาใหม่เพื่อทำ factory reset ก่อน
การละเมิด GPL และข้อสรุป
- Rabbit R1 ใกล้เคียงกับอุปกรณ์ Android MediaTek ทั่วไปที่ไม่ใช่ฮาร์ดแวร์เฉพาะทาง ยกเว้น scroll wheel และกล้องหมุน
- การปรับแต่ง AOSP ส่วนใหญ่เป็นการลบฟังก์ชันเดิมเพื่อบังคับใช้ single-app kiosk mode
- ความปลอดภัยของ boot chain ไม่มีประสิทธิผล ทำให้ยากที่จะปล่อยอุปกรณ์ทิ้งไว้อย่างปลอดภัย
- Rabbit Inc. กำลังละเมิด ไลเซนส์ GPL2 ของ Linux kernel
- ไดรเวอร์ตรวจจับ hall-effect scroll wheel ยังเป็น closed-source
- ไดรเวอร์ควบคุม stepper motor สำหรับหมุนกล้องก็ยังเป็น closed-source
- ไดรเวอร์ทั้งสองถูกลิงก์แบบ static เข้ากับ GPL kernel image
- วันที่ 12 กรกฎาคม มีการสอบถาม Rabbit Inc. เรื่องคอมเมนต์ต่อเนื้อหาและแผนการปฏิบัติตาม GPL แต่ ณ วันที่ 22 กรกฎาคม ยังไม่ได้รับคำตอบ
- เครื่องมือ tethered jailbreak ที่เผยแพร่นี้เป็นเครื่องมือทดลองเพื่อช่วยให้นักวิจัยเข้าถึง R1 ที่ตนเองเป็นเจ้าของ และช่วยให้ผู้ใช้ขั้นสูงสามารถขยายความสามารถของอุปกรณ์ในอนาคต
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
GPL กำหนดว่าต้องเปิดเผยไลเซนส์และ ซอร์สโค้ด เมื่อมีการร้องขอ แต่ Truth Social ก็ปล่อยผ่านโดยไม่เปิดเผยแม้แต่ไลเซนส์ จนกระทั่งถูกเปิดโปงว่าใช้โค้ด AGPL แล้วจึงค่อยเปิดซอร์ส
เลยสงสัยว่า Rabbit จะเอาตัวรอดแบบเดียวกันหรือเปล่า
ในทางปฏิบัติ การละเมิดที่เจ้าของสิทธิ์ไม่รู้ก็ไล่ตามไม่ได้ และโดยทั่วไปผู้ถือสิทธิ์มักสนใจทำให้ผู้ละเมิดกลับมาปฏิบัติตาม มากกว่าการเรียกค่าเสียหาย
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
เคยคิดว่าฝั่ง Linux มีข้อยกเว้น GPL สำหรับ kernel module อยู่ ตราบใดที่ไม่ต้องแก้ตัวเคอร์เนลเอง ไม่ว่าจะลิงก์แบบไหนก็ตาม
เนื้อหาในล็อกนี้ค่อนข้างเละเทะมาก: มีทั้งตำแหน่ง GPS ที่แม่นยำ, ชื่อเครือข่าย WiFi, ID สถานีฐานใกล้เคียงแม้ไม่มีซิมการ์ด, ที่อยู่ IP ที่เปิดเผยต่อภายนอก, โทเค็นผู้ใช้สำหรับยืนยันตัวตนกับ Rabbit backend API, รวมถึง MP3 ที่เข้ารหัส Base64 ของทุกอย่างที่ Rabbit พูดกับผู้ใช้ และข้อความถอดเสียงด้วย
อุปกรณ์ที่สร้างมาให้ตอบคำถามอย่าง “ร้านอาหารดี ๆ แถวนี้มีที่ไหนบ้าง?” ส่ง บริบทตำแหน่ง ไปพร้อมคำขอก็ไม่ใช่เรื่องน่าแปลกใจ แต่ถ้ามันสตรีมตำแหน่งตลอดเวลาโดยไม่มีเหตุผล อันนั้นน่ากังวล
ชื่อ WiFi ก็ต้องเก็บไว้เพื่อเชื่อมต่อใหม่ และการเห็น IP address ในล็อกภายในเครื่องก็ไม่ได้แปลกมาก
โทเค็นเข้าถึงของผู้ใช้ก็หลีกเลี่ยงไม่ได้ที่จะต้องเก็บในอุปกรณ์ ถ้าต้องการเชื่อมต่อใหม่โดยไม่ให้ล็อกอินทุกครั้ง แต่การทิ้งโทเค็นไว้ในล็อกแบบตรง ๆ เป็นแนวปฏิบัติที่ไม่ดี และถ้าล็อกอยู่ในสตอเรจเดียวกับ DB หรือไฟล์ตั้งค่านั้น ก็ไม่ได้เป็นปัญหาใหม่ทั้งหมดในตัวมันเอง แต่ถ้าอัปโหลดล็อกขึ้นเซิร์ฟเวอร์ทันที แน่นอนว่าเป็นปัญหา
ถ้าอยากให้อุปกรณ์แบบนี้ทำงานได้ลื่นไหลและเหมือนเวทมนตร์ มันก็ต้องคอยฟัง คอยดู และส่งตำแหน่งอยู่เรื่อย ๆ จริง ๆ แล้วถ้าจะให้ทำได้ดีต้องมีการอนุมานในเครื่อง และผมก็ไม่รู้ว่าทำไมถึงยอมจ่ายเงินซื้อของที่อีก 5 ปี Apple คงทำเวอร์ชันที่ดีกว่ามากออกมา แต่ถ้าจะซื้อจริง ๆ ก็ต้องทำงานแบบนี้
จะไม่ชอบบริษัทยักษ์ใหญ่ แต่ก็คาดหวังให้สตาร์ทอัพสร้างผลิตภัณฑ์ดี ๆ โดยไม่มีข้อมูลไม่ได้ ถ้า Rabbit จะมีโอกาสสร้างสิ่งที่ดีกว่าในอนาคต ก็ต้องมีข้อมูลแบบนี้
ถ้าจะบอกว่าเรื่องนี้ทำให้ไม่สบายใจ ก็ควรอธิบายให้ชัดว่าไม่สบายใจเพราะอะไร ส่วนใหญ่แล้วมันไม่ได้เป็นเรื่องที่ต้องกังวลมากในตัวเอง
ตลกดี ผมเคยทำงานที่ Rabbit แล้วลาออกหลังจากอ่าน codebase และถูกผู้บริหาร gaslight
แค่ดูการ jailbreak และช่องโหว่จากภายนอกก็ดูเหมือนเป็นแค่ยอดภูเขาน้ำแข็งแล้ว
ที่ Rabbit ไม่ตอบ น่าจะเพราะทนายกำลังดูว่าจะฟ้องอย่างไรอยู่
แทบไม่ได้ให้เวลาทำการที่เขาจะตอบได้จริงเลย
นักพัฒนา RabbitOS สามารถแพตช์ปัญหานี้ได้โดยตั้งค่า eFuse เพื่อบล็อกการเข้าถึง bootloader ผ่าน USB
Moto ก็เคยจัดการแบบนี้เมื่อหลายปีก่อน ตอนอุปกรณ์ MediaTek มีพื้นผิวโจมตี boot ROM แบบเดียวกัน ถ้าจำไม่ผิด eFuse นี้ถูกตั้งค่าในขั้น LK และนำไปใช้ผ่านการอัปเดตเฟิร์มแวร์แบบไร้สายตามปกติ
บทความเจ๋งดี
ซอฟต์แวร์ดูเหมือนขยะ และบริษัทจนถึงตอนนี้ก็ดูไม่ค่อยดีเท่าไร
แต่ถ้ารันแอปคัสตอมได้ง่าย ๆ แม้จะอยู่ใน kiosk mode ฟอร์มแฟกเตอร์นี้ก็น่าจะเอาไปใช้ทำอะไรที่น่าสนใจได้ไม่น้อย
ถ้าเอา PWA ไปวางแบบคร่าว ๆ ได้ ก็คงเร็วกว่าการเอา ESP32, แบตเตอรี่ และหน้าจอมาต่อเองมาก และดูเหมือนเป็นอุปกรณ์แบบ all-in-one ที่ค่อนข้างดี
ตามอุดมคติแล้ว อยากให้รันได้ปลอดภัยขึ้นโดยไม่มีบริการของ Google และถ้าไปในแนว GrapheneOS ก็น่าจะโอเค
ยังไม่ได้ลองค้นดู แต่สงสัยว่ามีกรณีใช้งานหรือเอกสารอ้างอิงสำหรับการใช้เป็น แอปคัสตอมวัตถุประสงค์เดียว แบบนี้ไหม
ถ้าราคาลงมาต่ำกว่า 50 ดอลลาร์ เช่น หลังจากปิดเซิร์ฟเวอร์ไปแล้ว ตอนนั้นผมถึงจะเห็นด้วยว่าเป็นแพลตฟอร์มฮาร์ดแวร์ที่ใช้ได้
เสียดาย อยากให้ผลิตภัณฑ์นี้ไปได้ดี
หวังว่ามันจะไม่กลายเป็นตัวปัญหาสำหรับการทดลอง ส่วนติดต่อผู้ใช้แบบฮาร์ดแวร์ + AI ในอนาคต ผมยังเห็นด้วยกับแนวคิดแบบ Bret Victor ว่าเราทำได้ดีกว่าการแตะและปัดสี่เหลี่ยมกระจก
ถ้าจะให้สะดวกขึ้น สมาร์ตวอตช์ก็สามารถส่งต่อคำถามไปยังโทรศัพท์ได้
Humane ถึงจะดูเหมือนไม่ได้แก้ปัญหาจริง ๆ แต่อย่างน้อยก็พอให้ความเคารพได้ตรงที่พยายามทำอะไรที่แตกต่างจริง ๆ ส่วน Rabbit R1 ก็แค่ ของจุกจิกราคาถูก
ตลกดีที่ความประทับใจแรกต่อ Rabbit ทั้งหมดหรือเกือบทั้งหมดมาจาก ดีไซน์ของ Teenage Engineering
หวังว่า TE จะเลือกไคลเอนต์ให้ดีกว่านี้ในอนาคต คนที่อยู่เบื้องหลัง Rabbit เป็นนักต้มตุ๋นที่มีชื่อเสียง
คงค้นชื่อดูก็ได้ แต่คุณภาพการค้นหาสมัยนี้แย่มากจนไม่อยากทำ ถ้ามีลิงก์ที่แสดงคำวิจารณ์ละเอียดกว่านี้ก็น่าจะมีประโยชน์
นี่เหมือน Juicero แห่งวงการผู้ช่วย AI
แค่บริษัทคิดว่าคนจะยอมจ่ายเงินมหาศาลให้เครื่องที่บีบถุงส่วนผสมผลไม้ที่หั่นเตรียมไว้ล่วงหน้าเฉพาะของบริษัท ทุกอย่างทำงานตรงตามที่ตั้งใจไว้เป๊ะ ๆ เพียงแต่ โมเดลธุรกิจ จริง ๆ มันไร้เหตุผล
เคยคาดหวัง ผู้ช่วย AI โอเพนซอร์สที่รักษาความเป็นส่วนตัว ประมาณการรวมกันของ Mycroft(https://en.wikipedia.org/wiki/Mycroft_(software)) และ Leon(https://getleon.ai)