Engenharia Reversa de Protocolo
AÇÃO NECESSÁRIA（leia e execute imediatamente）
AGORA: Leia ../field-journal/precedent-reverse.md — confirme autorização e limites operacionaisAGORA: Confirme se a tarefa é de engenharia reversa de protocolo/tráfego/formato de serialização (não assinatura de parâmetros Web pura → vá para js-reverse/)AGORA: Se houver interação com rede alvo → ../scripts/case-init.ps1 para definir escopo; auth não concedido proíbe ACT contra o alvoPRÓXIMO: Leia ../tool-index.md; se faltar ferramentas, bootstrap (tshark/wireshark etc. podem precisar de instalação manual)AJA: Entre no Fluxo de Trabalho Fase 1, produza um rascunho de layout de frame ou dicionário de mensagens
Cenários de Aplicação
- Protocolo binário TCP/UDP personalizado
- Protobuf / gRPC / FlatBuffers / MessagePack
- WebSocket / MQTT / RPC privado
- Recuperação de campos e máquina de estados a partir de PCAP / PCAPNG
- Validação cliente-servidor, número de sequência, cabeçalho de frame criptografado
Não Use Esta Skill
| Situação | Para Onde Ir |
|---|
| Apenas assinatura de parâmetros HTTP / criptografia JS | js-reverse/ |
| Apenas problema de certificado TLS | pentest-tools/ ou proxy de navegador |
| Exploração profunda de pilha de protocolo em firmware + simulação | firmware-pentest/ e depois retorne a esta skill |
Fluxo de Trabalho
Fase 1 — Coleta e Triagem
□ Obter amostra: PCAP / exportação de proxy / log do cliente / binário
□ Marcar direção: C→S / S→C; há handshake, heartbeat, reconexão?
□ Cabeçalho fixo? Magic number? Campo de comprimento? TLV? Tamanho fixo?
□ Está comprimido (zlib/gzip/lz4) ou criptografado (AES/ChaCha no frame)?
□ tshark -r cap.pcap -T fields -e frame.number -e ip.src -e tcp.payload
Fase 2 — Reconstrução de Layout de Frame
□ Alinhar várias mensagens do mesmo tipo, encontrar bytes invariáveis / número de sequência incremental
□ Campo de comprimento: big-endian/little-endian, inclui cabeçalho ou não
□ Checksum: CRC16/32, checksum, posição do HMAC
□ Desenhar máquina de estados: Connect → Auth → Ready → Request/Response → Close
□ Ferramentas: Rascunho de dissector personalizado no Wireshark / ImHex / Template 010 Editor / Kaitai Struct
Fase 3 — Serialização e Criptografia
□ Protobuf: Recuperação de .proto (blackboxprotobuf / pbtk / protoc --decode_raw)
□ gRPC: Cabeçalhos HTTP/2 + corpo protobuf
□ Criptografia: Encontrar derivação de chave (so/dll/JS do cliente) → Combinar com ida-reverse / js-reverse / apk-reverse
□ Replay: Apenas dentro do escopo autorizado; primeiro campos inofensivos, depois operações sensíveis
Fase 4 — Artefatos
DEVE produzir:
- Tabela de tipos de mensagem (nome / opcode / campos)
- Pelo menos 1 comando ou script de decodificação reproduzível
- Evidência: Trecho hex original + resultado decodificado (anonimizado)
Cadeia de Ferramentas
| Ferramenta | Obrigatório? | Uso | Bootstrap |
|---|
| tshark / Wireshark | Altamente recomendado | Análise de PCAP | Manual / winget |
| Python3 | Sim | Script de decodificação | Sistema |
| blackboxprotobuf | Opcional | Protobuf desconhecido | pip |
| ImHex / 010 | Opcional | Template de estrutura | Manual |
| IDA / r2 / Ghidra | Sob demanda | Funções de serialização do cliente | Ver skill correspondente |
Referências
references/protocol-workflow.md — Layout de frame e consulta rápida de Protobuf- Relacionados:
../ida-reverse/ ../js-reverse/ ../firmware-pentest/ ../pentest-tools/
Contexto de Roteamento
Upstream: MASTER-ROUTING R21 · routing.md
Downstream: Se precisar de algoritmo do cliente → ida-reverse/js-reverse; se precisar de replay → pentest-tools/api-security
Mesmo nível: malware-analysis (protocolo C2), digital-forensics (forense de tráfego)
Auto-Verificação de Conclusão de Tarefa