Cómo Claude ayudó a realizar ingeniería inversa de los protocolos BLE de Garmin para falsificar un sensor de carrera nativo

Un usuario de Reddit documentó cómo usó Claude para resolver dos difíciles problemas de integración con Garmin: hacer que un sensor de pecho no Garmin apareciera como una correa nativa de Garmin en un reloj Fenix, y lograr que un solo chip BLE se presentara como dos dispositivos simultáneamente. El post original detalla el proceso, las fortalezas y debilidades de la IA, y enlaza a dos publicaciones de blog detalladas.

Problema 1: Dinámicas de carrera falsas en un reloj Garmin

Garmin bloquea las métricas de dinámicas de carrera (oscilación vertical, tiempo de contacto con el suelo) a sus propias correas mediante protocolos no documentados. El desarrollador usó Claude para aplicar ingeniería inversa al protocolo mediante:

• Configurar un sniffer Bluetooth y placas ESP32 que ya poseía
• Interceptar la comunicación de una correa Garmin HRM real y luego emularla con un ESP32
• Comparar cientos de líneas de registro para encontrar la diferencia de un solo byte entre estados funcionales y no funcionales
• Migrar el código de suma de verificación y trama de Gadgetbridge
• Buscar en 57,000 archivos descompilados para encontrar el número de campo que descifró el protocolo

Claude escribió el código y realizó el análisis, pero el usuario tuvo que corregir la dirección cuando Claude invirtió el protocolo (qué lado envía qué) y persiguió suposiciones erróneas durante días. El resultado: un ESP32 desnudo con datos aleatorios hace que un Fenix muestre dinámicas de carrera como si vinieran de una correa nativa.

Problema 2: Cambio de identidad BLE dual

En los relojes Garmin, un solo sensor BLE a menudo no puede servir simultáneamente al monitor de frecuencia cardíaca nativo del reloj y a la app Connect IQ: las conexiones compiten y oscilan. Claude sugirió un truco de los estándares BLE: presentar dos direcciones MAC diferentes desde el mismo chip cambiando de dirección a mitad de la conexión. La publicación del blog del desarrollador explica cómo hizo que un nRF52832 alternara entre dos identidades sin perder el enlace activo, a pesar de que la documentación del chip lo desaconseja. Esto resolvió un problema de años para muchos desarrolladores de Connect IQ.

El papel de Claude: Fortalezas y debilidades

El usuario señala que Claude destacó en dos aspectos:

• Agregación de búsqueda: Sabía sobre el cambio de identidad dual aunque el usuario no, y sugirió la técnica.
• Trabajo pesado: Ejecutar la comparación, migrar código y buscar en archivos descompilados.

Pero tuvo dificultades con la dirección: invirtió el protocolo y se basó en suposiciones erróneas durante días. El usuario enfatiza que las pruebas, los datos estáticos y la validación fueron esenciales para detectar alucinaciones.

Más información

El usuario publicó dos artículos detallados con información completa sobre el protocolo y la implementación:

• Cambio de identidad BLE: Dos identidades BLE, un nRF52832
• Ingeniería inversa de dinámicas de carrera de Garmin: Ingeniería inversa de las dinámicas de carrera del Garmin HRM600