Uma olhada nas complicações da raiz do Marshmallow e da Verity

À medida que a poeira assenta sobre o Versão do Android 6.0, muitos usuários do Nexus estão mergulhando em OTAs e Imagens de fábricae se preparando para a iteração mais recente do sistema operacional Android.

Embora, do lado de fora, o Android 6.0 pareça (pelo menos visualmente) notavelmente semelhante ao Android 5.0 e 5.1 (os lançamentos do Lollipop), há uma série de mudanças significativas no dentro. Um deles potencialmente tem ramificações para a ROM personalizada e comunidades raiz. Primeiro, um pouco de contexto. Se você não estiver interessado nisso, vá para "Por que isso é importante".

Um recurso chamado Verity

O problema (é um problema se você gosta de fazer root e modificar dispositivos) decorre de algo que apontei há muito tempo, quando chegou ao AOSP pela primeira vez - a introdução do dm-verity para Android. Verity é um recurso de segurança, originalmente encontrado no ChromeOS, projetado para fornecer dispositivos de computação seguros e confiáveis, evitando que software malicioso modifique um dispositivo. De volta ao Android 4.4, o Google anunciou a verdade para o Android e então tudo permaneceu quieto. Embora tenha havido alguns

pesquisa sobre o uso da verdade, na maior parte, as coisas têm estado calmas. Até agora, isso é.

Com o Android 6.0, o Google começou a melhorar sua segurança de dispositivos. Um dos requisitos fundamentais para isso é evitar que o software de um dispositivo seja modificado sem o conhecimento do usuário - embora muitos aqui no XDA considere o root como garantido, imagine o dispositivo de um usuário sendo rooteado sem seu conhecimento ou consentimento, e o acesso root sendo usado para roubar seu dados. Por esse motivo, o Google começou a implementar a verificação da partição do sistema em alguns dispositivos. Eles também atualizaram recentemente seu páginas de suporte para cobrir isso.

O que isso significa para usuários enraizados?

Com a verdade no lugar, quaisquer alterações feitas na partição do sistema serão detectadas na inicialização ou no acesso. Você então se deparará com um dos erros vistos acima. Alguns permitem que você prossiga e outros desejam protegê-lo, impedindo a inicialização do dispositivo. Existem três estados disponíveis. Um é mostrado quando o bootloader está desbloqueado, indicando que você pode estar em risco até bloquear novamente o bootloader. Este é o caso, uma vez que uma imagem do kernel modificada pode ignorar a veracidade, uma vez que o ramdisk do kernel contém as chaves usadas para verificar o estado de um sistema.

As coisas parecem pouco divertidas para usuários aspirantes a root em dispositivos bloqueados.

O próximo estado é mostrado (presumivelmente) quando a verificação está desativada ou desativada, ou não pode ser verificada devido a modificações no ramdisk. Não posso ter certeza, devido à falta de um Nexus 5X ou 6P para investigar, mas minha suspeita (com base nas mensagens) é que se você carregar outra ROM, que então coloca seu próprio kernel no dispositivo, a página "sistema operacional diferente" será aparecer.

O estado final é o aviso vermelho informando que o dispositivo está corrompido. Suspeito que isso significa que a imagem contém veracidade, mas a verificação falhou devido à modificação da imagem do sistema. Novamente, não podemos ter certeza sem o hardware em mãos, mas esse erro parece ser aquele que você verá se um dispositivo padrão for modificado por um software malicioso.

Por que isso é importante?

No Android M (6.0), o root atualmente requer modificações na imagem do kernel, além do sistema de arquivos. Isso significa que, mesmo que ignoremos a veracidade (como em um dispositivo Nexus mais antigo, como um Nexus 7 2013), uma nova imagem do kernel é necessária para ignorar as proteções do SELinux que impedem o funcionamento do acesso root.

Se você quiser fazer root hoje, no Android Marshmallow, precisará usar uma imagem de inicialização modificada.

Até agora, houve kernels modificados para definir o SELinux no modo permissivo, mas esta não é uma solução ideal, pois significa que você não obtém os benefícios de segurança da proteção do SELinux. E, depois do Medo do palcosaga, presumo que você possa ver os benefícios do SELinux e outras proteções contra explorações de segurança.

Desenvolvedor Sênior Reconhecido XDA, Fogo em cadeia, o mestre de todas as coisas root lançou um versão atualizada do SuperSU que mantém o SELinux no modo de aplicação, mas mais uma vez requer que modificações sejam feitas na configuração do SELinux da imagem de inicialização. Isso significa que você precisa instalar o SuperSU, bem como uma imagem de inicialização modificada.

E está tudo muito bem, até que as operadoras dos EUA entrem no mix. Bastiões da escolha anti-consumidor, os fiéis como AT&T e Verizon são conhecidos por gostarem de bloquear dispositivos, evitando que os usuários instalem firmware personalizado através de seus bloqueios de bootloader. Na verdade, a Verizon é particularmente ruim em nem mesmo passar atualizações de firmware para os usuários, com o Sony Xperia Z3v não configurado para receber Marshmallow enquanto o resto da gama Z3 (e de facto a gama Z2) o fará. Caramba, eles ainda nem implementaram o Lollipop no dispositivo, apesar de estar disponível para algum tempo (Novembro de 2014) no Z3 normal.

Em vez de um desbloqueio não oficial do bootloader (esses são bastante raros hoje em dia, com exceção dos bootloaders de engenharia vazados para alguns dispositivos Samsung), parece altamente improvável que você fará root no Android 6.0 sem alguma intervenção divina - a combinação de dm-verity (para impedir que seu telefone inicialize com quaisquer modificações no partição do sistema) e o requisito para alterações do SELinux no ramdisk (para permitir que o root funcione), parecem destinados a tornar as coisas pouco divertidas para usuários aspirantes a root destes dispositivos bloqueados.

Android Pay?

Finalmente, Android Pay. Provavelmente parece completamente alheio ao restante deste artigo, mas na verdade é bastante relevante. O Android Pay conta com o novo APIs SafetyNet dentro da estrutura de serviços proprietários do Google, que é projetada para fornecer atestados de estado do dispositivo sobre se um dispositivo está enraizado, modificado de outra forma ou funcionando em um estado não aprovado.

Embora haja um projeto olhando para respostas de falsificação ao SafetyNet, atualmente ele requer um plugin Xposed, e isso não parece provável que mude, dada a forma como funciona. O Xposed requer root e faz modificações na partição do sistema. Isso torna isso difícil de realizar em um dispositivo bloqueado pelo bootloader. Mesmo assim, coisas como essa estão apenas entrando em um jogo de gato e rato com o Google. Com o SafetyNet, os dispositivos enraizados (ou mesmo os dispositivos modificados) são vistos como "não compatíveis com CTS", o que é um eufemismo para dispositivos modificados.

Há muito mais escrito sobre SafetyNet nesta postagem desmontada do blog, mas certamente parece que podemos identificar algumas áreas que o Google deseja reprimir. Em primeiro lugar, eles não gostam de root, Xposed e qualquer coisa que modifique a partição do sistema. Em segundo lugar, parece que o Google está considerando detectar usuários com bloqueio de anúncios ativado - o handshake SSL verifica pubads.g.doubleclick.net certamente me sugira que o Google queira saber se você está bloqueando anúncios no seu dispositivo. Considerando que root geralmente é um pré-requisito, mas que a API VPN poderia ser usada para fazer isso sem root, parece que o Google pelo menos quer ter uma ideia de quem (ou quantas pessoas) está bloqueando Publicidades. O bloqueio de anúncios é um problema atual, dada a pressão da Apple para apoiá-lo no navegador da web (provavelmente para encorajar pessoas usem mais os aplicativos, onde controlam a experiência e podem oferecer anúncios não bloqueáveis), e essas medidas são interessante.

Conclusão

Se você quiser fazer root hoje, no Android Marshmallow (6.0), você precisará usar uma imagem de inicialização modificada. Embora ainda não se saiba se isso permanecerá verdadeiro indefinidamente, parece provável que seja o caso por algum tempo - as alterações do SELinux tornam muito mais difícil obter acesso root sem modificar a imagem de inicialização. E como a modificação da imagem de inicialização requer um bootloader desbloqueado, isso pode acabar com o root (e o Xposed e outros recursos de root) em dispositivos fornecidos com bootloaders que não podem ser desbloqueados pelos usuários finais. O Dm-verity também está aparecendo e parece estar ativado no modo de aplicação em novos dispositivos. Isso tornará difícil modificar /system, mesmo se você obtiver acesso root, sem ter novamente um bootloader desbloqueado.

Isso muda sua visão dos dispositivos bloqueados pelo bootloader? O Android atingiu o estágio em que você ainda compraria um dispositivo bloqueado por bootloader se sua operadora lhe desse um bom negócio?, ou você está interessado apenas em dispositivos desbloqueados? Quais aplicativos ou recursos root você sentiria falta em um bootloader bloqueado?

Sinta-se à vontade para compartilhar suas idéias nos comentários abaixo.