- O Rabbit R1 é um dispositivo baseado em app que roda sobre Android 13 AOSP em algo como modo quiosque, e foi implementado um jailbreak tethered que obtém shell root sem desbloquear o bootloader nem alterar o armazenamento interno
- O jailbreak mantém a validação da cadeia de boot da MediaTek intacta e substitui, em memória, a imagem
boot por uma imagem customizada enviada por USB imediatamente antes de ela ser realmente usada
- O R1 usa MediaTek MT6765, 4 GB de DRAM e 128 GB de eMMC, e mesmo com
ro.boot.verifiedbootstate em green foi possível obter acesso uid=0(root) por um TCP bind shell
- Logs no armazenamento interno continham localização GPS, nomes de redes Wi‑Fi, IDs de torres de celular próximas, IP externo, tokens de usuário para a API de backend da Rabbit, além de MP3s de voz da Rabbit e suas transcrições; no RabbitOS v0.8.112 houve redução de logging e adição de opção de restauração de fábrica
- A Rabbit Inc. está em violação da GPL2 por não divulgar o código-fonte dos drivers do scroll wheel com sensor hall-effect e do motor da câmera rotativa, ambos vinculados estaticamente ao kernel Linux; até 22 de julho, a empresa não havia respondido aos questionamentos
O ponto de partida da análise do Rabbit R1
- O Rabbit R1 recebeu avaliações negativas de críticos, e no mercado de usados produtos lacrados estão sendo vendidos por menos do que o preço oficial de US$ 200
- O RabbitOS não é um modelo local de IA separado, mas sim um app rodando sobre Android 13 AOSP em algo como modo quiosque, comunicando-se com a nuvem por uma API JSON sobre WebSocket
- As chaves de API expostas relatadas anteriormente vieram, ao que se sabe, de código-fonte do lado do servidor, e não estavam armazenadas no aparelho
- Atualizações posteriores do app passaram a usar uma ferramenta comercial de ofuscação e incluíram lógica para detectar ferramentas de análise como Magisk e Frida, além de verificar se está rodando em um dispositivo R1
- Como a análise estática ficou trabalhosa, foi comprado um R1 no eBay por £122 e a análise em tempo de execução foi feita mantendo o firmware de fábrica o mais intacto possível
Hardware do R1 e estado básico de segurança
- O R1 usa SoC MediaTek MT6765, 4 GB de DRAM e 128 GB de armazenamento eMMC
- O MT6765 tem o exploit de bootrom
kamakiri, conhecido desde 2019
- Os 128 GB de armazenamento parecem uma escolha incomum para um dispositivo que aparentemente não mantém muitos dados locais
- Donos do R1 confirmaram que é possível usar
mtkclient para desbloquear o bootloader e instalar ROMs customizadas ou obter root
- O objetivo da análise não era instalar uma imagem Android customizada, mas investigar o aparelho mantendo o firmware instalado de fábrica o mais intacto possível
- A abordagem de desbloquear o bootloader e instalar Magisk traz vários problemas
- Atualizações OTA delta podem quebrar
- O código atual de anti-análise pode detectar isso
- Atualizações futuras podem detectar isso ao verificar valores como
ro.boot.verifiedbootstate
- Por isso, era necessário obter privilégios root locais reduzindo os pontos de alteração e minimizando a superfície detectável pela lógica anti-análise
Cadeia de boot baseada em MediaTek
- A cadeia de boot é composta pela lógica da MediaTek, e o ponto inicial é o bootrom gravado no silício da CPU
- O bootrom, após a inicialização básica do hardware, carrega o
Preloader da partição eMMC boot0 para a SRAM
- O Preloader é assinado, e o bootrom verifica sua assinatura
- Porém, no R1, é possível que essa verificação não aconteça na prática, exigindo confirmação adicional
- O Preloader inicializa a DRAM e carrega três imagens da partição GPT da eMMC para a DRAM
tee: Arm Trusted Firmware, EL3gz: GenieZone Hypervisor, EL2lk: Little Kernel, EL1
- O LK implementa Android Verified Boot 2.0 e
dm-verity
- Se o bootloader estiver locked, falhas de verificação impedem a inicialização
- Se estiver unlocked, aparece um aviso e flags relacionadas ao estado orange são definidas
- Se a verificação de
dm-verity falhar, o sistema não inicializa mesmo com o bootloader unlocked
- Quando a verificação passa, o LK descompacta e inicializa o kernel Linux, que executa
/init do initramfs
- O R1 usa particionamento A/B, então
boot é boot_a ou boot_b dependendo do slot ativo
- O estado de lock/unlock do bootloader é armazenado na partição GPT
seccfg
seccfg consiste em algumas flags e um hash criptografado- O último byte da partição
frp participa da permissão para desbloqueio do bootloader com algo como fastboot flashing unlock
carroot: jailbreak tethered sem tocar no armazenamento
- A root of trust da cadeia de confiança é o hash do certificado gravado em efuse da CPU e o código do bootrom que o verifica
- O MT6765 tem o exploit de bootrom
kamakiri, mas no R1, mesmo sem exploit, o modo USB bootloader do brom e do Preloader aceita uma imagem DA unsigned e a executa em memória
- Foi criado um payload DA próprio para que o Preloader o carregasse na DRAM
- O fluxo de funcionamento é o seguinte
- Uma imagem Android
boot customizada é carregada na DRAM por USB
- Um hook é instalado imediatamente antes de o Preloader saltar para o LK
- O controle retorna ao Preloader para seguir o processo normal de boot
- O Preloader carrega e valida da eMMC as imagens
tee, gz e lk
- Logo antes da entrada no LK, o hook é executado e instala hooks e patches adicionais dentro do LK
- O LK carrega e valida a partição
boot original da eMMC
- No momento em que a imagem
boot é copiada do código AVB para o código de boot do Linux, o hook a substitui pela imagem boot customizada enviada por USB
- Uma mensagem customizada também é mostrada na tela
- O ponto principal é deixar que os dados originalmente validados sejam verificados normalmente e substituir os dados alterados após a verificação, imediatamente antes do uso
- O armazenamento flash não é modificado em nenhum momento, e todo o jailbreak acontece apenas na memória
- Ao reiniciar, o aparelho volta a um estado limpo
- Isso facilita restaurar o estado original durante a engenharia reversa
- A imagem
boot customizada usa flashable-android-rootkit
- O binário
/init padrão é substituído para injetar um payload como serviço de user space com privilégios máximos
- A ferramenta
magiskboot usada para patch na imagem foi obtida do projeto Magisk
- Para compilar e executar
magiskboot em Linux comum, foi usado magiskboot_build
- O payload é um simples TCP bind shell
- Não é um método discreto e pode ser detectado pelo app da Rabbit
- Se necessário, isso pode ser melhorado depois
Ferramenta de jailbreak baseada em WebSerial e resultado da execução
- Para manipular dispositivos MediaTek, o mtkclient já fornece as funções necessárias, mas para entender o funcionamento foi escrito diretamente um cliente USB em Python
- Depois isso foi portado para js/WebSerial, permitindo fazer o jailbreak de um Rabbit R1 fisicamente conectado a partir de uma página web
- O nome do jailbreak, em trocadilho com rabbit, foi definido como carroot
- A ferramenta experimental foi publicada em r1_jailbreak
- Após a inicialização, o resultado da conexão ao TCP bind shell foi o seguinte
$ 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
- O sistema reconhecia o estado de secure boot como
green e ainda assim permitia acesso a um shell root
- O domínio SELinux
rootkit é configurado por flashable-android-rootkit
Interfaces do dispositivo usadas na análise e materiais de referência
- Nas fotos de desmontagem do iFixit do R1, aparecem test pads marcados como TX e RX, que são pads de teste UART
- A UART fornece logs de depuração de toda a cadeia de boot
- A fase brom usa 115200 baud
- As fases seguintes usam 921600 baud
- O nível lógico é 1,8 V, embora 3,3 V também tenha funcionado sem dano no equipamento de análise
- O Preloader desativa o logging via UART se o botão volume-up não estiver pressionado
- Como o R1 não tem botão volume-up, o Preloader foi patchado para desativar essa checagem
- O Preloader patchado pode inicializar no modo USB download do bootrom
- Na command line do kernel Linux foram patchadas as seguintes flags para enviar logs do kernel pela UART
earlycon console=ttyS1,921600
- Com essa combinação de patches, foi coletado o log UART de todo o processo de boot
- Um test pad ao lado do botão reset, acessível pelo slot do SIM, pode ser conectado ao GND durante o reset para inicializar no modo brom USB
- As principais referências foram as seguintes
Dados pessoais encontrados nos logs internos
- O R1 estava gravando logs de texto por data em
Android/data/tech.rabbit.r1launcher.r1/files/logs/ no armazenamento interno
- Em 7 de julho de 2024, o diretório de logs continha arquivos
.log de várias datas, e alguns tinham vários MB
- Os logs incluíam os seguintes dados
- Localização GPS precisa
- Nome da rede Wi‑Fi
- IDs de torres de celular próximas, coletados mesmo sem cartão SIM
- Endereço IP exposto à internet
- Token de usuário usado na autenticação da API de backend da Rabbit
- MP3 em Base64 de tudo o que a Rabbit disse ao usuário, além da transcrição em texto
- Entre esses dados, a localização GPS e os IDs de torres próximas também eram enviados aos servidores da Rabbit
- Havia dois problemas
- O dispositivo, que não oferece segurança de hardware significativa, estava registrando dados excessivamente detalhados
- Usuários comuns não tinham como fazer restauração de fábrica, então os logs ficavam efetivamente armazenados de forma permanente
- Em um cenário de revenda ativa, logs do usuário anterior poderiam permanecer no aparelho após venda, doação ou descarte
- No RabbitOS v0.8.112, por meio de um aviso de segurança, o logging foi reduzido e foi adicionada uma opção de restauração de fábrica nas configurações
- A resposta foi rápida e é vista como o primeiro caso em que a Rabbit reagiu de forma relativamente proativa a questões de privacidade e segurança dos usuários
O real alcance das customizações do AOSP
- A Rabbit já explicou, em resposta a reportagens dizendo que o RabbitOS era apenas um app, que se tratava de um AOSP altamente customizado com “lower level firmware modifications”
- Até agora, as customizações confirmadas parecem focadas principalmente em remover recursos do Android para manter o modo quiosque de app único
- Sem barra de navegação
- Sem barra de notificações
- Há medidas para impedir a ativação do ADB
- Um app chamado
Judy roda em segundo plano e desativa o ADB se ele estiver em execução
- Em 4 de julho, @MarcelD505 publicou um método de escape do quiosque que começava pelo navegador de login de captive portal do Wi‑Fi e chegava ao app de configurações do sistema Android
- Nas atualizações mais recentes, a Rabbit bloqueou esse caminho removendo completamente do aparelho o app de configurações do sistema Android
- Até aqui, as mudanças bespoke confirmadas no AOSP parecem mais próximas de remover funcionalidades do que de adicionar novas
- Ainda não foi identificado um motivo técnico para considerar que o RabbitOS, como está implementado hoje, não poderia existir como um app comum de smartphone
O que usuários comuns do R1 devem levar em conta
- Se houver preocupação de que o aparelho possa ter sido desbloqueado sem querer, basta desligá-lo e ligá-lo novamente
- Se ele inicializar normalmente sem mensagem de aviso, em geral pode estar tudo bem
- Porém, se o brom estiver configurado para inicializar uma imagem Preloader unsigned da eMMC, isso não é garantido e testes adicionais são necessários
- Seria melhor ainda poder reflashear uma imagem stock firmware confiável fornecida pelo fabricante, mas a Rabbit não oferece esse recurso
- Se o R1 ficar sem supervisão, os dados armazenados no aparelho podem ser extraídos com relativa facilidade por alguém com o conhecimento adequado
- Antes de vender, doar ou descartar o aparelho, é preciso usar a nova opção das configurações para fazer restauração de fábrica
Violação da GPL e conclusão
- Tirando o scroll wheel e a câmera rotativa, o Rabbit R1 se parece mais com um dispositivo Android comum baseado em MediaTek do que com um hardware especial
- As customizações do AOSP consistem, em sua maior parte, em remover funcionalidades existentes para impor um modo quiosque de app único
- A segurança da cadeia de boot não é efetiva, dificultando deixar o aparelho em segurança sem supervisão
- A Rabbit Inc. está violando a licença GPL2 do kernel Linux
- O driver de detecção do scroll wheel com sensor hall-effect permanece closed-source
- O driver de controle do stepper motor da rotação da câmera também permanece closed-source
- Ambos os drivers estão vinculados estaticamente à imagem do kernel sob GPL
- Em 12 de julho, foi solicitado à Rabbit Inc. um comentário sobre o conteúdo e seus planos de conformidade com a GPL, mas até 22 de julho não havia resposta
- A ferramenta pública de jailbreak tethered foi lançada como recurso experimental para ajudar pesquisadores a acessar seus próprios R1 e, no futuro, permitir que usuários avançados expandam as funções do dispositivo
1 comentários
Opiniões do Hacker News
A GPL exige que a licença e o código-fonte sejam disponibilizados mediante solicitação, mas o Truth Social passou sem divulgar nem sequer a licença até ficar evidente que usava código AGPL, e só então publicou o fonte
Fico curioso para saber se a Rabbit vai escapar do mesmo jeito
Na prática, não dá para rastrear violações que o titular dos direitos desconhece, e normalmente o interesse é mais colocar o infrator em conformidade do que obter indenização
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
Eu achava que, no caso de módulos do kernel, o Linux tinha uma exceção à GPL independentemente do modo de linkedição, desde que não fosse necessária uma modificação no próprio kernel
O conteúdo desses logs é bem sujo: localização GPS exata, nomes de redes WiFi, IDs de torres de celular próximas mesmo sem cartão SIM, endereço IP exposto externamente, tokens de usuário para autenticação na API de backend da Rabbit, além de MP3 codificado em Base64 de tudo que a Rabbit disse ao usuário e transcrições em texto
Não é surpreendente que um dispositivo feito para responder a perguntas como “qual é um restaurante bom por aqui?” envie o contexto de localização junto com a solicitação, mas seria preocupante se ele ficasse transmitindo a localização continuamente sem motivo
Nomes de WiFi precisam ser armazenados para reconexão, e ver endereços IP em logs locais também não é tão estranho
Tokens de acesso do usuário também inevitavelmente precisam ficar armazenados no dispositivo para reconectar sem exigir login toda vez. Dito isso, deixar tokens em claro nos logs é uma prática ruim, e se os logs estiverem no mesmo armazenamento que esse banco de dados ou arquivo de configuração, isso por si só não é um problema totalmente novo. Se os logs forem enviados diretamente para o servidor, aí obviamente é um problema
Se você queria que um dispositivo desses funcionasse de forma fluida e mágica, ele precisa ficar ouvindo, vendo e enviando localização o tempo todo. Na prática, para isso funcionar direito seria necessária inferência local, e eu não sei por que alguém pagaria por algo que a Apple provavelmente vai fazer em uma versão muito melhor daqui a 5 anos, mas, se for comprar, é assim que precisa funcionar
Não dá para odiar as big techs e ao mesmo tempo esperar que uma startup faça um bom produto sem dados. Se a Rabbit quiser ao menos ter a possibilidade de criar algo melhor no futuro, precisa desses dados
Se você vai dizer que isso é desconfortável, precisa explicar especificamente por quê. A maior parte não é, por si só, algo muito preocupante
Engraçado. Trabalhei na Rabbit, li a base de código, fui alvo de gaslighting pelos executivos e pedi demissão
Só olhando de fora para o jailbreak e as vulnerabilidades, parece ser apenas a ponta do iceberg
A Rabbit provavelmente não respondeu porque os advogados estão avaliando como processar
Na prática, quase não deram horário comercial para uma resposta de verdade
Os desenvolvedores do RabbitOS podem corrigir esse problema configurando o eFuse para bloquear o acesso ao bootloader via USB
A Moto fez isso alguns anos atrás quando dispositivos MediaTek eram vulneráveis à mesma superfície de ataque no bootrom. Se minha memória não falha, esse eFuse era configurado na etapa LK e foi aplicado por uma atualização comum de firmware over-the-air
O artigo é ótimo
O software parece lixo, e a empresa também não parece muito boa até agora
Ainda assim, se desse para rodar apps personalizados facilmente, mesmo que em modo quiosque, acho que esse formato permitiria usos bem interessantes
Se der para jogar uma PWA por cima de qualquer jeito, parece muito mais rápido do que montar você mesmo um ESP32, bateria e tela, e parece um dispositivo integrado até bem decente
Idealmente, seria bom conseguir rodar isso com mais segurança e sem os serviços do Google; algo na linha do GrapheneOS seria legal
Ainda não procurei, mas fico curioso se há casos de uso ou materiais de referência para usar algo assim em apps personalizados de propósito único
Se o preço cair para menos de US$ 50, por exemplo depois que eles desligarem os servidores, aí eu concordaria que é uma boa plataforma de hardware
É uma pena; eu queria que esse produto tivesse dado certo
Espero que ele não vire um empecilho para futuras experiências de interface de usuário de hardware + IA. Ainda concordo com a ideia à la Bret Victor de que dá para fazer melhor do que tocar e deslizar em um retângulo de vidro
De forma ainda mais conveniente, um smartwatch poderia retransmitir consultas para o celular
Mesmo que a Humane pareça não ter resolvido um problema real, respeito em certa medida o fato de ter tentado algo realmente diferente. O Rabbit R1 é só uma tralha barata
É meio engraçado que todo, ou quase todo, o apreço inicial pela Rabbit tenha vindo do design da Teenage Engineering
Espero que a TE escolha melhor seus clientes no futuro. A pessoa por trás da Rabbit é um golpista conhecido
Eu poderia pesquisar o nome, mas a qualidade das buscas hoje em dia está tão ruim que não vou fazer isso. Seria útil ter um link que mostrasse a crítica com mais detalhes
Isto é como a Juicero dos assistentes de IA
Ela só achou que as pessoas pagariam uma quantia absurda por uma máquina que espremia saquinhos proprietários de mistura de frutas já cortadas. Tudo funcionava exatamente como pretendido; o modelo de negócio real é que era ridículo
Eu esperava um assistente de IA open source que preservasse a privacidade, algo como uma combinação de Mycroft(https://en.wikipedia.org/wiki/Mycroft_(software)) e Leon(https://getleon.ai)