wiki-se.plil.fr - Contributions [fr]

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T17:13:53Z

Ybenmbar : /* Réception et envoi de la Raspberry Pi */

Pour ce TP d'IA, nous avons décidé de concevoir un système qui reconnaîtra des diverses formes.

[[Fichier:2025013063924.jpg|centré|vignette|Formes utilisées]]

== Réseau ==

=== Machine Virtuelle ===

Nous avons créé un serveur virtuel sur capbreton : '''SE5-yelqasta-ybenmbar-IA'''
- Interface réseau dans le commutateur virtuel '''bridgeStudents'''.
- IP : 172.26.145.104

Ce serveur sera nous servira de broker MQTT, afin d'analyser et afficher les résultats dynamiquement.

=== Architecture Réseau ===

Nous avons prévu cette architecture :
<div style="flex:1; padding-left:10px;">[[Fichier:Pppp.png|vignette|centré|571x571px]]</div>

* La Nucleo fera les mesures par le biais du capteur ToF;

* La Raspberry recevra ces données par UART;

* Enfin, la machine virtuelle les recevra et les affichera.

=== Réception et envoi de la Raspberry Pi ===

La Raspberry Pi lit des données via l'UART et les publie sur le broker MQTT, de la machine virtuelle :
<syntaxhighlight lang="c">
import paho.mqtt.client as mqtt
import serial
import time

# Configuration UART
SERIAL_PORT = "/dev/ttyACM0"

# Configuration MQTT
BROKER = "172.26.145.104"
PORT = 1883
TOPIC = "IA/data"
CLIENT_ID = "client"

# Connexion MQTT
def on_connect(client, userdata, flags, rc):
if rc == 0:
print("Connexion au broker MQTT réussie")
else:
print(f"Échec de connexion, code retour : {rc}")

client = mqtt.Client(CLIENT_ID)
client.on_connect = on_connect
client.connect(BROKER, PORT, 60)
client.loop_start()

# Configuration de la liaison série
try:
ser = serial.Serial(SERIAL_PORT, BAUD_RATE, timeout=1)
print(f"Ouverture du port série {SERIAL_PORT} à {BAUD_RATE} bauds")
except serial.SerialException as e:
print(f"Erreur d'ouverture du port série : {e}")
exit(1)

try:
while True:
if ser.in_waiting:
data = ser.readline().decode('utf-8').strip()
if data:
print(f"Donnée reçue : {data}")
client.publish(TOPIC, data)
time.sleep(0.1) # Pour éviter une surcharge CPU
except KeyboardInterrupt:
print("Arrêt du programme")
ser.close()
client.disconnect()
</syntaxhighlight>

== Apprentissage ==

Le matériel utilisé :

* Raspberry Pi 4

* Nucleo-F401RE

* Capteur de distance Nucleo-53L5A1

Notre Raspberry communiquera avec la Nucleo par liaison série UART. Elle servira aussi d'interface entre la Nucleo, qui sera entraînée à manipuler les données, et le réseau.

Nous avons mis en place un modèle simple de classification avec 3 classes, correspondant à 3 formes :

* Coeur

* Ours

* Soleil
[[Fichier:274314.jpg|gauche|vignette|Conditions de Mesure]]

Après avoir installé l'API X-CUBE-TOF1, qui nous permettra d'utiliser efficacement le capteur, nous avons pu "mettre en place" les données à envoyer.

Sous la forme d'une ligne, chaque coefficient de la matrice 8*8 est représenté :

[[Fichier:Captaaaa.png|centré|vignette|Distances (matrice 8*8) mesurées|571x571px]]

Pour ajouter des données d'entraînement, nous insérons des signaux sur NanoEdge AI. Ces données représentent des mesures réelles capturées par le capteur.

Comme nous avons 3 classes, nous allons le faire 3 fois :

[[Fichier:Capture d’écran du 2025-01-30 17-34-42.png|centré|571x571px]]

Voici un aperçu de la matrice :

[[Fichier:Capture d’écran du 2025-01-30 17-54-16.png|centré|571x571px]]

Après cela, nous avons pu générer un benchmark, représentatif de l'apprentissage du système :

[[Fichier:Qspkpocpqco.png|vignette|centré|571x571px]]

Notre benchmark indique 83% de fiabilité. Ce n'est pas l'idéal, mais c'est utilisable.

L’étape de validation dans NanoEdge AI Studio permet d’évaluer les performances du modèle généré.Pour ce faire, NanoEdge AI Studio compare les résultats du modèle avec les classes attendues et génère un rapport de performance :

[[Fichier:Pqspqopsckpoqc.png|centré|571x571px]]

[[Fichier:Pappapappapaa.png|centré|571x571px]]

Après avoir validé cette étape la librairie .a est alors prête à être exportée et intégrée au nucleo.

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T17:10:58Z

Ybenmbar : /* Réseau */

Pour ce TP d'IA, nous avons décidé de concevoir un système qui reconnaîtra des diverses formes.

[[Fichier:2025013063924.jpg|centré|vignette|Formes utilisées]]

== Réseau ==

=== Machine Virtuelle ===

Nous avons créé un serveur virtuel sur capbreton : '''SE5-yelqasta-ybenmbar-IA'''
- Interface réseau dans le commutateur virtuel '''bridgeStudents'''.
- IP : 172.26.145.104

Ce serveur sera nous servira de broker MQTT, afin d'analyser et afficher les résultats dynamiquement.

=== Architecture Réseau ===

Nous avons prévu cette architecture :
<div style="flex:1; padding-left:10px;">[[Fichier:Pppp.png|vignette|centré|571x571px]]</div>

* La Nucleo fera les mesures par le biais du capteur ToF;

* La Raspberry recevra ces données par UART;

* Enfin, la machine virtuelle les recevra et les affichera.

=== Réception et envoi de la Raspberry Pi ===

<syntaxhighlight lang="c">
import paho.mqtt.client as mqtt
import serial
import time

# Configuration UART
SERIAL_PORT = "/dev/ttyACM0"

# Configuration MQTT
BROKER = "172.26.145.104"
PORT = 1883
TOPIC = "IA/data"
CLIENT_ID = "client"

# Connexion MQTT
def on_connect(client, userdata, flags, rc):
if rc == 0:
print("Connexion au broker MQTT réussie")
else:
print(f"Échec de connexion, code retour : {rc}")

client = mqtt.Client(CLIENT_ID)
client.on_connect = on_connect
client.connect(BROKER, PORT, 60)
client.loop_start()

# Configuration de la liaison série
try:
ser = serial.Serial(SERIAL_PORT, BAUD_RATE, timeout=1)
print(f"Ouverture du port série {SERIAL_PORT} à {BAUD_RATE} bauds")
except serial.SerialException as e:
print(f"Erreur d'ouverture du port série : {e}")
exit(1)

try:
while True:
if ser.in_waiting:
data = ser.readline().decode('utf-8').strip()
if data:
print(f"Donnée reçue : {data}")
client.publish(TOPIC, data)
time.sleep(0.1) # Pour éviter une surcharge CPU
except KeyboardInterrupt:
print("Arrêt du programme")
ser.close()
client.disconnect()
</syntaxhighlight>

== Apprentissage ==

Le matériel utilisé :

* Raspberry Pi 4

* Nucleo-F401RE

* Capteur de distance Nucleo-53L5A1

Notre Raspberry communiquera avec la Nucleo par liaison série UART. Elle servira aussi d'interface entre la Nucleo, qui sera entraînée à manipuler les données, et le réseau.

Nous avons mis en place un modèle simple de classification avec 3 classes, correspondant à 3 formes :

* Coeur

* Ours

* Soleil
[[Fichier:274314.jpg|gauche|vignette|Conditions de Mesure]]

Après avoir installé l'API X-CUBE-TOF1, qui nous permettra d'utiliser efficacement le capteur, nous avons pu "mettre en place" les données à envoyer.

Sous la forme d'une ligne, chaque coefficient de la matrice 8*8 est représenté :

[[Fichier:Captaaaa.png|centré|vignette|Distances (matrice 8*8) mesurées|571x571px]]

Pour ajouter des données d'entraînement, nous insérons des signaux sur NanoEdge AI. Ces données représentent des mesures réelles capturées par le capteur.

Comme nous avons 3 classes, nous allons le faire 3 fois :

[[Fichier:Capture d’écran du 2025-01-30 17-34-42.png|centré|571x571px]]

Voici un aperçu de la matrice :

[[Fichier:Capture d’écran du 2025-01-30 17-54-16.png|centré|571x571px]]

Après cela, nous avons pu générer un benchmark, représentatif de l'apprentissage du système :

[[Fichier:Qspkpocpqco.png|vignette|centré|571x571px]]

Notre benchmark indique 83% de fiabilité. Ce n'est pas l'idéal, mais c'est utilisable.

L’étape de validation dans NanoEdge AI Studio permet d’évaluer les performances du modèle généré.Pour ce faire, NanoEdge AI Studio compare les résultats du modèle avec les classes attendues et génère un rapport de performance :

[[Fichier:Pqspqopsckpoqc.png|centré|571x571px]]

[[Fichier:Pappapappapaa.png|centré|571x571px]]

Après avoir validé cette étape la librairie .a est alors prête à être exportée et intégrée au nucleo.

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T17:05:42Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T17:04:33Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T17:01:57Z

Ybenmbar :

Fichier:Capture d’écran du 2025-01-30 17-54-16.png

2025-01-30T17:01:35Z

Ybenmbar :

aaa

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:58:36Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:57:41Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:56:42Z

Ybenmbar :

Fichier:Qspkpocpqco.png

2025-01-30T16:56:27Z

Ybenmbar :

qxjkkqjk

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:53:40Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:53:29Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:53:01Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:52:49Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:52:37Z

Ybenmbar : /* Apprentissage */

Fichier:274314.jpg

2025-01-30T16:52:09Z

Ybenmbar :

dsldsmdsml

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:51:04Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:46:18Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:45:43Z

Ybenmbar : /* Apprentissage */

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:44:33Z

Ybenmbar :

Fichier:Qbjjbsdbj.png

2025-01-30T16:44:28Z

Ybenmbar :

lkdmsvsd

Fichier:Pqspqopsckpoqc.png

2025-01-30T16:43:57Z

Ybenmbar :

SKLDCsLsLLC

Fichier:Pappapappapaa.png

2025-01-30T16:43:25Z

Ybenmbar :

kdk,ldskds

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:41:12Z

Ybenmbar :

Fichier:Capture d’écran du 2025-01-30 17-34-42.png

2025-01-30T16:41:01Z

Ybenmbar :

Ppppp

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:37:39Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:37:08Z

Ybenmbar : /* Apprentissage */

Fichier:Captaaaa.png

2025-01-30T16:36:08Z

Ybenmbar :

aaaa

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:34:50Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:30:30Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:30:05Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:27:25Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:27:12Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:26:49Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:26:30Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:26:13Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:25:16Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:24:43Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:22:41Z

Ybenmbar :

Fichier:Pppp.png

2025-01-30T16:22:20Z

Ybenmbar :

ss,

Fichier:Capturd’écradu2025-01-3017-10-51.png

2025-01-30T16:19:04Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T16:03:15Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T15:53:49Z

Ybenmbar :

Pour ce TP d'IA, nous avons décidé de concevoir un système qui reconnaîtra des diverses formes.

[[Fichier:2025013063924.jpg|centré|vignette|Formes utilisées]]

== Architecture Réseau ==

Nous avons prévu cette architecture :

== Apprentissage ==

Le matériel utilisé :

* Raspberry Pi 4

* Nucleo-F401RE

* Capteur de distance Nucleo-53L5A1

Le ca

Notre Raspberry communiquera avec la Nucleo par liaison série UART. Elle servira aussi d'interface entre la Nucleo, qui sera entraînée à manipuler les données, et le réseau.

Lors de cette première séance, nous avons aussi configuré l'OS de la Raspberry ainsi que sa connexion à la borne Wi-Fi de la salle.

Nous avons besoin Notre première approche est de proposer un modèle simple de classification.

Fichier:2025013063924.jpg

2025-01-30T15:48:58Z

Ybenmbar :

SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

2025-01-30T12:25:38Z

Ybenmbar :

# SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani

'''Le 03/09/2024 :'''

- Recherche du sujet

- Installation des logiciels

'''Le 05/09/2024 :''' Nous avons décidé de concevoir un système qui déterminera dans un premier temps la pression dans une balle en chute libre, puis, si on avance bien, prédire la hauteur du deuxième rebond.

Voici la démarche à laquelle nous avons pensé :
[[Fichier:Schema ia1.png|800px|center|Schéma]]

Avec quelques entrainements, nous pourrons calculer la pression.

Le matériel utilisé :

* Raspberry Pi 4

* Nucleo-F401RE

* Capteur de distance Nucleo-53L5A1

* Accéléromètre (pas pour le moment) (mettre reference)

Notre Raspberry communiquera avec la Nucleo par liaison série UART. Elle servira aussi d'interface entre la Nucleo, qui sera entraînée à manipuler les données, et le réseau.

Lors de cette première séance, nous avons aussi configuré l'OS de la Raspberry ainsi que sa connexion à la borne Wi-Fi de la salle.

// utiliser architecture perceptron, une entrée 15 sorties. ( winner takes all concept, ReLu activation func ? )

Nous avons besoin //
Notre première approche est de proposer un modèle simple de classification.

// La communication entre l'accéléromètre et la nucleo se fait en I2C.

// Possible Challenges:

// The trajectory of the falling object will almost always be non linear, which introduces new parameters to the equation.

// Need to take in account the weight of the object, the size, the rebound behaviour (ricochet). (Probably need a soft surface in order not to damage the object).

// The length of the connection could probably affect the communication ? Would it be possible to store the experience data then feed the model, or should it be real time ?

SE5 IdO sécurité des objets 2024/2025 b4

2025-01-26T21:23:05Z

Ybenmbar : /* Temptale USB */

== Wi-Fi ==

=== Création du serveur virtuel ===
- Création d'un serveur virtuel sur capbreton : '''SE5-yelqasta-ybenmbar'''
- Interface réseau dans le commutateur virtuel '''bridgeStudents''' avec :
* Adresse IPv4 : '''172.26.145.104'''
* Passerelle : '''172.26.145.251'''
- Interface réseau dans le VLAN 404 :
* Adresse IPv4 : '''172.16.4.1'''
* Masque : '''/24''' (255.255.255.0)
* VLAN : '''404'''

=== Configuration du point d'accès WiFi Cisco ===

- Définition du SSID '''VM_binome_4''' :
<syntaxhighlight lang="plaintext">
dot11 ssid VM_binome_4
vlan 404
authentication open eap eap_binome_4
authentication network-eap eap_binome_4
authentication key-management wpa
mbssid guest-mode
</syntaxhighlight>
- Configuration du VLAN 404 sur l'interface radio et l'interface Ethernet :
<syntaxhighlight lang="plaintext">
interface Dot11Radio0.404
encapsulation dot1Q 404
bridge-group 4
</syntaxhighlight>

<syntaxhighlight lang="plaintext">
interface GigabitEthernet0.404
encapsulation dot1Q 404
bridge-group 4
</syntaxhighlight>
- Configuration de l'accès au serveur FreeRADIUS :
<syntaxhighlight lang="plaintext">
aaa new-model
aaa authentication login eap_binome_4 group radius_binome_4
radius-server host 172.16.4.1 auth-port 1812 acct-port 1813 key glopglop
aaa group server radius radius_binome_4
server 172.16.4.1 auth-port 1812 acct-port 1813
</syntaxhighlight>

=== Configuration du serveur FreeRADIUS ===
- Installation de FreeRADIUS sur le serveur virtuel :
<syntaxhighlight lang="bash">
sudo apt update
sudo apt install freeradius freeradius-utils
</syntaxhighlight>
- Ajout de l'adresse IP du point d'accès Cisco dans le fichier de clients FreeRADIUS :
* Dans le fichier '''/etc/freeradius/3.0/clients.conf''' :
<syntaxhighlight lang="plaintext">
client wifi_ap {
ipaddr = 172.26.145.4
secret = glopglop
shortname = wifi_ap_binome_4
}
</syntaxhighlight>
- Configuration d'un utilisateur pour l'authentification WPA2-EAP :
* Dans le fichier '''/etc/freeradius/3.0/users''' :
<syntaxhighlight lang="plaintext">
mouss Cleartext-Password := "glopglop"
</syntaxhighlight>
- Activation de PEAP-MSCHAPv2 :
* Dans le fichier '''/etc/freeradius/3.0/mods-enabled/eap''' :
<syntaxhighlight lang="plaintext">
peap {
default_eap_type = mschapv2
}
</syntaxhighlight>

=== Serveur DHCP ===
- On a installé un serveur DHCP sur le serveur virtuel :
<syntaxhighlight lang="bash">
sudo apt install isc-dhcp-server
</syntaxhighlight>
- Configuration du serveur DHCP :
* Dans le fichier '''/etc/dhcp/dhcpd.conf''' :
<syntaxhighlight lang="plaintext">
subnet 172.16.4.0 netmask 255.255.255.0 {
range 172.16.4.100 172.16.4.200;
option routers 172.16.4.104;
option domain-name-servers 255.255.255.0;
}
</syntaxhighlight>
- Dans le fichier '''/etc/default/isc-dhcp-server''' :
<syntaxhighlight lang="plaintext">
INTERFACESv4="eth1"
</syntaxhighlight>

=== Serveur DNS minimal ===
* Dans '''/etc/bind/named.conf.options'''
<syntaxhighlight lang="plaintext">
...
forwarders {
172.26.188.12;
};
...
</syntaxhighlight>

=== Mascarade entre VLAN privé et routeur ===
- Activation du transfert IP sur le serveur virtuel :
<syntaxhighlight lang="bash">
systemctl -w net.ipv4.ip_forward=1
</syntaxhighlight>
- Ajout d'une règle de masquerade avec '''iptables''' :
<syntaxhighlight lang="bash">
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
</syntaxhighlight>

=== Passage de WPA-EAP à WPA-PSK ===
Afin d'utiliser notre balance connectée, nous devons mettre en place un point d'accès avec WPA-PSK et non WPA-EAP.

* Dans le point d'accès Cisco :

<pre>
no autentication open eap eap_binome_4
no authentication network-eap eap_binome_4
wpa-psk ascii [mdp]
</pre>

== Temptale USB ==

=== Identification des différentes puces ===

[[Fichier:Img cpsnts.jpg|vignette|Temptale ouvert]]

µC : Atmel AT91SAM7S256

Puce mémoire : Winbond 25X40CLNIG

SN74CBTLV3126 : commutateur de bus FET quadripolaire, probablement utilisé comme convertisseur de niveau

=== Modification du fichier pdf ===
Nous avons d'abord pensé à passer par le système de fichiers et plus précisément le fichier pdf pour hacker le Temptale.

=== Mémoire ===

Afin d'extraire les données de la mémoire, nous avons soudé des fils sur chaque broche de la puce mémoire. Elle fonctionne en SPI, nous l'avons alors connectée à la Raspberry Pi sur les broches correspondantes (SCK,MISO,MOSI,SS).
Grâce à l'utilitaire <code>flashrom</code>, nous pouvons depuis la Raspberry Pi extraire la mémoire flash.

[[Fichier:Capture broches.png|vignette|Schéma de la puce mémoire]]

Nous l'avons connecté de cette façon :

{| class="wikitable"
|+
!RPi
!Winbond 25X40CLNIG
|-
|CE0
|CS
|-
|MOSI
|DI
|-
|MISO
|DO
|-
|SCK
|CLK
|-
|3,3V
|VCC
|-
|GND
|GND
|}[[Fichier:Memoire soudee.jpg|vignette|Fils soudés sur les broches de la puce mémoire]]<syntaxhighlight lang="plaintext">
flashrom -p linux_spi:dev=/dev/spidev0.0
</syntaxhighlight>

Mais nous avons cette erreur :

<syntaxhighlight lang="plaintext">
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.
</syntaxhighlight>

Nous avons tenté de lancer le programme en lui spécifiant le modèle :
<syntaxhighlight lang="plaintext">
flashrom -p linux_spi:dev=/dev/spidev0.0 --chip W25X40
</syntaxhighlight>

Mais sans succès, nous suspectons un problème dans la soudure.

Nous avons alors par la suite dessoudé la flash et soudé un fil à chaque broche de celle-ci :

[[Fichier:7e4d8b63-7e49-4d2c-abbb-20ecb95b6820.jpg|vignette|Broches de la mémoire soudées aux fils|centré]]

Après cela, nous avons finalement réussi à extraire la mémoire.

[[Fichier:Lecturemem.jpg|vignette|Lecture de la mémoire|centré]]

L'utilitaire <code>binwalk</code>nous indique la présence d'un fichier pdf .

Nous avons décidé de remplacer le fichier pdf de base par un autre afin d'observer le comportement du temptale :
<syntaxhighlight lang="plaintext">
flashrom -p linux_spi:dev=/dev/spidev0.0 -w memory.bin
</syntaxhighlight>

Mais avant ça, nous avons fait en sorte de trouver un espace mémoire vide grâce à la commande <code>strings</code> :
<syntaxhighlight lang="plaintext">
strings -tx memory.bin
</syntaxhighlight>

[[Fichier:IMg.jpg|vignette|Visualisation de la mémoire, constat d'un espace mémoire disponible entre 0x136a2 et 0x16f8d|centré]]

Nous avons choisi de commencer à l'adresse 0x13700, donc en décimal 79616. Le fichier que nous avons choisi d'injecter fait 10,7 Ko.
<syntaxhighlight lang="plaintext">
dd if=example.pdf of=memory.bin bs=1 seek=79616 count=10771
</syntaxhighlight>Nous devons compléter la mémoire (524 kB) pour que l'écriture se fasse :
<syntaxhighlight lang="plaintext">
truncate -s 524288 memory.bin
</syntaxhighlight>

== Balance ==

=== Objectif du TP: ===
Nous devons analyser et compromettre la sécurité d'une balance connectée fournie par Nedis. Pour cela, nous avons installé l'application mobile associée, Nedis SmartLife, qui permet d'interagir avec la balance. [https://nedis.fr/fr-fr/smartlife Nedis SmartLife]

[[Fichier:WIFIHS10WT P50.jpg|vignette|Balance WiFi Nedis|néant]]

=== Problème réseau initial: ===
Lors des premières configurations, nous avons découvert que notre réseau Wi-Fi configuré en WPA EAP n’était pas compatible avec les exigences de la balance. Cette dernière nécessite une configuration en WPA PSK pour fonctionner correctement.

Malgré cette adaptation, nous avons rencontré des difficultés pour connecter nos téléphones à la balance. À la fin de l’appairage, la balance se déconnectait systématiquement avec le message d’erreur "Err2". D’après nos recherches, cette erreur est liée à un problème de réseau. Bien que la balance apparaisse dans l’application, elle n’envoie aucune donnée dans des conditions d’utilisation normale.
[[Fichier:Interface appli.jpg|néant|vignette|312x312px|interface de l'application]]
[[Fichier:Prob réseau appli.png|néant|vignette|333x333px|Erreur de connexion réseau]]

=== Diagnostic initial: ===
Pour identifier la source du problème, nous avons vérifié la communication entre les trois entités principales du système : le téléphone, la balance, et le point d’accès Wi-Fi. Nous avons utilisé le Wi-Fi préalablement configuré lors des séances précédentes et effectué des tests de connectivité :[[Fichier:Ping phone.jpg|vignette|Ping vers le téléphone : Réussi|néant]][[Fichier:Ping balance.jpg|vignette|Ping vers la balance : Réussi|néant]]

Ces résultats montrent que les appareils sont correctement connectés au réseau, ce qui écarte l’hypothèse d’un problème de connexion simple. Cependant, cela laisse supposer une potentielle perte des données pendant les échanges.

=== Analyse avancée avec Wireshark: ===
Pour approfondir le diagnostic, notre professeur nous a suggéré de mettre en place une analyse de trafic réseau en utilisant :

* Un injecteur PoE
* Le point d'accès PLIL
* Un commutateur réseau configuré pour effectuer un port mirroring.
* Wireshark en mode promiscuous pour capturer les paquets circulant dans le réseau.

Commande pour la configuration du port mirroring :
Switch(config)#monitor source interface fa 0/1 both
[[Fichier:Setup réseau.jpg|néant|vignette|Schéma du réseau]]

Grâce à cette configuration, nous avons pu observer que la balance établit bien une connexion avec un serveur cloud spécifique. Cependant, les données échangées restent inintelligibles, ce qui rend le problème difficile à cerner.

=== Observation architecture cloud: ===
[[Fichier:Arp.jpg|néant|vignette|379x379px|La balance qui prend l'adresse ip 172.26.145.206]]

La balance est identifiable dans les trames capturées par son adresse MAC : '''Express:16:2d:4c'''. Cette adresse MAC apparaît principalement dans des paquets ARP, confirmant que la balance effectue des requêtes pour résoudre des adresses IP ou répondre aux requêtes des autres équipements du réseau.
Nous remarquons que les paquets montrent une tentative de négociation TLS entre la balance et un serveur cloud.
[[Fichier:Host-cloud2.png|néant|vignette|584x584px|le serveur cloud]]
[[Fichier:Host-cloud.png|néant|vignette|580x580px|Le serveur cloud]]Ce qui signifie que la communication entre la balance et l’application ne se fait pas directement via le routeur local. Au lieu de cela, les données transitent par un serveur cloud distant. Cette architecture ajoute une couche d’abstraction qui complique le diagnostic.
[[Fichier:Wireshark 2.jpg|néant|vignette|393x393px|le handshake entre le téléphone ayant l'ip 172.26.145.211 et le serveur]]
[[Fichier:Interruption de la com.jpg|néant|vignette|389x389px|transfert des paquets par chiffrement TLS]]Bien que la balance semble bien résoudre les adresses et tenter d'établir une connexion avec le cloud, le message '''TCP RST''' indique probablement que l'une des deux parties rejette la connexion.
[[Fichier:TCP RST.jpg|néant|vignette|l'interruption de le communication TCP]]

=== Approche MITM (Man-in-the-Middle): ===
Un rejet du certificat présenté par le serveur peut être la cause de l'échec de la communication, donc pour mieux comprendre et intercepter les données, une approche MITM (Man-in-the-Middle) a été proposée. L’objectif est de configurer un serveur local qui imiterait le serveur cloud en utilisant un certificat TLS falsifié, permettant ainsi de capturer et d’analyser les communications chiffrées entre la balance et le serveur.

Avec l’équipe 5, nous avons configuré le réseau suivant:

VLAN 200: Réseau dédié à la balance, configuré pour se connecter à l’adresse 17.188.185.132 sur le port 5223.

VLAN 50: Réseau pour la machine locale à l’adresse 172.26.145.231, qui hébergera notre serveur MITM.

Le serveur est conçu pour générer et présenter un certificat TLS falsifié afin de se faire passer pour le serveur cloud légitime auprès de la balance.

<syntaxhighlight lang="python">

import socket
import ssl

# Chemins vers les certificats falsifiés
CERT_FILE = "fake_cert.pem"
KEY_FILE = "fake_key.pem"

# Création du socket serveur
server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_socket.bind(('0.0.0.0', 8443)) # Écoute sur le port 8443
server_socket.listen(5)

# Ajout de la couche TLS/SSL
ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
ssl_context.load_cert_chain(certfile=CERT_FILE, keyfile=KEY_FILE)

print("Serveur en attente de connexions...")

while True:
client_socket, addr = server_socket.accept()
print(f"Connexion acceptée de : {addr}")
try:
secure_socket = ssl_context.wrap_socket(client_socket, server_side=True)
print("TLS établi avec le client.")

# Communication avec le client
data = secure_socket.recv(1024)
print(f"Données reçues : {data.decode()}")

# Réponse du serveur
secure_socket.sendall(b"HTTP/1.1 200 OK\r\nContent-Type: text/plain\r\n\r\nFake Cloud Response")
except Exception as e:
print(f"Erreur TLS : {e}")
finally:
if 'secure_socket' in locals():
secure_socket.close()
</syntaxhighlight>

Génération des certificats falisifiés :

<syntaxhighlight lang="bash">
openssl req -new -x509 -key fake_key.pem -out fake_cert.pem -days 365 -subj "/C=FR/ST=Lille/L=Lille/O=Fake Cloud/OU=Dev/CN=localhost"
openssl genrsa -out fake_key.pem 2048
</syntaxhighlight>

Redirection de l'adresse de destination vers le serveur TCP :

<syntaxhighlight lang="bash">
sudo iptables -t nat -A PREROUTING -p tcp -d 3.121.210.75 --dport 443 -j DNAT --to-destination 127.0.0.1:8443
</syntaxhighlight>

=== Conclusion et étapes suivantes : ===
Problème actuel :

Bien que la configuration MITM soit en place, nous devons encore analyser en détail les paquets chiffrés interceptés pour identifier la cause exacte de l’échec de communication.

Étape suivante ou éventuelle:

* Déployer des outils pour décrypter le trafic TLS intercepté et approfondir l’analyse des données échangées. (obsolète)
* Repérer l'extension apk de l'application Nedis pour faire du reverse.
* transformer la zabeth17 en un routeur pour pouvoir rediriger les paquets vers son adresse ip
* déssouder la puce mémoire de la carte pour la tester à part.

SE5 IdO sécurité des objets 2024/2025 b4

2025-01-26T21:22:25Z

Ybenmbar :

== Wi-Fi ==

=== Création du serveur virtuel ===
- Création d'un serveur virtuel sur capbreton : '''SE5-yelqasta-ybenmbar'''
- Interface réseau dans le commutateur virtuel '''bridgeStudents''' avec :
* Adresse IPv4 : '''172.26.145.104'''
* Passerelle : '''172.26.145.251'''
- Interface réseau dans le VLAN 404 :
* Adresse IPv4 : '''172.16.4.1'''
* Masque : '''/24''' (255.255.255.0)
* VLAN : '''404'''

=== Configuration du point d'accès WiFi Cisco ===

- Définition du SSID '''VM_binome_4''' :
<syntaxhighlight lang="plaintext">
dot11 ssid VM_binome_4
vlan 404
authentication open eap eap_binome_4
authentication network-eap eap_binome_4
authentication key-management wpa
mbssid guest-mode
</syntaxhighlight>
- Configuration du VLAN 404 sur l'interface radio et l'interface Ethernet :
<syntaxhighlight lang="plaintext">
interface Dot11Radio0.404
encapsulation dot1Q 404
bridge-group 4
</syntaxhighlight>

<syntaxhighlight lang="plaintext">
interface GigabitEthernet0.404
encapsulation dot1Q 404
bridge-group 4
</syntaxhighlight>
- Configuration de l'accès au serveur FreeRADIUS :
<syntaxhighlight lang="plaintext">
aaa new-model
aaa authentication login eap_binome_4 group radius_binome_4
radius-server host 172.16.4.1 auth-port 1812 acct-port 1813 key glopglop
aaa group server radius radius_binome_4
server 172.16.4.1 auth-port 1812 acct-port 1813
</syntaxhighlight>

=== Configuration du serveur FreeRADIUS ===
- Installation de FreeRADIUS sur le serveur virtuel :
<syntaxhighlight lang="bash">
sudo apt update
sudo apt install freeradius freeradius-utils
</syntaxhighlight>
- Ajout de l'adresse IP du point d'accès Cisco dans le fichier de clients FreeRADIUS :
* Dans le fichier '''/etc/freeradius/3.0/clients.conf''' :
<syntaxhighlight lang="plaintext">
client wifi_ap {
ipaddr = 172.26.145.4
secret = glopglop
shortname = wifi_ap_binome_4
}
</syntaxhighlight>
- Configuration d'un utilisateur pour l'authentification WPA2-EAP :
* Dans le fichier '''/etc/freeradius/3.0/users''' :
<syntaxhighlight lang="plaintext">
mouss Cleartext-Password := "glopglop"
</syntaxhighlight>
- Activation de PEAP-MSCHAPv2 :
* Dans le fichier '''/etc/freeradius/3.0/mods-enabled/eap''' :
<syntaxhighlight lang="plaintext">
peap {
default_eap_type = mschapv2
}
</syntaxhighlight>

=== Serveur DHCP ===
- On a installé un serveur DHCP sur le serveur virtuel :
<syntaxhighlight lang="bash">
sudo apt install isc-dhcp-server
</syntaxhighlight>
- Configuration du serveur DHCP :
* Dans le fichier '''/etc/dhcp/dhcpd.conf''' :
<syntaxhighlight lang="plaintext">
subnet 172.16.4.0 netmask 255.255.255.0 {
range 172.16.4.100 172.16.4.200;
option routers 172.16.4.104;
option domain-name-servers 255.255.255.0;
}
</syntaxhighlight>
- Dans le fichier '''/etc/default/isc-dhcp-server''' :
<syntaxhighlight lang="plaintext">
INTERFACESv4="eth1"
</syntaxhighlight>

=== Serveur DNS minimal ===
* Dans '''/etc/bind/named.conf.options'''
<syntaxhighlight lang="plaintext">
...
forwarders {
172.26.188.12;
};
...
</syntaxhighlight>

=== Mascarade entre VLAN privé et routeur ===
- Activation du transfert IP sur le serveur virtuel :
<syntaxhighlight lang="bash">
systemctl -w net.ipv4.ip_forward=1
</syntaxhighlight>
- Ajout d'une règle de masquerade avec '''iptables''' :
<syntaxhighlight lang="bash">
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
</syntaxhighlight>

=== Passage de WPA-EAP à WPA-PSK ===
Afin d'utiliser notre balance connectée, nous devons mettre en place un point d'accès avec WPA-PSK et non WPA-EAP.

* Dans le point d'accès Cisco :

<pre>
no autentication open eap eap_binome_4
no authentication network-eap eap_binome_4
wpa-psk ascii [mdp]
</pre>

== Temptale USB ==

=== Identification des différentes puces ===

[[Fichier:Img cpsnts.jpg|vignette|Temptale ouvert]]

µC : Atmel AT91SAM7S256

Puce mémoire : Winbond 25X40CLNIG

SN74CBTLV3126 : commutateur de bus FET quadripolaire, probablement utilisé comme convertisseur de niveau

=== Modification du fichier pdf ===
Nous avons d'abord pensé à passer par le système de fichiers et plus précisément le fichier pdf pour hacker le Temptale.

=== Mémoire ===

Afin d'extraire les données de la mémoire, nous avons soudé des fils sur chaque broche de la puce mémoire. Elle fonctionne en SPI, nous l'avons alors connectée à la Raspberry Pi sur les broches correspondantes (SCK,MISO,MOSI,SS).
Grâce à l'utilitaire <code>flashrom</code>, nous pouvons depuis la Raspberry Pi extraire la mémoire flash.

[[Fichier:Capture broches.png|vignette|Schéma de la puce mémoire]]

Nous l'avons connecté de cette façon :

{| class="wikitable"
|+
!RPi
!Winbond 25X40CLNIG
|-
|CE0
|CS
|-
|MOSI
|DI
|-
|MISO
|DO
|-
|SCK
|CLK
|-
|3,3V
|VCC
|-
|GND
|GND
|}[[Fichier:Memoire soudee.jpg|vignette|Fils soudés sur les broches de la puce mémoire]]<syntaxhighlight lang="plaintext">
flashrom -p linux_spi:dev=/dev/spidev0.0
</syntaxhighlight>

Mais nous avons cette erreur :

<syntaxhighlight lang="plaintext">
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.
</syntaxhighlight>

Nous avons tenté de lancer le programme en lui spécifiant le modèle :
<syntaxhighlight lang="plaintext">
flashrom -p linux_spi:dev=/dev/spidev0.0 --chip W25X40
</syntaxhighlight>

Mais sans succès, nous suspectons un problème dans la soudure.

Nous avons alors par la suite dessoudé la flash et soudé un fil à chaque broche de celle-ci :

[[Fichier:7e4d8b63-7e49-4d2c-abbb-20ecb95b6820.jpg|vignette|Broches de la mémoire soudées aux fils|centré]]

Après cela, nous avons finalement réussi à extraire la mémoire.

[[Fichier:Lecturemem.jpg|vignette|Lecture de la mémoire|centré]]

L'utilitaire <code>binwalk</code>nous indique la présence d'un fichier pdf .

Nous avons décidé de remplacer le fichier pdf de base par un autre afin d'observer le comportement du temptale :
<syntaxhighlight lang="plaintext">
flashrom -p linux_spi:dev=/dev/spidev0.0 -w memory.bin
</syntaxhighlight>

Mais avant ça, nous avons fait en sorte de trouver un espace mémoire vide grâce à la commande <code>strings</code> :
<syntaxhighlight lang="plaintext">
strings -tx memory.bin
</syntaxhighlight>

[[Fichier:IMg.jpg|vignette|Visualisation de la mémoire, constat d'un espace mémoire disponible entre 0x136a2 et 0x16f8d|centré]]

Nous avons choisi de commencer à l'adresse 0x13700, donc en décimal 79616. Le fichier que nous avons choisi d'injecter fait 10,7 Ko.
<syntaxhighlight lang="plaintext">
dd if=example.pdf of=memory.bin bs=1 seek=79616 count=10771
</syntaxhighlight>Nous devons compléter la mémoire pour que l'écriture se fasse :
<syntaxhighlight lang="plaintext">
truncate -s 524288 memory.bin
</syntaxhighlight>

== Balance ==

=== Objectif du TP: ===
Nous devons analyser et compromettre la sécurité d'une balance connectée fournie par Nedis. Pour cela, nous avons installé l'application mobile associée, Nedis SmartLife, qui permet d'interagir avec la balance. [https://nedis.fr/fr-fr/smartlife Nedis SmartLife]

[[Fichier:WIFIHS10WT P50.jpg|vignette|Balance WiFi Nedis|néant]]

=== Problème réseau initial: ===
Lors des premières configurations, nous avons découvert que notre réseau Wi-Fi configuré en WPA EAP n’était pas compatible avec les exigences de la balance. Cette dernière nécessite une configuration en WPA PSK pour fonctionner correctement.

Malgré cette adaptation, nous avons rencontré des difficultés pour connecter nos téléphones à la balance. À la fin de l’appairage, la balance se déconnectait systématiquement avec le message d’erreur "Err2". D’après nos recherches, cette erreur est liée à un problème de réseau. Bien que la balance apparaisse dans l’application, elle n’envoie aucune donnée dans des conditions d’utilisation normale.
[[Fichier:Interface appli.jpg|néant|vignette|312x312px|interface de l'application]]
[[Fichier:Prob réseau appli.png|néant|vignette|333x333px|Erreur de connexion réseau]]

=== Diagnostic initial: ===
Pour identifier la source du problème, nous avons vérifié la communication entre les trois entités principales du système : le téléphone, la balance, et le point d’accès Wi-Fi. Nous avons utilisé le Wi-Fi préalablement configuré lors des séances précédentes et effectué des tests de connectivité :[[Fichier:Ping phone.jpg|vignette|Ping vers le téléphone : Réussi|néant]][[Fichier:Ping balance.jpg|vignette|Ping vers la balance : Réussi|néant]]

Ces résultats montrent que les appareils sont correctement connectés au réseau, ce qui écarte l’hypothèse d’un problème de connexion simple. Cependant, cela laisse supposer une potentielle perte des données pendant les échanges.

=== Analyse avancée avec Wireshark: ===
Pour approfondir le diagnostic, notre professeur nous a suggéré de mettre en place une analyse de trafic réseau en utilisant :

* Un injecteur PoE
* Le point d'accès PLIL
* Un commutateur réseau configuré pour effectuer un port mirroring.
* Wireshark en mode promiscuous pour capturer les paquets circulant dans le réseau.

Commande pour la configuration du port mirroring :
Switch(config)#monitor source interface fa 0/1 both
[[Fichier:Setup réseau.jpg|néant|vignette|Schéma du réseau]]

Grâce à cette configuration, nous avons pu observer que la balance établit bien une connexion avec un serveur cloud spécifique. Cependant, les données échangées restent inintelligibles, ce qui rend le problème difficile à cerner.

=== Observation architecture cloud: ===
[[Fichier:Arp.jpg|néant|vignette|379x379px|La balance qui prend l'adresse ip 172.26.145.206]]

La balance est identifiable dans les trames capturées par son adresse MAC : '''Express:16:2d:4c'''. Cette adresse MAC apparaît principalement dans des paquets ARP, confirmant que la balance effectue des requêtes pour résoudre des adresses IP ou répondre aux requêtes des autres équipements du réseau.
Nous remarquons que les paquets montrent une tentative de négociation TLS entre la balance et un serveur cloud.
[[Fichier:Host-cloud2.png|néant|vignette|584x584px|le serveur cloud]]
[[Fichier:Host-cloud.png|néant|vignette|580x580px|Le serveur cloud]]Ce qui signifie que la communication entre la balance et l’application ne se fait pas directement via le routeur local. Au lieu de cela, les données transitent par un serveur cloud distant. Cette architecture ajoute une couche d’abstraction qui complique le diagnostic.
[[Fichier:Wireshark 2.jpg|néant|vignette|393x393px|le handshake entre le téléphone ayant l'ip 172.26.145.211 et le serveur]]
[[Fichier:Interruption de la com.jpg|néant|vignette|389x389px|transfert des paquets par chiffrement TLS]]Bien que la balance semble bien résoudre les adresses et tenter d'établir une connexion avec le cloud, le message '''TCP RST''' indique probablement que l'une des deux parties rejette la connexion.
[[Fichier:TCP RST.jpg|néant|vignette|l'interruption de le communication TCP]]

=== Approche MITM (Man-in-the-Middle): ===
Un rejet du certificat présenté par le serveur peut être la cause de l'échec de la communication, donc pour mieux comprendre et intercepter les données, une approche MITM (Man-in-the-Middle) a été proposée. L’objectif est de configurer un serveur local qui imiterait le serveur cloud en utilisant un certificat TLS falsifié, permettant ainsi de capturer et d’analyser les communications chiffrées entre la balance et le serveur.

Avec l’équipe 5, nous avons configuré le réseau suivant:

VLAN 200: Réseau dédié à la balance, configuré pour se connecter à l’adresse 17.188.185.132 sur le port 5223.

VLAN 50: Réseau pour la machine locale à l’adresse 172.26.145.231, qui hébergera notre serveur MITM.

Le serveur est conçu pour générer et présenter un certificat TLS falsifié afin de se faire passer pour le serveur cloud légitime auprès de la balance.

<syntaxhighlight lang="python">

import socket
import ssl

# Chemins vers les certificats falsifiés
CERT_FILE = "fake_cert.pem"
KEY_FILE = "fake_key.pem"

# Création du socket serveur
server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_socket.bind(('0.0.0.0', 8443)) # Écoute sur le port 8443
server_socket.listen(5)

# Ajout de la couche TLS/SSL
ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
ssl_context.load_cert_chain(certfile=CERT_FILE, keyfile=KEY_FILE)

print("Serveur en attente de connexions...")

while True:
client_socket, addr = server_socket.accept()
print(f"Connexion acceptée de : {addr}")
try:
secure_socket = ssl_context.wrap_socket(client_socket, server_side=True)
print("TLS établi avec le client.")

# Communication avec le client
data = secure_socket.recv(1024)
print(f"Données reçues : {data.decode()}")

# Réponse du serveur
secure_socket.sendall(b"HTTP/1.1 200 OK\r\nContent-Type: text/plain\r\n\r\nFake Cloud Response")
except Exception as e:
print(f"Erreur TLS : {e}")
finally:
if 'secure_socket' in locals():
secure_socket.close()
</syntaxhighlight>

Génération des certificats falisifiés :

<syntaxhighlight lang="bash">
openssl req -new -x509 -key fake_key.pem -out fake_cert.pem -days 365 -subj "/C=FR/ST=Lille/L=Lille/O=Fake Cloud/OU=Dev/CN=localhost"
openssl genrsa -out fake_key.pem 2048
</syntaxhighlight>

Redirection de l'adresse de destination vers le serveur TCP :

<syntaxhighlight lang="bash">
sudo iptables -t nat -A PREROUTING -p tcp -d 3.121.210.75 --dport 443 -j DNAT --to-destination 127.0.0.1:8443
</syntaxhighlight>

=== Conclusion et étapes suivantes : ===
Problème actuel :

Bien que la configuration MITM soit en place, nous devons encore analyser en détail les paquets chiffrés interceptés pour identifier la cause exacte de l’échec de communication.

Étape suivante ou éventuelle:

* Déployer des outils pour décrypter le trafic TLS intercepté et approfondir l’analyse des données échangées. (obsolète)
* Repérer l'extension apk de l'application Nedis pour faire du reverse.
* transformer la zabeth17 en un routeur pour pouvoir rediriger les paquets vers son adresse ip
* déssouder la puce mémoire de la carte pour la tester à part.

SE5 IdO sécurité des objets 2024/2025 b4

2025-01-26T21:19:05Z

Ybenmbar :

== Wi-Fi ==

=== Création du serveur virtuel ===
- Création d'un serveur virtuel sur capbreton : '''SE5-yelqasta-ybenmbar'''
- Interface réseau dans le commutateur virtuel '''bridgeStudents''' avec :
* Adresse IPv4 : '''172.26.145.104'''
* Passerelle : '''172.26.145.251'''
- Interface réseau dans le VLAN 404 :
* Adresse IPv4 : '''172.16.4.1'''
* Masque : '''/24''' (255.255.255.0)
* VLAN : '''404'''

=== Configuration du point d'accès WiFi Cisco ===

- Définition du SSID '''VM_binome_4''' :
<syntaxhighlight lang="plaintext">
dot11 ssid VM_binome_4
vlan 404
authentication open eap eap_binome_4
authentication network-eap eap_binome_4
authentication key-management wpa
mbssid guest-mode
</syntaxhighlight>
- Configuration du VLAN 404 sur l'interface radio et l'interface Ethernet :
<syntaxhighlight lang="plaintext">
interface Dot11Radio0.404
encapsulation dot1Q 404
bridge-group 4
</syntaxhighlight>

<syntaxhighlight lang="plaintext">
interface GigabitEthernet0.404
encapsulation dot1Q 404
bridge-group 4
</syntaxhighlight>
- Configuration de l'accès au serveur FreeRADIUS :
<syntaxhighlight lang="plaintext">
aaa new-model
aaa authentication login eap_binome_4 group radius_binome_4
radius-server host 172.16.4.1 auth-port 1812 acct-port 1813 key glopglop
aaa group server radius radius_binome_4
server 172.16.4.1 auth-port 1812 acct-port 1813
</syntaxhighlight>

=== Configuration du serveur FreeRADIUS ===
- Installation de FreeRADIUS sur le serveur virtuel :
<syntaxhighlight lang="bash">
sudo apt update
sudo apt install freeradius freeradius-utils
</syntaxhighlight>
- Ajout de l'adresse IP du point d'accès Cisco dans le fichier de clients FreeRADIUS :
* Dans le fichier '''/etc/freeradius/3.0/clients.conf''' :
<syntaxhighlight lang="plaintext">
client wifi_ap {
ipaddr = 172.26.145.4
secret = glopglop
shortname = wifi_ap_binome_4
}
</syntaxhighlight>
- Configuration d'un utilisateur pour l'authentification WPA2-EAP :
* Dans le fichier '''/etc/freeradius/3.0/users''' :
<syntaxhighlight lang="plaintext">
mouss Cleartext-Password := "glopglop"
</syntaxhighlight>
- Activation de PEAP-MSCHAPv2 :
* Dans le fichier '''/etc/freeradius/3.0/mods-enabled/eap''' :
<syntaxhighlight lang="plaintext">
peap {
default_eap_type = mschapv2
}
</syntaxhighlight>

=== Serveur DHCP ===
- On a installé un serveur DHCP sur le serveur virtuel :
<syntaxhighlight lang="bash">
sudo apt install isc-dhcp-server
</syntaxhighlight>
- Configuration du serveur DHCP :
* Dans le fichier '''/etc/dhcp/dhcpd.conf''' :
<syntaxhighlight lang="plaintext">
subnet 172.16.4.0 netmask 255.255.255.0 {
range 172.16.4.100 172.16.4.200;
option routers 172.16.4.104;
option domain-name-servers 255.255.255.0;
}
</syntaxhighlight>
- Dans le fichier '''/etc/default/isc-dhcp-server''' :
<syntaxhighlight lang="plaintext">
INTERFACESv4="eth1"
</syntaxhighlight>

=== Serveur DNS minimal ===
* Dans '''/etc/bind/named.conf.options'''
<syntaxhighlight lang="plaintext">
...
forwarders {
172.26.188.12;
};
...
</syntaxhighlight>

=== Mascarade entre VLAN privé et routeur ===
- Activation du transfert IP sur le serveur virtuel :
<syntaxhighlight lang="bash">
systemctl -w net.ipv4.ip_forward=1
</syntaxhighlight>
- Ajout d'une règle de masquerade avec '''iptables''' :
<syntaxhighlight lang="bash">
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
</syntaxhighlight>

=== Passage de WPA-EAP à WPA-PSK ===
Afin d'utiliser notre balance connectée, nous devons mettre en place un point d'accès avec WPA-PSK et non WPA-EAP.

* Dans le point d'accès Cisco :

<pre>
no autentication open eap eap_binome_4
no authentication network-eap eap_binome_4
wpa-psk ascii [mdp]
</pre>

== Temptale USB ==

=== Identification des différentes puces ===

[[Fichier:Img cpsnts.jpg|vignette|Temptale ouvert]]

µC : Atmel AT91SAM7S256

Puce mémoire : Winbond 25X40CLNIG

SN74CBTLV3126 : commutateur de bus FET quadripolaire, probablement utilisé comme convertisseur de niveau

=== Modification du fichier pdf ===
Nous avons d'abord pensé à passer par le système de fichiers et plus précisément le fichier pdf pour hacker le Temptale.

=== Mémoire ===

Afin d'extraire les données de la mémoire, nous avons soudé des fils sur chaque broche de la puce mémoire. Elle fonctionne en SPI, nous l'avons alors connectée à la Raspberry Pi sur les broches correspondantes (SCK,MISO,MOSI,SS).
Grâce à l'utilitaire <code>flashrom</code>, nous pouvons depuis la Raspberry Pi extraire la mémoire flash.

[[Fichier:Capture broches.png|vignette|Schéma de la puce mémoire]]

Nous l'avons connecté de cette façon :

{| class="wikitable"
|+
!RPi
!Winbond 25X40CLNIG
|-
|CE0
|CS
|-
|MOSI
|DI
|-
|MISO
|DO
|-
|SCK
|CLK
|-
|3,3V
|VCC
|-
|GND
|GND
|}[[Fichier:Memoire soudee.jpg|vignette|Fils soudés sur les broches de la puce mémoire]]<syntaxhighlight lang="plaintext">
flashrom -p linux_spi:dev=/dev/spidev0.0
</syntaxhighlight>

Mais nous avons cette erreur :

<syntaxhighlight lang="plaintext">
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.
</syntaxhighlight>

Nous avons tenté de lancer le programme en lui spécifiant le modèle :
<syntaxhighlight lang="plaintext">
flashrom -p linux_spi:dev=/dev/spidev0.0 --chip W25X40
</syntaxhighlight>

Mais sans succès, nous suspectons un problème dans la soudure.

Nous avons alors par la suite dessoudé la flash et soudé un fil à chaque broche de celle-ci :

[[Fichier:7e4d8b63-7e49-4d2c-abbb-20ecb95b6820.jpg|vignette|Broches de la mémoire soudées aux fils|centré]]

Après cela, nous avons finalement réussi à extraire la mémoire.

[[Fichier:Lecturemem.jpg|vignette|Lecture de la mémoire|centré]]

L'utilitaire <code>binwalk</code>nous indique la présence d'un fichier pdf .

Nous avons décidé de remplacer le fichier pdf de base par un autre afin d'observer le comportement du temptale :
<syntaxhighlight lang="plaintext">
flashrom -p linux_spi:dev=/dev/spidev0.0 -w memory.bin
</syntaxhighlight>

Mais avant ça, nous avons fait en sorte de trouver un espace mémoire vide grâce à la commande <code>strings</code> :
<syntaxhighlight lang="plaintext">
strings -tx memory.bin
</syntaxhighlight>

[[Fichier:IMg.jpg|vignette|Visualisation de la mémoire, constat d'un espace mémoire disponible entre 0x136a2 et 0x16f8d]]

Nous avons choisi de commencer à l'adresse 0x13700, donc en décimal 79616. Le fichier fait 10,7 Ko.
<syntaxhighlight lang="plaintext">
dd if=example.pdf of=memory.bin bs=1 seek=79616 count=10771
</syntaxhighlight>Nous devons compléter la mémoire pour que l'écriture se fasse :
<syntaxhighlight lang="plaintext">
truncate -s 524288 memory.bin
</syntaxhighlight>

== Balance ==

=== Objectif du TP: ===
Nous devons analyser et compromettre la sécurité d'une balance connectée fournie par Nedis. Pour cela, nous avons installé l'application mobile associée, Nedis SmartLife, qui permet d'interagir avec la balance. [https://nedis.fr/fr-fr/smartlife Nedis SmartLife]

[[Fichier:WIFIHS10WT P50.jpg|vignette|Balance WiFi Nedis|néant]]

=== Problème réseau initial: ===
Lors des premières configurations, nous avons découvert que notre réseau Wi-Fi configuré en WPA EAP n’était pas compatible avec les exigences de la balance. Cette dernière nécessite une configuration en WPA PSK pour fonctionner correctement.

Malgré cette adaptation, nous avons rencontré des difficultés pour connecter nos téléphones à la balance. À la fin de l’appairage, la balance se déconnectait systématiquement avec le message d’erreur "Err2". D’après nos recherches, cette erreur est liée à un problème de réseau. Bien que la balance apparaisse dans l’application, elle n’envoie aucune donnée dans des conditions d’utilisation normale.
[[Fichier:Interface appli.jpg|néant|vignette|312x312px|interface de l'application]]
[[Fichier:Prob réseau appli.png|néant|vignette|333x333px|Erreur de connexion réseau]]

=== Diagnostic initial: ===
Pour identifier la source du problème, nous avons vérifié la communication entre les trois entités principales du système : le téléphone, la balance, et le point d’accès Wi-Fi. Nous avons utilisé le Wi-Fi préalablement configuré lors des séances précédentes et effectué des tests de connectivité :[[Fichier:Ping phone.jpg|vignette|Ping vers le téléphone : Réussi|néant]][[Fichier:Ping balance.jpg|vignette|Ping vers la balance : Réussi|néant]]

Ces résultats montrent que les appareils sont correctement connectés au réseau, ce qui écarte l’hypothèse d’un problème de connexion simple. Cependant, cela laisse supposer une potentielle perte des données pendant les échanges.

=== Analyse avancée avec Wireshark: ===
Pour approfondir le diagnostic, notre professeur nous a suggéré de mettre en place une analyse de trafic réseau en utilisant :

* Un injecteur PoE
* Le point d'accès PLIL
* Un commutateur réseau configuré pour effectuer un port mirroring.
* Wireshark en mode promiscuous pour capturer les paquets circulant dans le réseau.

Commande pour la configuration du port mirroring :
Switch(config)#monitor source interface fa 0/1 both
[[Fichier:Setup réseau.jpg|néant|vignette|Schéma du réseau]]

Grâce à cette configuration, nous avons pu observer que la balance établit bien une connexion avec un serveur cloud spécifique. Cependant, les données échangées restent inintelligibles, ce qui rend le problème difficile à cerner.

=== Observation architecture cloud: ===
[[Fichier:Arp.jpg|néant|vignette|379x379px|La balance qui prend l'adresse ip 172.26.145.206]]

La balance est identifiable dans les trames capturées par son adresse MAC : '''Express:16:2d:4c'''. Cette adresse MAC apparaît principalement dans des paquets ARP, confirmant que la balance effectue des requêtes pour résoudre des adresses IP ou répondre aux requêtes des autres équipements du réseau.
Nous remarquons que les paquets montrent une tentative de négociation TLS entre la balance et un serveur cloud.
[[Fichier:Host-cloud2.png|néant|vignette|584x584px|le serveur cloud]]
[[Fichier:Host-cloud.png|néant|vignette|580x580px|Le serveur cloud]]Ce qui signifie que la communication entre la balance et l’application ne se fait pas directement via le routeur local. Au lieu de cela, les données transitent par un serveur cloud distant. Cette architecture ajoute une couche d’abstraction qui complique le diagnostic.
[[Fichier:Wireshark 2.jpg|néant|vignette|393x393px|le handshake entre le téléphone ayant l'ip 172.26.145.211 et le serveur]]
[[Fichier:Interruption de la com.jpg|néant|vignette|389x389px|transfert des paquets par chiffrement TLS]]Bien que la balance semble bien résoudre les adresses et tenter d'établir une connexion avec le cloud, le message '''TCP RST''' indique probablement que l'une des deux parties rejette la connexion.
[[Fichier:TCP RST.jpg|néant|vignette|l'interruption de le communication TCP]]

=== Approche MITM (Man-in-the-Middle): ===
Un rejet du certificat présenté par le serveur peut être la cause de l'échec de la communication, donc pour mieux comprendre et intercepter les données, une approche MITM (Man-in-the-Middle) a été proposée. L’objectif est de configurer un serveur local qui imiterait le serveur cloud en utilisant un certificat TLS falsifié, permettant ainsi de capturer et d’analyser les communications chiffrées entre la balance et le serveur.

Avec l’équipe 5, nous avons configuré le réseau suivant:

VLAN 200: Réseau dédié à la balance, configuré pour se connecter à l’adresse 17.188.185.132 sur le port 5223.

VLAN 50: Réseau pour la machine locale à l’adresse 172.26.145.231, qui hébergera notre serveur MITM.

Le serveur est conçu pour générer et présenter un certificat TLS falsifié afin de se faire passer pour le serveur cloud légitime auprès de la balance.

<syntaxhighlight lang="python">

import socket
import ssl

# Chemins vers les certificats falsifiés
CERT_FILE = "fake_cert.pem"
KEY_FILE = "fake_key.pem"

# Création du socket serveur
server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_socket.bind(('0.0.0.0', 8443)) # Écoute sur le port 8443
server_socket.listen(5)

# Ajout de la couche TLS/SSL
ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
ssl_context.load_cert_chain(certfile=CERT_FILE, keyfile=KEY_FILE)

print("Serveur en attente de connexions...")

while True:
client_socket, addr = server_socket.accept()
print(f"Connexion acceptée de : {addr}")
try:
secure_socket = ssl_context.wrap_socket(client_socket, server_side=True)
print("TLS établi avec le client.")

# Communication avec le client
data = secure_socket.recv(1024)
print(f"Données reçues : {data.decode()}")

# Réponse du serveur
secure_socket.sendall(b"HTTP/1.1 200 OK\r\nContent-Type: text/plain\r\n\r\nFake Cloud Response")
except Exception as e:
print(f"Erreur TLS : {e}")
finally:
if 'secure_socket' in locals():
secure_socket.close()
</syntaxhighlight>

Génération des certificats falisifiés :

<syntaxhighlight lang="bash">
openssl req -new -x509 -key fake_key.pem -out fake_cert.pem -days 365 -subj "/C=FR/ST=Lille/L=Lille/O=Fake Cloud/OU=Dev/CN=localhost"
openssl genrsa -out fake_key.pem 2048
</syntaxhighlight>

Redirection de l'adresse de destination vers le serveur TCP :

<syntaxhighlight lang="bash">
sudo iptables -t nat -A PREROUTING -p tcp -d 3.121.210.75 --dport 443 -j DNAT --to-destination 127.0.0.1:8443
</syntaxhighlight>

=== Conclusion et étapes suivantes : ===
Problème actuel :

Bien que la configuration MITM soit en place, nous devons encore analyser en détail les paquets chiffrés interceptés pour identifier la cause exacte de l’échec de communication.

Étape suivante ou éventuelle:

* Déployer des outils pour décrypter le trafic TLS intercepté et approfondir l’analyse des données échangées. (obsolète)
* Repérer l'extension apk de l'application Nedis pour faire du reverse.
* transformer la zabeth17 en un routeur pour pouvoir rediriger les paquets vers son adresse ip
* déssouder la puce mémoire de la carte pour la tester à part.

SE5 IdO sécurité des objets 2024/2025 b4

2025-01-26T21:15:35Z

Ybenmbar : /* Mémoire */

== Wi-Fi ==

=== Création du serveur virtuel ===
- Création d'un serveur virtuel sur capbreton : '''SE5-yelqasta-ybenmbar'''
- Interface réseau dans le commutateur virtuel '''bridgeStudents''' avec :
* Adresse IPv4 : '''172.26.145.104'''
* Passerelle : '''172.26.145.251'''
- Interface réseau dans le VLAN 404 :
* Adresse IPv4 : '''172.16.4.1'''
* Masque : '''/24''' (255.255.255.0)
* VLAN : '''404'''

=== Configuration du point d'accès WiFi Cisco ===

- Définition du SSID '''VM_binome_4''' :
<syntaxhighlight lang="plaintext">
dot11 ssid VM_binome_4
vlan 404
authentication open eap eap_binome_4
authentication network-eap eap_binome_4
authentication key-management wpa
mbssid guest-mode
</syntaxhighlight>
- Configuration du VLAN 404 sur l'interface radio et l'interface Ethernet :
<syntaxhighlight lang="plaintext">
interface Dot11Radio0.404
encapsulation dot1Q 404
bridge-group 4
</syntaxhighlight>

<syntaxhighlight lang="plaintext">
interface GigabitEthernet0.404
encapsulation dot1Q 404
bridge-group 4
</syntaxhighlight>
- Configuration de l'accès au serveur FreeRADIUS :
<syntaxhighlight lang="plaintext">
aaa new-model
aaa authentication login eap_binome_4 group radius_binome_4
radius-server host 172.16.4.1 auth-port 1812 acct-port 1813 key glopglop
aaa group server radius radius_binome_4
server 172.16.4.1 auth-port 1812 acct-port 1813
</syntaxhighlight>

=== Configuration du serveur FreeRADIUS ===
- Installation de FreeRADIUS sur le serveur virtuel :
<syntaxhighlight lang="bash">
sudo apt update
sudo apt install freeradius freeradius-utils
</syntaxhighlight>
- Ajout de l'adresse IP du point d'accès Cisco dans le fichier de clients FreeRADIUS :
* Dans le fichier '''/etc/freeradius/3.0/clients.conf''' :
<syntaxhighlight lang="plaintext">
client wifi_ap {
ipaddr = 172.26.145.4
secret = glopglop
shortname = wifi_ap_binome_4
}
</syntaxhighlight>
- Configuration d'un utilisateur pour l'authentification WPA2-EAP :
* Dans le fichier '''/etc/freeradius/3.0/users''' :
<syntaxhighlight lang="plaintext">
mouss Cleartext-Password := "glopglop"
</syntaxhighlight>
- Activation de PEAP-MSCHAPv2 :
* Dans le fichier '''/etc/freeradius/3.0/mods-enabled/eap''' :
<syntaxhighlight lang="plaintext">
peap {
default_eap_type = mschapv2
}
</syntaxhighlight>

=== Serveur DHCP ===
- On a installé un serveur DHCP sur le serveur virtuel :
<syntaxhighlight lang="bash">
sudo apt install isc-dhcp-server
</syntaxhighlight>
- Configuration du serveur DHCP :
* Dans le fichier '''/etc/dhcp/dhcpd.conf''' :
<syntaxhighlight lang="plaintext">
subnet 172.16.4.0 netmask 255.255.255.0 {
range 172.16.4.100 172.16.4.200;
option routers 172.16.4.104;
option domain-name-servers 255.255.255.0;
}
</syntaxhighlight>
- Dans le fichier '''/etc/default/isc-dhcp-server''' :
<syntaxhighlight lang="plaintext">
INTERFACESv4="eth1"
</syntaxhighlight>

=== Serveur DNS minimal ===
* Dans '''/etc/bind/named.conf.options'''
<syntaxhighlight lang="plaintext">
...
forwarders {
172.26.188.12;
};
...
</syntaxhighlight>

=== Mascarade entre VLAN privé et routeur ===
- Activation du transfert IP sur le serveur virtuel :
<syntaxhighlight lang="bash">
systemctl -w net.ipv4.ip_forward=1
</syntaxhighlight>
- Ajout d'une règle de masquerade avec '''iptables''' :
<syntaxhighlight lang="bash">
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
</syntaxhighlight>

=== Passage de WPA-EAP à WPA-PSK ===
Afin d'utiliser notre balance connectée, nous devons mettre en place un point d'accès avec WPA-PSK et non WPA-EAP.

* Dans le point d'accès Cisco :

<pre>
no autentication open eap eap_binome_4
no authentication network-eap eap_binome_4
wpa-psk ascii [mdp]
</pre>

== Temptale USB ==

=== Identification des différentes puces ===

[[Fichier:Img cpsnts.jpg|vignette|Temptale ouvert]]

µC : Atmel AT91SAM7S256

Puce mémoire : Winbond 25X40CLNIG

SN74CBTLV3126 : commutateur de bus FET quadripolaire, probablement utilisé comme convertisseur de niveau

=== Modification du fichier pdf ===
Nous avons d'abord pensé à passer par le système de fichiers et plus précisément le fichier pdf pour hacker le Temptale.

=== Mémoire ===

Afin d'extraire les données de la mémoire, nous avons soudé des fils sur chaque broche de la puce mémoire. Elle fonctionne en SPI, nous l'avons alors connectée à la Raspberry Pi sur les broches correspondantes (SCK,MISO,MOSI,SS).
Grâce à l'utilitaire <code>flashrom</code>, nous pouvons depuis la Raspberry Pi extraire la mémoire flash.

[[Fichier:Capture broches.png|vignette|Schéma de la puce mémoire]]

Nous l'avons connecté de cette façon :

{| class="wikitable"
|+
!RPi
!Winbond 25X40CLNIG
|-
|CE0
|CS
|-
|MOSI
|DI
|-
|MISO
|DO
|-
|SCK
|CLK
|-
|3,3V
|VCC
|-
|GND
|GND
|}[[Fichier:Memoire soudee.jpg|vignette|Fils soudés sur les broches de la puce mémoire]]<syntaxhighlight lang="plaintext">
flashrom -p linux_spi:dev=/dev/spidev0.0
</syntaxhighlight>

Mais nous avons cette erreur :

<syntaxhighlight lang="plaintext">
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.
</syntaxhighlight>

Nous avons tenté de lancer le programme en lui spécifiant le modèle :
<syntaxhighlight lang="plaintext">
flashrom -p linux_spi:dev=/dev/spidev0.0 --chip W25X40
</syntaxhighlight>

Mais sans succès, nous suspectons un problème dans la soudure.

Nous avons alors par la suite dessoudé la flash et soudé un fil à chaque broche de celle-ci :

[[Fichier:7e4d8b63-7e49-4d2c-abbb-20ecb95b6820.jpg|vignette|Broches de la mémoire soudées aux fils]]

Après cela, nous avons finalement réussi à extraire la mémoire.

[[Fichier:Lecturemem.jpg|vignette|Lecture de la mémoire]]

L'utilitaire binwalk nous indique la présence d'un fichier pdf :

Nous avons décidé de remplacer le fichier pdf de base par un autre afin d'observer le comportement du temptale :
<syntaxhighlight lang="plaintext">
flashrom -p linux_spi:dev=/dev/spidev0.0 -w memory.bin
</syntaxhighlight>

Mais avant ça, nous avons fait en sorte de trouver un espace mémoire vide grâce à la commande <code>strings</code> :
<syntaxhighlight lang="plaintext">
strings -tx memory.bin
</syntaxhighlight>

[[Fichier:IMg.jpg|vignette|Visualisation de la mémoire, constat d'un espace mémoire disponible entre 0x136a2 et 0x16f8d]]

Nous avons choisi de commencer à l'adresse 0x13700, donc en décimal 79616. Le fichier fait 10,7 Ko.
<syntaxhighlight lang="plaintext">
dd if=example.pdf of=memory.bin bs=1 seek=79616 count=10771
</syntaxhighlight>Nous devons compléter la mémoire pour que l'écriture se fasse :
<syntaxhighlight lang="plaintext">
truncate -s 524288 memory.bin
</syntaxhighlight>

== Balance ==

=== Objectif du TP: ===
Nous devons analyser et compromettre la sécurité d'une balance connectée fournie par Nedis. Pour cela, nous avons installé l'application mobile associée, Nedis SmartLife, qui permet d'interagir avec la balance. [https://nedis.fr/fr-fr/smartlife Nedis SmartLife]

[[Fichier:WIFIHS10WT P50.jpg|vignette|Balance WiFi Nedis|néant]]

=== Problème réseau initial: ===
Lors des premières configurations, nous avons découvert que notre réseau Wi-Fi configuré en WPA EAP n’était pas compatible avec les exigences de la balance. Cette dernière nécessite une configuration en WPA PSK pour fonctionner correctement.

Malgré cette adaptation, nous avons rencontré des difficultés pour connecter nos téléphones à la balance. À la fin de l’appairage, la balance se déconnectait systématiquement avec le message d’erreur "Err2". D’après nos recherches, cette erreur est liée à un problème de réseau. Bien que la balance apparaisse dans l’application, elle n’envoie aucune donnée dans des conditions d’utilisation normale.
[[Fichier:Interface appli.jpg|néant|vignette|312x312px|interface de l'application]]
[[Fichier:Prob réseau appli.png|néant|vignette|333x333px|Erreur de connexion réseau]]

=== Diagnostic initial: ===
Pour identifier la source du problème, nous avons vérifié la communication entre les trois entités principales du système : le téléphone, la balance, et le point d’accès Wi-Fi. Nous avons utilisé le Wi-Fi préalablement configuré lors des séances précédentes et effectué des tests de connectivité :[[Fichier:Ping phone.jpg|vignette|Ping vers le téléphone : Réussi|néant]][[Fichier:Ping balance.jpg|vignette|Ping vers la balance : Réussi|néant]]

Ces résultats montrent que les appareils sont correctement connectés au réseau, ce qui écarte l’hypothèse d’un problème de connexion simple. Cependant, cela laisse supposer une potentielle perte des données pendant les échanges.

=== Analyse avancée avec Wireshark: ===
Pour approfondir le diagnostic, notre professeur nous a suggéré de mettre en place une analyse de trafic réseau en utilisant :

* Un injecteur PoE
* Le point d'accès PLIL
* Un commutateur réseau configuré pour effectuer un port mirroring.
* Wireshark en mode promiscuous pour capturer les paquets circulant dans le réseau.

Commande pour la configuration du port mirroring :
Switch(config)#monitor source interface fa 0/1 both
[[Fichier:Setup réseau.jpg|néant|vignette|Schéma du réseau]]

Grâce à cette configuration, nous avons pu observer que la balance établit bien une connexion avec un serveur cloud spécifique. Cependant, les données échangées restent inintelligibles, ce qui rend le problème difficile à cerner.

=== Observation architecture cloud: ===
[[Fichier:Arp.jpg|néant|vignette|379x379px|La balance qui prend l'adresse ip 172.26.145.206]]

La balance est identifiable dans les trames capturées par son adresse MAC : '''Express:16:2d:4c'''. Cette adresse MAC apparaît principalement dans des paquets ARP, confirmant que la balance effectue des requêtes pour résoudre des adresses IP ou répondre aux requêtes des autres équipements du réseau.
Nous remarquons que les paquets montrent une tentative de négociation TLS entre la balance et un serveur cloud.
[[Fichier:Host-cloud2.png|néant|vignette|584x584px|le serveur cloud]]
[[Fichier:Host-cloud.png|néant|vignette|580x580px|Le serveur cloud]]Ce qui signifie que la communication entre la balance et l’application ne se fait pas directement via le routeur local. Au lieu de cela, les données transitent par un serveur cloud distant. Cette architecture ajoute une couche d’abstraction qui complique le diagnostic.
[[Fichier:Wireshark 2.jpg|néant|vignette|393x393px|le handshake entre le téléphone ayant l'ip 172.26.145.211 et le serveur]]
[[Fichier:Interruption de la com.jpg|néant|vignette|389x389px|transfert des paquets par chiffrement TLS]]Bien que la balance semble bien résoudre les adresses et tenter d'établir une connexion avec le cloud, le message '''TCP RST''' indique probablement que l'une des deux parties rejette la connexion.
[[Fichier:TCP RST.jpg|néant|vignette|l'interruption de le communication TCP]]

=== Approche MITM (Man-in-the-Middle): ===
Un rejet du certificat présenté par le serveur peut être la cause de l'échec de la communication, donc pour mieux comprendre et intercepter les données, une approche MITM (Man-in-the-Middle) a été proposée. L’objectif est de configurer un serveur local qui imiterait le serveur cloud en utilisant un certificat TLS falsifié, permettant ainsi de capturer et d’analyser les communications chiffrées entre la balance et le serveur.

Avec l’équipe 5, nous avons configuré le réseau suivant:

VLAN 200: Réseau dédié à la balance, configuré pour se connecter à l’adresse 17.188.185.132 sur le port 5223.

VLAN 50: Réseau pour la machine locale à l’adresse 172.26.145.231, qui hébergera notre serveur MITM.

Le serveur est conçu pour générer et présenter un certificat TLS falsifié afin de se faire passer pour le serveur cloud légitime auprès de la balance.

<syntaxhighlight lang="python">

import socket
import ssl

# Chemins vers les certificats falsifiés
CERT_FILE = "fake_cert.pem"
KEY_FILE = "fake_key.pem"

# Création du socket serveur
server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_socket.bind(('0.0.0.0', 8443)) # Écoute sur le port 8443
server_socket.listen(5)

# Ajout de la couche TLS/SSL
ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
ssl_context.load_cert_chain(certfile=CERT_FILE, keyfile=KEY_FILE)

print("Serveur en attente de connexions...")

while True:
client_socket, addr = server_socket.accept()
print(f"Connexion acceptée de : {addr}")
try:
secure_socket = ssl_context.wrap_socket(client_socket, server_side=True)
print("TLS établi avec le client.")

# Communication avec le client
data = secure_socket.recv(1024)
print(f"Données reçues : {data.decode()}")

# Réponse du serveur
secure_socket.sendall(b"HTTP/1.1 200 OK\r\nContent-Type: text/plain\r\n\r\nFake Cloud Response")
except Exception as e:
print(f"Erreur TLS : {e}")
finally:
if 'secure_socket' in locals():
secure_socket.close()
</syntaxhighlight>

Génération des certificats falisifiés :

<syntaxhighlight lang="bash">
openssl req -new -x509 -key fake_key.pem -out fake_cert.pem -days 365 -subj "/C=FR/ST=Lille/L=Lille/O=Fake Cloud/OU=Dev/CN=localhost"
openssl genrsa -out fake_key.pem 2048
</syntaxhighlight>

Redirection de l'adresse de destination vers le serveur TCP :

<syntaxhighlight lang="bash">
sudo iptables -t nat -A PREROUTING -p tcp -d 3.121.210.75 --dport 443 -j DNAT --to-destination 127.0.0.1:8443
</syntaxhighlight>

=== Conclusion et étapes suivantes : ===
Problème actuel :

Bien que la configuration MITM soit en place, nous devons encore analyser en détail les paquets chiffrés interceptés pour identifier la cause exacte de l’échec de communication.

Étape suivante ou éventuelle:

* Déployer des outils pour décrypter le trafic TLS intercepté et approfondir l’analyse des données échangées. (obsolète)
* Repérer l'extension apk de l'application Nedis pour faire du reverse.
* transformer la zabeth17 en un routeur pour pouvoir rediriger les paquets vers son adresse ip
* déssouder la puce mémoire de la carte pour la tester à part.

SE5 IdO sécurité des objets 2024/2025 b4

2025-01-26T21:12:06Z

Ybenmbar : /* Mémoire */

== Wi-Fi ==

=== Création du serveur virtuel ===
- Création d'un serveur virtuel sur capbreton : '''SE5-yelqasta-ybenmbar'''
- Interface réseau dans le commutateur virtuel '''bridgeStudents''' avec :
* Adresse IPv4 : '''172.26.145.104'''
* Passerelle : '''172.26.145.251'''
- Interface réseau dans le VLAN 404 :
* Adresse IPv4 : '''172.16.4.1'''
* Masque : '''/24''' (255.255.255.0)
* VLAN : '''404'''

=== Configuration du point d'accès WiFi Cisco ===

- Définition du SSID '''VM_binome_4''' :
<syntaxhighlight lang="plaintext">
dot11 ssid VM_binome_4
vlan 404
authentication open eap eap_binome_4
authentication network-eap eap_binome_4
authentication key-management wpa
mbssid guest-mode
</syntaxhighlight>
- Configuration du VLAN 404 sur l'interface radio et l'interface Ethernet :
<syntaxhighlight lang="plaintext">
interface Dot11Radio0.404
encapsulation dot1Q 404
bridge-group 4
</syntaxhighlight>

<syntaxhighlight lang="plaintext">
interface GigabitEthernet0.404
encapsulation dot1Q 404
bridge-group 4
</syntaxhighlight>
- Configuration de l'accès au serveur FreeRADIUS :
<syntaxhighlight lang="plaintext">
aaa new-model
aaa authentication login eap_binome_4 group radius_binome_4
radius-server host 172.16.4.1 auth-port 1812 acct-port 1813 key glopglop
aaa group server radius radius_binome_4
server 172.16.4.1 auth-port 1812 acct-port 1813
</syntaxhighlight>

=== Configuration du serveur FreeRADIUS ===
- Installation de FreeRADIUS sur le serveur virtuel :
<syntaxhighlight lang="bash">
sudo apt update
sudo apt install freeradius freeradius-utils
</syntaxhighlight>
- Ajout de l'adresse IP du point d'accès Cisco dans le fichier de clients FreeRADIUS :
* Dans le fichier '''/etc/freeradius/3.0/clients.conf''' :
<syntaxhighlight lang="plaintext">
client wifi_ap {
ipaddr = 172.26.145.4
secret = glopglop
shortname = wifi_ap_binome_4
}
</syntaxhighlight>
- Configuration d'un utilisateur pour l'authentification WPA2-EAP :
* Dans le fichier '''/etc/freeradius/3.0/users''' :
<syntaxhighlight lang="plaintext">
mouss Cleartext-Password := "glopglop"
</syntaxhighlight>
- Activation de PEAP-MSCHAPv2 :
* Dans le fichier '''/etc/freeradius/3.0/mods-enabled/eap''' :
<syntaxhighlight lang="plaintext">
peap {
default_eap_type = mschapv2
}
</syntaxhighlight>

=== Serveur DHCP ===
- On a installé un serveur DHCP sur le serveur virtuel :
<syntaxhighlight lang="bash">
sudo apt install isc-dhcp-server
</syntaxhighlight>
- Configuration du serveur DHCP :
* Dans le fichier '''/etc/dhcp/dhcpd.conf''' :
<syntaxhighlight lang="plaintext">
subnet 172.16.4.0 netmask 255.255.255.0 {
range 172.16.4.100 172.16.4.200;
option routers 172.16.4.104;
option domain-name-servers 255.255.255.0;
}
</syntaxhighlight>
- Dans le fichier '''/etc/default/isc-dhcp-server''' :
<syntaxhighlight lang="plaintext">
INTERFACESv4="eth1"
</syntaxhighlight>

=== Serveur DNS minimal ===
* Dans '''/etc/bind/named.conf.options'''
<syntaxhighlight lang="plaintext">
...
forwarders {
172.26.188.12;
};
...
</syntaxhighlight>

=== Mascarade entre VLAN privé et routeur ===
- Activation du transfert IP sur le serveur virtuel :
<syntaxhighlight lang="bash">
systemctl -w net.ipv4.ip_forward=1
</syntaxhighlight>
- Ajout d'une règle de masquerade avec '''iptables''' :
<syntaxhighlight lang="bash">
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
</syntaxhighlight>

=== Passage de WPA-EAP à WPA-PSK ===
Afin d'utiliser notre balance connectée, nous devons mettre en place un point d'accès avec WPA-PSK et non WPA-EAP.

* Dans le point d'accès Cisco :

<pre>
no autentication open eap eap_binome_4
no authentication network-eap eap_binome_4
wpa-psk ascii [mdp]
</pre>

== Temptale USB ==

=== Identification des différentes puces ===

[[Fichier:Img cpsnts.jpg|vignette|Temptale ouvert]]

µC : Atmel AT91SAM7S256

Puce mémoire : Winbond 25X40CLNIG

SN74CBTLV3126 : commutateur de bus FET quadripolaire, probablement utilisé comme convertisseur de niveau

=== Modification du fichier pdf ===
Nous avons d'abord pensé à passer par le système de fichiers et plus précisément le fichier pdf pour hacker le Temptale.

=== Mémoire ===

Afin d'extraire les données de la mémoire, nous avons soudé des fils sur chaque broche de la puce mémoire. Elle fonctionne en SPI, nous l'avons alors connectée à la Raspberry Pi sur les broches correspondantes (SCK,MISO,MOSI,SS).
Grâce à l'utilitaire <code>flashrom</code>, nous pouvons depuis la Raspberry Pi extraire la mémoire flash.

[[Fichier:Capture broches.png|vignette|Schéma de la puce mémoire]]

Nous l'avons connecté de cette façon :

{| class="wikitable"
|+
!RPi
!Winbond 25X40CLNIG
|-
|CE0
|CS
|-
|MOSI
|DI
|-
|MISO
|DO
|-
|SCK
|CLK
|-
|3,3V
|VCC
|-
|GND
|GND
|}[[Fichier:Memoire soudee.jpg|vignette|Fils soudés sur les broches de la puce mémoire]]<syntaxhighlight lang="plaintext">
flashrom -p linux_spi:dev=/dev/spidev0.0
</syntaxhighlight>

Mais nous avons cette erreur :

<syntaxhighlight lang="plaintext">
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.
</syntaxhighlight>

Nous avons tenté de lancer le programme en lui spécifiant le modèle :
<syntaxhighlight lang="plaintext">
flashrom -p linux_spi:dev=/dev/spidev0.0 --chip W25X40
</syntaxhighlight>

Mais sans succès, nous suspectons un problème dans la soudure.

Nous avons alors par la suite dessoudé la flash et soudé un fil à chaque broche de celle-ci :

[[Fichier:7e4d8b63-7e49-4d2c-abbb-20ecb95b6820.jpg|vignette|Broches de la mémoire soudées aux fils]]

Après cela, nous avons finalement réussi à extraire la mémoire.

[[Fichier:Lecturemem.jpg|vignette|Lecture de la mémoire]]

L'utilitaire binwalk nous indique la présence d'un fichier pdf :

Nous avons décidé de remplacer le fichier pdf de base par un autre afin d'observer le comportement du temptale :
<syntaxhighlight lang="plaintext">
flashrom -p linux_spi:dev=/dev/spidev0.0 -w memory.bin
</syntaxhighlight>

Mais avant ça, nous avons fait en sorte de trouver un espace mémoire vide grâce à la commande <code>strings</code> :
<syntaxhighlight lang="plaintext">
strings -tx memory.bin
</syntaxhighlight>

[[Fichier:IMg.jpg|vignette|Visualisation de la mémoire, constat d'un espace mémoire disponible entre 0x136a2 et 0x16f8d]]

Nous avons choisi de commencer à l'adresse 0x13700, donc en décimal 79616. Le fichier fait 10,7 Ko.
<syntaxhighlight lang="plaintext">
dd if=example.pdf of=memory4.bin bs=1 seek=79616 count=10771
</syntaxhighlight>Nous devons compléter la mémoire pour que l'écriture se fasse :
<syntaxhighlight lang="plaintext">
truncate -s 524288 memory4.bin
</syntaxhighlight>

== Balance ==

=== Objectif du TP: ===
Nous devons analyser et compromettre la sécurité d'une balance connectée fournie par Nedis. Pour cela, nous avons installé l'application mobile associée, Nedis SmartLife, qui permet d'interagir avec la balance. [https://nedis.fr/fr-fr/smartlife Nedis SmartLife]

[[Fichier:WIFIHS10WT P50.jpg|vignette|Balance WiFi Nedis|néant]]

=== Problème réseau initial: ===
Lors des premières configurations, nous avons découvert que notre réseau Wi-Fi configuré en WPA EAP n’était pas compatible avec les exigences de la balance. Cette dernière nécessite une configuration en WPA PSK pour fonctionner correctement.

Malgré cette adaptation, nous avons rencontré des difficultés pour connecter nos téléphones à la balance. À la fin de l’appairage, la balance se déconnectait systématiquement avec le message d’erreur "Err2". D’après nos recherches, cette erreur est liée à un problème de réseau. Bien que la balance apparaisse dans l’application, elle n’envoie aucune donnée dans des conditions d’utilisation normale.
[[Fichier:Interface appli.jpg|néant|vignette|312x312px|interface de l'application]]
[[Fichier:Prob réseau appli.png|néant|vignette|333x333px|Erreur de connexion réseau]]

=== Diagnostic initial: ===
Pour identifier la source du problème, nous avons vérifié la communication entre les trois entités principales du système : le téléphone, la balance, et le point d’accès Wi-Fi. Nous avons utilisé le Wi-Fi préalablement configuré lors des séances précédentes et effectué des tests de connectivité :[[Fichier:Ping phone.jpg|vignette|Ping vers le téléphone : Réussi|néant]][[Fichier:Ping balance.jpg|vignette|Ping vers la balance : Réussi|néant]]

Ces résultats montrent que les appareils sont correctement connectés au réseau, ce qui écarte l’hypothèse d’un problème de connexion simple. Cependant, cela laisse supposer une potentielle perte des données pendant les échanges.

=== Analyse avancée avec Wireshark: ===
Pour approfondir le diagnostic, notre professeur nous a suggéré de mettre en place une analyse de trafic réseau en utilisant :

* Un injecteur PoE
* Le point d'accès PLIL
* Un commutateur réseau configuré pour effectuer un port mirroring.
* Wireshark en mode promiscuous pour capturer les paquets circulant dans le réseau.

Commande pour la configuration du port mirroring :
Switch(config)#monitor source interface fa 0/1 both
[[Fichier:Setup réseau.jpg|néant|vignette|Schéma du réseau]]

Grâce à cette configuration, nous avons pu observer que la balance établit bien une connexion avec un serveur cloud spécifique. Cependant, les données échangées restent inintelligibles, ce qui rend le problème difficile à cerner.

=== Observation architecture cloud: ===
[[Fichier:Arp.jpg|néant|vignette|379x379px|La balance qui prend l'adresse ip 172.26.145.206]]

La balance est identifiable dans les trames capturées par son adresse MAC : '''Express:16:2d:4c'''. Cette adresse MAC apparaît principalement dans des paquets ARP, confirmant que la balance effectue des requêtes pour résoudre des adresses IP ou répondre aux requêtes des autres équipements du réseau.
Nous remarquons que les paquets montrent une tentative de négociation TLS entre la balance et un serveur cloud.
[[Fichier:Host-cloud2.png|néant|vignette|584x584px|le serveur cloud]]
[[Fichier:Host-cloud.png|néant|vignette|580x580px|Le serveur cloud]]Ce qui signifie que la communication entre la balance et l’application ne se fait pas directement via le routeur local. Au lieu de cela, les données transitent par un serveur cloud distant. Cette architecture ajoute une couche d’abstraction qui complique le diagnostic.
[[Fichier:Wireshark 2.jpg|néant|vignette|393x393px|le handshake entre le téléphone ayant l'ip 172.26.145.211 et le serveur]]
[[Fichier:Interruption de la com.jpg|néant|vignette|389x389px|transfert des paquets par chiffrement TLS]]Bien que la balance semble bien résoudre les adresses et tenter d'établir une connexion avec le cloud, le message '''TCP RST''' indique probablement que l'une des deux parties rejette la connexion.
[[Fichier:TCP RST.jpg|néant|vignette|l'interruption de le communication TCP]]

=== Approche MITM (Man-in-the-Middle): ===
Un rejet du certificat présenté par le serveur peut être la cause de l'échec de la communication, donc pour mieux comprendre et intercepter les données, une approche MITM (Man-in-the-Middle) a été proposée. L’objectif est de configurer un serveur local qui imiterait le serveur cloud en utilisant un certificat TLS falsifié, permettant ainsi de capturer et d’analyser les communications chiffrées entre la balance et le serveur.

Avec l’équipe 5, nous avons configuré le réseau suivant:

VLAN 200: Réseau dédié à la balance, configuré pour se connecter à l’adresse 17.188.185.132 sur le port 5223.

VLAN 50: Réseau pour la machine locale à l’adresse 172.26.145.231, qui hébergera notre serveur MITM.

Le serveur est conçu pour générer et présenter un certificat TLS falsifié afin de se faire passer pour le serveur cloud légitime auprès de la balance.

<syntaxhighlight lang="python">

import socket
import ssl

# Chemins vers les certificats falsifiés
CERT_FILE = "fake_cert.pem"
KEY_FILE = "fake_key.pem"

# Création du socket serveur
server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_socket.bind(('0.0.0.0', 8443)) # Écoute sur le port 8443
server_socket.listen(5)

# Ajout de la couche TLS/SSL
ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
ssl_context.load_cert_chain(certfile=CERT_FILE, keyfile=KEY_FILE)

print("Serveur en attente de connexions...")

while True:
client_socket, addr = server_socket.accept()
print(f"Connexion acceptée de : {addr}")
try:
secure_socket = ssl_context.wrap_socket(client_socket, server_side=True)
print("TLS établi avec le client.")

# Communication avec le client
data = secure_socket.recv(1024)
print(f"Données reçues : {data.decode()}")

# Réponse du serveur
secure_socket.sendall(b"HTTP/1.1 200 OK\r\nContent-Type: text/plain\r\n\r\nFake Cloud Response")
except Exception as e:
print(f"Erreur TLS : {e}")
finally:
if 'secure_socket' in locals():
secure_socket.close()
</syntaxhighlight>

Génération des certificats falisifiés :

<syntaxhighlight lang="bash">
openssl req -new -x509 -key fake_key.pem -out fake_cert.pem -days 365 -subj "/C=FR/ST=Lille/L=Lille/O=Fake Cloud/OU=Dev/CN=localhost"
openssl genrsa -out fake_key.pem 2048
</syntaxhighlight>

Redirection de l'adresse de destination vers le serveur TCP :

<syntaxhighlight lang="bash">
sudo iptables -t nat -A PREROUTING -p tcp -d 3.121.210.75 --dport 443 -j DNAT --to-destination 127.0.0.1:8443
</syntaxhighlight>

=== Conclusion et étapes suivantes : ===
Problème actuel :

Bien que la configuration MITM soit en place, nous devons encore analyser en détail les paquets chiffrés interceptés pour identifier la cause exacte de l’échec de communication.

Étape suivante ou éventuelle:

* Déployer des outils pour décrypter le trafic TLS intercepté et approfondir l’analyse des données échangées. (obsolète)
* Repérer l'extension apk de l'application Nedis pour faire du reverse.
* transformer la zabeth17 en un routeur pour pouvoir rediriger les paquets vers son adresse ip
* déssouder la puce mémoire de la carte pour la tester à part.