Brocas de control IR de ingeniería inversa / CRC

Question

Estoy tratando de construir un simple basado en Arduino control remoto IR para un hoteles de juguete IR-helicóptero controlado (igual que este - que se llama "Diamond Gyro" o "Diamante de la Fuerza"). He decodificado el IR protocolo , excepto para el último par de bits. Estos últimos bits parecen ser un cheque o CRC, pero no he sido capaz de "crack".

Es bastante fácil de simplemente repetir un grabado de paquetes, pero quiero controlar totalmente el helicóptero. Eso significa que la ingeniería inversa de los bits de comprobación.

(Debo añadir que yo software por día, pero la electrónica es una a veces-afición, así que a lo mejor me estoy perdiendo algo muy básico.)

Los detalles del protocolo en la pregunta y la respuesta, pero estas son las bases:

• 32 bits de paquetes que abarcan múltiples valores individuales/comandos de longitud variable (más 1 bit de inicio/preámbulo, que no cuenta como datos)
• Los valores son "little endian" (MSB primero)
• Estoy seguro de que tenemos las primeras 22 bits asignada...
• ... pero los siguientes 4 bits son un poco misterioso, aunque sé que la finalidad de, al menos 2 de ellos.
• El pasado 6 bits no parecen ser una verificación de CRC o de algún tipo

He aquí un diagrama de

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
--+---------------------------+-----------+---+---+-+-+-----------
 P|    Yaw    |   Throttle    |   Pitch   | T | C |X|X|  CRC?

P: Preamble (always 1), T: Trim, C: Channel,
X: Either part of the channel data or the checksum.

Primero de todo, no estoy seguro de si el X bits son parte del valor del canal, parte de la verificación, o algo más. Que siempre siga el canal de valor, aunque, por lo que es probable que el valor del canal es de 3 a 4 bits de ancho, aunque los 2 bits sería suficiente para los 3 posibles valores de canal.

En segundo lugar, no son los últimos 6 bits (marcado CRC? anteriormente), los cuales son claramente algún tipo de verificación (y, de hecho, el helicóptero no responde si puedo cambiar cualquiera de los bits).

Así que, básicamente, hay un paquete de 24 al 26 de bits de datos, seguido por 6-8 bits de comprobación. Y realmente me gustaría calcular los bits de comprobación para que yo pueda componer paquetes de mí mismo.

A continuación, hay un montón de muestras de los datos binarios que estoy consiguiendo. El preámbulo "1" está siempre presente, y no creo que se considera como parte de los datos, pero he incluido todos modos, sólo en caso de que la clave de todo.

De nuevo, no sé si el X bits son parte de los datos o la verificación. Dependiendo de la forma en que la verificación se calcula, podría ser que los primeros 1 a 2 bits de la verificación acaba de pasar para seguir el canal de valor. Pero es muy posible también que el valor del canal es de 4 bits de longitud, la incorporación de la X bits. O se está en el medio con un X bits de la parte de la canal, y el otro es parte de la verificación. No sé.

Si alguien sabe lo que la verificación es, o cómo se podría ir sobre la búsqueda de fuera, me encantaría saber. Me imagino que puedo fuerza bruta, pero incluso si esa es la única opción, me gustaría saber algunos consejos de cómo hacer mejor que.

El helicóptero es muy barato, así que dudo que haya algo realmente de lujo pasando.

Channel A                                                       
P  Yaw     Throttle  Pitch   Tr  Ch  XX  Check     Description
--------------------------------------------------------------
1  000100  10000100  000000  00  01  01  000101    Left Mid + throttle 
1  000000  10000110  010001  00  01  01  010010    Left Max + throttle 
1  100001  10000110  000000  00  01  01  100010    Right Mid + throttle 
1  100100  10000100  010001  00  01  01  110100    Right Max + throttle
1  010001  00000000  001011  00  01  01  011111    Forward Min 
1  010001  00000000  000000  00  01  01  010100    Forward Max 
1  010001  00000000  011000  00  01  01  001100    Back Min 
1  010001  00000000  100101  00  01  01  110001    Back Max
1  010001  00000000  010001  01  01  01  010101    Left Trim 
1  010001  00000000  010001  10  01  01  100101    Right Trim 
1  010001  00000011  010001  00  01  01  000110    Throttle 01 (min)
1  010001  00010110  010001  00  01  01  010011    Throttle 02
1  010001  00011111  010001  00  01  01  011010    Throttle 03
1  010001  00101111  010001  00  01  01  101010    Throttle 04
1  010001  00111110  010001  00  01  01  111011    Throttle 05
1  010001  01010101  010001  00  01  01  010000    Throttle 06
1  010001  01011111  010001  00  01  01  011010    Throttle 07
1  010001  01101100  010001  00  01  01  101001    Throttle 08
1  010001  01111010  010001  00  01  01  111111    Throttle 09
1  010001  10000101  010001  00  01  01  000000    Throttle 10 (max)

Channel B
P  Yaw     Throttle  Pitch   Tr  Ch  XX  Check     Description
--------------------------------------------------------------
1  000000  10000110  010001  00  00  10  010101    Left Max + throttle 
1  100100  10000110  010001  00  00  10  110001    Right Max + throttle 
1  010001  00000000  001001  00  00  10  011010    Forward Min 
1  010001  00000000  000000  00  00  10  010011    Forward Max 
1  010001  00000000  010111  00  00  10  000100    Back Min 
1  010001  00000000  100110  00  00  10  110101    Back Max
1  010001  00000000  010001  01  00  10  010010    Left Trim 
1  010001  00000000  010001  10  00  10  100010    Right Trim 
1  010001  00000001  010001  00  00  10  000011    Throttle Min 
1  010001  00110100  010001  00  00  10  110110    Throttle Mid 
1  010001  01100111  010001  00  00  10  100101    Throttle High 
1  010001  10001111  010001  00  00  10  001101    Throttle Max 

Channel C
P  Yaw     Throttle  Pitch   Tr  Ch  XX  Check     Description
--------------------------------------------------------------
1  000000  10000101  010001  00  10  00  011100    Left Max + throttle
1  100100  10000101  010001  00  10  00  111000    Right Max + throttle 
1  010001  00000000  001010  00  10  00  010011    Forward Min 
1  010001  00000000  000000  00  10  00  011001    Forward Max 
1  010001  00000000  010111  00  10  00  001110    Back Min 
1  010001  00000000  100110  00  10  00  111111    Back Max
1  010001  00000000  010001  01  10  00  011000    Left Trim 
1  010001  00000000  010001  10  10  00  101000    Right Trim 
1  010001  00000001  010001  00  10  00  001001    Throttle Min 
1  010001  00110100  010001  00  10  00  111100    Throttle Mid 
1  010001  01100110  010001  00  10  00  101110    Throttle High 
1  010001  10000101  010001  00  10  00  001101    Throttle Max

Answer 1

Acerca del XX: como señala Dave, parecen ser parte de la información del canal, ya que siempre son los mismos para un canal determinado. No son realmente requeridos; como dijiste, puedes codificar 3 canales con solo 2 bits, pero los 4 bits dados permiten una distancia de Hamming de 2. Esto significa que los códigos para los canales siempre están separados al menos en 2 bits; cambiar un solo bit no da como resultado un código de canal válido. Junto con la suma de comprobación, esto aumenta la fiabilidad.

Answer 2

Primero de todo, es bastante claro que el "XX" bits son parte de la canal de designación, ya que es la única cosa de la que dependen. El "XX" bits puede ser simplemente un cheque en la "Ch" bits.

Los bits de comprobación son un simple XOR bit a bit, de 24 de los 26 bits de datos: Si usted toma el 6 de Guiñada bits, el 6 LSBs del Acelerador, el 6 de Tono bits, y el próximo de 6 bits, y XOR esas cantidades, tienes los 6 bits de comprobación. Parece que la parte superior de 2 bits del Acelerador no afectar a los bits de comprobación.

La siguiente secuencia de comandos Perl verifica esto.

#!/usr/bin/perl

# crc.pl - verify decoding of check bits

# On the lines starting with '1', just keep the '0's and '1's in an array. 
while (<>) {
    my @letters = split '', $_;
    next unless $letters[0] eq '1';
    @letters = grep /[01]/, @letters;
    @letters = @letters[1..32];
    $a = string2bin (@letters[0..5]);
    $b = string2bin (@letters[8..13]);
    $c = string2bin (@letters[14..19]);
    $d = string2bin (@letters[20..25]);
    $e = string2bin (@letters[26..31]);
    $f = $a ^ $b ^ $c ^ $d;
    printf "%02X %02X %02X %02X %02X %02X %s\n", $a, $b, $c, $d, $e, $f,
        $e == $f ? '-' : '###';
}

sub string2bin {
    my $temp = 0;
    for (@_) {
        $temp = ($temp << 1) + ($_ eq '1' ? 1 : 0);
    }
    $temp;
}

Answer 3

No veo un evidente patrón, así que me iba a atacar a este más algorítmicamente. Evidentemente, usted tiene la capacidad de capturar un gran número de paquetes, a continuación, utilizar algún método automatizado para entrar en un ordenador. Me gustaría capturar un gran número mientras que poco a poco variando los controles.

Después de que usted tiene un montón de paquetes en un archivo, escribir el código para descifrar el código. Piense en ello como un problema de la criptografía. Una de las primeras cosas que me gustaría hacer es buscar pares de paquetes que solo varían un poco. Que debe decir de inmediato si usted tiene una simple suma de comprobación o algo más complicado como un CRC. Si un básico de la suma de comprobación, entonces la suma de comprobación de tales paquetes pares sólo debe variar al tener una potencia de 2 añadido. Si un montón de bits variar en un modo impredecible, entonces usted probablemente tiene un CRC.

Si es un básico suma, a continuación, después de recibir un par de un solo bit de cambios debe ser capaz de averiguar cómo cada campo se añade a la suma de comprobación. Si se ve como un CRC, entonces probablemente me haga una búsqueda exhaustiva siguiente. Sólo un 6 bits de la suma de comprobación, por lo que hay sólo 64 posibles polinomios. No podría ser de hasta 64 diferentes valores de inicio, pero por lo general se inicia un CRC con el conjunto de bits y los demás bits 0. Nueva bits podría ser desplazado desde cualquiera de los extremos. Probablemente, al menos si quien diseñó el CRC sabían lo que estaban haciendo, entonces, si se ejecuta el paquete entero a través de la CRC el resultado debe ser 0. El número de combinaciones es lo suficientemente pequeño que una búsqueda exhaustiva por la máquina debe encontrar la respuesta al instante en el tiempo humano si es que realmente es un habitual de la CRC.

Añadió:

Acabo de ver a Dave de Tweed de la respuesta de donde se ha demostrado que esto es incluso más simple que una suma, sólo XOR de los campos. Hay un montón de pereza ingenieros. Yo lo hubiera hecho con un CRC, que es realmente muy fácil de calcular.

Yo voy a dejar mi respuesta aquí como una descripción de cómo atacar algo como esto cuando usted no ve un patrón por la inspección. Si usted ha usado este método, habría visto que solo bit cambios en los datos que hubiese resultado en un único bit cambios en la comprobación, que inmediatamente habría apuntado a un XOR esquema.