Capturar tráfico USB y HID con Wireshark: guía práctica

Cuando el protocolo de un equipo no está documentado, la vía es grabarlo. Y cuando lo cuentas por primera vez suena intimidante: módulos del núcleo, capturas de USB, filtros… Pero en la práctica se reduce a dos decisiones: qué filtro usar y cuánto tiempo grabar. Lo demás es mecánica.

Esta guía es la parte técnica de la anterior. Allí vimos por qué hay que capturar y en qué orden; aquí, cómo se hace.

Antes de capturar: decide qué buscas

El error más común no es técnico, es de planteamiento: lanzar una captura sin saber qué se quiere ver.

Hay exactamente dos escenarios, y se resuelven de forma distinta:

1. Tu equipo habla MIDI y quieres mapearlo. No necesitas Wireshark. El modo de depuración del propio software, o un monitor MIDI, te da los mensajes en claro. Es más rápido, más limpio y no hay que interpretar nada raro.
2. Tu equipo no habla MIDI, o quieres ver lo que hace otro programa. Aquí sí: hay que grabar el USB.

Si estás en el primer caso y has llegado hasta aquí, vuelve a la guía anterior: te estás complicando.

Por qué MIDI se captura con el filtro de audio

Este detalle descoloca a todo el mundo la primera vez, y tiene una explicación sencilla:

MIDI forma parte del estándar de audio por USB.

Por eso, cuando capturas tráfico USB para analizar MIDI, no buscas en una familia de filtros «de MIDI»: buscas dentro de la familia de audio. Y una vez ahí, aislas lo que te interesa con dos filtros concretos:

• Uno para los eventos MIDI, que suelta los mensajes sueltos y te deja fuera el ruido del audio.
• Otro para los mensajes de sistema exclusivo, que además llegan ya reensamblados por el analizador. Ese segundo es especialmente cómodo, porque los SysEx viajan troceados (lo veremos enseguida) y el analizador te los junta.

Y luego está HID, que es otra familia completamente distinta, con sus propios filtros. Ahí ya no hay mensajes MIDI: hay bloques de datos que hay que interpretar.

Los filtros: qué buscar según lo que quieres ver

La tabla resume la decisión. Fíjate en la última fila, porque es la que salva las capturas densas: cuando tienes un equipo con veinte controles y quieres aislar uno, se filtra por identificador de informe.

El byte que sobra (y cómo no volverse loco)

Aquí está la trampa número uno, y es la que hace perder más tiempo.

Cuando capturas paquetes y lees los datos directamente, los datos capturados empiezan con un byte extra que no forma parte del mensaje. No es un mensaje misterioso ni un protocolo propietario: es un artefacto de la propia captura.

La equivalencia se ve mejor con ejemplos de la documentación:

Datos capturados	Mensaje real
0990007f	90 00 7f
0bbf6400	bf 64 00
09900100	90 01 00

Lee la primera fila con lo que ya sabes: 0x90 es note on del canal 1, 0x00 es la nota, y 0x7f es la velocidad, que en un pad o botón significa «pulsado». El 09 inicial es el byte que sobra.

Regla práctica: si estás leyendo una captura cruda y los bytes no cuadran con ninguna tabla de mensajes MIDI, prueba a ignorar el primero. Casi siempre es eso.

Los mensajes SysEx viajan partidos

Aquí está la segunda trampa, y explica por qué en las capturas ves cosas raras.

Los mensajes de sistema exclusivo son más largos que el hueco disponible en un paquete USB. Así que no viajan enteros: se reparten en bloques de tres bytes MIDI, y cada bloque lleva delante un byte de control que indica si el mensaje continúa o si es el último.

Esa es la razón de que en una captura aparezcan números como 04, 05 o 06 intercalados entre los bytes del mensaje. No son parte del protocolo del equipo: son la fontanería del transporte.

Consecuencia práctica muy útil: si tu analizador ofrece la vista reensamblada, úsala. Te ahorra justo el trabajo manual de quitar los bytes de control y volver a pegar los trozos. Y si no la ofrece, ya sabes qué hay que hacer a mano: quitar el byte de control de cada bloque y unir lo que queda.

Y una firma que conviene memorizar, porque es la que buscas en una captura: los mensajes de sistema exclusivo siempre empiezan por f0 y terminan por f7.

Cuando el mensaje no aparece: cambia la hipótesis

Un caso real que enseña mucho: buscando los mensajes de un equipo, no aparecía nada bajo el identificador de su fabricante.

La solución fue preguntarse quién más habla con ese equipo. Si el fabricante del hardware había colaborado con una empresa de software, quizá el mensaje estuviera bajo el identificador de fabricante de esa otra empresa. Se cambió la búsqueda a ese identificador y aparecieron los mensajes.

De ahí salen dos lecciones:

• Los identificadores de fabricante MIDI son una herramienta de búsqueda, no solo un dato de relleno. Hay listados públicos oficiales.
• Cuando no encuentras algo, casi siempre el problema es la hipótesis, no la captura. Antes de volver a grabar, plantéate qué otra cosa podría estar enviando ese mensaje.

Y un aviso para no engañarte: en ese caso, los resultados aparecían etiquetados como datos sobrantes de la captura, porque el analizador no reconocía esos bytes como MIDI. No es que la captura fuera mala: es que no sabía qué eran. Hay que leerlos a mano.

La regla de los pocos segundos

Este consejo parece menor y es el que decide si el trabajo es viable:

Captura solo unos segundos mientras haces una acción concreta.

¿Por qué insistir tanto? Porque capturar treinta segundos arrancando un programa puede generar fácilmente entre 70 y 100 MB de datos. Analizar eso a mano es inviable, y además te obliga a filtrar después para encontrar el fragmento que importaba.

Lo que funciona: una acción, una captura. Pulso un botón, grabo dos segundos, lo leo. Repito. Es más lento en apariencia y muchísimo más rápido en la práctica.

Enviar, no solo escuchar

Hay un paso que convierte la observación en método, y mucha gente se lo salta: además de escuchar, hay que enviar.

Las herramientas de línea de comandos permiten no solo volcar el tráfico de un dispositivo, sino mandarle mensajes concretos. Y ahí es donde dejas de adivinar: localizas un mensaje sospechoso en la captura, lo envías a mano y ves si el equipo responde con el estado de sus mandos.

Ese es el bucle real de trabajo:

1. Observo.
2. Formulo una hipótesis.
3. La envío y compruebo la respuesta.
4. Documento lo que funciona.

Sin el paso 3 estás haciendo arqueología. Con él, estás haciendo ingeniería.

Montar el escenario para ver otro software

Para grabar lo que hace otro programa con tu equipo, la vía documentada es ejecutarlo en una máquina virtual y grabar el USB desde el sistema anfitrión. En Linux, con el módulo de monitorización cargado, la captura se hace igual que con cualquier otro dispositivo.

Detalles que ahorran disgustos:

• Necesitas virtualización por hardware activada en el firmware de la placa.
• Deja espacio de sobra en disco. Con música de prueba, el propio software y el sistema, andar por debajo de unos 35 GB es pedir problemas.
• El audio irá con cortes, y da igual. Estás espiando mensajes, no pinchando. De hecho, conviene poner el búfer al máximo para que los cortes sean tolerables.
• Cuidado con los drivers propietarios de algunos fabricantes: la documentación advierte de que instalar los del fabricante de un equipo concreto deja el programa sin la opción de audio que funcionaba bien en la máquina virtual.

Y si el programa que quieres espiar es exigente con la tarjeta gráfica, no te compliques: hay soluciones que renderizan por software y son suficientes para esto.

Herramientas por sistema

• Windows: un monitor de MIDI clásico permite interceptar mensajes de otros programas, no solo del tuyo. Es la vía directa si tu equipo habla MIDI y quieres ver qué dice el software ajeno.
• macOS: hay monitores de MIDI específicos, y alguno que además permite simular dispositivos.
• Linux: el paquete de utilidades de audio trae lo necesario para listar dispositivos, volcar su tráfico y enviar mensajes concretos desde la línea de comandos. Ese trío cubre el ciclo completo de observación, hipótesis y prueba sin salir de la terminal.

Errores frecuentes

• Abrir Wireshark cuando bastaba el modo de depuración. Si habla MIDI, empieza por lo simple.
• Olvidar el byte extra. Vas a leer mensajes inválidos y culpar al protocolo.
• Leer un SysEx sin reensamblar. Verás bytes de control intercalados y parecerá ruido.
• Capturar treinta segundos. Cien megas que no vas a analizar.
• Buscar solo por el fabricante del equipo. Puede estar bajo el de su socio.
• No enviar nada. Sin probar hipótesis, el análisis no concluye.
• Descartar resultados etiquetados como datos sobrantes. Suelen ser justo lo que buscas.
• Montar la máquina virtual sin activar la virtualización por hardware. Y perder una tarde sin entender por qué.

Siguiente paso

Con esto ya tienes el ciclo completo: observar, filtrar, interpretar, probar y documentar. Y en el camino ha aparecido una pieza que no es un mapping ni una captura, sino una capa que se pone en medio: cuando un control necesita enviar algo que el software no sabe recibir, o cuando un mensaje tiene que convertirse en otro, hace falta un traductor. Eso tiene nombre, tiene usos muy concretos y es la siguiente guía.