SE5 IdO sécurité des objets 2025/2026 b2 - Historique des versions

Kelbachi : /* 2. Approche Matérielle */

2026-01-24T22:31:40Z

2. Approche Matérielle

← Version précédente		Version du 24 janvier 2026 à 22:31
Ligne 449 :		Ligne 449 :

	En effectuant une inspection physique du détecteur de fumée (démontage du boîtier), j'ai repéré sur le circuit imprimé (PCB) une série de pistes et de broches non soudées ressemblant fortement à un port de programmation ou de débogage.		En effectuant une inspection physique du détecteur de fumée (démontage du boîtier), j'ai repéré sur le circuit imprimé (PCB) une série de pistes et de broches non soudées ressemblant fortement à un port de programmation ou de débogage.
	[[Fichier:1000096446.jpg\|gauche\|~~vignette~~\|~~398x398px~~]]		[[Fichier:1000096446.jpg\|gauche\|456x456px\|sans_cadre]]
	[[Fichier:1000096443.jpg\|centré\|~~vignette~~\|~~407x407px~~]]		[[Fichier:1000096443.jpg\|centré\|419x419px\|sans_cadre]]

Kelbachi : /* 2.3 Analyse des Trames (Reverse Engineering) */

2026-01-24T22:30:34Z

2.3 Analyse des Trames (Reverse Engineering)

← Version précédente		Version du 24 janvier 2026 à 22:30
Ligne 499 :		Ligne 499 :
	Lorsque j'appuie sur le bouton de test (Reset), le comportement change radicalement :		Lorsque j'appuie sur le bouton de test (Reset), le comportement change radicalement :
	* La fréquence des paquets augmente (flood).		* La fréquence des paquets augmente (flood).
	* L'octet de donnée change de `04` à ~~`24`~~.		* L'octet de donnée change de 04 à 23.
	* Un nouveau DPID ~~(Data Point ID) `~~54` apparaît brièvement.		* Un nouveau DPID 54 apparaît brièvement.
	[[Fichier:Screenshot 2025-12-16 17-56-33.png\|sans_cadre\|547x547px]]		[[Fichier:Screenshot 2025-12-16 17-56-33.png\|sans_cadre\|547x547px]]

Kelbachi : /* 2.4 Validation Physique à l'Oscilloscope */

2026-01-24T22:29:28Z

2.4 Validation Physique à l'Oscilloscope

← Version précédente		Version du 24 janvier 2026 à 22:29
Ligne 316 :		Ligne 316 :
	'''Configuration Réseau (Lien avec le Cisco) :'''		'''Configuration Réseau (Lien avec le Cisco) :'''

	Pour que cette VM puisse communiquer avec notre infrastructure (VLAN, Accès Internet via notre passerelle), ~~nous avons~~ dû modifier la configuration réseau pour la lier au pont `bridgeStudents` et lui attribuer une IP statique dans notre plage.		Pour que cette VM puisse communiquer avec notre infrastructure (VLAN, Accès Internet via notre passerelle), j'ai dû modifier la configuration réseau pour la lier au pont `bridgeStudents` et lui attribuer une IP statique dans notre plage.

	Modification du fichier <code>/etc/network/interfaces</code> (ou configuration via console selon la version) :		Modification du fichier <code>/etc/network/interfaces</code> (ou configuration via console selon la version) :
Ligne 354 :		Ligne 354 :

	; Analyse technique		; Analyse technique
	Pour comprendre, ~~nous avons~~ analysé le fichier APK lui-même en le convertissant en archive ZIP pour explorer son contenu.		Pour comprendre, j'ai analysé le fichier APK lui-même en le convertissant en archive ZIP pour explorer son contenu.
	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
	# Renommage pour extraction		# Renommage pour extraction
Ligne 370 :		Ligne 370 :

	==== Phase 2.2 : Tentatives d'Émulation QEMU android ARM ====		==== Phase 2.2 : Tentatives d'Émulation QEMU android ARM ====
	Pour pallier le problème d'architecture ou de version, ~~nous avons~~ testé l'émulation brute via QEMU.		Pour pallier le problème d'architecture ou de version, j'ai testé l'émulation brute via QEMU.

	'''1. Tentative d'émulation ARM (Android 4.4)'''		'''1. Tentative d'émulation ARM (Android 4.4)'''
Ligne 423 :		Ligne 423 :
	'''4. Root et Injection du Certificat (Succès avec Magisk)'''		'''4. Root et Injection du Certificat (Succès avec Magisk)'''

	Pour injecter le certificat système sur Android 12 (où la partition <code>/system</code> est en lecture seule via dm-verity), ~~nous avons~~ utilisé Magisk et un script d'automatisation (RootAVD).		Pour injecter le certificat système sur Android 12 (où la partition <code>/system</code> est en lecture seule via dm-verity), j'ai utilisé Magisk et un script d'automatisation (RootAVD).

	Commandes et procédure :		Commandes et procédure :
Ligne 461 :		Ligne 461 :

	==== 2.1 Inspection du PCB et Identification des composants ====		==== 2.1 Inspection du PCB et Identification des composants ====
	Après démontage, ~~nous avons~~ identifié deux éléments principaux sur le circuit imprimé (PCB) :		Après démontage, j'ai identifié deux éléments principaux sur le circuit imprimé (PCB) :
	* Le Microcontrôleur principal (MCU) : Il gère le capteur optique de fumée, le bouton de test et le buzzer piézoélectrique.		* Le Microcontrôleur principal (MCU) : Il gère le capteur optique de fumée, le bouton de test et le buzzer piézoélectrique.
	* Le Module de Communication (TYWE3S) : Il s'agit d'un module basé sur l'ESP8266, fabriqué par Tuya. Son rôle est uniquement de gérer la connexion Wi-Fi et l'envoi des données vers le Cloud (Nedis/Tuya).		* Le Module de Communication (TYWE3S) : Il s'agit d'un module basé sur l'ESP8266, fabriqué par Tuya. Son rôle est uniquement de gérer la connexion Wi-Fi et l'envoi des données vers le Cloud (Nedis/Tuya).
Ligne 469 :		Ligne 469 :
	En observant les pistes reliant le MCU au module TYWE3S, j'ai repéré des broches non soudées mais clairement étiquetées : VCC, GND, RX, TX.		En observant les pistes reliant le MCU au module TYWE3S, j'ai repéré des broches non soudées mais clairement étiquetées : VCC, GND, RX, TX.

	Il s'agit d'un port série (UART) utilisé pour la communication entre le processeur de l'alarme et le module Wi-Fi. C'est notre vecteur d'attaque : si je regarde ce qui en sort, ~~nous pouvons~~ voir ce que l'alarme "dit" au module Wi-Fi.		Il s'agit d'un port série (UART) utilisé pour la communication entre le processeur de l'alarme et le module Wi-Fi. C'est notre vecteur d'attaque : si je regarde ce qui en sort, je peux voir ce que l'alarme "dit" au module Wi-Fi.

	==== 2.2 Interception Série (UART) ====		==== 2.2 Interception Série (UART) ====
Ligne 490 :		Ligne 490 :
	'''Observation du trafic :'''		'''Observation du trafic :'''

	Grâce à ce programme, ~~nous avons~~ isolé deux comportements distincts :		Grâce à ce programme, j'ai isolé deux comportements distincts :

	1. État de Veille (Heartbeat) :		1. État de Veille (Heartbeat) :
Ligne 497 :		Ligne 497 :

	2. État d'Alarme (Choc Reset) :		2. État d'Alarme (Choc Reset) :
	Lorsque ~~nous appuyons~~ sur le bouton de test (Reset), le comportement change radicalement :		Lorsque j'appuie sur le bouton de test (Reset), le comportement change radicalement :
	* La fréquence des paquets augmente (flood).		* La fréquence des paquets augmente (flood).
	* L'octet de donnée change de `04` à `24`.		* L'octet de donnée change de `04` à `24`.
	* Un nouveau DPID (Data Point ID) `54` apparaît brièvement.		* Un nouveau DPID (Data Point ID) `54` apparaît brièvement.
	[[Fichier:Screenshot 2025-12-16 17-56-33.png\|sans_cadre\|547x547px]][[Fichier:Screenshot 2025-12-16 17-56-16.png\|sans_cadre\|1018x1018px]]		[[Fichier:Screenshot 2025-12-16 17-56-33.png\|sans_cadre\|547x547px]]


			[[Fichier:Screenshot 2025-12-16 17-56-16.png\|sans_cadre\|1018x1018px]]
	; Conclusion de l'analyse logique		; Conclusion de l'analyse logique
	: L'alarme communique en clair avec le module Wi-Fi. L'octet 0x23 est la commande "ALERTE". Si je parvenons à injecter cette trame, ~~nous pourrions~~ déclencher une fausse alerte sur le téléphone sans fumée.		: L'alarme communique en clair avec le module Wi-Fi. L'octet 0x23 est la commande "ALERTE". Si je parvenons à injecter cette trame, je pourais déclencher une fausse alerte sur le téléphone sans fumée.

	==== 2.4 Validation Physique à l'Oscilloscope ====		==== 2.4 Validation Physique à l'Oscilloscope ====
	Pour confirmer scientifiquement la vitesse de transmission (Baudrate) et valider nos réglages logiciels, ~~nous avons~~ utilisé un oscilloscope numérique sur la broche TX.		Pour confirmer scientifiquement la vitesse de transmission (Baudrate) et valider nos réglages logiciels, j'ai utilisé un oscilloscope numérique sur la broche TX.

	'''Méthodologie de mesure :'''		'''Méthodologie de mesure :'''

	1. Capture d'une trame de données en mode "Single Trigger".		1. Capture d'une trame de données en mode "Single Trigger".

	2. Utilisation des curseurs pour mesurer la largeur du bit le plus étroit (le bit élémentaire).		2. Utilisation des curseurs pour mesurer la largeur du bit le plus étroit (le bit élémentaire).
			[[Fichier:1000103578.jpg\|centré\|sans_cadre\|582x582px]]


			'''Calculs :'''

			Sur l'oscilloscope, j'ai mesuré une largeur de 52.00 µs pour une séquence de ce qui semblait être deux bits identiques consécutifs (un creux large).
			* Durée d'un bit T<sub>bit</sub> : 52 µs / 2 = 26 µs.
			* Formule du Baudrate : Frequency = 1 / T<sub>bit</sub>
			* Application numérique : 1 / 0.000026 ≃ 38461 Bauds.

			'''Résultat :'''

			La valeur calculée (38461) est extrêmement proche de la valeur standard 38400 Bauds. Cette mesure physique confirme indiscutablement que notre configuration logicielle pour l'interception était correcte.
	~~'''Calculs :'''~~
	~~Sur l'oscilloscope, nous avons mesuré une largeur de 52.00 µs pour une séquence de ce qui semblait être deux bits identiques consécutifs (un creux large).~~
	* Durée d'un bit ($T_{bit}$) : $52 \mu s / 2 = 26 \mu s$.
	* Formule du Baudrate : $Frequency = 1 / T_{bit}$
	* Application numérique : $1 / 0.000026 \approx 38461$ Bauds.

	~~'''Résultat :'''~~
	La valeur calculée (38461) est extrêmement proche de la valeur standard 38400 Bauds. Cette mesure physique confirme indiscutablement que notre configuration logicielle pour l'interception était correcte.

Kelbachi : /* 2.4 Validation Physique à l'Oscilloscope */

2026-01-24T22:24:54Z

2.4 Validation Physique à l'Oscilloscope

← Version précédente		Version du 24 janvier 2026 à 22:24
Ligne 512 :		Ligne 512 :
	2. Utilisation des curseurs pour mesurer la largeur du bit le plus étroit (le bit élémentaire).		2. Utilisation des curseurs pour mesurer la largeur du bit le plus étroit (le bit élémentaire).

	~~[[Fichier:1000103576.jpg\|vignette\|gauche\|300px]]~~

Kelbachi : /* 2. Approche Matérielle */

2026-01-24T22:24:32Z

2. Approche Matérielle

← Version précédente		Version du 24 janvier 2026 à 22:24
Ligne 457 :		Ligne 457 :
	=== <span style="color:#6369e6;font-weight: bold;">2. Approche Matérielle</span> ===		=== <span style="color:#6369e6;font-weight: bold;">2. Approche Matérielle</span> ===

	Devant les difficultés de l'attaque logicielle, ~~nous avons~~ ouvert le boîtier de l'alarme pour analyser son fonctionnement interne et tenter d'intercepter les communications avant qu'elles ne soient chiffrées par le module Wi-Fi.		Devant les difficultés de l'attaque logicielle, j'ai ouvert le boîtier de l'alarme pour analyser son fonctionnement interne et tenter d'intercepter les communications avant qu'elles ne soient chiffrées par le module Wi-Fi.
			[[Fichier:1000096443.jpg\|droite\|sans_cadre\|285x285px]]

	==== 2.1 Inspection du PCB et Identification des composants ====		==== 2.1 Inspection du PCB et Identification des composants ====
	Après démontage, nous avons identifié deux éléments principaux sur le circuit imprimé (PCB) :		Après démontage, nous avons identifié deux éléments principaux sur le circuit imprimé (PCB) :
	~~* ~~Le Microcontrôleur principal (MCU) :** C'est le "cerveau" de l'alarme. Il gère le capteur optique de fumée, le bouton de test et le buzzer piézoélectrique.		* Le Microcontrôleur principal (MCU) : Il gère le capteur optique de fumée, le bouton de test et le buzzer piézoélectrique.
	~~* ~~Le Module de Communication (TYWE3S) :** Il s'agit d'un module basé sur l'ESP8266, fabriqué par Tuya. Son rôle est uniquement de gérer la connexion Wi-Fi et l'envoi des données vers le Cloud (Nedis/Tuya).		* Le Module de Communication (TYWE3S) : Il s'agit d'un module basé sur l'ESP8266, fabriqué par Tuya. Son rôle est uniquement de gérer la connexion Wi-Fi et l'envoi des données vers le Cloud (Nedis/Tuya).

	~~[[Fichier~~:~~1000096443.jpg\|vignette\|droite\|300px\|Zoom sur le module Tuya TYWE3S et les pistes UART]]~~		'''Découverte majeure :'''

	~~'''Découverte majeure :'''~~		En observant les pistes reliant le MCU au module TYWE3S, j'ai repéré des broches non soudées mais clairement étiquetées : VCC, GND, RX, TX.
	En observant les pistes reliant le MCU au module TYWE3S, ~~nous avons~~ repéré des broches non soudées mais clairement étiquetées : VCC, GND, RX, TX.
	Il s'agit d'un port série (UART) utilisé pour la communication entre le processeur de l'alarme et le module Wi-Fi. C'est notre vecteur d'attaque : si ~~nous nous branchons ici~~, nous pouvons voir ce que l'alarme "dit" au module Wi-Fi.		Il s'agit d'un port série (UART) utilisé pour la communication entre le processeur de l'alarme et le module Wi-Fi. C'est notre vecteur d'attaque : si je regarde ce qui en sort, nous pouvons voir ce que l'alarme "dit" au module Wi-Fi.

	==== 2.2 Interception Série (UART) ====		==== 2.2 Interception Série (UART) ====
	~~Nous avons~~ soudé des connecteurs sur les pistes TX/RX et connecté un adaptateur USB-TTL pour lire le trafic sur notre PC.		J'ai soudé des connecteurs sur les pistes TX/RX et connecté un adaptateur USB-TTL pour lire le trafic sur notre PC.

	'''Recherche de la vitesse (Baudrate) avec Minicom :'''		'''Recherche de la vitesse (Baudrate) avec Minicom :'''
	~~La première difficulté a été de trouver la vitesse de communication. Nous avons testé les vitesses standards (9600, 115200) avec l'outil `minicom`.~~
	* À des vitesses incorrectes, nous recevions des caractères illisibles (garbage data).
	* En testant 38400 bauds, nous avons commencé à voir apparaître une structure répétitive cohérente en hexadécimal.

	'''Analyse de la parité (8N1 vs 7E1) :'''		La première difficulté a été de trouver la vitesse de communication. J'ai testé les vitesses standards (9600, 115200) avec l'outil `minicom`.
	~~Nous avons~~ observé que l'affichage ASCII des données semblait corrompu par moment. Nous avons émis l'hypothèse d'un réglage de parité différent.		* À des vitesses incorrectes, je recevais des caractères illisibles.
	~~* ~~Test en 7E1 (7 bits de données, Parité Paire) :** L'octet d'en-tête `0xAA` (10101010 en binaire) était interprété comme le caractère `*` (0x2A), car le 8ème bit était pris pour un bit de parité.		* En testant 38400 bauds, j'ai commencé à voir apparaître une structure répétitive cohérente en hexadécimal.
	~~* ~~Conclusion : Le protocole est bien du 8N1** (8 bits de données, Pas de parité, 1 bit de stop)~~, car c'est le seul mode qui restitue correctement l'en-tête hexadécimal `AA 23` caractéristique du protocole Tuya.~~		[[Fichier:Screenshot 2025-12-16 15-57-04.png\|néant\|vignette\|788x788px\|Résultat a 9600 bauds]]
			[[Fichier:Screenshot 2025-12-16 16-08-32.png\|néant\|vignette\|790x790px\|Résultat a 38400 bauds]]
			'''Analyse de la parité (8N1 vs 7E1) :'''J'ai observé que l'affichage ASCII des données semblait corrompu par moment. Nous avons émis l'hypothèse d'un réglage de parité différent.
			* Test en 7E1 (7 bits de données, Parité Paire) : L'octet d'en-tête `0xAA` (10101010 en binaire) était interprété comme le caractère `*` (0x2A), car le 8ème bit était pris pour un bit de parité.
			* Conclusion : Le protocole est bien du 8N1 (8 bits de données, Pas de parité, 1 bit de stop)

	==== 2.3 Analyse des Trames (Reverse Engineering) ====		==== 2.3 Analyse des Trames (Reverse Engineering) ====
	Pour analyser le flux plus efficacement qu'avec Minicom, ~~nous avons~~ développé un programme en C (`serial_reader.c`) utilisant la bibliothèque `termios` pour lire le port série octet par octet et afficher simultanément les valeurs Hexadécimales et ASCII.		Pour analyser le flux plus efficacement qu'avec Minicom, j'ai développé un programme en C (`serial_reader.c`) utilisant la bibliothèque `termios` pour lire le port série octet par octet et afficher simultanément les valeurs Hexadécimales et ASCII.

	'''Observation du trafic :'''		'''Observation du trafic :'''

	Grâce à ce programme, nous avons isolé deux comportements distincts :		Grâce à ce programme, nous avons isolé deux comportements distincts :

	1. État de Veille (Heartbeat) :		1. État de Veille (Heartbeat) :
	Toutes les quelques secondes, une trame courte est envoyée. Elle contient l'octet `04`. Cela correspond au clignotement de la LED de l'alarme. Le système dit "Tout va bien".		Toutes les quelques secondes, une trame courte est envoyée. Elle contient l'octet `04`. Cela correspond au clignotement de la LED de l'alarme. Le système dit "Tout va bien".
	<br><code>Trame type : aa 23 ... 06 53 ... 04 ...</code>		<br><code>Trame type : aa 23 ... 06 53 ... 04 ...</code>

	2. État d'Alarme (Choc Reset) :		2. État d'Alarme (Choc Reset) :
	Lorsque nous appuyons sur le bouton de test (Reset), le comportement change radicalement :		Lorsque nous appuyons sur le bouton de test (Reset), le comportement change radicalement :
	* La fréquence des paquets augmente (flood).		* La fréquence des paquets augmente (flood).
	* L'octet de donnée change de `04` à `24`.		* L'octet de donnée change de `04` à `24`.
	* Un nouveau DPID (Data Point ID) `54` apparaît brièvement.		* Un nouveau DPID (Data Point ID) `54` apparaît brièvement.
			[[Fichier:Screenshot 2025-12-16 17-56-33.png\|sans_cadre\|547x547px]][[Fichier:Screenshot 2025-12-16 17-56-16.png\|sans_cadre\|1018x1018px]]
	[[Fichier:~~Screenshot_2025~~-12-~~16_17~~-56-16.png\|~~cadre~~\|~~néant~~\|~~700x700px~~\|~~Capture du programme C montrant le flux de données lors du déclenchement de l'alarme (Octet 24 visible).~~]]

	; Conclusion de l'analyse logique		; Conclusion de l'analyse logique
	: L'alarme communique en clair avec le module Wi-Fi. L'octet ~~0x24~~ est la commande "ALERTE". Si ~~nous~~ parvenons à injecter cette trame, nous pourrions déclencher une fausse alerte sur le téléphone sans fumée.		: L'alarme communique en clair avec le module Wi-Fi. L'octet 0x23 est la commande "ALERTE". Si je parvenons à injecter cette trame, nous pourrions déclencher une fausse alerte sur le téléphone sans fumée.

	==== 2.4 Validation Physique à l'Oscilloscope ====		==== 2.4 Validation Physique à l'Oscilloscope ====
Ligne 511 :		Ligne 512 :
	2. Utilisation des curseurs pour mesurer la largeur du bit le plus étroit (le bit élémentaire).		2. Utilisation des curseurs pour mesurer la largeur du bit le plus étroit (le bit élémentaire).

	[[Fichier:1000103576.jpg\|vignette\|gauche\|300px~~\|Mesure à l'oscilloscope : Delta T de 52µs pour deux bits.~~]]		[[Fichier:1000103576.jpg\|vignette\|gauche\|300px]]





	'''Calculs :'''		'''Calculs :'''

Kelbachi : /* 2. Approche Matérielle */

2026-01-24T22:09:21Z

2. Approche Matérielle

← Version précédente		Version du 24 janvier 2026 à 22:09
Ligne 456 :		Ligne 456 :

	=== <span style="color:#6369e6;font-weight: bold;">2. Approche Matérielle</span> ===		=== <span style="color:#6369e6;font-weight: bold;">2. Approche Matérielle</span> ===
	En ~~parallèle~~ de l'~~approche logicielle~~, nous avons ~~mené~~ une analyse ~~matérielle directe~~ sur le ~~circuit~~ de l'~~alarme~~...
			Devant les difficultés de l'attaque logicielle, nous avons ouvert le boîtier de l'alarme pour analyser son fonctionnement interne et tenter d'intercepter les communications avant qu'elles ne soient chiffrées par le module Wi-Fi.

			==== 2.1 Inspection du PCB et Identification des composants ====
			Après démontage, nous avons identifié deux éléments principaux sur le circuit imprimé (PCB) :
			* Le Microcontrôleur principal (MCU) : C'est le "cerveau" de l'alarme. Il gère le capteur optique de fumée, le bouton de test et le buzzer piézoélectrique.
			* Le Module de Communication (TYWE3S) : Il s'agit d'un module basé sur l'ESP8266, fabriqué par Tuya. Son rôle est uniquement de gérer la connexion Wi-Fi et l'envoi des données vers le Cloud (Nedis/Tuya).

			[[Fichier:1000096443.jpg\|vignette\|droite\|300px\|Zoom sur le module Tuya TYWE3S et les pistes UART]]

			'''Découverte majeure :'''
			En observant les pistes reliant le MCU au module TYWE3S, nous avons repéré des broches non soudées mais clairement étiquetées : VCC, GND, RX, TX.
			Il s'agit d'un port série (UART) utilisé pour la communication entre le processeur de l'alarme et le module Wi-Fi. C'est notre vecteur d'attaque : si nous nous branchons ici, nous pouvons voir ce que l'alarme "dit" au module Wi-Fi.

			==== 2.2 Interception Série (UART) ====
			Nous avons soudé des connecteurs sur les pistes TX/RX et connecté un adaptateur USB-TTL pour lire le trafic sur notre PC.

			'''Recherche de la vitesse (Baudrate) avec Minicom :'''
			La première difficulté a été de trouver la vitesse de communication. Nous avons testé les vitesses standards (9600, 115200) avec l'outil `minicom`.
			* À des vitesses incorrectes, nous recevions des caractères illisibles (garbage data).
			* En testant 38400 bauds, nous avons commencé à voir apparaître une structure répétitive cohérente en hexadécimal.

			'''Analyse de la parité (8N1 vs 7E1) :'''
			Nous avons observé que l'affichage ASCII des données semblait corrompu par moment. Nous avons émis l'hypothèse d'un réglage de parité différent.
			* Test en 7E1 (7 bits de données, Parité Paire) : L'octet d'en-tête `0xAA` (10101010 en binaire) était interprété comme le caractère `*` (0x2A), car le 8ème bit était pris pour un bit de parité.
			* Conclusion : Le protocole est bien du 8N1 (8 bits de données, Pas de parité, 1 bit de stop), car c'est le seul mode qui restitue correctement l'en-tête hexadécimal `AA 23` caractéristique du protocole Tuya.

			==== 2.3 Analyse des Trames (Reverse Engineering) ====
			Pour analyser le flux plus efficacement qu'avec Minicom, nous avons développé un programme en C (`serial_reader.c`) utilisant la bibliothèque `termios` pour lire le port série octet par octet et afficher simultanément les valeurs Hexadécimales et ASCII.

			'''Observation du trafic :'''
			Grâce à ce programme, nous avons isolé deux comportements distincts :

			1. État de Veille (Heartbeat) :
			Toutes les quelques secondes, une trame courte est envoyée. Elle contient l'octet `04`. Cela correspond au clignotement de la LED de l'alarme. Le système dit "Tout va bien".
			<br><code>Trame type : aa 23 ... 06 53 ... 04 ...</code>

			2. État d'Alarme (Choc Reset) :
			Lorsque nous appuyons sur le bouton de test (Reset), le comportement change radicalement :
			* La fréquence des paquets augmente (flood).
			* L'octet de donnée change de `04` à `24`.
			* Un nouveau DPID (Data Point ID) `54` apparaît brièvement.

			[[Fichier:Screenshot_2025-12-16_17-56-16.png\|cadre\|néant\|700x700px\|Capture du programme C montrant le flux de données lors du déclenchement de l'alarme (Octet 24 visible).]]

			; Conclusion de l'analyse logique
			: L'alarme communique en clair avec le module Wi-Fi. L'octet 0x24 est la commande "ALERTE". Si nous parvenons à injecter cette trame, nous pourrions déclencher une fausse alerte sur le téléphone sans fumée.

			==== 2.4 Validation Physique à l'Oscilloscope ====
			Pour confirmer scientifiquement la vitesse de transmission (Baudrate) et valider nos réglages logiciels, nous avons utilisé un oscilloscope numérique sur la broche TX.

			'''Méthodologie de mesure :'''
			1. Capture d'une trame de données en mode "Single Trigger".
			2. Utilisation des curseurs pour mesurer la largeur du bit le plus étroit (le bit élémentaire).

			[[Fichier:1000103576.jpg\|vignette\|gauche\|300px\|Mesure à l'oscilloscope : Delta T de 52µs pour deux bits.]]

			'''Calculs :'''
			Sur l'oscilloscope, nous avons mesuré une largeur de 52.00 µs pour une séquence de ce qui semblait être deux bits identiques consécutifs (un creux large).
			* Durée d'un bit ($T_{bit}$) : $52 \mu s / 2 = 26 \mu s$.
			* Formule du Baudrate : $Frequency = 1 / T_{bit}$
			* Application numérique : $1 / 0.000026 \approx 38461$ Bauds.

			'''Résultat :'''
			La valeur calculée (38461) est extrêmement proche de la valeur standard 38400 Bauds. Cette mesure physique confirme indiscutablement que notre configuration logicielle pour l'interception était correcte.

Kelbachi : /* Partie 2 : Casse d'objets connectés - Alarme incendie (IoT) */

2026-01-24T22:09:01Z

Partie 2 : Casse d'objets connectés - Alarme incendie (IoT)

@@ Ligne 382 : / Ligne 382 : @@
 ; Bilan des tests QEMU
 Aucune VM n'a été exploitable pour des raisons variées :
 * Pas de Google Play Services (impossible de télécharger l'app).

Kelbachi : /* Partie 2 : Casse d'objets connectés - Alarme incendie (IoT) */

2026-01-24T22:05:07Z

Partie 2 : Casse d'objets connectés - Alarme incendie (IoT)

← Version précédente		Version du 24 janvier 2026 à 22:05
Ligne 328 :		Ligne 328 :
	</syntaxhighlight>		</syntaxhighlight>

	Commandes utilisées pour les différents tests :		==== Phase 2.1 : Tentatives d'Émulation QEMU android ARM ====
			J'ai d'abord tenté d'émuler Android "à la main" via QEMU/KVM en utilisant plusieurs images ISO (Android x86 versions 6 à 9). Cette méthode légère permettait théoriquement un contrôle total sur les paramètres de lancement.Commandes utilisées pour les différents tests :
	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
	# Test basique en mode user net		# Test basique en mode user net
Ligne 348 :		Ligne 349 :
	</syntaxhighlight>		</syntaxhighlight>

	; Problème rencontré : L'application ne se lance pas		; Problème rencontré
	L'installation de l'OS fonctionne, le réseau fonctionne, l'APK Nedis se télécharge, mais l'application crashe immédiatement au lancement.		;L'application ne se lance pas
			L'installation de l'OS fonctionne, le réseau fonctionne, l'APK Nedis se télécharge, mais l'application crashe immédiatement au lancement.

	; Analyse technique		; Analyse technique
Ligne 362 :		Ligne 364 :
	</syntaxhighlight>		</syntaxhighlight>

	; Résultat de l'analyse :		; Résultat de l'analyse
	Le dossier <code>lib/</code> ne contient que des sous-dossiers <code>armeabi-v7a</code> et <code>arm64-v8a</code>.		Le dossier <code>lib/</code> ne contient que des sous-dossiers <code>armeabi-v7a</code> et <code>arm64-v8a</code>.
	~~* ~~Conclusion : L'application est compilée avec des instructions natives pour processeurs ARM**.		* Conclusion : L'application est compilée avec des instructions natives pour processeurs ARM.
	~~* ~~Cause du crash : Notre VM tourne sur une architecture x86_64**. Sans bibliothèques compatibles (x86) ni traducteur binaire (libhoudini) fonctionnel, l'application ne peut pas s'exécuter.		* Cause du crash : Notre VM tourne sur une architecture x86_64. Sans bibliothèques compatibles (x86) ni traducteur binaire (libhoudini) fonctionnel, l'application ne peut pas s'exécuter.

	==== Phase 2 : Tentatives d'Émulation QEMU ~~(Ligne de commande)~~ ====		==== Phase 2.2 : Tentatives d'Émulation QEMU android ARM ====
	Pour pallier le problème d'architecture ou de version, nous avons testé l'émulation brute via QEMU.		Pour pallier le problème d'architecture ou de version, nous avons testé l'émulation brute via QEMU.

	'''1. Tentative d'émulation ARM (Android 4.4)'''		'''1. Tentative d'émulation ARM (Android 4.4)'''
	Sur conseil, ~~nous avons~~ tenté d'émuler une architecture ARM pour être compatible avec les librairies de l'application.
			Sur conseil, j'ai tenté d'émuler une architecture ARM pour être compatible avec les librairies de l'application.
	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
	sudo apt install qemu-system-arm		sudo apt install qemu-system-arm
	# Lancement de l'image Android 4.4 ARM		# Lancement de l'image Android 4.4 ARM
	</syntaxhighlight>		</syntaxhighlight>
	~~* ~~Résultat : L'architecture est bonne, mais la version d'Android (4.4 KitKat) est trop ancienne**. L'application Nedis requiert une API plus récente (Android 6.0+) et refuse de s'installer.		* Résultat : L'architecture est bonne, mais la version d'Android (4.4 KitKat) est trop ancienne. L'application Nedis requiert une API plus récente (Android 6.0+) et refuse de s'installer.

	~~'''2. Tentatives d'émulation x86 diverses'''~~
	~~Nous avons enchaîné les tests avec différentes ISOs Android via QEMU (x86_64) pour trouver une version compatible.~~
	~~Commandes utilisées :~~
	~~<syntaxhighlight lang="bash">~~
	~~# Test standard~~
	~~qemu-system-x86_64 -net nic -net user -m 1024 -enable-kvm -display sdl -drive file=android.img,format=raw~~

	~~# Installation depuis ISO~~
	~~qemu-system-x86_64 -net nic -net user -m 1024 -enable-kvm -display sdl -drive file=android.img,format=raw -cdrom android-x86-9.0.iso -boot d~~

	~~# Configuration avancée (USB, CPU Host)~~
	~~qemu-system-x86_64 -m 2048 -enable-kvm -cpu host -smp 2 -display sdl -drive file=android.img,format=raw,if=virtio -usb -device usb-host,vendorid=0x148f,productid=0x5370~~
	~~</syntaxhighlight>~~

	; Bilan des tests QEMU :		; Bilan des tests QEMU
	Aucune VM n'a été exploitable pour des raisons variées :		Aucune VM n'a été exploitable pour des raisons variées :
	* Pas de Google Play Services (impossible de télécharger l'app).		* Pas de Google Play Services (impossible de télécharger l'app).
Ligne 399 :		Ligne 388 :

	==== Phase 3 : La Réussite avec Android Studio ====		==== Phase 3 : La Réussite avec Android Studio ====
	~~Nous sommes passés~~ à Android Studio pour créer un émulateur (AVD) stable et récent.		Je suis passée à Android Studio pour créer un émulateur (AVD) stable et récent.

	'''1. Installation'''		'''1. Installation'''
Ligne 411 :		Ligne 400 :

	'''2. Création de l'AVD (Attention à l'architecture)'''		'''2. Création de l'AVD (Attention à l'architecture)'''
	* Tentative initiale avec une image Pixel 4 / Android 10 ARM64.		* Tentative initiale avec une image Pixel 4 / Android 10 ARM64.
	~~* ~~Erreur :** <code>AVD's CPU Architecture 'arm64' is not supported by the QEMU2 emulator on x86_64 host</code>. L'émulation ARM sur x86 est trop lente ou non supportée par défaut.		* Erreur : <code>AVD's CPU Architecture 'arm64' is not supported by the QEMU2 emulator on x86_64 host</code>. L'émulation ARM sur x86 est trop lente ou non supportée par défaut.
	~~* ~~Correction : Choix d'une image Google APIs x86_64** (Android 12 / API 31).		* Correction : Choix d'une image Google APIs x86_64 (Android 12 / API 31).

	'''3. Installation de l'application'''		'''3. Installation de l'application'''
	L'APK officiel du Play Store ne fonctionnant pas toujours sur émulateur, ~~nous avons~~ récupéré l'APK compatible via Aptoide (<code>https://nedis-smartlife.en.aptoide.com/app</code>). L'installation fonctionne.
			L'APK officiel du Play Store ne fonctionnant pas toujours sur émulateur, j'ai récupéré l'APK compatible via Aptoide (<code>https://nedis-smartlife.en.aptoide.com/app</code>). L'installation fonctionne.

	'''4. Root et Injection du Certificat (Succès avec Magisk)'''		'''4. Root et Injection du Certificat (Succès avec Magisk)'''
	Pour injecter le certificat système sur Android 12 (où la partition <code>/system</code> est en lecture seule via dm-verity), nous avons utilisé Magisk et un script d'automatisation (RootAVD).
			Pour injecter le certificat système sur Android 12 (où la partition <code>/system</code> est en lecture seule via dm-verity), nous avons utilisé Magisk et un script d'automatisation (RootAVD).

	Commandes et procédure :		Commandes et procédure :
Ligne 431 :		Ligne 422 :
	</syntaxhighlight>		</syntaxhighlight>

	L'injection directe via <code>adb push</code> échouait (`Read-only file system`).		L'injection directe via <code>adb push</code> échouait (`Read-only file system`)
	Solution : Installation d'un module Magisk spécifique via le script RootAVD. Ce module monte le certificat en "overlay" au démarrage, contournant la protection en écriture.

	; Résultat Final :		Solution : Installation d'un module Magisk spécifique via le script RootAVD. Ce module monte le certificat en "overlay" au démarrage, contournant la protection en écriture.
	* La VM est ~~Rootée~~.		; Résultat Final
	* Le certificat CA est reconnu par le système.		[[Fichier:Perso.png\|centré\|sans_cadre\|547x547px]]
	* L'application Nedis se lance.		* La VM est rootée.
			* Le certificat est reconnu par le système.
			* L'application Nedis se lance.
	* Nous pouvons désormais intercepter le trafic HTTPS.		* Nous pouvons désormais intercepter le trafic HTTPS.

	=== <span style="color:#6369e6;font-weight: bold;">2. Approche Matérielle ~~(Hardware Hacking)~~</span> ===		==== Changement de stratégie ====
			Face à l'impasse technique de la virtualisation (problèmes d'architecture CPU et de droits Root persistants), j'ai décidé de réévaluer le vecteur d'attaque.

			En effectuant une inspection physique du détecteur de fumée (démontage du boîtier), j'ai repéré sur le circuit imprimé (PCB) une série de pistes et de broches non soudées ressemblant fortement à un port de programmation ou de débogage.
			[[Fichier:1000096446.jpg\|gauche\|vignette\|398x398px]]
			[[Fichier:1000096443.jpg\|centré\|vignette\|407x407px]]


			Plutôt que de continuer à lutter contre les sécurités logicielles d'Android, j'ai choisi de pivoter vers une analyse matérielle . L'hypothèse est simple : si le trafic réseau est chiffré, les données transitant en clair entre le microcontrôleur de l'alarme et son module Wi-Fi sont peut-être accessibles via ce port physique.

			=== <span style="color:#6369e6;font-weight: bold;">2. Approche Matérielle</span> ===
	En parallèle de l'approche logicielle, nous avons mené une analyse matérielle directe sur le circuit de l'alarme...		En parallèle de l'approche logicielle, nous avons mené une analyse matérielle directe sur le circuit de l'alarme...

Kelbachi : /* Partie 2 : Casse d'objets connectés - Alarme incendie (IoT) */

2026-01-24T21:34:18Z

Partie 2 : Casse d'objets connectés - Alarme incendie (IoT)

@@ Ligne 326 : / Ligne 326 : @@
      gateway 172.16.9.1
      dns-nameservers 172.16.9.1
 </syntaxhighlight>

Kelbachi : /* Partie 2 : Casse d'objets connectés (IoT) */

2026-01-24T21:33:53Z

Partie 2 : Casse d'objets connectés (IoT)

← Version précédente		Version du 24 janvier 2026 à 21:33
Ligne 304 :		Ligne 304 :
	* Erreur AP <code>cipher not configured</code> : corriger en posant `authentication ... version 2` côté SSID et <code>encryption mode ciphers aes-ccm</code> côté radio.		* Erreur AP <code>cipher not configured</code> : corriger en posant `authentication ... version 2` côté SSID et <code>encryption mode ciphers aes-ccm</code> côté radio.

	== <span style="color:#34495E;font-weight: bold; font-size: 130%">Partie 2 : Casse d'objets connectés (IoT)</span> ==		== <span style="color:#34495E;font-weight: bold; font-size: 130%">Partie 2 : Casse d'objets connectés - Alarme incendie (IoT)</span> ==
	L'objectif est d'intercepter les communications HTTPS de l'application mobile Nedis SmartLife pour récupérer la `localKey` de l'alarme.		L'objectif est d'intercepter les communications HTTPS de l'application mobile Nedis SmartLife pour récupérer la localKey de l'alarme.

	=== <span style="color:#6369e6;font-weight: bold;">1. Approche Logicielle : Virtualisation Android</span> ===		=== <span style="color:#6369e6;font-weight: bold;">1. Approche Logicielle : Virtualisation Android</span> ===

	~~Nous avons~~ exploré plusieurs méthodes de virtualisation pour obtenir un environnement Android capable de faire tourner l'application tout en étant root pour injecter ~~notre~~ certificat ~~d'interception~~.		J'ai exploré plusieurs méthodes de virtualisation pour obtenir un environnement Android capable de faire tourner l'application tout en étant root pour injecter le certificat en mode système et non pas utilisateur comme cela se passerai sur des versions android plus récentes que celle de la tablette utilisée plus tot.

	==== Phase 1 : VM Android x86 sur Xen ====		==== Phase 1 : VM Android x86 sur Xen ====
	Première tentative avec une image ISO Android-x86 ~~directement sur l'hyperviseur de la salle de TP~~.		Première tentative avec une image ISO Android-x86.

	'''Configuration Réseau (Lien avec le Cisco) :'''		'''Configuration Réseau (Lien avec le Cisco) :'''

	Pour que cette VM puisse communiquer avec notre infrastructure (VLAN, Accès Internet via notre passerelle), nous avons dû modifier la configuration réseau pour la lier au pont `bridgeStudents` et lui attribuer une IP statique dans notre plage.		Pour que cette VM puisse communiquer avec notre infrastructure (VLAN, Accès Internet via notre passerelle), nous avons dû modifier la configuration réseau pour la lier au pont `bridgeStudents` et lui attribuer une IP statique dans notre plage.

Ligne 330 :		Ligne 331 :
	L'installation de l'OS fonctionne, le réseau fonctionne, l'APK Nedis se télécharge, mais l'application crashe immédiatement au lancement.		L'installation de l'OS fonctionne, le réseau fonctionne, l'APK Nedis se télécharge, mais l'application crashe immédiatement au lancement.

	; Analyse technique ~~(Pourquoi ça plante ?)~~		; Analyse technique
	Pour comprendre, nous avons analysé le fichier APK lui-même en le convertissant en archive ZIP pour explorer son contenu.		Pour comprendre, nous avons analysé le fichier APK lui-même en le convertissant en archive ZIP pour explorer son contenu.
	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">

SE5 IdO sécurité des objets 2025/2026 b2 - Historique des versions

Kelbachi : /* 2. Approche Matérielle */

Kelbachi : /* 2.3 Analyse des Trames (Reverse Engineering) */

Kelbachi : /* 2.4 Validation Physique à l'Oscilloscope */

Kelbachi : /* 2.4 Validation Physique à l'Oscilloscope */

Kelbachi : /* 2. Approche Matérielle */

Kelbachi : /* 2. Approche Matérielle */

Kelbachi : /* Partie 2 : Casse d'objets connectés - Alarme incendie (IoT) */

Kelbachi : /* Partie 2 : Casse d'objets connectés - Alarme incendie (IoT) */

Kelbachi : /* Partie 2 : Casse d'objets connectés - Alarme incendie (IoT) */

Kelbachi : /* Partie 2 : Casse d'objets connectés (IoT) */

Kelbachi : /* 2. Approche Matérielle */

Kelbachi : /* 2.3 Analyse des Trames (Reverse Engineering) */

Kelbachi : /* 2.4 Validation Physique à l'Oscilloscope */

Kelbachi : /* 2.4 Validation Physique à l'Oscilloscope */

Kelbachi : /* 2. Approche Matérielle */

Kelbachi : /* 2. Approche Matérielle */

Kelbachi : /* Partie 2 : Casse d'objets connectés - Alarme incendie (IoT) */

Kelbachi : /* Partie 2 : Casse d'objets connectés - Alarme incendie (IoT) */

Kelbachi : /* Partie 2 : Casse d'objets connectés - Alarme incendie (IoT) */

Kelbachi : /* Partie 2 : Casse d'objets connectés (IoT) */