Cómo los escolares de Hackathon de la NASA realizan ingeniería inversa en un brazalete de ejercicios para controlar un dron

Hace un año, compré un rastreador de ejercicios SONY SmartBand SWR10. Como la mayoría de los otros rastreadores de ejercicios, el dispositivo no jugó un papel importante en mi vida, su principal ocupación estaba en mi mesa. Sin embargo, este es un dispositivo electrónico interesante, y cuando un amigo me invitó a unirme a su equipo en el hackathon de la NASA Space Apps , decidí usar el rastreador. Seleccionamos la sección No bloquear mi drone, donde necesitábamos crear una solución para controlar el drone. Se decidió usar este rastreador para controlar el dron.



Tan pronto como comenzó el hackathon, comencé a buscar la API de mi pulsera o herramientas para desarrolladores, pero no se encontró nada. Algunos usuarios del foro dijeron que SONY tiene un SDK patentado que se otorga a los desarrolladores que deciden trabajar con la compañía, pero según los términos del hackathon, solo se pueden usar soluciones de código abierto. Así que decidí que era hora de crear mi propia interfaz de control de drones. Inicié la aplicación de seguimiento y activé la función "Registro de snoop de Bluetooth HCI". Esta característica le permitió detectar el tráfico y guardar el volcado en la tarjeta SD.

Encontré el registro:
~ adb shell echo $ EXTERNAL_STORAGE
/ sdcard
~ adb pull /sdcard/btsnoop_hci.log

y lo abrí en WireShark:



Parece que la transferencia de datos se realizó utilizando el protocolo Bluetooth Low Energy o, más precisamente, a través del protocolo GATT . Esta es una transferencia de datos bidireccional, donde el teléfono actúa como un servidor, "Servidor GATT", y los periféricos reciben "características GATT", que pueden contener datos binarios.

Seleccioné el primer UUID (00000208–37cb-11e3–8682–0002a5d5c51b) y lo busqué en Google. Esperaba encontrar el servicio GATT estandarizado habitual, pero encontré algo más interesante .

Decidí que descubrimos el repositorio Git de alguien creado por una persona que realizó ingeniería inversa del protocolo. Y esto era parcialmente cierto: el proyecto contenía varias funciones de trabajo, incluida la conexión, la respuesta a los movimientos de las manos, la lectura del estado de la batería y el mantenimiento de la conexión activa. Pero la implementación del acelerómetro fue extraña. Agregué los datos del acelerómetro a MPAndroidChart , y obtuve esto:



aunque la información sobre las pendientes era correcta, los valores no se mostraban. Después de estudiar el código de función, resultó que el número de precisión simple de 32 bits contenía tres valores de 10 bits. Esto tiene sentido, ya que la mayoría de los acelerómetros funcionan con una precisión de 10 bits (como la mayoría de los ADC, convertidores analógico a digital). Aquí están los datos de origen, preste atención a los primeros dos bits:

datos ACC: 0b00101110 0b10110101 0b10111100 0b10111000
datos ACC: 0b00111010 0b11110001 0b00011101 0b11101011
datos ACC: 0b00111110 0b01110110 0b10100110 0b10011001
datos ACC: 0b00001011 0b11011101 0b10111101 0b00111001

Pero el análisis de datos como los tres valores de 10 bits era bastante extraño, cada pocos grados de inclinación cambia el valor 511 a -512, y el desplazamiento no cambió (además, no hubo ningún problema de desbordamiento de enteros aquí). Entonces decidí que SONY podría usar algún tipo de método de empaquetado binario patentado, o que la compañía usaría codificación aritmética y compresión.

Probé Protobuf, MsgPack, Thrift y varios analizadores, pero nada funcionó. Solo tuve un día para conectar mi dispositivo a la conexión Wi-Fi del dron. Ya desesperado, probé la descompilación DEX de la aplicación de la compañía, y después de media hora resultó esto:

// Aproximadamente
1: iconst_0 512 iconst_1 1023
2: r1 xor iconst_0
3: istore_0
4: iload_0
5: ifneq 8
6: r1 xor iconst_1
7: istore_0

if ((data & 0x200)! = 0) {
data = - ((data ^ 1023) + 1);
}
return (((float) (-data)) * 15.625f) / GRAVITY_FACTOR;

La primera mitad [0, 512] se invirtió y, por lo tanto, surgió la situación descrita anteriormente. Lo arreglé usando XOR normal y funcionó. Agregué el factor de gravedad, con el resultado [-1.1] para ± 1 g, y todo lo que tenía que hacer a continuación era usar los datos del acelerómetro para controlar el dron.

Source: https://habr.com/ru/post/es394095/