IA erra ao decodificar os dados de localização que o iPhone envia à Apple, mas escreve ferramenta que pode ser validada

Douglas J. Leith, do Trinity College Dublin, na Irlanda, publicou no arXiv em 15 de outubro de 2026 o artigo “Decoding What iOS Location Services Send to Apple: An LLM Is an Unreliable Analyst but a Useful Toolmaker”, que testa se a inteligência artificial pode fazer a engenharia reversa dos dados que o iPhone envia aos serviços de localização da Apple e conclui que a IA é um analista pouco confiável, mas um bom construtor de ferramentas, desde que o resultado da ferramenta possa ser conferido.

O problema: mensagens sem manual

O tráfego de rede de um iPhone pode ser decifrado num aparelho desbloqueado (jailbreak), mas o conteúdo vem codificado em protobuf, um formato binário cujo esquema, a lista de campos com número, tipo e nome de cada um, a Apple não publica, e por isso o esquema tem de ser recuperado do próprio programa que monta a mensagem.

O código da Apple é, em boa parte, Objective-C compilado para processadores ARM64, e o autor descreve esse trabalho como especializado e lento, o que torna atraente entregar a tarefa a um modelo de linguagem, e o estudo diz que essa pergunta interessa à análise pericial e de privacidade em geral.

O teste com dois modelos de IA

O autor usou dois modelos de ponta, Claude Opus 4.8 e Codex GPT Sol 5.6, para reconstruir, a partir dos binários da Apple, os esquemas de 17 mensagens de requisição e resposta observadas no tráfego, que somavam 7.788 campos em 1.627 tipos de mensagem, e cada tipo foi entregue a um subagente novo, com contexto limpo.

A avaliação foi cega, com cada modelo rodando num ambiente isolado, sem acesso aos esquemas corretos, a conversas anteriores nem à internet, e o resultado foi comparado campo a campo com o da ferramenta validada que o autor desenvolveu à parte, considerando certo só o campo com o mesmo número, no mesmo lugar da árvore da mensagem, com o mesmo tipo e o mesmo nome.

O que saiu errado

O Claude acertou 86,1% dos 4.151 campos simples e o Codex 79,1%, mas, quando se exige que toda a subárvore abaixo de um campo de mensagem esteja certa, os acertos caem para 57,8% e 52,0%, e no total ficaram errados 1.069 campos no Claude e 1.980 no Codex, com só 3 dos 17 esquemas inteiramente certos para cada modelo.

Os exemplos do artigo mostram o tipo de dano, como o campo de latitude declarado pelo Claude com um tipo errado, de modo que o decodificador simplesmente o pula, um campo com sinal lido sem sinal, em que o valor −5 vira 9, e a troca de números de campo pelo Codex numa mensagem de consulta de lugares, que impediu a leitura de todas as 34 mensagens desse tipo capturadas.

Esse último foi o único erro que se denunciou sozinho, porque todos os outros decodificaram sem nenhum aviso, e num caso o esquema do Claude fez desaparecer em silêncio 70% dos valores decodificados de oito mensagens capturadas.

O ponto central do estudo é que os esquemas errados são coerentes por dentro, com sintaxe correta e nomes de campo plausíveis, e por isso nada no próprio esquema aponta o erro.

O tráfego real ainda esconde o problema, porque só 806 dos 7.407 campos dos esquemas testáveis (10,9%) apareceram nas capturas, e nesses campos os acertos subiram para 94,2% no Claude e 95,9% no Codex, de modo que testar o esquema contra o tráfego capturado deixaria passar quase 90% dos campos errados.

A reconstrução direta pelos modelos levou cerca de cinco dias de relógio, contra cerca de 2 minutos da ferramenta do autor sem chamar nenhum modelo.

A ferramenta escrita pela IA e como foi validada

A ferramenta, chamada Extractor, tem cerca de 21.000 linhas de Python e um conjunto de testes de tamanho parecido, e o autor informa que foi construída inteiramente pelo Claude, sem nenhuma linha de código ou de teste escrita por pessoa.

A validação partiu da engenharia reversa do molde que as classes de protobuf da Apple seguem, o que permitiu ao autor escrever esquemas com resposta conhecida, compilá-los com um compilador da mesma época do código da Apple e exigir que a ferramenta os recuperasse exatamente, e os testes cobriram 83% das instruções e 71% dos desvios do código que faz a recuperação.

O resultado também foi comparado com esquemas já publicados por outros pesquisadores, com concordância em todos os números de campo e, nas divergências de tipo ou de sentido, com os binários do iPhone dando razão à ferramenta, e com o tráfego real, em que os 889 pares de mensagem e campo observados decodificaram com valores coerentes com o nome do campo, como uma latitude compatível com a posição conhecida do aparelho.

O que o iPhone enviou

Com a ferramenta, o autor decodificou o tráfego de um iPhone 8 com iOS 16.7.11, desbloqueado e interceptado por um proxy, usado por um usuário que recusa compartilhar dados com a Apple, e nenhuma mensagem trouxe identificador direto do usuário ou do aparelho.

Com a localização ligada, o aparelho enviou a posição precisa à Apple em consultas de endereço, em consultas de impressão de Wi-Fi com horários de entrada e saída de visitas e em lotes de pontos de GPS com precisão de cerca de 5m, enquanto a telemetria de uso levou identificadores de sessão que duraram pelo menos 106 dias.

Nas 27 horas com a localização desligada, o aparelho ainda fez 97 consultas de qualidade de Wi-Fi com o endereço MAC do ponto de acesso conectado, o que situa o aparelho na casa das dezenas de metros se a Apple souber onde fica esse ponto de acesso.

Os limites que o autor aponta

O autor diz que o uso do aparelho foi pequeno e que, por isso, a coleta relatada provavelmente está subestimada, que o aparelho desbloqueado pode se comportar de outro jeito, embora não tenha visto sinal disso, e que a principal limitação é a versão antiga do iOS, já que não há jailbreak para as versões mais novas.

Para reduzir esse último problema, ele rodou a ferramenta nos binários do iOS 27 e do macOS 27 e verificou que os 739 campos vistos nas capturas continuam declarados com o mesmo número, nome e tipo, e lembra ainda que os testes da ferramenta partem de um molde reconstruído por ele mesmo e, por isso, carregam as suas premissas sobre o código da Apple.

O que isso muda na prática pericial

A regra que o estudo deixa para quem faz perícia digital é que o uso direto da IA para reconstruir formatos de dados não serve para análise pericial, enquanto uma ferramenta escrita com ajuda da IA é confiável quando há uma referência que não vem do próprio modelo para conferir o resultado, que neste trabalho foram os esquemas compilados com resposta conhecida.

O artigo também situa as mensagens decodificadas ao lado do que a perícia já extrai do próprio aparelho, como as bases do CoreRoutine e os Locais Significativos (Significant Locations), descrevendo os envios à Apple como a contrapartida, do lado do servidor, desses registros guardados no telefone.