Revers Engineer Serial Signal

Navega tus respuestas
6

Este es un post largo, ya que quiero llevarte a través de todo el trabajo que he hecho. La versión TL; DR es que tengo un controlador desconocido para una bomba de calor mecánica y estoy tratando de aplicar ingeniería inversa a la señal y los datos ... así que si crees que puedes ayudar, sigue leyendo.

Primero que nada, no soy ingeniero eléctrico. Soy un ingeniero de software que está un poco fuera de su profundidad.

Tengo un ITS heatpump y tiene un controlador que quiero hacer ingeniería inversa para leer datos de los sensores y configurar algunos parámetros en el software. Busqué especificaciones técnicas y le pregunté al fabricante, pero me dijeron a GTFO. Al final, la ingeniería inversa parecía la única forma de obtener lo que quería.

Entre la unidad y el panel de control hay una conexión de 3 cables. De lo que he podido deducir es GND, + 12V (al panel de alimentación) y un cable de señal.

Luego me conseguí un analizador de protocolo Saleae para ver qué podía ver. He confirmado que el cable de datos único se utiliza para RX / TX. Pensé que el punto más fácil de abordar es el panel de control y desconecté el cable de señal para que pudiera leer solo lo que el panel está transmitiendo. Se puede encontrar una muestra en enlace . Estoy utilizando la 1.1.24 versión beta para descodificación. Parece decodificar muy bien usando Async Serial 8N1 autobaud. He probado un montón de otros decodificadores y parámetros, pero todos tienen errores de encuadre u otros.

Luego comencé a cambiar sistemáticamente los valores en el controlador para ver cómo cambia el flujo de bytes. Cambié el parámetro 1 usando valores [51-55] y este fue el resultado (espaciado intencionalmente para facilitar la detección de diferencias) de los flujos de bytes. 

Format <Param>-<value>:<decoded byte string in hex>
01-51:8055DD555555555555555555555555555575577557F58075757757 DD 757577577755DD55555D7777775577755D 55 5D 77 FD
01-52:8055DD555555555555555555555555555575577557F58075757757 D5 DD7577577755DD55555D7777775577755D 55 77 77 F5
01-53:8055DD555555555555555555555555555575577557F58075757757 5D DD7577577755DD55555D7777775577755D 55 75 77 FD
01-54:8055DD555555555555555555555555555575577557F58075757757 75 DD7577577755DD55555D7777775577755D 55 D7 77 F5
01-55:8055DD555555555555555555555555555575577557F58075757757 DD D757DD5D7755D757555D75DD7755DDD575 57 D5 77 57

A partir de eso, el patrón no era obvio, así que decidí cambiar otro parámetro (param: 0 cambiado a 16 de 15) manteniendo el parámetro 01 en 52 y esto es lo que obtuve. 

Format <Param>-<value>:<decoded byte string in hex>
00-15:8055DD555555555555555555555555555575577557F5807575 7757 D5 DD7577577755DD55555D7777775577755D 55 77 77 F5 
00-16:8055DD555555555555555555555555555575577557F5807575 5555 D7 57DD5D7755D757555D75DD7755DDD57557 55 77 F5

Aquellos de ustedes que sean rápidos en el sorteo notarán que la captura de 00-16 es de 1 byte más corta. Mi única conclusión es que o estoy usando la decodificación incorrecta o el panel está haciendo algo de compresión.

Necesito consejos sobre qué intentar a continuación, ya que me siento bastante estancado.

    
pregunta user3180989

2 respuestas

2

Mi primer pensamiento (basado solo en los datos decodificados asíncronos) fue que podría ser una señal codificada de Manchester, en lugar de una serie asíncrona. Ahora creo que los datos se codifican al suprimir pulsos de reloj alternativos.

He aquí por qué:

Con la excepción de 0x80 (que puede ser un "byte de inicio"), el async serial 8N1 afirma que los mensajes están compuestos de solo 10 bytes de símbolos distintos: 

0x55 01010101 (139 occurrence) 
0x57 01010111 (32 occurrence) 
0x5d 01011101 (16 occurrence) 
0x75 01110101 (45 occurrence) 
0x77 01110111 (49 occurrence) 
0xd5 11010101 (5 occurrence) 
0xd7 11010111 (5 occurrence) 
0xdd 11011101 (24 occurrence) 
0xf5 11110101 (11 occurrence, only at end of message) 
0xfd 11111101 (2 occurrence, only at end of message)

En cuanto al binario, parece que el flujo de bits del mensaje está compuesto de pulsos largos y cortos, y puede que no esté sincronizado correctamente con los bits de inicio y parada de la serie asíncrona. Los únicos patrones de bits que tienen más de tres 1 en una fila son 0xFD y 0xF5, pero esto ocurre solo al final de un mensaje, y recuerde, la serie asíncrona es LSB en primer lugar. Por lo tanto, esas secuencias más largas de 1 en la MSB pueden ser posteriores al final de la señal codificada de Manchester subyacente. De manera similar, el 0x80 al comienzo de cada mensaje puede preceder a la señal subyacente.

La introducción de Atmel en Manchester Coding Basics ofrece una buena visión general de la codificación y decodificación: enlace

Ahoraqueveolaformadeonda,definitivamentenoeslacodificacióndeManchester...Pareceinactivo,conunpulsolargocomoencabezado,seguidodeunacadenamuylargadepulsosdereloj,conpulsosderelojfaltantesocasionales.Enestepunto,supongoquelospulsosalternanentrepulsosderelojypulsosdedatos.Porlotanto,un0secodificacomodospulsosderelojyun1secodificacomounpulsoderelojyunpulso"faltante". No estoy seguro de cómo se llama, pero creo que lo he visto antes, hace mucho tiempo ...

    
respondido por el MarkU
2

Definitivamente hay un patrón en los datos que consiste en grupos de bits alineados en los límites de nybble.

Los únicos nybbles que ocurren son 0 , 5 , 7 , 8 , D y F . Además, F y 8 aparecen solo en la mitad superior de un byte. 8 siempre ocurre con 0 como 80 . F ocurre con un 5 , 7 o D inferior nybble.

Los 5 , 7 y D nybbles corresponden a 0101 , 0111 , 1101 . Básicamente, casi todas las posibles repeticiones permitidas son combinaciones de 01 y 11 , excepto 1111 que corresponde a F . Claramente, hay un lenguaje en curso aquí que está compuesto por los símbolos 01 y 11 . Y observa cómo la secuencia 80 viola este patrón: 10, 00, 00, 00 .

Esto sugiere que los datos pueden cambiarse a una entrada de dos bits, llamémosla XY, donde un valor de Y significa hacer algo con X, como cambiar el bit a un registro.

Supongamos que las variables D y F son señales, y 5 y 7 son datos.

Sobre esta base, ¿por qué no reagrupamos los datos de alguna manera? 

                 
00-15:80 55DD555555555555555555555555555575577557F5 80 7575 7     757D 5DD757757 7755D D55 555D7 777 7755 77755D 557  7  77F5
00-16:80 55DD555555555555555555555555555575577557F5 80 7575 5555D 757D D5D       7755D 757 555D7 5DD 7755 DDD57  557  55 77F5

Otra agrupación, mira esto: Supongamos que el byte DD es un separador / terminador: 

00-15:80 55 DD 555555555555555555555555555575577557 F5 80 75757757D5   DD 7577577755              DD 55555D7777775577755D557777 F5
00-16:80 55 DD 555555555555555555555555555575577557 F5 80 75755555D757 DD 5D7755D757555D75DD7755D DD 575575577 F5

Comprueba eso; Ahora tenemos el mismo número de campos. No solo eso, sino que todos los campos están alineados en bytes, no en nybble.

Los otros datos apoyan esta hipótesis de división de campo, excepto la última: 

01-51:80 55 DD 555555555555555555555555555575577557 F5 80 75757757   DD 757577577755 DD 55555D7777775577755D555D77 FD
01-52:80 55 DD 555555555555555555555555555575577557 F5 80 75757757D5 DD 7577577755   DD 55555D7777775577755D557777 F5
01-53:80 55 DD 555555555555555555555555555575577557 F5 80 757577575D DD 7577577755   DD 55555D7777775577755D557577 FD
01-54:80 55 DD 555555555555555555555555555575577557 F5 80 7575775775 DD 7577577755   DD 55555D7777775577755D55D777 F5

01-55:80 55 DD 555555555555555555555555555575577557 F5 80 75757757   DD D757         DD5D7755D757555D75 DD 7755 DD D57557D57757

Pero el último tampoco es Fx terminado; podría ser una mala captura.

La codificación de los campos debe contener algún tipo de convención de escape, porque ¿qué ocurre si DD ocurre naturalmente en los datos? Sería mal interpretado como un separador. Podría haber algún esquema por el cual un D nybble esté sobrecargado como un código de escape de alguna manera.

Puede que no sea una codificación binaria; quizás los nybbles manejen alguna máquina de estado que de alguna manera produce los valores de registro basados en algunas operaciones de incremento combinadas con turnos o lo que sea.

    
respondido por el Kaz

Lea otras preguntas en las etiquetas

Si le doy vuelta a un AA, ¿drenará o dañará la electrónica? Inductancia larga de la línea de transmisión con SPI