ICEBERG Labs

Fase 1: Capturamos el trafico USB equivocado

Empezamos con Wireshark capturando TODO el trafico USB mientras programabamos pulseras con 10, 60 y 180 minutos. Analizamos 40KB de datos hexadecimales con un script Python que comparaba byte por byte.

Encontramos 591 diferencias... pero ninguna escalaba con el tiempo. Despues de renderizar los datos como imagen, descubrimos que eran tickets de la impresora 3nStar, no del programador.

Fase 2: Descubrimos que es un HID, no una impresora

Investigando en el Administrador de Dispositivos encontramos el programador real: un dispositivo HID con VID=0x1A86, PID=0xE010. El fabricante: WCH.CN, producto: "HID To Serial".

Escribimos un lector HID en Python y capturamos los primeros mensajes del dispositivo:

Pero cuando intentamos ENVIAR comandos... el dispositivo los ignoraba todos. Probamos cientos de formatos: ACK, NAK, STX/ETX, ASCII, binario, checksums. Nada funcionaba.

Fase 3: Enviamos basura y el dispositivo reacciono

En un test de diagnostico, enviamos bytes 0xAA repetidos para probar tamanios de reporte. De repente: el dispositivo sono, los LEDs cambiaron de color y el IR empezo a parpadear.

Pero los resultados eran completamente inconsistentes. El mismo comando a veces hacia algo, a veces no. Probamos el header AA 55, y parecia un protocolo real, pero los resultados seguian siendo erraticos.

Fase 4: Abrimos el programador con destornillador

Decidimos ir al hardware. Con un destornillador abrimos el programador y encontramos dos chips principales:

Esto lo cambio todo. Ahora sabiamos que el CH9326 es un puente transparente USB-UART. Los datos que enviamos por HID se convierten a serial y llegan al STC. Solo necesitabamos espiar esa comunicacion serial.

Fase 5: Soldamos cables al UART interno con un ESP32

Conectamos un ESP32 directamente a las lineas UART entre el CH9326 y el STC. Literalmente espiando la conversacion entre los dos chips dentro del programador.

Hubo un momento de panico: al conectar el cable al pin TXD, el IR dejo de funcionar. Solucion: usar una resistencia de 10K para no cargar la linea.

Fase 6: Capturamos el protocolo real por primera vez

Con el sniffer activo y el software original corriendo, vimos por primera vez los bytes REALES del protocolo:

Tambien descubrimos POR QUE los comandos anteriores eran inconsistentes: el CH9326 usa el primer byte como longitud. Nuestro header 0x05 se interpretaba como "envia 5 bytes" en vez de ser parte del protocolo. Faltaba anteponer 0x0B (11 bytes).

Fase 7: Primera pulsera programada con nuestro codigo

Con el protocolo decodificado, creamos programar_pulsera.py. Un ultimo obstaculo: la pulsera no encendia porque el software original de Kpoplight seguia corriendo en segundo plano, sobreescribiendo nuestros tiempos con ceros.

Al cerrar el software del fabricante y ejecutar solo el nuestro: