Ingeniería Inversa de Protocolos
ACCIÓN REQUERIDA (leer y ejecutar después de leer)
AHORA: Leer ../field-journal/precedent-reverse.md — confirmar autorización y límites operativos habitualesAHORA: Confirmar si la tarea es ingeniería inversa de protocolo/tráfico/formato de serialización (no solo firma de parámetros web → ir a js-reverse/)AHORA: Si hay interacción de red objetivo → ../scripts/case-init.ps1 para completar el alcance; si auth no está concedido, no ACTUAR sobre el objetivoSIGUIENTE: Leer ../tool-index.md; si faltan herramientas, bootstrap (tshark/wireshark etc. pueden necesitar instalación manual)ACTUAR: Entrar en el flujo de trabajo Fase 1, producir un borrador del diseño de la trama o diccionario de mensajes
Escenarios de Aplicación
- Protocolos binarios TCP/UDP personalizados
- Protobuf / gRPC / FlatBuffers / MessagePack
- WebSocket / MQTT / RPC privado
- Recuperación de campos y máquina de estados desde PCAP / PCAPNG
- Validación cliente-servidor, números de secuencia, cabeceras cifradas
No usar este skill
| Situación | Ir a |
|---|
| Solo firma de parámetros HTTP / cifrado JS | js-reverse/ |
| Solo problemas de certificados TLS | pentest-tools/ o proxy de navegador |
| Análisis profundo de stack de protocolos en firmware + simulación | firmware-pentest/ y luego volver a este skill |
Flujo de Trabajo
Fase 1 — Recolección y Triaje
□ Obtener muestra: PCAP / exportación de proxy / registros de cliente / binario
□ Marcar dirección: C→S / S→C; ¿handshake, heartbeat, reconexión?
□ ¿Cabecera fija? ¿Número mágico? ¿Campo de longitud? ¿TLV? ¿Longitud fija?
□ ¿Comprimido (zlib/gzip/lz4) o cifrado (AES/ChaCha dentro de la trama)?
□ tshark -r cap.pcap -T fields -e frame.number -e ip.src -e tcp.payload
Fase 2 — Reconstrucción del Diseño de la Trama
□ Alinear múltiples mensajes del mismo tipo, buscar bytes invariables / números de secuencia crecientes
□ Campo de longitud: big-endian/little-endian, ¿incluye cabecera o no?
□ Suma de verificación: CRC16/32, checksum, posición de HMAC
□ Dibujar máquina de estados: Connect → Auth → Ready → Request/Response → Close
□ Herramientas: Borrador de dissector personalizado de Wireshark / ImHex / Plantilla de 010 Editor / Kaitai Struct
Fase 3 — Serialización y Cifrado
□ Protobuf: Recuperación de .proto (blackboxprotobuf / pbtk / protoc --decode_raw)
□ gRPC: Cabeceras HTTP/2 + cuerpo protobuf
□ Cifrado: Buscar derivación de clave (cliente so/dll/JS) → Combinar con ida-reverse / js-reverse / apk-reverse
□ Rejuego: Solo dentro del alcance autorizado; primero campos inofensivos, luego operaciones sensibles
Fase 4 — Artefactos
DEBE producir:
- Tabla de tipos de mensaje (nombre / código de operación / campos)
- Al menos 1 comando o script de decodificación reproducible
- Evidencia: Extracto hex original + resultado decodificado (anonimizado)
Cadena de Herramientas
| Herramienta | ¿Obligatorio? | Uso | Bootstrap |
|---|
| tshark / Wireshark | Altamente recomendado | Análisis PCAP | Manual / winget |
| Python3 | Sí | Scripts de decodificación | Sistema |
| blackboxprotobuf | Opcional | Protobuf desconocido | pip |
| ImHex / 010 | Opcional | Plantillas de estructura | Manual |
| IDA / r2 / Ghidra | Según necesidad | Funciones de serialización del cliente | Ver skill correspondiente |
Referencias
references/protocol-workflow.md — Diseño de trama y referencia rápida de Protobuf- Relacionados:
../ida-reverse/ ../js-reverse/ ../firmware-pentest/ ../pentest-tools/
Contexto de Enrutamiento
Ascendente: MASTER-ROUTING R21 · routing.md
Descendente: Si se necesita algoritmo del cliente → ida-reverse/js-reverse; si se necesita rejuego → pentest-tools/api-security
Mismo nivel: malware-analysis (protocolo C2), digital-forensics (forense de tráfico)
Autochequeo de Finalización de Tarea