Gadgetshowto
Se você tem acompanhado os desenvolvimentos no Android, deve ter ouvido bastante o nome “Boot verificado” nos últimos anos. O Google introduziu o recurso de segurança no Android 4.4 (Kitkat), de forma totalmente não intrusiva, e aos poucos vem aumentando sua visibilidade nas versões mais recentes de seu sistema operacional Android.
Nos últimos dias, vimos notícias sobre a presença de um “Inicialização verificada estritamente aplicada”Na mais recente iteração do Google do sistema operacional móvel mais usado do mundo. O Android Nougat usará um nível mais alto de verificação de segurança quando o dispositivo for inicializado. Embora, no Marshmallow, a inicialização verificada fornecesse apenas um aviso ao usuário, caso detectasse algo errado com a partição do sistema, o Android Nougat vai dar um passo adiante e usar o que o Google está chamando de “inicialização verificada estritamente imposta”, que irá não permitir que o dispositivo inicialize de forma alguma, caso detecte anomalias na partição, alterações feitas no bootloader ou a presença de código “malicioso” no dispositivo. Isso levanta a questão: “O que exatamente isso significa para os usuários?”, Parece que a resposta difere para as duas categorias principais de usuários do Android (usuários casuais e avançados), e iremos fornecer a resposta para ambos.
Inicialização verificada estritamente aplicada
Primeiro, algumas informações básicas sobre inicialização verificada: Normalmente, quando o Android executa um teste de verificação em partições, ele divide as partições em blocos de 4 KB e os verifica em uma tabela assinada. Se tudo estiver certo, isso significa que o sistema está completamente limpo. No entanto, se alguns blocos forem adulterados ou corrompidos, o Android informa o usuário sobre os problemas e deixa que o usuário resolva (ou não).
Tudo isso está prestes a mudar com o Android Nougat e a inicialização verificada estritamente imposta. Quando a inicialização verificada é executada no modo forçado, não tolerará nenhuma falha nas partições. Se detectar algum problema, não permitirá que o dispositivo inicialize, e poderia permitir que o usuário inicialize em um ambiente de modo seguro, para tentar corrigir os problemas. No entanto, a inicialização verificada Strictly Enforced não é apenas uma verificação contra blocos de dados inválidos. Geralmente, também pode corrigir erros em blocos de dados. Isso é possível pela presença de códigos Forward Error Correcting, que podem ser usados para corrigir erros em blocos de dados. No entanto, isso nem sempre funciona e, nos casos em que não funciona, você está praticamente morto na água.
Inicialização verificada estritamente aplicada: o bom, o mau e o feio
1. O Bom
Impor inicialização verificada em dispositivos Android irá aumentar a segurança nos dispositivos. No caso de o dispositivo ser infectado por malware, o Strictly Enforced Verified Boot irá detectá-lo na próxima vez que você inicializar o dispositivo e consertá-lo ou, possivelmente, solicitar que você faça algo a respeito.
Este recurso também irá verificar se há corrupção de dados, e na maioria dos casos, será capaz de corrigir quaisquer erros introduzidos nos dados, graças aos códigos FEC. O Google usa códigos FEC que podem corrija um erro de bit desconhecido em 255 bits. Claro, parece um número muito pequeno, mas vamos colocar isso em perspectiva, com relação a um dispositivo móvel:
Observação: Os valores abaixo foram retirados da postagem do blog do engenheiro do Google Sami Tolvanen nos desenvolvedores Android.
O Google poderia ter usado códigos RS (255.223) FEC: esses códigos seriam capazes de corrigir erros de 16 bits desconhecidos em 255 bits, mas a sobrecarga de espaço por causa dos 32 bits de dados redundantes seria de quase 15%, e isso é muito, principalmente em dispositivos móveis. Adicione isso ao fato de que o Android é o sistema operacional predominante em smartphones econômicos que vêm com memórias de 4 a 8 GB, e 15% de espaço extra com certeza parece muito.
Ao sacrificar a capacidade de correção de erros em favor da economia de espaço, o Google decidiu usar os códigos FEC RS (255.253). Esses códigos podem corrigir apenas um único erro desconhecido em 255 bits, mas a sobrecarga de espaço é de apenas 0,8%.
Observação: RS (255, N) é uma representação dos códigos Reed-Solomon, que são um tipo de códigos de correção de erros.
2. O Mau
Já ouviu falar de “A moeda tem dois lados”? Claro que sim. Embora as intenções do Google com a inicialização verificada estritamente imposta fossem, sem dúvida, puras como um unicórnio bebê, elas vêm com seu próprio conjunto de problemas.
Inicialização verificada quando estritamente aplicada verifica se há malware, também verifica modificações ilegais para o kernel, o bootloader e outras coisas com as quais não vou aborrecê-lo, mas, isso significa que o Android Nougat provavelmente encontrará muitos problemas com o enraizamento e flashing ROMs personalizados, porque a inicialização verificada não consegue distinguir entre códigos de malware indesejados, e o código que desbloqueou seu bootloader. O que significa que, se o seu dispositivo veio com um bootloader bloqueado, e seu OEM não permite o desbloqueio do bootloader, você praticamente não pode fazer isso. Esperançosamente, alguém descobrirá um exploit para este.
Felizmente, a maioria das pessoas que fazem o root em seus dispositivos e flash ROMs personalizados para os recursos e funcionalidades adicionais, optam por telefones amigáveis para desenvolvedores, como o Nexus. Há muito a se considerar, com relação a este tópico, e definitivamente não é o fim das ROMs personalizadas, pelo menos não em dispositivos que vêm com um bootloader desbloqueado, ou que permitem desbloquear o bootloader. No entanto, dispositivos como telefones Samsung não permitem oficialmente o desbloqueio do bootloader e, nesses dispositivos, desbloquear o bootloader definitivamente será visto como “um problema” pela inicialização verificada, impedindo o dispositivo de inicializar.
Outro problema que surgirá com a inicialização verificada estritamente imposta afetará até mesmo os usuários que não se importam em obter privilégios de root ou em instalar ROMs personalizadas. Com o tempo, conforme você usa seu dispositivo, é provável que haja corrupção natural de dados na memória; não devido à presença de um malware, mas simplesmente porque isso acontece. Geralmente, isso não é um problema, ou pelo menos não é um problema tão grave quanto a inicialização verificada irá transformá-lo. Se você tiver dados corrompidos que o Strictly Enforced Verified Boot não consiga consertar na inicialização, ele não permitirá que seu dispositivo seja inicializado. Na minha opinião, esse é um problema maior e mais visível do que alguns dados corrompidos na partição do usuário.
3. O Feio
Em todos os benefícios de aplicar a inicialização verificada e todos os problemas em potencial, o mais perturbador, provavelmente, é o fato de que os OEMs podem começar a usar mal isso para bloquear seus dispositivos de forma que as pessoas não sejam capazes de usar o Android para o que foi criado be: aberto, amigável ao desenvolvedor e completamente personalizável. O Boot Verificado Strictly Enforced colocará nas mãos dos OEMs o poder de garantir que as pessoas não sejam capazes de desbloquear os bootloaders em seus dispositivos, proibindo-as, assim, de instalar ROMs personalizadas e ferramentas de aprimoramento de recursos como Módulos Xposed.
VEJA TAMBÉM: Nenhuma ROM personalizada do Android N disponível? Nós temos a solução para você
Android Nougat: uma mudança radical na maneira como o Android funciona?
Embora tenhamos certeza de que as intenções do Google eram simplesmente evitar possíveis problemas para usuários casuais do Android, que não saberiam o que fazer caso seu dispositivo fosse afetado por um malware ou se sua memória tivesse blocos de dados corrompidos, ele pode ter entregado OEMs e o fabricante é a ferramenta perfeita para fazer com que os usuários vivam com o que lhes foi oferecido e nada mais.
Claro que alguém vai descobrir um exploit, ou uma solução para esta situação, e nós esperamos que eles façam, no verdadeiro espírito do Android. Até que alguém descubra uma solução, no entanto, tudo o que nós, como usuários podemos fazer, é garantir que compramos nossos dispositivos de fabricantes amigáveis ao desenvolvedor.
Cortesia da imagem em destaque: Flickr
