- Não se trata de um anúncio oficial do Google: em uma solicitação de recurso no IssueTracker ainda em andamento, um dos principais mantenedores do ADB mencionou limitar conexões locais e vincular o serviço apenas a
wlan0para evitar abusos - Se apenas
wlan0for permitido, o ADB no próprio dispositivo, que usa o endereço de loopback127.0.0.1, pode deixar de funcionar, assim como ADB via VPN, Ethernet e vários ambientes de desenvolvimento - A discussão começou a partir da CVE-2026-0073, que contornava completamente a autenticação do Wireless ADB; a solicitação original era permitir escolher a interface de escuta do ADBD para evitar exposição em todas as redes
- Apps maliciosos comuns não conseguem iniciar o ADBD diretamente nem concluir sozinhos o pareamento do Wireless ADB ou a aprovação de TCP/IP; por isso, é difícil obter permissões de ADB sem ação manual do usuário
- Bloquear conexões de loopback de forma permanente afetaria ferramentas baseadas em Shizuku e libadb-android, portanto seria necessária uma configuração de escolha do usuário que permita desativar o bloqueio mesmo após reinicializações
Não é um anúncio oficial, mas uma discussão inicial
- Este caso não é uma política definida nem um anúncio oficial do Google; ele se baseia em uma solicitação de recurso no IssueTracker em andamento e em comentários de um dos principais mantenedores do ADB
- O responsável citou casos em que apps usaram o socket local do ADBD para elevar privilégios e mencionou a possibilidade de vincular o ADBD apenas à interface Wi-Fi
wlan0 - Em discussões públicas, deve-se evitar simples protestos, insultos ou repetição dos mesmos casos de uso
- Se houver um caso de uso específico, é possível deixar uma opinião concreta incluindo o fluxo de trabalho, links relacionados e compromissos técnicos
- Se o mesmo caso já tiver sido registrado, recomenda-se usar +1 e o recurso de notificações em vez de repetir comentários
- Uma enxurrada de comentários de baixa qualidade pode fazer a issue ser bloqueada ou reduzir feedback útil e atualizações públicas
Três formas de conexão do ADB
- ADB é um protocolo que oferece acesso a comandos com altos privilégios para desenvolvedores e usuários avançados testarem e gerenciarem dispositivos Android
- As principais formas de conexão se dividem em três
- USB: o método original, em que um computador separado se conecta diretamente ao dispositivo por um cabo USB
- ADB TCP/IP: geralmente usa a porta
5555, transmite tráfego em texto claro e autentica por uma janela de aprovação YES/NO. É preciso ter uma conexão ADB existente para ativá-lo - Wireless Debugging: introduzido no Android 11, pareia o computador por código ou QR code e depois estabelece uma conexão autenticada e criptografada. Não exige uma conexão ADB existente para ser ativado
O ecossistema criado pelo ADB no próprio dispositivo
- O ADB comum conecta o ADBD do dispositivo Android ao cliente ADB de um computador de desenvolvimento separado, mas alguns desenvolvedores trabalham diretamente no dispositivo Android sem computador
- ADB no próprio dispositivo (On-Device ADB) não é um termo oficial; ele se refere ao método de executar um cliente ADB em um emulador de terminal, como o Termux, e conectá-lo ao ADBD do mesmo dispositivo
- Usa ADB TCP/IP ou Wireless Debugging
- Como cliente e servidor estão no mesmo dispositivo, a conexão passa pelo endereço de loopback
127.0.0.1
- Esse método serve de base para projetos open source voltados a desenvolvedores e usuários avançados, como libadb-android e Shizuku
- ShizuCallRecorder é um app baseado em Shizuku criado para reduzir dificuldades cotidianas causadas por deficiência
- Um usuário usou esse app para preservar mensagens de voz de um familiar falecido
- A gravação de chamadas no Android era muito solicitada por usuários e chegou a ser promovida como recurso oficial no Android 11, mas foi cancelada; hoje também existem apps de contorno fechados ou com potencial de violar privacidade
- Algumas OEMs forçam um aviso sonoro de gravação de chamadas mesmo em regiões onde isso não é legalmente necessário
Solicitação de escolha de interface e restrição a wlan0
- O objetivo original da nova solicitação de recurso é permitir que desenvolvedores escolham a interface de rede em que o ADBD deve escutar
- O pano de fundo é a CVE-2026-0073, que permitia contornar completamente o processo de autenticação do Wireless ADB
- Atualmente, o ADBD pode ser acessado por qualquer rede à qual o telefone esteja conectado, portanto a seleção de interface em si pode reduzir a superfície de exposição
- No entanto, permitir apenas
wlan0pode quebrar as seguintes configurações- ADB no próprio dispositivo usando loopback
- ADB via VPN
- ADB via Ethernet
- Outros ambientes de desenvolvimento especiais
- Há também casos em que desenvolvedores do Android usaram ADB no próprio dispositivo quando não tinham acesso a um computador
Restrições que um app malicioso precisa superar
- O ADB no próprio dispositivo pode ser usado para elevação de privilégios, mas um app malicioso comum não consegue estabelecer a conexão por conta própria
-
Usuários comuns de Android
- Se o ADB estiver desativado, o ADBD não é executado
- Apps maliciosos também não têm a permissão
WRITE_SECURE_SETTINGS, que precisa ser concedida manualmente via ADB, o que dificulta tentar um ataque via ADB
-
Desenvolvedores que usam Wireless ADB no Android 11 ou superior
- O usuário precisa ativar manualmente a depuração USB e o Wireless ADB para que o ADBD escute em uma interface de rede
- Para que um app se conecte, o usuário precisa obter e fornecer um código de pareamento de uso único na tela de configurações, então o app sozinho não consegue se conectar
-
Desenvolvedores que usam ADB TCP/IP
- O usuário precisa ativar a depuração USB, habilitar TCP/IP via USB ADB e então desconectar o cabo
- Quando o app inicia a conexão, uma janela de aprovação aparece na tela; se o usuário escolher No, ela é recusada
- Em um estado normal de autenticação, o app não consegue se conectar e atacar sem que o usuário saiba
Risco de vulnerabilidades e escopo do bloqueio
- Em condições normais, um app malicioso não consegue iniciar o ADBD diretamente, então a possibilidade de conexão só surge quando o desenvolvedor está usando ADB no dispositivo
- Se houver uma vulnerabilidade que contorne a autenticação, como a CVE-2026-0073, ela pode ser explorada em ambientes Wireless ADB e TCP/IP
- Ainda assim, o usuário primeiro precisa ativar manualmente a depuração USB
- No método TCP/IP, o usuário também precisa ativar manualmente o ADB TCP/IP
- É preciso diferenciar uma medida que bloqueia conexões de loopback por padrão de um bloqueio permanente que o usuário não possa desativar
- A designação como administrador do dispositivo ou permissões de acessibilidade também podem ser concedidas a apps maliciosos por ação do usuário, mas essa possibilidade por si só não leva à remoção completa desses recursos
Uma solução de compromisso que preserve a escolha do usuário
- O bloqueio de loopback deve ser uma configuração persistente que o usuário possa desativar explicitamente
- Ela precisa permanecer após reinicializações para que ferramentas como Shizuku sejam práticas de usar
- Se possível, apps de terceiros não deveriam conseguir ler o estado da configuração, para que não seja necessário reconfigurá-la repetidamente a fim de evitar detecção por apps bancários ou jogos
- Ao conceder manualmente
WRITE_SECURE_SETTINGSa um app, algumas restrições podem ser contornadas
- A estrutura adequada é permitir que o usuário desative o recurso de segurança e permita depuração no próprio dispositivo, ao mesmo tempo em que aceita o risco de exposição a vulnerabilidades futuras
- Bloquear permanentemente o ADB no próprio dispositivo afetaria os seguintes ecossistemas open source de nicho
2 comentários
eca...
Opiniões no Hacker News
Em geral sou a favor de melhorias de segurança, mas aqui parece haver pouquíssimo benefício real. Para esse ataque funcionar, o usuário precisaria ativar as opções de desenvolvedor e o ADB remoto, então para 99,9% das pessoas isso não é um vetor de ataque realista, e os 0,1% restantes em geral sabem o que estão fazendo.
Mudanças que limitam o acesso a uma interface ou IP específico são boas, mas bastaria permitir que o desenvolvedor restrinja a localhost. Dá muito a impressão de que querem bloquear Shizuku, Canta e afins disfarçando isso como dano colateral.
disable sandboxpara executar um agente em modo ilimitado, isso não funciona no mobile.No Firefox, nem dá para instalar extensões não assinadas, então é preciso usar a Developer Edition; sites forçam passkeys; até um único bucket S3 vem com dezenas de camadas de controle de acesso, identidade de serviço, IAM e OAuth. Também continuam aparecendo OAuth que não funciona em dispositivos headless, bancos que exigem apps próprios em vez de TOTP, bloqueio de VPNs, vigilância com nome real em nome da proteção infantil e movimentos para proibir modelos de pesos abertos sob a alegação de que informações iriam para a China.
A segurança virou um valor absoluto que sempre fica acima de conveniência, usabilidade, privacidade, possibilidade de modificação e abertura, e a indústria de segurança de TI deveria se envergonhar disso.
Esta mudança parece ser para proteger interesses corporativos, não a segurança do usuário.
No começo diziam para usar apenas o Safari, sem App Store, e vejo a raiz disso na paranoia típica de Steve Jobs, que, mesmo durante o tratamento contra câncer, relutava em deixar dispositivos médicos sem um design bonito tocarem seu corpo. A atitude de não deixar nada “impuro” encostar no dispositivo “perfeito” foi justificada depois com a linguagem da segurança.
Na época se dizia que era preciso evitar uma situação como a do Windows 98 cheio de malware, mas os sistemas operacionais modernos já superaram em muito o nível frágil de segurança do Windows daquela época.
O objetivo de bloquear ferramentas de privacidade sem root baseadas em Shizuku não é a segurança do proprietário, mas a segurança do governo. Aplicações de ambiente de execução confiável, como a EU Digital Identity Wallet, e recursos que provavelmente serão exigidos no futuro em nome da proteção infantil dependem muito da premissa de que o usuário não pode manipular o dispositivo nem instalar software não aprovado. Todos sabemos para onde o Intel SGX está caminhando.
A restrição ao ADB é o próximo passo óbvio. Mesmo que esta proposta não passe exatamente assim, o Google fez até tarefas normais de computação pessoal dependerem de interfaces de desenvolvedor internas ao dispositivo ou via USB/sem fio.
É bem provável que um dia seja preciso entregar sua identidade e pagar uma taxa anual, ou então sofrer restrições sérias para usar Android de forma significativa. O Google não quer que apps Android sejam desenvolvidos fora de canais de distribuição controlados, e a derrota já aconteceu quando ele não recuou em mudanças que proíbem o sideloading normal e legítimo.
O alerta de gravação de chamadas também é responsabilidade do Google. À medida que fabricantes adotaram o discador do Google em vez de seus discadores próprios, que eram melhores, isso passou a ser aplicado em massa até em regiões sem obrigação legal. É especialmente irritante em SoCs MediaTek que não dão suporte, em nível de hardware, à gravação por apps de terceiros estáveis.
No fim, é prova de que você não é dono do “seu” dispositivo, e talvez daqui a alguns anos o Gemini passe a ouvir e resumir suas chamadas por meio de um caminho de vigilância aprovado.
Fico curioso se também serão oferecidos meios alternativos para usos legítimos. Se removerem a funcionalidade sem dar uma alternativa, desenvolvedores serão empurrados para contornos mais frágeis ou, às vezes, que violam regras.
Esta reação parece um grande exagero nascido de um mal-entendido. Uso ADB remoto para instalar novos builds de um projeto Android em desenvolvimento e coletar logs, e hoje me conecto via VPN Tailscale.
Mas o método atual pode expor vulnerabilidades pré-autenticação em qualquer Wi-Fi público ao qual o aparelho se conecte. Se fosse possível restringir apenas à interface do Tailscale, isso seria uma melhoria.
O ponto central da proposta é, ao configurar o ADB remoto, especificar a interface à qual ele deve fazer bind, em vez de todas as interfaces. Não há nada dizendo que localhost será recusado, e a sugestão curta de fazer bind apenas a
wlan0é claramente errada, por ser menos confiável que uma VPN, e provavelmente não será a direção da implementação real.Mesmo que uma enxurrada de comentários faça um desenvolvedor do Google bloquear a issue e ignorar o feedback, nada mudará em relação ao que já acontece. Se a crítica em si incomoda, já que feedback valioso também pode ser bloqueado, fiquem à vontade para manifestar apoio.
O Google às vezes aceita feedback de desenvolvedores de apps, mas é natural que dê mais peso ao julgamento de equipes internas do que a desenvolvedores open source que dependem desse tipo de gambiarra.
O daemon do ADB claramente não foi projetado para permitir que um app abra uma sessão ADB para o endereço de loopback e possibilite gravação de chamadas. https://xkcd.com/1172/ vem à mente de novo.
Isso não significa que os desenvolvedores estejam errados em não gostar da mudança. O Google também adicionou gravação de chamadas ao discador, então apoia o recurso em si, mas isso não quer dizer que a equipe do ADB não deva reforçar a segurança.
Quando o Google anunciou pela primeira vez as restrições ao sideloading, disseram “mas ainda existe o ADB”, e quem se opôs a isso recebeu críticas pesadas.
Agora é preciso esperar até por uma forma de contornar a ativação do ADB, e o Android há muito tempo deixou de ser mais aberto que o iOS. Essa tendência vai continuar.
Como é um problema não técnico da mentalidade do Google, não dá para resolvê-lo com uma solução técnica.
Mesmo que você consiga instalar seu próprio software, o dispositivo é tratado como “modificado”. Se a atestação falhar, ele deixa de ser confiável e você vira um cidadão de segunda classe, excluído de praticamente todos os aspectos da sociedade digital, como comunicação, bancos, streaming e jogos.
Esse é o futuro do Android, e o GrapheneOS é a última esperança porque algumas empresas, quase por milagre, começaram a confiar nas chaves de atestação do GrapheneOS. Se até essa esperança desaparecer, é melhor comprar um iPhone.
Era óbvio que isso ia acontecer. No próximo passo, as pessoas ainda vão se surpreender se a restrição de 24 horas para sideloading virar indefinida.
Ela não precisa dominar o mercado inteiro; basta fazer o Google hesitar ou tornar a execução juridicamente difícil. Algo parecido com o papel ideal do Firefox em relação ao Chrome.
O fato de o Android estar ficando tão fechado é um sinal de alerta sério. Eles estão removendo, uma a uma e lentamente, as coisas que tornavam o Android bom.
Preocupa que em breve o mesmo aconteça com sites. Para permitir que um site abra em dispositivos Apple, talvez seja preciso pagar uma taxa mensal à Apple; em dispositivos Android, ao Google.
https://www.eff.org/deeplinks/2026/07/googles-new-remote-att...
Ainda não há cobrança, mas o Google passa a poder decidir quais dispositivos terão permissão de acessar um grande número de sites.
Há também uma grande chance de que o conteúdo da web antiga seja raspado em massa por empresas de IA e depois reproduzido ao público por meio da nova web.
Precisamos de Linux para smartphones. Se for possível fazer operações bancárias pelo navegador, não é necessário ter app, mas o modem celular e apps importantes como Sonos e Spotify precisam funcionar.
Precisamos de leis que obriguem serviços essenciais, como bancos e contas de serviços públicos, a oferecer um ambiente web que funcione corretamente. Caso contrário, o duopólio atual ficará ainda mais entrincheirado.
Eu também deveria apoiar de forma mais ativa empresas que oferecem serviços pela web.
Consulte a wiki do postmarketOS para ver os dispositivos compatíveis e verificar se um aparelho que você já possui é suportado; se possível, contribua para melhorar esse suporte. Caso contrário, dá para encontrar no eBay aparelhos usados com bom status de suporte.
O Librem 5 e o PinePhone têm bom suporte, mas aparelhos Android antigos como o OnePlus 6T podem oferecer melhor custo-benefício. Antes de comprar, é preciso verificar se os recursos principais funcionam.
Apps Android populares podem ser executados com Waydroid.
A alternativa, autenticação por SMS, também não é segura e está desaparecendo; do ponto de vista da segurança, é a direção correta, mas faltam outros meios utilizáveis.