O Magisk talvez não consiga mais ocultar o desbloqueio do bootloader dos aplicativos - M-DROID
Masgisk • Root
O Magisk talvez não consiga mais ocultar o desbloqueio do bootloader dos aplicativos
Desenvolvedor reconhecido por DA O projeto "Magisk" de topjohnwu tornou-se essencialmente sinônimo de "root" na comunidade Android. Um dos principais motivos pelos quais é tão popular é porque pode ocultar o fato de o usuário ter modificado o dispositivo. No entanto, o Google pode estar reprimindo a capacidade do Magisk de ocultar o status de desbloqueio do carregador de inicialização dos aplicativos.
Para fazer root no telefone, você geralmente precisa desbloquear o bootloader, o que permite exibir imagens de inicialização modificadas. Isso é necessário porque o Magisk modifica a imagem de inicialização para falsificar o status do carregador de inicialização e / ou as verificações de status de inicialização verificada. SafetyNet do GoogleA API de atestado, que faz parte do Google Play Services, é usada para informar um aplicativo se ele estiver sendo executado em um dispositivo violado; se a API SafetyNet detectar que o carregador de inicialização foi desbloqueado, ele retornará um status de falha para a verificação de "Integridade básica". Os dispositivos que falham nessa verificação podem ser bloqueados nos aplicativos que usam a API SafetyNet para determinar a integridade do dispositivo; esses aplicativos geralmente incluem aplicativos bancários, aplicativos de pagamento (como o Google Pay) e muitos jogos online (como o Pokémon Go). No entanto, como a API SafetyNet até agora usou apenas verificações de software para determinar se o dispositivo foi violado, o Magisk pode simplesmente falsificar o gerenciador de inicialização e / ou o status de inicialização verificada, pois está instalado em um nível mais baixo e com privilégios mais altos que o Google Play Serviços e outros aplicativos de espaço do usuário. Como topjohnwu explica,resultado legítimo do SafetyNet que não reflete o status real do dispositivo ".
Recentemente, no entanto, os usuários notaram que seus dispositivos desbloqueados pelo carregador de inicialização estão com falha na verificação de integridade básica da SafetyNet, apesar de terem usado o Magisk para corrigir a imagem de inicialização. De acordo com topjohnwu, isso ocorre porque o Google pode ter implementado atestado de chave no nível de hardware para verificar se a imagem de inicialização não foi violada. Especificamente, isso significa que o Google Play Services "[envia] um certificado de keystore não modificado para os servidores SafetyNet, verifica sua legitimidade e verifica os dados de extensão de certificado para saber se o seu dispositivo [verificou] a inicialização ativada (status do carregador de inicialização)". Isso significa que talvez não seja mais possível ocultar o fato de o carregador de inicialização ter sido desbloqueado, o que resultará em aplicativos como Google Pay e Pokémon Go não funcionar normalmente.
Como notou topjohnwu, essa alteração na maneira como o SafetyNet verifica o status de desbloqueio do carregador de inicialização ocorre por meio de uma atualização no servidor da API SafetyNet contida no Google Play Services. No entanto, nem todos os usuários falham nessas verificações SafetyNet atualizadas; portanto, o novo atestado de chave no nível do hardware ainda não pode ser amplamente aplicado.
Vimos topjohnwu superar obstáculos técnicos uma e outra vez. O Google frequentemente lança novas verificações na SafetyNet que topjohnwu descobrem e ignoram no Magisk. Cada nova versão do Android traz alterações na estrutura da partição ou na imagem de inicialização, exigindo que o topjohnwu estude as alterações e implemente um novo método de aplicação de patches. No entanto, mesmo topjohnwu pode ter dificuldade para encontrar um desvio desta vez.
Isso porque a solução alternativa dessa vez envolveria a invasão do firmware dos dispositivos do Trusted Execution Environment (TEE) para recuperar a chave privada. No entanto, isso é incrivelmente difícil de fazer, pois exige encontrar uma vulnerabilidade no firmware projetada para ser incrivelmente segura. De fato, muitas empresas oferecem pagamentos na ordem de centenas de milhares de dólares se essa vulnerabilidade for encontrada. O Google, por exemplo, paga US $ 250.000 por vulnerabilidades de execução remota de código no Trusted Execution Environment da Pixel e até US $ 1.000.000 por vulnerabilidades no chip de segurança Titan M. Mesmo que uma chave privada vazasse de alguma maneira, é improvável que seja de grande utilidade, já que o Google pode revogar remotamente a chave portanto, não pode ser usado para verificar a integridade dos dispositivos.
Uma vez que o atestado de chave de nível de hardware é amplamente aplicado ao SafetyNet, a maioria dos dispositivos com gerenciadores de inicialização desbloqueados executando o Android 8.0 Oreo ou superior não conseguirá passar na verificação de integridade básica do SafetyNet. Isso ocorre porque todos os dispositivos lançados com o Android 8.0 Oreo ou superior precisam ter um keystore de hardware implementado em um TEE.
Hoje em dia, certos dispositivos têm até HSMs (Hardware Security Modules) dedicados que dificultam ainda mais a exploração, afastando o TEE do processador principal; o Titan M no Pixel 4 e o novo chip de segurança da Samsung no Galaxy S20 são exemplos disso.
Topjohnwu também explica que outras soluções possíveis são impossíveis ou altamente desafiadoras. O uso do Xposed Framework para modificar a API SafetyNet Attestation no Google Play Services provavelmente não funcionará, pois "as verificações adequadas do SafetyNet verificarão os resultados em um servidor remoto, não no dispositivo que pode ser manipulado pelas estruturas de injeção de código". Além disso, o Google Play Services é altamente ofuscado, tornando a criação de um módulo Xposed incrivelmente desafiadora em primeiro lugar. A falsificação de um resultado de teste do SafetyNet também não será possível, já que as respostas do SafetyNet "vêm dos servidores do Google e são assinadas com a chave privada do Google".
O Google conseguiu endurecer as verificações do SafetyNet usando atestado de chave com suporte de hardware há vários anos. O fato de que eles se abstiveram de fazer isso por três anos permitiu que os usuários desfrutassem dos módulos root e Magisk sem sacrificar a capacidade de usar aplicativos bancários. No entanto, parece que a capacidade da Magisk de ocultar efetivamente o status de desbloqueio do carregador de inicialização está chegando ao fim. É uma mudança que esperamos há anos, mas estamos tristes ao vê-la finalmente entrar em vigor. Esperamos que o Google atualize a API SafetyNet Attestation para retornar se a verificação de status usou atestado baseado em hardware, pois isso permitiria que os desenvolvedores de aplicativos decidissem se desejam bloquear todos os usuários que desbloquearam o gerenciador de inicialização.