Le reverse engineering et le piratage de dispositifs de stockage auto-chiffrants externes sont une de mes passions de longue date. Par le passé, j'ai eu l'occasion de travailler avec des modèles tels que le Zalman VE-400, le Zalman ZM-SHE500 et le Zalman ZM-VE500. Récemment, un collègue m'a apporté un autre exemplaire : le Patriot (Aigo) SK8671, qui est construit selon un design typique – un écran LCD et un clavier pour entrer un code PIN. Voici ce que j'en ai tiré…
1. Introduction
Boîtier
Emballage
L'accès aux données sauvegardées sur le disque, qui sont prétendument chiffrées, se fait après l'entrée du code PIN. Quelques remarques préliminaires sur cet appareil :
- Pour changer le code PIN, il faut appuyer sur F1 avant le déverrouillage ;
- Le code PIN doit comporter entre 6 et 9 chiffres ;
- Après 15 tentatives incorrectes, le disque est effacé.
2. Architecture matérielle
Nous commençons par démonter l'appareil en pièces pour comprendre de quels composants il se compose. La tâche la plus fastidieuse est d'ouvrir le boîtier : de nombreuses vis microscopiques et du plastique. Une fois le boîtier ouvert, nous voyons ce qui suit (notez le connecteur à cinq broches que j'ai soudé) :
2.1. Carte mère
La carte mère est plutôt simple :
Les parties les plus remarquables (voir de haut en bas) :
- connecteur pour écran LCD (CN1) ;
- haut-parleur (SP1) ;
- Pm25LD010 () mémoire flash SPI (U2) ;
- contrôleur Jmicron JMS539 () pour USB-SATA (U1) ;
- connecteur USB 3 (J1).
La mémoire flash SPI stocke le firmware pour le JMS539 et certains paramètres.
2.2. Carte d'affichage LCD
Sur la carte LCD, il n'y a rien de remarquable.
Il y a seulement :
- un écran LCD d'origine inconnue (probablement avec un jeu de polices chinois) ; contrôle séquentiel ;
- un connecteur à ruban pour la carte de clavier.
2.3. Carte de clavier
Lors de l'inspection de la carte de clavier, les choses deviennent plus intéressantes.
Ici, sur le côté arrière, nous voyons un connecteur à ruban ainsi que le Cypress CY8C21434 – un microcontrôleur PSoC 1 (que nous appellerons simplement PSoC par la suite)
Le CY8C21434 utilise un ensemble d'instructions M8C (voir. ). Sur [la page du produit]( () il est indiqué qu'il prend en charge la technologie (une solution de Cypress pour les claviers capacitifs). Ici, on peut voir le connecteur à cinq broches que j'ai soudé – c'est une approche standard pour connecter un programmateur externe via l'interface ISSP.
2.4. Regardons les fils
Déterminons ce qui est connecté ici. Il suffit de vérifier les fils avec un multimètre :
Explications pour ce schéma dessiné à la va-vite :
- Le PSoC est décrit dans la spécification technique ;
- le prochain connecteur, celui de droite – interface ISSP, qui est en accord avec ce qui est écrit à son sujet sur Internet ;
- le connecteur le plus à droite – c'est la borne pour le connecteur à ruban avec la carte du clavier ;
- le rectangle noir – le schéma du connecteur CN1, destiné à connecter la carte mère à la carte LCD. P11, P13 et P4 – sont raccordés aux broches PSoC 11, 13 et 4, sur la carte LCD.
3. Séquence des étapes d'attaque
Maintenant que nous savons de quels composants est composé ce dispositif, nous devons : 1) nous assurer que la fonctionnalité de base de chiffrement est bien présente ; 2) savoir comment les clés de chiffrement sont générées/sauvegardées ; 3) trouver où le code PIN est effectivement vérifié.
Pour cela, j'ai effectué les étapes suivantes :
- j'ai extrait le dump de la mémoire flash SPI ;
- j'ai tenté d'extraire le dump de la mémoire flash PSoC ;
- j'ai vérifié que l'échange de données entre le Cypress PSoC et le JMS539 contient effectivement les touches pressées ;
- je me suis assuré que lors du changement de mot de passe, rien n'est réécrit dans la mémoire flash SPI ;
- j'ai été trop paresseux pour effectuer le reverse engineering du firmware 8051 du JMS539.
3.1. Extraction du dump de la mémoire flash SPI
Cette procédure est très simple :
- connectez les sondes aux broches de la mémoire flash : CLK, MOSI, MISO et (optionnellement) EN ;
- « flairer » les communications avec un sniffer, en utilisant un analyseur logique (j'ai utilisé le );
- décrypter le protocole SPI et exporter les résultats en CSV ;
- utiliser le , pour analyser les résultats et obtenir le dump.
Notez que cette approche fonctionne particulièrement bien avec le contrôleur JMS539, car ce contrôleur charge tout le firmware de la mémoire flash lors de l'initialisation.
$ decode_spi.rb boot_spi1.csv dump
0.039776 : ÉCRITURE DÉSACTIVÉE
0.039777 : LECTURE D'IDENTIFIANT JEDEC
0.039784 : ID 0x7f 0x9d 0x21
---------------------
0.039788 : LECTURE @ 0x0
0x12,0x42,0x00,0xd3,0x22,0x00,
[...]
$ ls --size --block-size=1 dump
49152 dump
$ sha1sum dump
3d9db0dde7b4aadd2b7705a46b5d04e1a1f3b125 dumpAprès avoir extrait le dump de la mémoire flash SPI, j'en ai conclu que sa seule tâche était de stocker le firmware pour le dispositif de contrôle JMicron, qui est intégré dans un microcontrôleur 8051. Malheureusement, l'extraction du dump de la mémoire flash SPI s'est avérée inutile :
- lors du changement de code PIN, le dump de la mémoire flash reste exactement le même ;
- après la phase d'initialisation, l'appareil n'accède pas à la mémoire flash SPI.
3.2. Analyser les communications
C'est l'un des moyens de déterminer quel chip est responsable de la vérification des communications, pour le temps/le contenu d'intérêt. Comme nous le savons déjà, le contrôleur USB-SATA est connecté à la puce Cypress PSoC via le connecteur CN1 et deux bandes. Nous connectons donc les sondes aux trois broches correspondantes :
- P4, entrée/sortie générale;
- P11, I2C SCL;
- P13, I2C SDA.
Ensuite, nous lançons l'analyseur logique Saleae et tapons sur le clavier : “123456~”. En conséquence, nous voyons le diagramme suivant.
Sur celui-ci, nous pouvons voir trois canaux d'échange de données :
- sur le canal P4, quelques courts pics;
- sur P11 et P13 – un échange de données presque continu.
En augmentant le premier pic sur le canal P4 (le rectangle bleu du dessin précédent), nous voyons ce qui suit :
Ici, on peut voir qu'il y a presque 70 ms de signal uniforme sur P4, qui, au début, semblait jouer le rôle d'un signal de synchronisation. Cependant, après avoir pris le temps de vérifier ma supposition, j'ai découvert que ce n'était pas un signal de synchronisation, mais un flux audio qui est émis sur le buzzer lors de la pression des touches. Par conséquent, cette portion de signal ne contient pas d'informations utiles pour nous. Toutefois, elle peut être utilisée comme indicateur, pour savoir quand le PSoC enregistre la pression d'une touche.
Cependant, le dernier flux audio du canal P4 est légèrement différent des autres : c'est le son pour « code PIN incorrect » !
En revenant au diagramme de pression des touches, en augmentant le diagramme du dernier flux audio (voir à nouveau le rectangle bleu), nous obtenons :
Ici, nous voyons des signaux uniformes sur P11. Donc, il semble que cela soit le signal de synchronisation. Et P13 – les données. Notez comment le motif change après la fin du signal sonore. Il serait intéressant de voir ce qui se passe ici.
Les protocoles fonctionnant avec deux fils sont généralement SPI ou I2C, et la spécification technique de Cypress indique que ces contacts correspondent à I2C, ce qui semble être vrai dans notre cas :
Le chipset USB-SATA interroge constamment le PSoC pour lire l'état de la touche, qui est par défaut "0". Ensuite, lorsque la touche "1" est pressée, elle change en "1". La transmission finale, juste après avoir appuyé sur "~", est différente si un mauvais code PIN est entré. Cependant, jusqu'à présent, je n'ai pas vérifié ce qui est réellement transmis. Mais je soupçonne qu'il s'agit peu probable d'une clé de cryptage. Quoi qu'il en soit, consulte la section suivante pour comprendre comment j'ai extrait le dump du firmware interne du PSoC.
Source : habr.com
