« 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
 
(10 versions intermédiaires par 2 utilisateurs non affichées)
Ligne 63 : Ligne 63 :


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


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


Ensuite, nous allons également tenter de cracker un capteur de température LIBERO CS.
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''' ==
== '''Sonnette sans fil''' ==
Ligne 76 : 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 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.
Ligne 82 : Ligne 82 :
# '''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é.
# '''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) : ===
=== Méthode 1 : Ecoute et réémission (PARROT) : ===
On écoute la télécommande et on réémet le signal.
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.
 
[[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 :


Méthode PARROT où l'on enregistre pour réémettre.
# '''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.


On utilise le programme GNU Radio suivant :
==== Améliorations possibles ====
[[Fichier:Screenshot from 2024-11-27 14-33-26.png|vignette|Méthode PARROT où l'on enregistre pour réémettre.]]
Cette méthode pourrait être optimisée en ajoutant :


Cela ne fonctionne pas, nous avons donc opté pour une autre méthode.
* '''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.


Nous avons créé un programme GNU Radio plus complexe qui recrée le signal de la télécommande.
Grâce à ces mesures, nous avons développé un programme GNU Radio capable de reproduire le signal de la télécommande.


Le signal est le suivant :
[[Fichier:Montage fonctionel.png|vignette|left|Programme qui recrée le signal à émettre et l'émet.]]
<br clear="all"/>


75 trames avec le codage binaire suivant :
==== Structure du signal ====


<blockquote>0001010011000111100110000[[Fichier:Trame.jpg|vignette|Visualisation de la trame émise par le SDR.]]
La trame transmise contient le message suivant, répété 75 fois par pression sur le bouton :
[[Fichier:Montage fonctionel.png|vignette|Programme qui recrée le signal à émettre et l'émet.]]</blockquote>


Les timings sont les suivants :
'''0001010011000111100110000'''


* 0 : 0,2 ms high et 0,6 ms low 
Le codage du signal est défini ainsi :
* 1 : 0,6 ms high et 0,2 ms low 


Nous prenons le PGCD de 6 et 2, qui est 2, donc on prend 0,2 ms comme plus petit pas.
* '''0''' : 0,2 ms high + 0,6 ms low
* '''1''' : 0,6 ms high + 0,2 ms low


On code de manière suivante :
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.


* 0 = 1000
L'encodage du signal à '''5 kHz''' suit la règle suivante :
* 1 = 1110


Par exemple, pour coder le message "101", on envoie 1110 1000 1110.
* '''0''' → 1000
* '''1''' → 1110


Nous utilisons un sampling_rate de 10 MHz, mais nous voulons envoyer un signal dont la fréquence maximale est de 5 kHz.
Par exemple, pour coder le message '''"101"''', nous transmettons la séquence : '''1110 1000 1110'''.


Nous utilisons donc un bloc de rééchantillonnage.
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'''.


Cela fonctionne et nous parvenons à actionner la sonnette via la SDR !
==== 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 LIBERO''' ==
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.
[[Fichier:Capteur.jpg|vignette|left|Capteur de température]]
[[Fichier:Capteur.jpg|vignette|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'''.
 
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.


Après une analyse, on peut remarquer le capteur de température, comme indiqué sur l'image suivante.
=== Étapes du contournement ===
----


* Une possibilité serait de modifier le comportement du capteur en ajoutant une résistance, par exemple.
==== '''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 autre possibilité serait de reprogrammer le microcontrôleur afin de modifier son comportement. Il s'agit d'un '''STM32L073CZTb.'''
Une lecture complète ('''READ ALL''') permet d’obtenir un fichier '''.bin''' contenant le firmware.
----


Pour cela, il faut mapper chaque pin pour pouvoir se connecter directement sur les testpoints.
==== '''2. Analyse du programme''' ====


Le but est déjà de repérer les pins qui serviront à la programmation, soit :
[[Fichier:Screenshot from 2025-01-06 07-31-09.png|vignette|left|Ghidra found DR]]
* '''NRST (Pin 7)''' - Pin Reset.
<br clear="all"/>
* '''SWDIO (Pin 34, PA13)''' - Serial Wire Debug Data Input/Output.
* '''SWCLK (Pin 35, PA14)''' - Serial Wire Debug Clock.
* '''VSS (Pin 8 ou 33)''' - Pin Ground.
[[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 chargé dans la variable]]'''VDD (Pin 9 ou 36)''' - Power supply.


=== Étape de contournement : ===
Le fichier '''.bin''' a été analysé avec '''Ghidra''', configuré pour un '''ARM Cortex-M 32 bits'''.


# Récupération du programme en se connectant sur les pins du port SWD
Grâce à '''Ghidra SVD Loader''', nous avons chargé le fichier SVD du STM32 pour afficher les registres et leur correspondance en mémoire.
# Analyse du programme via Ghidra
# 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 ===
Nous avons identifié plusieurs zones d’intérêt :
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.


=== 2. Analyse du programme ===
* '''Le programme principal''' : Adresse '''0x02E850'''
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.
* '''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'''


Le logiciel Ghidra fait ensuite une analyse du code, permettant de récupérer une vue assembleur du programme et aussi une vue en C.
----


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.
==== '''3. Modification du programme''' ====


Dans le programme, on peut retrouver :
[[Fichier:Ghidra registre modifier.png|vignette|left|Modification de la valeur du registre chargé dans la variable]]
<br clear="all"/>


Le programme (adresse : 0x02E850).
Nous avons cherché à modifier la récupération des valeurs mesurées par l’'''ADC''' du STM32.


On utilise un gestionnaire pour rechercher la chaîne "pdf".
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).


À partir de l'adresse 0x2B040, se trouve la mémoire où est stocké le fichier PDF, occupant 24 Ko. 
Cette modification devait perturber l’affichage des températures dans le '''PDF généré'''.
Le début du PDF commence à l'adresse 0x8300.
----
Le dernier mot du PDF se trouve à l'adresse 0x2414B. 


De l'adresse 0x237C8 jusqu'à 0x24163, se trouve le template du PDF.
==== '''4. Réinjection du programme''' ====
Le programme modifié a été réinjecté via '''STM32 Programmer'''.
----


De l'adresse 0x9010 jusqu'à 0x9384, se trouvent les valeurs dans la mémoire.
==== '''5. Vérification des résultats''' ====
L’analyse dans '''Ghidra''' a confirmé que la valeur du registre mesuré avait bien été modifiée.


Cette dernière section est celle qui nous intéresse, car nous allons tenter de modifier la valeur que le programme récupère.
Cependant, nous avons rencontré une difficulté pour '''relancer une nouvelle mesure''', sans parvenir à identifier la séquence nécessaire dans le code.


=== 3. Modification du programme ===
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é'''.
En cherchant à modifier ce qui est récupéré dans le programme via l'ADC du STM32, nous cherchons le registre ADC_DR qui correspond au décalage 0x40 de l'ADC. Nous trouvons à quel endroit la mesure est faite.


En choisissant, pour l'exemple, de modifier le programme afin que ce qui sera récupéré dans ce programme ne soit 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.
Cependant, nous n’avons pas encore compris précisément l’impact de cette modification sur l’ensemble du système.


=== 4. Réinjection 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.
La réinjection du programme est assez simple avec le programmateur STM32. 
----


Nous modifions une valeur (adresse 0x9010) dans le code et observons un changement sur le graphique des températures dans le PDF généré par la clé. En revanche, nous ne comprenons pas encore de quelle manière cela affecte précisément le graphique. 
=== '''Conclusion''' ===
Nous avons démontré plusieurs moyens potentiels pour compromettre le capteur '''LIBERO CS''' :


Le PDF est stocké à l'adresse 0x8000.
* '''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.