« SE5 IdO sécurité des objets 2024/2025 b1 » : différence entre les versions

De wiki-se.plil.fr
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
 
(19 versions intermédiaires par 2 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
== '''Configuration du routeur wifi pour notre Vlan 11''' ==
== '''Configuration du routeur wifi pour notre VLAN 11''' ==
le vlan est aparent sur le reseau mais pas d'acces internet
Le VLAN est apparent sur le réseau, mais il n'y a pas d'accès Internet.


pourtant is semble que on a la meme configuration que les binomes qui avaient un wifi fonctionel.
Pourtant, il semble que nous ayons la même configuration que les binômes qui avaient un wifi fonctionnel.


Configuration de l'interface '''eth0 (172.26.145.101)''' et '''eth1 (172.16.11.111)''' sur la VM SE5-WIJSMAN-LEFRANC sur Capbreton.


 
'''Dans la VM,''' configuration de FreeRADIUS''':'''
 
Configuration de l'interface '''eth0 (172.26.145.101)''' et '''eth1 (172.16.11.111)''' sur la VM SE5-WIJSMAN-LEFRANC sur capbreton.
 
 
'''Dans la VM,''' configuration de Freeradius''':'''


/etc/freeradius/3.0/users:
/etc/freeradius/3.0/users:
Ligne 30 : Ligne 26 :
'''Sur le routeur CISCO:'''
'''Sur le routeur CISCO:'''


mise en place d'un poin d'acces VM_binome_11 avec comme mot de passe glopglop en suivant les comandes du wiki.
Mise en place d'un point d'accès VM_binome_11 avec comme mot de passe "glopglop" en suivant les commandes du wiki.
<pre>
<pre>
ssh -l admin -o KexAlgorithms=diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 -o HostKeyAlgorithms=ssh-rsa -c aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc 172.26.145.1
ssh -l admin -o KexAlgorithms=diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 -o HostKeyAlgorithms=ssh-rsa -c aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc 172.26.145.1
Ligne 66 : Ligne 62 :
</pre>
</pre>


== '''Piratage d’objets connectés''' ==


=== '''Objectif :''' ===
Dans un premier temps, notre objectif est de pirater une sonnette sans fil.


Ensuite, nous tenterons également de compromettre un capteur de température '''LIBERO CS''' afin d'analyser sa sécurité et ses vulnérabilités.


 
== '''Sonnette sans fil''' ==
== '''Piratage d’objets connectés:''' ==
'''Objectif :'''
 
Notre objectif dans un premier temps est de pirater une sonnette sans fil.
 
Puis nous allons egalement tenter de cracker un capteur de temperature LIBERO CS.
 
== '''Sonnete sans fil:''' ==
'''Matériel utilisé :'''
'''Matériel utilisé :'''


Ligne 84 : Ligne 76 :


'''Méthodologie :'''
'''Méthodologie :'''
[[Fichier:Screenshot from 2024-10-21 14-25-36.png|vignette]]


# '''Analyse du signal :'''  Nous commençons par analyser le signal envoyé lorsqu'on appuie sur le bouton de la sonnette à l'aide d'un analyseur de spectre.
# '''Analyse des trames :'''  Nous analysons la trame envoyée à chaque appui sur le bouton. Après une série de tests, nous avons découvert que la trame envoyée est toujours la même.
# '''Reproduction du signal :'''  Dans un deuxième temps, nous mettons en place un programme sur GNU Radio pour reproduire le signal, afin de faire croire à la sonnette que le bouton a été appuyé.


=== Première méthode (PARROT) : ===
# '''Analyse du signal :''' Nous commençons par analyser le signal envoyé lorsqu'on appuie sur le bouton de la sonnette à l'aide d'un analyseur de spectre.
On écoute la télécommande et on réémet le signal.
# '''Analyse des trames :''' Nous analysons la trame envoyée à chaque appui sur le bouton. Après une série de tests, nous avons découvert que la trame envoyée est toujours la même.
# '''Reproduction du signal :''' Dans un deuxième temps, nous mettons en place un programme sur GNU Radio pour reproduire le signal, afin de faire croire à la sonnette que le bouton a été appuyé.


Méthode PARROT où l'on enregistre pour réémettre.
=== Méthode 1 : Ecoute et réémission (PARROT) : ===
La méthode consiste à utiliser une antenne et un récepteur SDR pour écouter le signal émis par la télécommande, puis à le réémettre après enregistrement.


On utilise le programme GNU Radio suivant :
Le programme '''GNU Radio''' utilisé pour cette opération est présenté ci-dessous.
[[Fichier:Screenshot from 2024-11-27 14-33-26.png|vignette|Méthode PARROT où l'on enregistre pour réémettre.]]


Cela ne fonctionne pas, nous avons donc opté pour une autre méthode.
[[Fichier:Screenshot from 2024-11-27 14-33-26.png|vignette|left|Méthode PARROT où l'on enregistre pour réémettre.]][[Fichier:Screenshot from 2024-10-21 14-25-36.png|vignette]]
<br clear="all"/>
==== Problèmes rencontrés ====
Malheureusement, cette approche ne fonctionne pas en l’état, pour deux raisons principales :
 
# '''Accumulation de bruit''' : Lors de l’enregistrement, du bruit parasite est capté avec le signal. Lors de la réémission, ce bruit est amplifié, ce qui altère la qualité du signal transmis.
# '''Manque de puissance''' : Une puissance insuffisante lors de la réémission peut empêcher le signal d’avoir un effet notable, d’autant plus que l’augmentation de puissance améliorerait également le rapport signal/bruit.
 
==== Améliorations possibles ====
Cette méthode pourrait être optimisée en ajoutant :
 
* '''Des filtres''' pour réduire le bruit et améliorer la qualité du signal réémis.
* '''Un amplificateur''' pour garantir une puissance suffisante et assurer une transmission efficace.


=== Méthode 2 : Recréation du signal ===
=== Méthode 2 : Recréation du signal ===
Nous avons utilisé un oscilloscope et une sonde de champ proche pour améliorer le rapport signal/bruit et ainsi observer clairement le signal.
[[Fichier:Trame.jpg|vignette|left|Visualisation de la trame émise par le SDR.]]
<br clear="all"/>
Dans un premier temps, nous avons analysé le signal à l’aide d’un récepteur SDR, mais celui-ci introduisait des défauts suffisants pour altérer la qualité du rendu. Nous avons ensuite amélioré la mesure en utilisant un oscilloscope professionnel, ce qui nous a permis d’obtenir les fréquences exactes du signal.
Grâce à ces mesures, nous avons développé un programme GNU Radio capable de reproduire le signal de la télécommande.
[[Fichier:Montage fonctionel.png|vignette|left|Programme qui recrée le signal à émettre et l'émet.]]
<br clear="all"/>
==== Structure du signal ====
La trame transmise contient le message suivant, répété 75 fois par pression sur le bouton :
'''0001010011000111100110000'''
Le codage du signal est défini ainsi :
* '''0''' : 0,2 ms high + 0,6 ms low
* '''1''' : 0,6 ms high + 0,2 ms low
Nous prenons le PGCD de 6 et 2, soit 2, ce qui nous donne un pas de temps minimal de '''0,2 ms'''. Un signal de '''5 kHz''' est donc utilisé pour générer cette modulation.
L'encodage du signal à '''5 kHz''' suit la règle suivante :
* '''0''' → 1000
* '''1''' → 1110
Par exemple, pour coder le message '''"101"''', nous transmettons la séquence : '''1110 1000 1110'''.
Nous avons utilisé une fréquence d’échantillonnage ('''sampling rate''') de '''10 MHz''', largement supérieure à '''433 kHz''', garantissant ainsi un signal propre. L'interpolation est réalisée avec un facteur de 2000 pour obtenir un signal carré net : '''2k × 5k = 10M'''.
==== Résultats ====
Après de nombreux tests et ajustements, nous avons réussi à déclencher l’alarme à environ '''1 mètre''' de distance. En intégrant un système d’amplification, il serait possible d’augmenter considérablement cette portée.
== '''Capteur de température LIBERO''' ==
[[Fichier:Capteur.jpg|vignette|left|Capteur de température]]
<br clear="all"/>
=== Objectif ===
L’objectif est de contourner le système afin de modifier les valeurs enregistrées en mémoire et fausser les mesures de température.
=== Analyse matérielle ===
Nous avons démonté le boîtier afin d’examiner le '''PCB''' et les composants. L’image ci-dessous montre l’emplacement du '''capteur de température'''.


Nous avons créé un programme GNU Radio plus complexe qui recrée le signal de la télécommande.
Deux approches ont été envisagées pour compromettre le capteur :


Le signal est le suivant :
==== '''Modification matérielle''' : ====
Le capteur semble être une '''CTN (thermistance à coefficient de température négatif)'''.


75 trames avec le codage binaire suivant :
Il est possible d’ajouter une '''résistance en parallèle''' ou de '''remplacer complètement la CTN''', ce qui permettrait de modifier les valeurs mesurées à volonté.


<blockquote>0001010011000111100110000[[Fichier:Trame.jpg|vignette|Visualisation de la trame émise par le SDR.]]
==== '''Reprogrammation du microcontrôleur''' : ====
[[Fichier:Montage fonctionel.png|vignette|Programme qui recrée le signal à émettre et l'émet.]]</blockquote>
Le microcontrôleur utilisé est un '''STM32L073CZTB'''.


Les timings sont les suivants :
Nous avons identifié plusieurs '''testpoints''' sur la carte, utilisés pour la programmation automatisée.


* 0 : 0,2 ms high et 0,6 ms low 
Nous avons procédé à une rétro-ingénierie afin de localiser les '''pins de reprogrammation''' :
* 1 : 0,6 ms high et 0,2 ms low 


Nous prenons le PGCD de 6 2 est 2 donc on prend  0,2 ms comme plus petit pas:
* '''NRST (Pin 7)''' : Reset du microcontrôleur
* '''SWDIO (Pin 34, PA13)''' : Interface de communication bidirectionnelle
* '''SWCLK (Pin 35, PA14)''' : Horloge du débogage série
* '''VSS (Pin 8 ou 33)''' : Masse
* '''VDD (Pin 9 ou 36)''' : Alimentation


On code de maniere suivante:
Aprés s'être connecter dessus voici les étapes que nous avons réalisés.


* 0 = 1000
=== Étapes du contournement ===
* 1 = 1110
----


Par exemple pour coder le message "101" on envoie 1110 1000 1110.
==== '''1. Récupération du programme''' ====
Nous avons utilisé le logiciel '''STM32 Programmer''' et un '''ST-Link''' '''V2''' pour extraire le programme via le port SWD.


Nous utilisons un sampling_rate de 10MHz mais nous voulons envoyer un signal dont la frequence maximale est 5KHz.
Une lecture complète ('''READ ALL''') permet d’obtenir un fichier '''.bin''' contenant le firmware.
----


Nous utilisons donc un bloc ressampling.
==== '''2. Analyse du programme''' ====


Cela fonctionne et nous parvenons à actionner la sonnette via la SDR !
[[Fichier:Screenshot from 2025-01-06 07-31-09.png|vignette|left|Ghidra found DR]]
<br clear="all"/>


Le fichier '''.bin''' a été analysé avec '''Ghidra''', configuré pour un '''ARM Cortex-M 32 bits'''.


== '''Capteur de température LIBERO:''' ==
Grâce à '''Ghidra SVD Loader''', nous avons chargé le fichier SVD du STM32 pour afficher les registres et leur correspondance en mémoire.
Le but est de trouver un moyen de contourner le système pour lui faire retenir en mémoire des valeurs différentes de celles normales.


Nous avons démonté le boîtier afin de visualiser le PCB et les composants.
Nous avons identifié plusieurs zones d’intérêt :
[[Fichier:Capteur.jpg|vignette|Capteur de température]]


Après une analyse, on peut remarquer le capteur de température, comme indiqué sur l'image suivante.
* '''Le programme principal''' : Adresse '''0x02E850'''
* '''Les valeurs stockées en mémoire''' : Adresse '''0x9010 - 0x9384'''
* '''Le fichier PDF contenant les mesures''' :
** Stocké en mémoire de '''0x2B040''' à '''0x2414B'''
** Le '''template du PDF''' est entre '''0x237C8 et 0x24163'''
** Le fichier commence à '''0x8300''' et se termine à '''0x2414B'''


* Une  possibilité serait de modifier le comportement du capteur en ajoutant une résistance, par exemple.
----


* Une autre possibilité serait de reprogrammer le microcontrôleur afin de modifier son comportement. Il s'agit d'un '''STM32L073CZTb.'''
==== '''3. Modification du programme''' ====


Pour cela, il faut mapper chaque pin pour pouvoir se connecter directement sur les testpoints.
[[Fichier:Ghidra registre modifier.png|vignette|left|Modification de la valeur du registre chargé dans la variable]]
<br clear="all"/>


Nous avons cherché à modifier la récupération des valeurs mesurées par l’'''ADC''' du STM32.


Le but est déja de reperer les pins qui serviront a la programation, soit:
L’objectif était de détourner la lecture du registre '''ADC_DR''' (offset '''0x40''' dans l’ADC) et de le remplacer par une autre valeur, par exemple le registre '''ISR''' (Interrupt Status Register).
* '''NRST (Pin 7)''' - Reset pin.
* '''SWDIO (Pin 34, PA13)''' - Serial Wire Debug Data Input/Output.
* '''SWCLK (Pin 35, PA14)''' - Serial Wire Debug Clock.
* '''VSS (Pin 8 or 33)''' - Ground pin.[[Fichier:Screenshot from 2025-01-06 07-31-09.png|vignette|Ghidra found DR]]
* [[Fichier:Ghidra registre modifier.png|vignette|Modification de la valeur du registre charger dans la variable]]'''VDD (Pin 9 or 36)''' - Power supply.


=== Etape de contournement: ===
Cette modification devait perturber l’affichage des températures dans le '''PDF généré'''.
----


# Récupération du programme en se connectant sur les pins du port SWD
==== '''4. Réinjection du programme''' ====
# Analyse du programme via ghidra
Le programme modifié a été réinjecté via '''STM32 Programmer'''.
# Modification du programme afin de mettre en défaut le système
----
# Réinjection du programme via le port SWD
# Vérification de la bonne réalisation du contournement


=== 1. Récupération du programme ===
==== '''5. Vérification des résultats''' ====
Avec le logiciel STM32 programmeur il est possible en se connectant via un ST link de récupérer le programme avec un READ ALL qui donne un fichier .bin
L’analyse dans '''Ghidra''' a confirmé que la valeur du registre mesuré avait bien été modifiée.


=== 2. Analyse du programme ===
Cependant, nous avons rencontré une difficulté pour '''relancer une nouvelle mesure''', sans parvenir à identifier la séquence nécessaire dans le code.
Avec le logiciel ghidra il est possible de charger le fichier .bin en configurant qu'il s'agit d'un programme ARM cortex LE 32 bits


Le logiciel ghidra fait ensuite une analyse du code qui permet de récupérer une vue assembleur du programme et aussi une vue en C
Nous avons aussi modifié une valeur à '''l’adresse 0x9010''', ce qui a entraîné un changement dans le graphique des températures du '''PDF généré par la clé'''.


On peut aussi via l'extension ghidra SVD loader charger le fichier SVD correspondant au STM32 afin d'avoir un affichage de la correspondance des valeurs des registres avec la mémoire du STM32.
Cependant, nous n’avons pas encore compris précisément l’impact de cette modification sur l’ensemble du système.


=== 3. Modification du programme ===
Par manque de temps, nous n’avons pas poursuivi l’exploration, mais cette approche pourrait être approfondie pour mieux comprendre la manière dont le système enregistre et affiche les mesures.
En cherchant à modifier ce qui est récupérer dans le programme via l'ADC du STM32. Donc en cherchant le registre ADC_DR qui correspond au décalage 0x40 de l'ADC on trouve à quel endroit la mesure est faite.
----


En choisissant pour l'exemple de modifier le programme afin que ce qui sera récupérer dans ce programme ne sera plus la valeur des données de L'ADC mais la valeur du registre des interruptions ISR. Ce qui sans nul doute va générer un problème concernant l'affichage des températures dans le PDF.
=== '''Conclusion''' ===
Nous avons démontré plusieurs moyens potentiels pour compromettre le capteur '''LIBERO CS''' :


=== 4. Reinjection du programme ===
* '''Altération matérielle''' du capteur (ajout/remplacement de composants).
* '''Reprogrammation du microcontrôleur''' pour modifier les valeurs enregistrées.


=== 5. Vérification du résultat ===
Des recherches supplémentaires seraient nécessaires pour comprendre '''comment déclencher une nouvelle mesure après modification''' et pour '''affiner les modifications''' appliquées au système.

Version actuelle datée du 30 janvier 2025 à 15:52

Configuration du routeur wifi pour notre VLAN 11

Le VLAN est apparent sur le réseau, mais il n'y a pas d'accès Internet.

Pourtant, il semble que nous ayons la même configuration que les binômes qui avaient un wifi fonctionnel.

Configuration de l'interface eth0 (172.26.145.101) et eth1 (172.16.11.111) sur la VM SE5-WIJSMAN-LEFRANC sur Capbreton.

Dans la VM, configuration de FreeRADIUS:

/etc/freeradius/3.0/users:

louis Cleartext-Password := "glopglop"      
MS-CHAP-Use-NTLM-Auth := Yes

/etc/freeradius/3.0/clients.conf:

client wifi_ap {
        ipaddr = 172.26.145.1
        secret = glopglop
        shortname = VM_binome_11
}

Sur le routeur CISCO:

Mise en place d'un point d'accès VM_binome_11 avec comme mot de passe "glopglop" en suivant les commandes du wiki.

ssh -l admin -o KexAlgorithms=diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 -o HostKeyAlgorithms=ssh-rsa -c aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc 172.26.145.1
  ...
       aaa new-model
       aaa authentication login eap_binome_11 group radius_binome_11
       radius-server host 172.26.145.101 auth-port 1812 acct-port 1813 key glopglop
       aaa group server radius radius_binome_11
         server 172.26.145.101 auth-port 1812 acct-port 1813
       !
       ...
       dot11 ssid VM_binome_11
         vlan 411
         authentication open eap eap_binome_11
         authentication network-eap eap_binome_11
         authentication key-management wpa
         mbssid guest-mode
       !
       ...
       interface Dot11Radio0
         encryption vlan 411 mode ciphers aes-ccm
         ...
       !
       ...
       interface Dot11Radio0.11
         encapsulation dot1Q 411
         bridge-group 11
       !
       interface GigabitEthernet0.11
         encapsulation dot1Q 411
         bridge-group 11
       !

Piratage d’objets connectés

Objectif :

Dans un premier temps, notre objectif est de pirater une sonnette sans fil.

Ensuite, nous tenterons également de compromettre un capteur de température LIBERO CS afin d'analyser sa sécurité et ses vulnérabilités.

Sonnette sans fil

Matériel utilisé :

  • PC avec GNU Radio
  • SDR HackRF One

Méthodologie :


  1. Analyse du signal : Nous commençons par analyser le signal envoyé lorsqu'on appuie sur le bouton de la sonnette à l'aide d'un analyseur de spectre.
  2. Analyse des trames : Nous analysons la trame envoyée à chaque appui sur le bouton. Après une série de tests, nous avons découvert que la trame envoyée est toujours la même.
  3. Reproduction du signal : Dans un deuxième temps, nous mettons en place un programme sur GNU Radio pour reproduire le signal, afin de faire croire à la sonnette que le bouton a été appuyé.

Méthode 1 : Ecoute et réémission (PARROT) :

La méthode consiste à utiliser une antenne et un récepteur SDR pour écouter le signal émis par la télécommande, puis à le réémettre après enregistrement.

Le programme GNU Radio utilisé pour cette opération est présenté ci-dessous.

Méthode PARROT où l'on enregistre pour réémettre.
Screenshot from 2024-10-21 14-25-36.png


Problèmes rencontrés

Malheureusement, cette approche ne fonctionne pas en l’état, pour deux raisons principales :

  1. Accumulation de bruit : Lors de l’enregistrement, du bruit parasite est capté avec le signal. Lors de la réémission, ce bruit est amplifié, ce qui altère la qualité du signal transmis.
  2. Manque de puissance : Une puissance insuffisante lors de la réémission peut empêcher le signal d’avoir un effet notable, d’autant plus que l’augmentation de puissance améliorerait également le rapport signal/bruit.

Améliorations possibles

Cette méthode pourrait être optimisée en ajoutant :

  • Des filtres pour réduire le bruit et améliorer la qualité du signal réémis.
  • Un amplificateur pour garantir une puissance suffisante et assurer une transmission efficace.

Méthode 2 : Recréation du signal

Nous avons utilisé un oscilloscope et une sonde de champ proche pour améliorer le rapport signal/bruit et ainsi observer clairement le signal.

Visualisation de la trame émise par le SDR.


Dans un premier temps, nous avons analysé le signal à l’aide d’un récepteur SDR, mais celui-ci introduisait des défauts suffisants pour altérer la qualité du rendu. Nous avons ensuite amélioré la mesure en utilisant un oscilloscope professionnel, ce qui nous a permis d’obtenir les fréquences exactes du signal.

Grâce à ces mesures, nous avons développé un programme GNU Radio capable de reproduire le signal de la télécommande.

Programme qui recrée le signal à émettre et l'émet.


Structure du signal

La trame transmise contient le message suivant, répété 75 fois par pression sur le bouton :

0001010011000111100110000

Le codage du signal est défini ainsi :

  • 0 : 0,2 ms high + 0,6 ms low
  • 1 : 0,6 ms high + 0,2 ms low

Nous prenons le PGCD de 6 et 2, soit 2, ce qui nous donne un pas de temps minimal de 0,2 ms. Un signal de 5 kHz est donc utilisé pour générer cette modulation.

L'encodage du signal à 5 kHz suit la règle suivante :

  • 0 → 1000
  • 1 → 1110

Par exemple, pour coder le message "101", nous transmettons la séquence : 1110 1000 1110.

Nous avons utilisé une fréquence d’échantillonnage (sampling rate) de 10 MHz, largement supérieure à 433 kHz, garantissant ainsi un signal propre. L'interpolation est réalisée avec un facteur de 2000 pour obtenir un signal carré net : 2k × 5k = 10M.

Résultats

Après de nombreux tests et ajustements, nous avons réussi à déclencher l’alarme à environ 1 mètre de distance. En intégrant un système d’amplification, il serait possible d’augmenter considérablement cette portée.

Capteur de température LIBERO

Capteur de température


Objectif

L’objectif est de contourner le système afin de modifier les valeurs enregistrées en mémoire et fausser les mesures de température.

Analyse matérielle

Nous avons démonté le boîtier afin d’examiner le PCB et les composants. L’image ci-dessous montre l’emplacement du capteur de température.

Deux approches ont été envisagées pour compromettre le capteur :

Modification matérielle :

Le capteur semble être une CTN (thermistance à coefficient de température négatif).

Il est possible d’ajouter une résistance en parallèle ou de remplacer complètement la CTN, ce qui permettrait de modifier les valeurs mesurées à volonté.

Reprogrammation du microcontrôleur :

Le microcontrôleur utilisé est un STM32L073CZTB.

Nous avons identifié plusieurs testpoints sur la carte, utilisés pour la programmation automatisée.

Nous avons procédé à une rétro-ingénierie afin de localiser les pins de reprogrammation :

  • NRST (Pin 7) : Reset du microcontrôleur
  • SWDIO (Pin 34, PA13) : Interface de communication bidirectionnelle
  • SWCLK (Pin 35, PA14) : Horloge du débogage série
  • VSS (Pin 8 ou 33) : Masse
  • VDD (Pin 9 ou 36) : Alimentation

Aprés s'être connecter dessus voici les étapes que nous avons réalisés.

Étapes du contournement


1. Récupération du programme

Nous avons utilisé le logiciel STM32 Programmer et un ST-Link V2 pour extraire le programme via le port SWD.

Une lecture complète (READ ALL) permet d’obtenir un fichier .bin contenant le firmware.


2. Analyse du programme

Ghidra found DR


Le fichier .bin a été analysé avec Ghidra, configuré pour un ARM Cortex-M 32 bits.

Grâce à Ghidra SVD Loader, nous avons chargé le fichier SVD du STM32 pour afficher les registres et leur correspondance en mémoire.

Nous avons identifié plusieurs zones d’intérêt :

  • Le programme principal : Adresse 0x02E850
  • Les valeurs stockées en mémoire : Adresse 0x9010 - 0x9384
  • Le fichier PDF contenant les mesures :
    • Stocké en mémoire de 0x2B040 à 0x2414B
    • Le template du PDF est entre 0x237C8 et 0x24163
    • Le fichier commence à 0x8300 et se termine à 0x2414B

3. Modification du programme

Modification de la valeur du registre chargé dans la variable


Nous avons cherché à modifier la récupération des valeurs mesurées par l’ADC du STM32.

L’objectif était de détourner la lecture du registre ADC_DR (offset 0x40 dans l’ADC) et de le remplacer par une autre valeur, par exemple le registre ISR (Interrupt Status Register).

Cette modification devait perturber l’affichage des températures dans le PDF généré.


4. Réinjection du programme

Le programme modifié a été réinjecté via STM32 Programmer.


5. Vérification des résultats

L’analyse dans Ghidra a confirmé que la valeur du registre mesuré avait bien été modifiée.

Cependant, nous avons rencontré une difficulté pour relancer une nouvelle mesure, sans parvenir à identifier la séquence nécessaire dans le code.

Nous avons aussi modifié une valeur à l’adresse 0x9010, ce qui a entraîné un changement dans le graphique des températures du PDF généré par la clé.

Cependant, nous n’avons pas encore compris précisément l’impact de cette modification sur l’ensemble du système.

Par manque de temps, nous n’avons pas poursuivi l’exploration, mais cette approche pourrait être approfondie pour mieux comprendre la manière dont le système enregistre et affiche les mesures.


Conclusion

Nous avons démontré plusieurs moyens potentiels pour compromettre le capteur LIBERO CS :

  • Altération matérielle du capteur (ajout/remplacement de composants).
  • Reprogrammation du microcontrôleur pour modifier les valeurs enregistrées.

Des recherches supplémentaires seraient nécessaires pour comprendre comment déclencher une nouvelle mesure après modification et pour affiner les modifications appliquées au système.