Clement Thomas
0 
1446
155
Se você acompanha os desenvolvimentos no Android, deve ter ouvido o nome "Inicialização verificada" nos últimos dois anos. O Google introduziu o recurso de segurança no Android 4.4 (Kitkat), de uma maneira totalmente não invasiva, e vem aumentando lentamente sua visibilidade nas versões mais recentes do seu sistema operacional Android.
Nos últimos dias, vimos notícias sobre a presença de um "Inicialização verificada rigorosamente aplicada”Na mais recente iteração do Google do sistema operacional móvel mais usado no 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 apenas avise o usuário, caso detecte algo errado com a partição do sistema, o Android Nougat dará um passo adiante e usará o que o Google chama de "Inicialização verificada rigorosamente aplicada", que não permitir que o dispositivo inicialize, caso detecte anomalias na partição, alterações feitas no gerenciador de inicialização ou a presença de código "malicioso" no dispositivo. Isso levanta a pergunta: “O que exatamente isso significa para os usuários?”, A resposta difere para as duas principais categorias de usuários do Android (usuários casuais e avançados), e nós vamos fornecer a resposta para os dois.
Inicialização verificada rigorosamente aplicada
Primeiro, um pouco de experiência na Inicialização verificada: normalmente, quando o Android executa um teste de verificação em partições, ele faz isso dividindo as partições em blocos 4KiB e comparando-as com uma tabela assinada. Se tudo der certo, significa que o sistema está completamente limpo. No entanto, se alguns blocos forem adulterados ou corrompidos, o Android informará o usuário sobre os problemas e deixará ao usuário resolvê-lo (ou não).
Tudo isso está prestes a mudar com o Android Nougat e a Inicialização verificada rigorosamente aplicada. Quando a Inicialização Verificada é executada no modo Imposto, não tolerará falhas nas partições. Se detectar algum problema, será não permitirá que o dispositivo inicialize, e poderia permitir que o usuário inicialize em um ambiente em modo de segurança, para tentar corrigir os problemas. No entanto, a Inicialização verificada rigorosamente aplicada não é apenas uma verificação contra blocos de dados incorretos. Geralmente, também pode corrigir erros nos blocos de dados. Isso é possível devido à presença de códigos de correção de erro de encaminhamento, que podem ser usados para corrigir erros nos 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 rigorosamente aplicada: os bons, os maus e os feios
1. O Bom
A imposição da inicialização verificada em dispositivos Android aumentar a segurança nos dispositivos. Caso o dispositivo seja infectado por malware, o Strictly Enforced Verified Boot o detectará na próxima vez que você inicializar o dispositivo e o corrigirá ou, possivelmente, solicitará que você faça algo a respeito..
Esse recurso também verifique se há corrupção de dados, e na maioria dos casos, ele poderá corrigir os erros introduzidos nos dados, graças aos códigos FEC. O Google usa códigos FEC que podem corrigir um erro de bit desconhecido em 255 bits. Claro, isso parece um número bem pequeno, mas vamos colocar isso em perspectiva, no que diz respeito a um dispositivo móvel:
Nota: Os valores abaixo foram retirados da postagem do blog do engenheiro do Google Sami Tolvanen em Desenvolvedores do Android.
O Google poderia ter usado códigos FEC RS (255.223): esses códigos poderiam corrigir erros de 16 bits desconhecidos em 255 bits, mas a sobrecarga de espaço por causa dos 32 bits de dados redundantes teria sido de quase 15%, e isso é muito, especialmente em dispositivos móveis. Acrescente isso ao fato de que o Android é o sistema operacional predominante em smartphones econômicos que vêm com 4-8 GB de memória e 15% de espaço extra com certeza parece muito.
Ao sacrificar os recursos de correção de erros, em favor da economia de espaço, o Google decidiu usar os códigos RS (255.253) FEC. Esses códigos podem corrigir apenas um único erro desconhecido em 255 bits, mas a sobrecarga de espaço é de apenas 0,8%.
Nota: RS (255, N) é uma representação dos códigos de Reed-Solomon, que são um tipo de código de correção de erros.
2. O Mau
Já ouviu falar de "Existem dois lados de uma moeda"? Claro que você tem. Embora as intenções do Google com o Strictly Enforced Verified Boot sejam, sem dúvida, puras como um bebê unicórnio, eles vêm com seu próprio conjunto de problemas.
Quando inicialização verificada rigorosamente aplicada verifica se há malware, também verifica se há modificações ilegais para o kernel, o gerenciador de inicialização e outras coisas com as quais não vou incomodá-lo, mas isso significa que o Android Nougat provavelmente encontrará muitos problemas com o root e as ROMs personalizadas piscantes, porque o Verified Boot não pode distinguir entre códigos de malware indesejados, e o código que desbloqueou o seu gerenciador de inicialização. O que significa que, se o seu dispositivo veio com um carregador de inicialização bloqueado e o seu OEM não permite o desbloqueio do carregador, você praticamente não pode fazê-lo. Felizmente, alguém descobrirá uma façanha para isso.
Felizmente, a maioria das pessoas que faz root em seus dispositivos e atualiza ROMs personalizadas para os recursos e funcionalidades adicionais, usa telefones compatíveis com desenvolvedores, como o Nexus. Há muito a considerar em relação a esse tópico, e definitivamente não é o fim das ROMs personalizadas, pelo menos não nos dispositivos que vêm com um gerenciador de inicialização desbloqueado ou que permitem desbloquear o gerenciador de inicialização. No entanto, dispositivos como telefones Samsung não permitem oficialmente o desbloqueio do carregador de inicialização e, nesses dispositivos, desbloquear o carregador de inicialização será definitivamente visto como "um problema" pelo Verified Boot, impedindo que o dispositivo seja inicializado..
Outro problema que surgirá com a Inicialização verificada rigorosamente aplicada é o que afetará até os usuários que realmente não se importam em obter privilégios de root ou instalar ROMs personalizadas. Com o tempo, conforme você usa o dispositivo, é provável que haja corrupção de dados natural 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 o transformará. Se você tiver dados corrompidos que a Inicialização verificada estritamente aplicada não pode corrigir na inicialização, isso não permitirá que o 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 impor a Inicialização verificada e todos os problemas em potencial, o mais preocupante, provavelmente, é o fato de que os OEMs podem começar a usar isso para bloquear seus dispositivos, para que as pessoas não consigam usar o Android para o que se destinava. ser: aberto, fácil de desenvolver e completamente personalizável. A Inicialização verificada rigorosamente aplicada colocará nas mãos dos OEMs o poder de garantir que as pessoas não sejam capazes de desbloquear os gerenciadores de inicialização em seus dispositivos, proibindo-os de instalar ROMs personalizadas e ferramentas de aprimoramento de recursos, como Xposed Modules.
VEJA TAMBÉM: Não há ROM personalizada do Android N disponível? Nós temos a solução para você
Nougat do Android: uma mudança radical na maneira como o Android funciona?
Embora tenhamos certeza de que as intenções do Google eram simplesmente evitar problemas em potencial 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 corrompido os blocos de dados, ele pode ter fornecido OEMs e o fabricante é a ferramenta perfeita para prender os usuários a viver com o que lhes foi oferecido, e nada mais.
É claro que alguém descobrirá uma exploração ou solução alternativa para essa situação, e esperamos que sim, no verdadeiro espírito do Android. Até que alguém descubra uma solução, no entanto, tudo o que nós, como os usuários podem fazer, é garantir que compramos nossos dispositivos de fabricantes amigáveis para desenvolvedores.
Imagem em destaque Cortesia: Flickr