Comment les écoliers du Hackathon de la NASA inversent la conception d'un bracelet de fitness pour contrôler un drone

Il y a un an, j'ai acheté un tracker de fitness SONY SmartBand SWR10. Comme la plupart des autres trackers de fitness, le gadget n'a pas joué un grand rôle dans ma vie, son occupation principale reposait sur ma table. Cependant, c'est un appareil électronique intéressant, et quand un ami m'a invité à rejoindre son équipe au hackathon NASA Space Apps , j'ai décidé d'utiliser le tracker. Nous avons sélectionné la section Ne pas planter mon drone, où nous devions créer une solution pour contrôler le drone. Il a été décidé d'utiliser ce tracker pour contrôler le drone.



Dès que le hackathon a commencé, j'ai commencé à chercher l'API de mon bracelet ou des outils pour les développeurs, mais rien n'a été trouvé. Certains utilisateurs du forum ont déclaré que SONY possède un SDK propriétaire qui est fourni aux développeurs qui décident de travailler avec l'entreprise, mais selon les termes du hackathon, seules des solutions open-source pourraient être utilisées. J'ai donc décidé qu'il était temps de créer ma propre interface de contrôle de drone. J'ai lancé l'application tracker et activé la fonction «Bluetooth HCI snoop log». Cette fonctionnalité vous a permis de renifler le trafic et d'enregistrer le vidage sur la carte SD.

J'ai trouvé le journal:
~ adb shell echo $ EXTERNAL_STORAGE
/ sdcard
~ adb pull /sdcard/btsnoop_hci.log

et l' ai ouvert dans WireShark:



Il semble que le transfert de données ait été effectué en utilisant le protocole Bluetooth Low Energy, ou, plus précisément, via le protocole GATT . Il s'agit d'un transfert de données bidirectionnel, où le téléphone agit comme un serveur, "GATT Server", et les périphériques reçoivent des "caractéristiques GATT", qui peuvent contenir toutes les données binaires.

J'ai sélectionné le premier UUID (00000208–37cb-11e3–8682–0002a5d5c51b) et l'ai recherché sur Google. Je m'attendais à trouver le service GATT standardisé habituel, mais j'ai trouvé quelque chose de plus intéressant .

J'ai décidé que nous avons découvert le référentiel Git de quelqu'un créé par une personne qui a procédé à une rétro-ingénierie du protocole. Et cela était partiellement vrai: le projet contenait plusieurs fonctions de travail, y compris la connexion, la réponse aux mouvements des mains, la lecture de l'état de la batterie et le maintien de la connexion active. Mais la mise en œuvre de l'accéléromètre était étrange. J'ai ajouté les données de l'accéléromètre à MPAndroidChart , et j'ai obtenu ceci:



Bien que les informations sur les pentes soient correctes, les valeurs n'étaient pas affichées. Après avoir étudié le code de fonction, il s'est avéré que le nombre simple précision 32 bits contenait trois valeurs de 10 bits. Cela a du sens, car la plupart des accéléromètres fonctionnent avec une précision de 10 bits (comme la plupart des ADC, convertisseurs analogique-numérique). Voici les données source, faites attention aux deux premiers bits:

données acc: 0b00101110 0b10110101 0b10111100 0b10111000
données acc: 0b00111010 0b11110001 0b00011101 0b11101011
données acc: 0b00111110 0b01110110 0b10100110 0b10011001
données acc: 0b00001011 0b11011101 0b10111101 0b00111001

Mais l' analyse des données que les trois valeurs 10 bits était assez étrange, tous les quelques degrés d'inclinaison valeur modifiée 511 à -512, et le décalage n'a pas changé (de plus, il n'y a pas eu de problème de débordement d'entier ici). J'ai donc décidé que SONY pourrait utiliser une sorte de méthode d'emballage binaire propriétaire, ou que la société utiliserait le codage et la compression arithmétiques.

J'ai essayé Protobuf, MsgPack, Thrift et plusieurs analyseurs, mais rien n'a fonctionné. Je n'avais qu'une journée pour connecter mon appareil au Wi-Fi du drone. Déjà désespéré, j'ai essayé de décompiler l'application DEX, et après une demi-heure, cela s'est avéré:

// Environ
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 première moitié [0, 512] a été inversée et la situation décrite ci-dessus s'est donc produite. Je l'ai corrigé en utilisant XOR normal et cela a fonctionné. J'ai ajouté le facteur de gravité, avec le résultat [-1,1] pour ± 1 g, et tout ce qui devait être fait ensuite était d'utiliser les données de l'accéléromètre pour contrôler le drone.

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