Joe Maring / Autoridade Android
DR
- O Google quebrou o aplicativo Pixel IMS que habilitava VoLTE/VoWiFi em operadoras não suportadas, mas o desenvolvedor já lançou uma nova solução alternativa.
- A atualização de outubro do Google corrigiu uma brecha que o aplicativo explorava, bloqueando especificamente o usuário “shell” de chamar uma API interna restrita.
- A nova correção contorna essa restrição “lavando” a chamada da API por meio de outro componente, para que o sistema não a detecte vindo do shell.
No início de 2023, um desenvolvedor coreano lançou um aplicativo chamado “Pixel IMS” que permite aos usuários do Pixel ativar VoLTE e VoWiFi em qualquer operadora. Este aplicativo é útil para pessoas que importam telefones Pixel para determinados países, pois os Pixels não têm suporte para VoLTE e VoWiFi em muitos dos mercados onde não são vendidos diretamente pelo Google. No entanto, o Google lançou uma atualização na semana passada que corrigiu a brecha que o aplicativo Pixel IMS usava para ativar VoLTE e VoWiFi à força, quebrando o aplicativo no processo. Os usuários que dependiam do aplicativo para ativar esses recursos de chamada cruciais ficaram desanimados com a ação do Google, mas, felizmente para eles, uma nova solução alternativa já foi encontrada.
Não quero perder o melhor de Autoridade Android?
Como o Google tentou impedir que os usuários do Pixel ativassem o VoLTE em todos os lugares e por que isso falhou
Na semana passada, o Google lançou a atualização de outubro de 2025 para telefones Pixel para resolver uma variedade de problemas de exibição e interface de usuário. Embora o boletim de segurança deste mês não tenha mencionado nenhuma vulnerabilidade, o Google incluiu discretamente um patch que fechou a brecha específica usada pelo aplicativo Pixel IMS para habilitar VoLTE e VoWiFi. Este patch fazia com que o aplicativo travasse sempre que os usuários tentassem alternar VoLTE ou VoWiFi, com um log de travamento informando que “overrideConfig não pode ser invocado pelo shell.”
overrideConfig é uma API interna na estrutura de telefonia do Android que permite que os chamadores substituam o configuração da operadora — um conjunto de chaves específicas da operadora que o sistema operacional lê para determinar quais recursos de conectividade ativar. Normalmente, as operadoras fornecem essas chaves diretamente, mas a API overrideConfig pode substituí-las. Como os aplicativos de terceiros não devem ter esse nível de controle, o overrideConfig API é não é público.
Em vez de, overrideConfig só pode ser chamado por aplicativos que possuem o MODIFY_PHONE_STATE permissão, que é restrita a aplicativos privilegiados do sistema. Então, como o Pixel IMS usou essa API? Ele aproveitou o Shizuku, uma ferramenta de código aberto que permite que outros aplicativos sejam executados como usuário “shell”. O usuário shell tem privilégios elevados necessários para testar e depurar aplicativos por meio do Android Debug Bridge (ADB). Como os desenvolvedores de plataforma do Google também usam ADB para testar novas configurações, o aplicativo shell recebeu o MODIFY_PHONE_STATE permissão.
O aplicativo Pixel IMS explorou isso para usar o overrideConfig API, uma brecha que o Google deixou intocada por mais de dois anos e meio. Recentemente, porém, o Google classificou essa brecha como uma vulnerabilidade de escalonamento de privilégios de alta gravidade. Apesar dessa classificação, não foi considerado um risco alto o suficiente no novo Sistema de Atualização Baseado em Risco (RBUS) para ser incluído no boletim de segurança deste mês, mas o Google lançou a correção mesmo assim.
A correção do Google adicionou uma verificação ao overrideConfig API, bloqueando o acesso se o processo de chamada for o usuário shell. Isso quebrou o aplicativo Pixel IMS, pois ele dependia da execução como usuário shell para chamar a API.
No fim de semana, o desenvolvedor implementou uma solução que ignora a nova restrição do Android. Em vez de fazer uma ligação direta para o overrideConfig API, Pixel IMS agora usa um método indireto, lançando um Instrumentation componente para fazer a chamada de API em seu nome. Isso contorna a restrição porque a chamada não parece mais vir do usuário shell; em essência, o aplicativo está lavando sua chamada de API por meio de um usuário diferente e “limpo”.
É claro que este novo método não é infalível. O Google poderia corrigi-lo de várias maneiras, sendo a mais eficaz a remoção completa do MODIFY_PHONE_STATE permissão do aplicativo shell. Este seria um killswitch eficaz, já que a nova brecha só funciona porque o aplicativo shell ainda tem tecnicamente a permissão necessária para chamar o overrideConfig API.
A questão é: quão agressivamente o Google irá atrás do Pixel IMS e aplicativos semelhantes? Um bloqueio completo do Pixel IMS impediria você de importar um telefone Pixel? Deixe-nos saber por que ou por que não nos comentários abaixo!
Obrigado por fazer parte da nossa comunidade. Leia nossa Política de Comentários antes de postar.
Link do Autor