Todos os Hooks do Frida Funcionaram. Por Que Ainda Fiquei com Zero Endpoints Utilizáveis.

Mapeei os vínculos nativos nas três plataformas: onde começa o registro do dispositivo, em que camada o SDK de segurança intercepta a requisição, como o interceptor nativo reescreve o pacote de saída e quais métodos o JNI registra dinamicamente no runtime com RegisterNatives. O script do Frida conectava, os logs corriam e todos os hooks disparavam de forma confiável. Ainda assim, ao abrir o catálogo de comandos, a contagem de endpoints nativos chamáveis nesses três apps era: zero.

No mesmo projeto, outra plataforma tinha 11. Todos validados em campo, já migrados para o código e disponíveis como comandos de primeira classe.

A diferença não estava na técnica de hooking. Os hooks funcionavam e o diagrama do fluxo estava bem desenhado. O ponto é um critério que muita gente nem percebe que existe: entre um hook disparar e uma capacidade ser utilizável, há uma camada de evidências. Este texto mostra como definir esse limite, por que declarar algo como “ainda não utilizável” custa menos do que lançar um endpoint incompleto e qual é o papel real dos modelos nesse processo.

Hook ativo não significa endpoint utilizável

Quem faz engenharia reversa de apps costuma tratar “o hook disparou” como linha de chegada. O script se conectou ao método-alvo, o log trouxe argumentos, valor de retorno e pilha de chamadas. A sensação de “estou lá dentro” é real — e bastante enganosa.

Mas o catálogo de comandos não aceita “estou lá dentro”. Ele exige outra coisa: dado um input normal, esse comando consegue produzir de forma confiável um payload não vazio, estruturado corretamente e pronto para consumo pelos sistemas seguintes? Há uma distância enorme entre essas duas situações.

O colapso típico acontece assim: todos os hooks disparam, o fluxo está completo e você até vê no log a requisição de registro do dispositivo saindo, o SDK de segurança calculando seu valor e o interceptor nativo adicionando o cabeçalho de assinatura. Tudo parece certo. Então você executa em um dispositivo real e o registro devolve um ID de dispositivo zerado, ou o endpoint de detalhes retorna um corpo vazio. O caminho está aberto, mas os dados não existem.

O que você tem nesse momento? Um conjunto de sondas capaz de observar o comportamento interno de uma versão desse app. O que você não tem é um endpoint chamável. Publicar a primeira coisa como se fosse a segunda é deixar uma armadilha para quem vier depois.

O grupo de controle: o que separa 11 de 0

Coloque os dois grupos de plataformas lado a lado e o critério aparece com clareza.

Os 11 comandos da plataforma de controle não tinham apenas “hooks melhores”. Cada um ultrapassou os quatro limiares de evidência da próxima seção antes de ser migrado para um comando Python de primeira classe — e levou consigo suas evidências estruturadas de validação.

As três plataformas não ficaram paradas. A camada de interceptação do SDK de segurança, o interceptor nativo de requisições e o conjunto de métodos que o JNI registrou dinamicamente foram todos identificados, e os hooks do Frida continuam no lugar. Porém, enquanto o estado real de instalação não passar, enquanto o registro do dispositivo não conseguir uma identidade diferente de zero, tudo que vem depois seguirá vazio. Por isso, os comandos nativos desses apps continuam honestamente em 0; o que é utilizável hoje segue por uma rota totalmente separada, via transporte Web ou navegador.

No balanço maior, este conjunto de capacidades móveis soma 32: 23 viraram implementações de fato, e as 9 restantes estão presas em “aguardando perfil real do dispositivo”, sem entrar antecipadamente no catálogo. O número 9 não representa fracasso; representa disciplina. Ele mede exatamente o tamanho do grupo “fluxo entendido, evidência insuficiente”.

Os quatro limiares de evidência

Ao separar a comparação, fica claro que uma capacidade de app precisa atender a quatro condições para entrar no catálogo de comandos. Se faltar uma, ela fica de fora.

1. Estado real de instalação. A requisição precisa partir de uma identidade de instalação diferente de zero e reconhecida pelo upstream. Não basta um hook disparar em um ambiente emulado ou em um perfil quebrado. Quando o registro do dispositivo devolve um ID zerado, esta barreira falhou; depois disso, não importa o quão completo esteja o fluxo, a saída será vazia. Foi aqui que as três plataformas travaram juntas.

2. Resposta não vazia. Estar aberto não é o mesmo que conter dados. A requisição sai, o status é 200, mas o corpo vem vazio. Esse “sucesso com resposta vazia” é mais perigoso do que um erro, porque passa por toda validação que só verifica se uma exceção foi lançada. O limiar exige dados estruturados, completos e não vazios, que possam seguir diretamente para consumo downstream.

3. Classificação completa de erros. Quando falha, uma capacidade madura precisa explicar a causa em vez de lançar um erro genérico. Página ausente, falta de login, runtime não pronto e resposta vazia são falhas completamente diferentes; elas precisam ter códigos de erro distintos, não ser agrupadas em um só. Um comando que apenas diz “falhou” não está pronto para o catálogo, pois quem o chama não consegue decidir se deve tentar novamente, autenticar-se de novo ou ignorar o resultado.

4. Teste fechado e repetível. Um único acerto por sorte não é uma capacidade. O mesmo input e o mesmo fluxo precisam funcionar de forma repetível, e esse sucesso deve ficar congelado como evidência estruturada de validação. Se funciona uma vez e volta vazio na seguinte, você ainda não controla o fluxo; apenas coincidiu uma vez com aquele estado do runtime.

Os quatro fechados, a capacidade entra no catálogo de comandos. Basta um permanecer aberto para ela continuar sendo um ativo de pesquisa, e não um endpoint. A diferença entre esses dois termos é o núcleo deste texto.

Quando o log do Frida explode, divida o trabalho entre camadas de modelos

Para avaliar em qual dos quatro limiares um fluxo travou, a matéria-prima é o trace produzido pelo Frida. E traces do Frida crescem rápido. Conecte algumas dezenas de métodos, execute um fluxo completo e será normal lidar com dezenas ou centenas de milhares de linhas, em grande parte ruído de polyfills, heartbeats e módulos de negócio sem relação com o problema.

Jogar tudo em um único modelo e perguntar “por que este hook não trouxe dados?” tende a gerar um palpite genérico. Quanto maior o contexto, maior também a chance de ele unir trechos de chamadas que não têm relação. A abordagem certa é dividir o trace e encaminhar segmentos distintos para camadas de modelos diferentes, de acordo com a capacidade necessária.

Este é um caso clássico para combinar camadas, não para “escolher o modelo mais forte e usá-lo em tudo”. As quatro tarefas pedem competências muito diferentes:

Vale destacar a etapa de rotulagem. É trabalho braçal puro: separar, em dezenas de milhares de linhas, o ruído e preservar apenas as classes de registro de dispositivo, criptografia e rede. O volume é alto demais para fazer à mão. Esse tipo de “julgamento simples em frequência muito alta” é exatamente o terreno da camada barata; usar a camada de raciocínio aqui é desperdício direto de dinheiro. Depois que o log for comprimido em algumas centenas de linhas rotuladas, passe-o para a camada de raciocínio decidir “qual limiar falhou”. Custo e precisão passam a fazer sentido ao mesmo tempo.

O efeito dessa divisão é fácil de verificar. Basta executar uma rodada:

1. Separe um trecho de trace de um fluxo, com algumas milhares a dezenas de milhares de linhas.

2. Rotule-o em blocos primeiro com claude-sonnet-5, removendo as linhas de ruído e preservando as classes de registro de dispositivo, criptografia e rede.

3. Envie o resumo rotulado para claude-opus-5 e peça que informe “em qual dos quatro limiares este fluxo está travado, além das linhas que sustentam essa evidência”.

4. Como controle, despeje o mesmo trace bruto inteiro em um único modelo e faça a mesma pergunta.

5. Observe uma única coisa: ele entrega um palpite genérico ou aponta um limiar específico e linhas específicas? Essa diferença é seu critério de seleção.

Um hook é uma sonda de observação presa à versão, não um signer

Por que os hooks dessas três plataformas foram mantidos, mas deliberadamente deixados fora do catálogo de comandos? Porque hook é sonda, não signer — e a natureza dos dois é fundamentalmente diferente.

Um hook está preso a uma build específica do app, como a versão 32.x. Os símbolos, offsets e o layout de métodos dos quais ele depende pertencem àquela versão. O upstream lança uma atualização, tudo muda e o hook morre na hora. Ele é inerentemente perecível e dependente de versão. Sua resposta é observacional: “o que esta versão está fazendo internamente agora?”. É exatamente para isso que serve uma ferramenta de instrumentação: a documentação do Frida descreve Interceptor como um meio de observar e reescrever chamadas em runtime. Ele permite ver como uma função é chamada e quais são seus argumentos, mas não é, por si só, um artefato pronto que “calcula uma assinatura a partir de um input”.

Um signer que entra no catálogo de endpoints é o oposto: precisa ser estável, repetível, independente e testável em CI. Ele responde a uma pergunta de capacidade reutilizável: “dê-me um input e eu calculo a assinatura correta”. Mesmo que um hook revele com clareza a estrutura do algoritmo de assinatura, isso é apenas a etapa de identificação de fingerprint do algoritmo; ainda há todo um processo de purificação e verificação diferencial até chegar a um signer independente.

Isso também explica a ordem da escada de purificação: uma capacidade deve primeiro buscar conexão direta em Python puro; depois, recorrer à execução de um fragmento mínimo de assinatura em Node/V8 local; e só aceitar, com relutância, uma ponte passiva de navegador. Hook nem entrou nessa escada ainda. Ele fica antes dela, na fase de “pesquisa”, não de “implementação”. Registrar uma sonda de observação dependente de versão como signer é pendurar a placa de “implementação” em algo que ainda está pela metade na fase de “pesquisa”.

Como arquivar um ativo de pesquisa sem deixá-lo apodrecer

Deixar um hook fora do catálogo de endpoints não significa jogá-lo fora. Ele é um ativo de pesquisa no qual você investiu esforço real, carregando conhecimento do fluxo, amostras e evidências de validação. Apagá-lo é prejuízo líquido. O objetivo é arquivá-lo corretamente, ou em dois meses nem você saberá até onde o trabalho chegou.

Um ativo de pesquisa de app deve registrar pelo menos estas quatro informações:

• Tipo de transporte. Se o fluxo roda no protocolo nativo, em uma assinatura local com Node/V8 ou em uma ponte passiva de navegador. Isso define até onde ele pode ser purificado mais tarde.

• Nível de evidência. Quantos dos quatro limiares ele ultrapassou. Pode ser “fluxo localizado”, “estado de instalação diferente de zero, mas resposta vazia” ou “resposta não vazia, porém não repetível”. Esse item informa a quem vier depois exatamente o que falta para torná-lo utilizável.

• Versão / build do app. A versão à qual o hook está vinculado. Sem isso, quando o upstream atualizar, não haverá como distinguir entre um erro na sua implementação e uma mudança na build.

• Resumo da amostra. Como eram o input e o output daquela execução, preservados em uma cópia dessensibilizada. É a âncora mais rápida para retomar a pesquisa.

Registre esses quatro pontos e um fluxo travado em 0 comandos se torna um ativo que pode avançar, não uma pilha de logs vencidos. Isso também evita os dois piores tratamentos de uma vez: apagar o hook e fingir que a pesquisa nunca existiu, ou forçá-lo para dentro do catálogo e fingir que é utilizável. O segundo custa especialmente caro. Um endpoint que “parece chamável, mas na prática retorna vazio” distribui seu custo por todos os consumidores downstream que confiam no catálogo: eles criam integrações em cima dele, implementam retentativas, são atingidos uma vez pelos dados vazios e acabam desconfiando do catálogo inteiro. Uma lacuna honesta, marcada como “ativo de pesquisa, 0 comandos”, custa apenas a você, uma única vez, em uma linha do README.

Uma casca vazia custa mais do que uma lacuna — e poucos cenários deixam isso tão claro quanto este.

Uma chave reduz o atrito ao dividir os logs

Voltando à divisão de logs da quarta seção: contexto longo para ler o trace completo, camada barata para rotular em massa, camada de raciocínio para classificar e camada de raciocínio intermediário para atribuir causas. São quatro camadas de vários fornecedores, quatro SDKs, quatro esquemas de autenticação e quatro formatos de erro. Para classificar um log do Frida entre quatro clientes, muita gente faz as contas, conclui que não vale a pena e acaba encarando centenas de milhares de linhas de trace com um único modelo — gastando demais ou sem conseguir processar tudo.

AIReiter elimina esse atrito: uma chave, uma interface compatível com OpenAI e as quatro camadas por trás dela. Para alternar entre elas, basta mudar o campo model no corpo da requisição.

# Label the log: the cheap tier, thousands of calls at high concurrency
curl https://aireiter.com/api/v1/chat/completions \
  -H "Authorization: Bearer $AIREITER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "messages": [{"role": "user", "content": "<one chunk of trace + labeling instruction>"}]
  }'

# Classify the threshold: switch to the reasoning tier, leave the rest
#   "model": "claude-opus-5"
# Read the whole call chain: the long-context tier
#   "model": "kimi-k3"
# Attribute the response difference:
#   "model": "gpt-5.6-sol"

Se você já usa o SDK da OpenAI, aponte base_url para https://aireiter.com/api/v1 e não mude mais nada. No SDK da Anthropic, use POST /api/v1/messages com a mesma chave.

Este processo tem uma estrutura de custos desigual, e o desconto incide justamente na parte desigual. O trace de um único fluxo contém de dezenas a centenas de milhares de linhas; a rotulagem acontece bloco a bloco, e uma plataforma pode exigir centenas ou milhares de chamadas a claude-sonnet-5. Esse é o grosso do custo. As chamadas de contexto longo para ler um trace inteiro trabalham com algumas centenas de milhares de tokens por input e formam outra parcela grande. Classificação e atribuição são poucas chamadas, mas com preço unitário maior. O desconto de 30% no Claude incide diretamente sobre rotulagem e classificação de limiar, as duas partes mais caras. O GPT pela metade do preço entra na camada de atribuição. A leitura de contexto longo roda no Kimi K3, acessível pela mesma chave.

• Obtenha uma chave de API

• Experimente sem cadastro: entregue um segmento de trace ao claude-sonnet-5 para rotular e depois peça ao claude-opus-5 que o classifique. Antes de decidir integrar, veja se ele consegue apontar diretamente em qual limiar o fluxo travou.

Conclusão

Na engenharia reversa de apps, um hook disparar oferece a capacidade de observação: “consigo ver o que esta versão está fazendo internamente”. Já o catálogo de endpoints exige capacidade de chamada: “dê-me um input e eu produzo, de forma confiável, dados corretos e não vazios”. Entre as duas coisas estão quatro limiares de evidência: estado real de instalação, resposta não vazia, classificação de erros e teste repetível.

Ter três plataformas completamente mapeadas, com todos os hooks funcionando e ainda assim 0 comandos não é fracasso; é disciplina. Se o estado real de instalação não passa, você para honestamente no 0, arquiva o hook como ativo de pesquisa e retoma o avanço quando tiver o perfil do dispositivo em mãos.

O lugar do modelo nesse fluxo é específico. Ele divide, rotula, classifica e atribui causas em centenas de milhares de linhas de trace, comprimindo “onde este fluxo travou?” de uma tarde lendo logs para alguns minutos. Mas a decisão de “o limiar foi ultrapassado?”, assim como a decisão de “a hipótese está correta?” em testes diferenciais, não cabe ao modelo no fim. Ela cabe aos quatro critérios que você definiu e às evidências que se repetem na prática. A visão de como todo o fluxo de engenharia reversa posiciona o modelo no lugar certo está no panorama das quatro etapas.