Mapear protocolo binário desconhecido com ajuda da IA

Encarar um protocolo binário desconhecido é um exercício específico de paciência: você tem bytes brutos, nenhum manual, e precisa transformar isso em código que leia eventos de aplicação. No WS-engine, foi assim que montei o decoder do jogo — sem documentação, sem acesso ao código fonte do cliente, apenas capturas pcapng e a IA como par de programação pelo terminal. Este artigo mostra o processo real, as hipóteses erradas que custaram tempo, e como a IA entrou no meio. Nada aqui revela layouts específicos do protocolo analisado; o foco é método. Para o contexto maior, veja o guia de engenharia reversa com IA.

Como se começa quando o protocolo não é documentado

A premissa inicial é incômoda: você tem bytes, não tem semântica. A única forma de atribuir sentido é correlacionar o que o jogo faz (ação visível na tela) com o que viaja pelo cabo (bytes capturados). O método básico é esse laço: executar uma ação conhecida, capturar o tráfego, isolar as mensagens que apareceram naquele intervalo, formular hipótese sobre o que cada byte representa, testar a hipótese numa segunda captura com a mesma ação, confirmar ou descartar.

Mapear um protocolo binário desconhecido assim leva semanas, não dias. Não existe atalho inteligente — ou você investe o tempo olhando bytes com cuidado, ou publica decoder que quebra ao primeiro corner case. A IA ajuda na velocidade de iteração, não no pular etapa. Essa diferença importa.

Primeira hipótese: um framing simples demais

No começo, o modelo mental mais fácil de aceitar é que cada mensagem tem um identificador de tipo em um byte, seguido de um tamanho em outro byte, seguido do payload. Simples. Funciona nos primeiros exemplos. Para a maioria das mensagens pequenas, parece explicar tudo que você está vendo.

Essa foi a hipótese inicial no WS-engine. Rodei dias em cima dela, escrevi um parser que funcionava em muitas capturas, publiquei código, segui pra decoders específicos. O problema é que esse modelo é simples demais. Ele funcionou por coincidência enquanto os campos de tipo e tamanho ficaram pequenos — abaixo de um certo limite, qualquer esquema de codificação de inteiro cabe no mesmo byte, então o modelo errado parece certo.

Esse é o perigo mais sutil de encarar protocolo binário desconhecido: a primeira hipótese parece sempre bater com os dados até você encontrar o caso que ela não cobre. Até lá, você constrói em cima de areia.

Como você descobre que a hipótese está errada

No meu caso, o colapso veio quando apareceram mensagens maiores que a hipótese simples suportava. De repente, o parser começou a interpretar bytes de dados reais como se fossem bytes de controle. O sintoma concreto: campos faziam sentido no começo da mensagem, depois degeneravam em números absurdos no meio. Qualquer tentativa de "patch" criava novas exceções — "para este tipo, use interpretação A; para aquele outro, B; para um terceiro, C".

Quando o decoder começa a precisar de três ou mais formatos alternativos pra uma mesma mensagem, é sinal de que o modelo base está errado. Não é que o protocolo seja irregular; é que a teoria subjacente não captura o que ele realmente faz. A IA é útil aqui porque entra sem viés — você conta o sintoma, ela sugere modelos alternativos sem defender o que você já implementou.

As pistas conceituais que destravaram tudo

Dois conceitos acabaram sendo a chave: varint e TLV. Mencionados aqui apenas no nível alto, porque cada um merece artigo próprio: varint é uma forma de codificar inteiros em quantidade variável de bytes, usando o bit mais alto de cada byte como sinal de "continua"; TLV é um padrão de mensagem onde tipo, tamanho e valor convivem em sequência. Juntos, formam um framing comum em protocolos de aplicação modernos.

Reconhecer que o protocolo que eu estava decodificando usava esse par explicou tudo que a hipótese anterior não conseguia. Mensagens maiores passaram a bater porque o tamanho não é mais um byte fixo — é um inteiro de comprimento variável. O conjunto de "formatos alternativos" sumiu, porque não havia alternativa de verdade: era um só framing com codificação de inteiros que eu estava interpretando errado.

Essa é a parte onde a IA mais rendeu. Descrevi os sintomas, mostrei bytes concretos, e o modelo propôs varint-TLV como hipótese alternativa. Não teria pensado nisso sozinho no estágio em que estava. Pra um protocolo binário desconhecido, ter alguém que lê documentação de protocolos como esporte é um super poder.

Ground truth: usar o jogo pra conferir cada hipótese

Hipótese sem teste é especulação. O que separa o método real do "achismo com IA" é a ground truth sistemática. Pra cada hipótese que você levanta, você precisa de uma situação no jogo onde o resultado é conhecido antes de você olhar o pacote — e esse resultado precisa aparecer nos bytes de alguma forma identificável.

No WS-engine, isso significou gravar sessões onde eu fiz exatamente o que ia testar: deu dano X num mob, curou Y num aliado, entrou numa área específica. Depois procurava esses valores no byte stream da captura. Se o número aparecia como u32 little-endian em certa posição, ótimo, hipótese reforçada. Se não aparecia em nenhum formato esperado, hipótese perdeu força.

Mantenho um conjunto de capturas de referência salvas em disco, cada uma com arquivo markdown ao lado descrevendo o que acontece naquela sessão (ground truth). Qualquer mudança no decoder passa por uma suíte automática que corre essas capturas e compara os totais extraídos com o ground truth esperado. Essa suíte é o que me permite refatorar o decoder sem medo depois de aprender algo novo.

Hipóteses erradas que custaram tempo

Duas valem o aviso. A primeira: o byte mais alto de identificadores de entidade parecia ter semântica estável — todas as invocações começavam com um valor fixo, todos os monstros com outro. Construí filtros em cima disso. Patch do jogo migrou todos esses bytes altos de uma vez pra valores completamente diferentes, e um bando de componentes quebrou junto. Lição: byte alto de identificador em protocolo de aplicação quase sempre é alocação arbitrária do servidor, não semântica.

A segunda: passei horas investigando o que acreditava ser uma estrutura separada dentro de um envelope comprimido — supostamente uma lista de jogadores presentes na área. Scripts probe, análises exaustivas, nested parsing. No fim, descobri que aquilo que meu scan achava era só uma repetição de um tipo de mensagem já conhecido aninhado dentro do envelope — a estrutura separada nunca existiu. Lição: hipótese que precisa postular "uma coisa nova aqui" costuma estar reinventando algo que já está em outro lugar do protocolo.

Como a IA entrou como par nessa dança

A IA não substituiu o processo, acelerou cada iteração. Sentado no terminal com Claude Code, abria uma captura e dizia "procura o número X nessa sequência de bytes". Ele propunha varreduras, escrevia scripts de análise, lia o output comigo. Em muitos ciclos acertou de primeira; em outros, propôs três hipóteses conflitantes e me ajudou a desenhar o experimento que escolheu entre elas.

Também usei a IA pra ler meus próprios probes depois que o resultado não fazia sentido — ela cruzava com os logs e às vezes identificava que minha interpretação do próprio experimento estava errada. Isso aconteceu em pelo menos duas situações em que estava convencido de que o protocolo tinha um comportamento que, na verdade, era bug no meu script de teste. Encarar protocolo binário desconhecido sozinho é lento; com par que te lê sem ego, acelera. Pra ver outros projetos no mesmo espírito, dá uma volta no ModoDev.