Reverse engineering de una controladora: por dónde empezar

Hay un momento en el que mapear deja de bastar. Mueves un control, buscas su función en la lista del software y no está. Consultas la documentación del fabricante y no la encuentras. O peor: la documentación existe, es un PDF de doscientas páginas, y no recoge justo el mensaje que necesitas.

Ese es el punto donde empieza este terreno. Y empieza con una buena noticia: casi todo lo que necesitas ya lo tienes delante, porque tu equipo está enviando esos mensajes constantemente.

Cuándo hace falta, y cuándo no

Antes de meterse en faena, conviene saber que la mayoría de los casos no lo requieren. Para una controladora corriente, observar los mensajes que llegan y consultar la documentación del fabricante es suficiente.

Hace falta de verdad cuando:

• La documentación no existe. No es raro.
• La documentación existe pero está incompleta. Y el ejemplo clásico es muy concreto: muchos manuales no documentan el mensaje que pide la posición de todos los knobs y faders al arrancar la aplicación. Sin él, tu mapping funciona, pero el software no sabe dónde están tus mandos hasta que los mueves uno a uno.
• El equipo no habla MIDI. Va por HID o por un protocolo propio, y ahí no hay mensajes que buscar en una lista: hay bytes que interpretar.

Y una advertencia que ahorra semanas: no empieces de cero. Investiga antes si tu modelo —o cualquier modelo de su familia— ya ha sido analizado. Muchas cosas se comparten entre equipos del mismo fabricante, y los detalles finos (cómo se interpretan los valores de un LED, por ejemplo) suelen repetirse. Repetir un análisis ya publicado es el error más caro de este terreno.

Vías para descubrir el protocolo, de menos a más

La tabla ordena las cuatro vías. El orden no es decorativo: las dos primeras resuelven la mayoría de los casos y mucha gente se lanza a la cuarta sin haber hecho las dos primeras.

El punto de partida: mirar lo que llega

Esto es lo primero que hay que hacer, y no requiere ninguna herramienta externa.

Se arranca el software con la depuración de controladores activada y se mira la salida por consola o el fichero de registro, que contendrá todos los mensajes MIDI que se reciben. Mientras manipulas la controladora, los mensajes aparecen impresos.

Un ejemplo real de esa salida, al mover un fader:

MIDI ch 1: opcode: B0, ctrl: 2, val: 3D
MIDI ch 1: opcode: B0, ctrl: 2, val: 3A
MIDI ch 1: opcode: B0, ctrl: 2, val: 3B

Se lee así: 0xB0 es un mensaje de Control Change en el canal 1; el segundo byte, 0x02, es el número del control que se ha movido; y el tercero es el valor o posición, que para mapear puedes ignorar.

Y ojo con un detalle que casi todo el mundo descubre tarde: ese valor sí importa si quieres controlar LEDs, porque ahí el número te dice qué color o qué nivel de brillo estás enviando.

El método es más simple de lo que parece

Una vez identificados los dos primeros bytes, se convierten en un bloque de control del XML: el primero en el estado y el segundo en el número de control. Eso es todo el mapeo de un control nuevo.

O sea: mover un control, mirar qué sale, apuntar dos bytes. Repetir. La parte tediosa no es la dificultad, es la cantidad de controles.

El salto de mirar a entender: los bytes de estado

Para no ir a ciegas conviene entender cómo se construye un byte de estado, y es más fácil de lo que suena.

El primer byte de todo mensaje MIDI es el byte de estado, y se lee en dos mitades:

• El primer dígito hexadecimal es el código de operación: qué tipo de mensaje es.
• El segundo es el número de canal.

Así, 0x90 significa: código de operación 9 (note on) y canal 0 (el primero). Con esa regla y una tabla pequeña ya puedes leer cualquier captura:

Byte de estado	Mensaje
0x8n	Note off
0x9n	Note on
0xAn	After-touch polifónico
0xBn	Control change
0xCn	Program change

Donde n es el canal. Con esta tabla delante, una captura de cientos de líneas deja de ser un jeroglífico: es una lista de «este botón», «este fader», «este pad».

Dos apuntes que conviene tener presentes desde el principio:

• Todo se muestra en hexadecimal. No es por gusto: es el formato en el que se piensa MIDI, y los manuales que sí documentan sus mensajes también lo usan.
• Los equipos que cumplen el estándar USB MIDI —los llamados class compliant— no necesitan driver. O sea: si tu equipo necesita un driver propio, eso ya es una pista de que puede estar usando algo que no es MIDI estándar.

Cuando el fabricante esconde el protocolo

Aquí llegamos al terreno donde el MIDI se acaba. Si el equipo no envía MIDI, o si el fabricante lo oculta, mirar los logs de tu propio software no sirve: no hay nada que mirar porque el mensaje nunca llega a esa capa.

La vía entonces es grabar el tráfico USB. Es decir, escuchar la conversación a un nivel más bajo, donde sí aparece todo, hable MIDI o no.

Y hay un detalle elegante que explica por qué esto funciona: MIDI viaja dentro del estándar de audio por USB. Por eso se puede analizar con las mismas herramientas que el tráfico de audio por USB, filtrando lo que es MIDI. Para HID, en cambio, el tráfico es otro, y tiene su propio filtro.

La técnica completa —cómo montarlo, qué filtros usar, cómo leer un byte que sobra y cómo capturar sin ahogarte en datos— tiene su propia guía, porque da para mucho. Aquí basta con la idea: cuando el protocolo se esconde, se graba el cable.

Un consejo que sí conviene adelantar, porque es el que más tiempo ahorra: captura pocos segundos mientras haces una acción concreta. Una captura de treinta segundos arrancando un programa puede dejar fácilmente entre 70 y 100 MB de datos. Con eso no se trabaja: se sufre.

Dos casos reales, y por qué son el mejor material

La documentación de referencia recoge dos ejemplos sobre hardware Denon que ilustran perfectamente los dos finales posibles de este trabajo.

El caso que sale bien

En la MC4000, analizando la captura se localizó el mensaje SysEx que el software usaba para pedir el estado de todos los knobs al arrancar. Se envió a la controladora, esta respondió con la posición actual de todos sus mandos, y ese mensaje se pudo usar en la rutina de arranque del mapping.

Resultado: el software ya sabe dónde están los mandos sin que el usuario tenga que moverlos.

El caso que obliga a trabajar más

En la MC7000 el fabricante ocultaba las especificaciones. No había mensajes SysEx evidentes que buscar.

La solución fue más astuta: como se sabía que Denon había colaborado con el otro software, se buscó directamente el identificador de fabricante MIDI de esa otra empresa dentro de la captura, en lugar del de Denon. Y aparecieron mensajes SysEx utilizables.

Lo que enseñan estos dos casos

• Los identificadores de fabricante MIDI son una herramienta de búsqueda. Si el mensaje no está bajo el nombre de tu fabricante, puede estar bajo el de su socio.
• Los SysEx siempre empiezan por f0 y terminan por f7. Es la firma que buscas en una captura.
• A veces la información está, pero no donde esperabas. Cambiar la hipótesis de búsqueda es parte del método.
• Y a menudo no se puede sacar todo. En el caso del hardware Engine DJ hubo documentación del fabricante que se pudo leer, y aun así quedaron preguntas abiertas: cómo interpretar los valores, qué enviar para controlar un anillo de LEDs, o si son encendido/apagado o admiten regulación. Eso se resuelve por prueba y error, no leyendo.

Esa última frase es importante y no se suele decir: en este terreno, a veces no hay una respuesta que leer, solo una que comprobar.

Herramientas por sistema

No hace falta un laboratorio. Lo que hace falta es un monitor de MIDI y, si vas a por HID, una captura de tráfico:

• Windows: un monitor de MIDI clásico sirve para interceptar mensajes de otros programas.
• macOS: hay monitores de MIDI específicos para observar las señales.
• Linux: el paquete de utilidades de audio incluye herramientas para listar dispositivos, volcar su tráfico y enviar mensajes concretos desde la línea de comandos. Ese último detalle es el que convierte el análisis en prueba: no solo escuchas, también pruebas hipótesis.

Y para ver lo que hace otro software con el equipo, la vía documentada es ejecutar ese otro programa en una máquina virtual y grabar el USB desde el sistema anfitrión. Sobre Windows en una máquina virtual, la propia documentación avisa de que conviene no instalar los drivers propietarios de algunos fabricantes porque interfieren con el audio de la máquina virtual, y de que el audio irá con cortes —lo cual es perfectamente aceptable cuando solo estás espiando mensajes, no pinchando.

Reglas de trabajo responsable

Esta sección no es un trámite. Es lo que distingue este trabajo de otra cosa, y conviene tenerlo claro antes de empezar.

Lo que este terreno es:

• Trabajar sobre tu propio equipo.
• Buscar interoperabilidad: que tu hardware funcione donde tú quieres, no donde te obligan.
• Documentar lo observado para que el siguiente no empiece de cero.
• Distinguir siempre entre investigar un protocolo y saltarse una protección. No son lo mismo, aunque a veces se parezcan desde fuera.

Lo que este terreno no es:

• Redistribuir firmware propietario. Se analiza, no se reparte.
• Compartir claves o credenciales ajenas.
• Publicar instrucciones de evasión de protecciones.

Y esta guía se aplica su propia regla: explica arquitectura, método y riesgos, y no publica procedimientos para habilitar interfaces cerradas. No es una omisión: es la línea editorial de este bloque, y es la que hace que el material siga siendo útil y defendible.

Sobre el marco legal: esta guía no da asesoramiento jurídico, y las normas cambian según el país y el caso. Lo que sí se puede afirmar es que la práctica que sigue la comunidad técnica —equipo propio, propósito de interoperabilidad, documentación pública, nada de firmware ajeno— es la que ha producido todo el conocimiento abierto que usas a diario sin saberlo.

Errores frecuentes

• Empezar por Wireshark. La mayoría de los casos se resuelven observando el propio software.
• No buscar antes si tu modelo ya está analizado. Es el trabajo repetido más caro que existe.
• Capturar minutos enteros de tráfico. Vas a ahogarte en datos por una acción que dura dos segundos.
• Buscar solo bajo el fabricante de tu equipo. A veces el mensaje está bajo el de su socio.
• Ignorar el valor del tercer byte. Para mapear da igual; para LEDs, es todo.
• Suponer que el fabricante documenta. Muchos no lo hacen, y la propia documentación técnica lo admite sin rodeos.
• Confundir investigar con evadir. Es la frontera que hay que tener clara, y la que decide si tu trabajo es publicable.

Siguiente paso

Ya tienes el método, las vías, las herramientas y las reglas. Lo que falta es la parte más técnica y la que más veces aparece en los foros: cómo se monta una captura de tráfico USB de verdad, qué filtros se usan para separar MIDI de HID, por qué hay un byte que sobra y cómo hacer capturas limpias y reproducibles. Es exactamente la siguiente guía.