Recrutement
Si vous êtes intéressés pour bosser sur des sujets sympas tout en restant loin de Paris, consultez nos offres d'emploi et envoyez nous votre CV à rh@amossys.fr.

Smart Light Bulb Teardown

Analyse des surfaces d'attaques matérielles d'une ampoule LED connectée. Cet article analyse d'abord les échanges réseau sans fil, puis explique comment la lampe est démontée de façon non destructive pour accéder au port de debug de sa carte principale.

Figure1

L'ampoule connectée permet de faire varier sa luminosité et sa couleur d'éclairage via une application sur smartphone.

Figure2

Test fonctionnel et analyse réseau

Lors de la première connection de l’application à l’ampoule, un message apparaît sur le smartphone indiquant qu’une mise à jour de l’ampoule est disponible : nous n’acceptons pas la mise à jour volontairement pour essayer de récupérer des informations supplémentaires.

Comme l’application va transférer la mise à jour en Bluetooth à la lampe, les options pour les développeurs sont activées, ainsi que la capture des paquets Bluetooth :

Figure3

Après avoir configuré un proxy de capture Ethernet entre le smartphone et le point d'accès WiFi, l'application mobile est lancée et la mise à jour de la lampe est acceptée.

Dans le fichier pcap de capture Ethernet, une url de téléchargement de la mise à jour est identifiée :

Figure4

Ce fichier « .hex » est téléchargé sur le PC avec le navigateur web. Celui-ci sera analysé par l’équipe de rétro-ingénierie logicielle d'Amossys.

Dans Wireshark, certaines payloads TCP du fichier « .hex » montrent des chaînes de caractères en clair, indiquant que ce binaire n'est a priori pas chiffré :

Figure5

Cela est confirmé en éditant le fichier :

Figure6

Le fichier de capture Bluetooth, éditable dans Wireshark, est alors récupéré sur le smartphone : "/storage/emulated/0/btsnoop_hci.log" (574ko).

Il montre les échanges entre le mobile (Xiaomi Redmi) et la lampe (Texas Ins., apparemment un composant Texas Instruments) :

Figure7

De nombreux paquets de 32 octets sont envoyés à la lampe, correspondant à la mise à jour.

Les chaînes de caractères du binaire « .hex » se retrouvent dans les paquets Bluetooth : aucune transformation n’a lieu entre le binaire reçu via le réseau mobile et les paquets Bluetooth.

L'analyse réseau a permis de récupérer une image de mise à jour de firmware, non chiffrée. Afin de pouvoir l'analyser, l'équipe rétro-ingénierie a besoin de connaître le type de processeur utilisé, l'étape suivante va donc consister à ouvrir la lampe.

Démontage

L’ampoule fonctionne, nous ne souhaitons pas l’abîmer. Il n’y a pas de vis apparente, tout semble serti ou collé.

Figure8

Le flux d'air chaud de la station de dessoudage permet de décoller le bulbe translucide, faisant apparaître un circuit imprimé avec 8 LEDs, fixé avec 2 vis sur une plaque en aluminium.

Figure8

Après avoir enlevé les vis et dessoudé les 8 points de contact de la carte, le démontage de la tôle en aluminium, sertie/collée, est impossible au flux d'air chaud.

Figure8

Un extracteur permettrait d'exercer un effort constant sur la tôle, en prenant appui sur le corps de l'ampoule. Un trou est taraudé dans la tôle, ce qui permet d'y insérer une vis.

Figure8

Celle-ci est passée au travers d'une petite planche en bois : l'extracteur est réalisé et permet d'ôter la tôle sans effort, en serrant la vis.

Figure8

Le démontage nécessite un peu de temps, de méthode et d'outillage. Cette étape permet d'accéder au système électronique interne.

Analyse du système interne

A l’intérieur de la lampe se trouve deux autres cartes électroniques. La première est reliée au 230VAC du secteur et également par deux broches à la seconde carte. Sur celles-ci la tension est continue et de 19V : elle ne fait donc qu’adapter le niveau de tension pour la seconde carte.

Figure9

La seconde, la « carte principale », est plus complexe. Elle dispose de 8 broches sur lesquelles est connectée la carte LED identifiée précédemment. On y voit également un module, basé sur un circuit CC2541, avec une antenne :

Figure10

Il n’y a qu’un seul composant qui pourrait faire office de processeur, il est présent sur le module, avec comme référence CC2541.

Recherche documentaire

Une recherche sur le web donne rapidement des informations sur le composant CC2541. Il est fabriqué par Texas Instruments, décrit comme un « Bluetooth low energy and proprietary wireless MCU » : un SoC (System on Chip) contenant un microcontrôleur BLE en architecture 8051.

L'environnement de développement à utiliser pour le CC2541 est IAR, qui utilise un module appelé CC Debugger pour se connecter à la carte.

un SDK BLE IoT est disponible sur le site de Texas Instruments : BLE-STACK.

Celui-ci contient un exemple de projet bootloader BIM (« Boot Image Manager ») pour mise à jour « Over the Air ».

Figure18

Il contient également le projet « SimpleBLEPeripheral », qui peut générer un binaire au format d'image OAD (« Over the Air Download ») :

  • A ou B en clair (« CC2541-OAD-ImgA.hex », « CC2541-OAD-ImgB.hex »), comme le fichier « hex » récupéré depuis le site de mise à jour de la lampe connectée
  • A ou B chiffré (« CC2541-OAD-Encrypted-ImgA.hex », « CC2541-OAD-Encrypted-ImgB.hex »)

Figure19

Le document OAD for CC254x et ces deux projets expliquent la solution de mise à jour OAD de Texas Instruments.

Il est fort probable que la lampe connectée utilise le mécanisme de mise à jour proposé dans le SDK, et que le binaire récupéré pendant l'analyse réseau ne contienne qu'une image A ou B, sans le boot manager, donc un firmware incomplet. Il faut alors pousser l'analyse un peu plus loin, en vérifiant si la carte CC2541 propose des interfaces physiques "ouvertes".

Interfaces physiques

La documentation en ligne, cc2541.pdf, présente le schéma fonctionnel suivant :

Figure11

Plusieurs interfaces sont identifiées :

  • une interface de debug
  • une interface I2C
  • deux interfaces USART (configurable en liaison SPI ou UART)

Les signaux sur les broches I2C sont analysés à l'oscilloscope, mais ne montrent aucune activité. De plus La carte principale de la lampe ne contenant pas d’autre puce que le CC2541, l’interface d’attaque potentielle I2C est exclue car certainement non utilisée. Les interfaces USART ne sont pas attribuées physiquement à des broches, mais doivent être définies par programmation : ne disposant pas du code source, celles-ci sont exclues de l’analyse d’attaque.

Il ne reste alors que l’interface de debug pour effectuer une attaque physique.

Le document présente un schéma de brochage pour le CC2541, dans un format correspondant à celui de la carte :

Figure12

la programmation d’un module à base de CC2541 s'effectue avec une sonde « CC Debugger », connectée sur l’interface de debug. Un extrait du tableau de la description des broches donne les informations suivantes :

Figure13

Interfaçage de debug

CC Debugger

Le CC Debugger se connecte en USB sur le PC de développement, ainsi qu’en filaire à la carte (module CC2541) à programmer/analyser.

Figure14

Son manuel utilisateur swru197h.pdf explique comment l'installer et le câbler sur les broches suivantes, identifiées précédemment :

  • VDD : en entrée, pour que le CC Debugger adapte ses niveaux de tension à ceux de la carte cible
  • GND : masse de référence entre le CC Debugger et la carte
  • DD : sortie Debug Data
  • DC : sortie Debug Clock

Soudure des points de tests

Les broches du CC2541 sont très peu espacées, donc pour souder les points de test nécessaires nous repérons les broches en périphérie du module, puis nous y soudons les fils que nous connectons au CC Debugger :

Figure15

Le montage de test est alors le suivant :

Figure16

Lorsque le CC Debugger est alimenté par le port USB du PC, sa LED est verte : cela indique que le CC2541 est reconnu par la sonde.

SmartRF Flash Programmer

L'application SmartRF Flash Programmer est une application gratuite de Texas Instruments, qui permet de lire et d'écrire un programme via une interface CC Debugger.

Celle-ci reconnaît le type de composant « CC2541 », nous cochons alors l’action « Read flash into hex-file », puis nous cliquons sur « Perform actions » :

Figure17

Le message « Chip is locked » indique que lorsque le fabricant a flashé le programme, il a bloqué le port de debug pour empêcher son utilisation.

Conclusion

L’analyse réseau a permis de récupérer l’image de mise à jour du firmware de la lampe connectée. Celle-ci n'est pas chiffrée, car certaines chaînes de caractères y sont en clair.

Le démontage de la lampe a donné l'accès physique à la carte électronique, permettant d'identifier le processeur CC2541 et donc l'architecture 8051, information nécessaire à l'équipe rétro-ingénierie AMOSSYS pour analyser l'image binaire.

L’interfaçage hardware a été effectué avec succès, même si le port de debug est protégé, puisque nous avons pu nous interfacer au système via le CC Debugger, après avoir soudé quelques fils sur la carte.