bits de control de IR de ingeniería inversa / CRC

Navega tus respuestas
4

Estoy tratando de construir un simple control remoto IR basado en Arduino para un helicóptero barato controlado por IR (igual que este - se llama "Diamond Gyro" o "Diamond Force"). He descifrado el protocolo IR , excepto los últimos bits. Estos últimos bits parecen ser un cheque o CRC, pero no he podido "romperlo".

Es bastante fácil simplemente repetir un paquete grabado, pero quiero controlar completamente el helicóptero. Eso significa ingeniería inversa de los bits de verificación.

(Debo agregar que hago software por día, pero la electrónica es un pasatiempo a veces, así que tal vez solo me esté perdiendo algo muy básico)

Los detalles del protocolo se encuentran en la pregunta y la respuesta , pero aquí están los conceptos básicos:

  • paquete de 32 bits que abarca varios valores / comandos individuales 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 tengo los primeros 22 bits asignados ...
  • ... pero los siguientes 4 bits son un poco misteriosos, aunque conozco el propósito de al menos 2 de ellos.
  • Los últimos 6 bits parecen ser un cheque o CRC de algún tipo

Aquí hay un diagrama 

 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.

En primer lugar, no estoy seguro de si los X bits son parte del valor del canal, parte de la verificación u otra cosa. Sin embargo, siempre siguen el valor del canal, por lo que es probable que el valor del canal tenga un ancho de 3 a 4 bits, aunque 2 bits serían suficientes para los 3 valores posibles del canal.

En segundo lugar, están los últimos 6 bits (marcados como CRC? arriba) que son claramente algún tipo de verificación (y, de hecho, el helicóptero no responde si cambio alguno de esos bits).

Básicamente, hay un paquete de 24-26 bits de datos, seguido de 6-8 bits de verificación. Y realmente me gustaría descifrar esos bits de verificación para poder componer paquetes yo mismo.

A continuación hay un montón de muestras de los datos binarios que estoy obteniendo. El preámbulo "1" siempre está presente, y no creo que cuente como parte de los datos, pero lo he incluido de todos modos, por si acaso es la clave de todo.

Nuevamente, no sé si los X bits son parte de los datos o la verificación. Dependiendo de la forma en que se calcule la verificación, puede ser que los primeros 1-2 bits de la verificación simplemente sigan el valor del canal. Pero también es bastante posible que el valor del canal tenga una longitud de 4 bits, incorporando los bits X . O está en el medio con un bit X formando parte del canal, y el otro formando parte del cheque. No lo sé.

Si alguien sabe qué es ese cheque, o cómo podría averiguarlo, me encantaría saberlo. Me imagino que puedo forzarlo bruscamente, pero incluso si esa es la única opción, me encantaría escuchar algunas sugerencias sobre cómo hacerlo mejor.

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

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
    
pregunta Flambino

3 respuestas

7

En primer lugar, es bastante claro que los bits "XX" son parte de la designación del canal, ya que eso es lo único de lo que dependen. Los bits "XX" pueden ser simplemente una comprobación de los bits "Ch".

Los bits de verificación son un XOR simple a modo de bits de 24 de los 26 bits de datos: si toma los 6 bits de Yaw, los 6 LSB del acelerador, los 6 bits de tono y los 6 bits siguientes, y XOR estas cantidades , obtienes los 6 bits de verificación. Parece que los 2 bits superiores del acelerador no afectan en absoluto a los bits de verificación.

El siguiente script de Perl lo verifica. 

#!/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;
}
    
respondido por el Dave Tweed
3

No veo un patrón obvio de inmediato, así que atacaría esto más algorítmicamente. Al parecer, tiene la capacidad de capturar una gran cantidad de paquetes y, luego, utilizar alguna forma automatizada para ingresar a una computadora. Capturaría un gran número mientras variaba lentamente los controles.

Después de tener una pila de paquetes en un archivo, escribe un código para descifrarlo. Piense en ello como un problema de criptografía. Una de las primeras cosas que haría es buscar pares de paquetes que solo varíen en un bit. Eso debería indicarle de inmediato si tiene una suma de comprobación simple o algo más complicado como un CRC. Si se trata de una suma de comprobación básica, entonces la suma de comprobación de dichos pares de paquetes solo debe variar si se le agrega una potencia de 2. Si un montón de bits varían de una manera impredecible, entonces probablemente tenga un CRC.

Si es una suma básica, luego de obtener algunos cambios de un solo bit, debería poder averiguar cómo se agrega cada campo a la suma de comprobación. Si parece un CRC, es probable que haga una búsqueda exhaustiva a continuación. Es solo una suma de comprobación de 6 bits, por lo que solo hay 64 polinomios posibles. Podría haber hasta 64 valores de inicio diferentes, pero normalmente se inicia un CRC con el bit alto establecido y los otros bits 0. Los nuevos bits se pueden desplazar desde cualquier extremo. Probablemente, al menos si quien diseñó el CRC sabía lo que estaba haciendo, entonces, si ejecuta todo el paquete a través del CRC, el resultado debería ser 0. El número de combinaciones es lo suficientemente grande como para que una búsqueda exhaustiva por máquina encuentre la respuesta al instante Tiempo humano si realmente es un CRC habitual.

Añadido:

Acabo de ver la respuesta de Dave Tweed, donde él ha demostrado que esto es incluso más simple que una suma, solo XOR de los campos. Hay muchos ingenieros perezosos por ahí. Habría hecho esto con un CRC, que es realmente muy fácil de calcular.

Dejaré mi respuesta aquí como una descripción de cómo atacar algo como esto cuando no ves un patrón por inspección. Si hubiera utilizado este método, habría visto que los cambios de un solo bit en los datos habrían dado lugar a cambios de un solo bit en la suma de comprobación, lo que habría apuntado inmediatamente a un esquema XOR.

    
respondido por el Olin Lathrop
2

Sobre el 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 confiabilidad.

    
respondido por el flup

Lea otras preguntas en las etiquetas

¿Por qué este dispositivo alimentado por batería de bajo costo usa perlas de ferrita en la entrada de alimentación? ¡Ayuda del circuito divisible por 2!