SE5 IdO sécurité des objets 2025/2026 b2

2026-01-24T22:24:32Z

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

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 130%; background: #14164f; vertical-align: top; width: 98%; font-family: 'Poppins', sans-serif;">🌐 TP Infrastructure Réseau 🛜</div>=

== Introduction ==
Ce wiki documente la mise en place d’une petite infrastructure réseau pédagogique pour le TP 2025/2026.

L’objectif est de '''déployer un serveur virtuel''' sur ''capbreton'', d’y '''terminer un VLAN privé''' (ici '''409''' car je suis a la Zabeth 09), puis d’implanter les services exigés : '''DHCP''', '''DNS (forwarder + zone locale d’interception)''', '''NAT/mascarade''', et '''redirection réseau''' pour l’HTTP.

Des choix techniques sont explicités à chaque étape (pourquoi tel fichier, telle option, tel service), afin d’argumenter les décisions et permettre la reproductibilité.

== Serveur virtuel (17/09) ==
La VM est créée sur <code>Xen</code> depuis <code>capbreton</code> avec une unique interface reliée à <code>bridgeStudents</code>, conformément au sujet (routage par <code>172.26.145.251</code> côté salles projets).

<syntaxhighlight lang="bash">
xen-create-image \
--hostname=SE5.kelbachi \
--dhcp \
--bridge=bridgeStudents \
--dir=/usr/local/xen \
--size=10GB \
--dist=daedalus \
--memory=2G \
--force
</syntaxhighlight>

; Pourquoi cette commande ?
: <code>--bridge=bridgeStudents</code> impose l’unique attachement réseau demandé ; <code>--dist=daedalus</code> assure une base Devuan stable (<code>ifupdown</code> classique) ; les ressources (2 Gio RAM/10 Gio disque) suffisent pour DHCP/DNS/NAT.

Démarrage et accès console :
<syntaxhighlight lang="bash">
xl create -c /etc/xen/SE5.kelbachi.cfg
# Ctrl+] pour détacher la console sans éteindre
</syntaxhighlight>

=== Adresse routée (réseau des salles projets) ===
Configuration statique avec passerelle <code>172.26.145.251</code>. On choisit une IP libre dans la plage fournie (exemple <code>172.26.145.109/24</code>).

<syntaxhighlight lang="linux-config">
# /etc/network/interfaces (extrait)
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 172.26.145.109/24
gateway 172.26.145.251
dns-nameservers 1.1.1.1 8.8.8.8
</syntaxhighlight>

; Pourquoi une IP statique ?
: Le sujet exige un adressage maîtrisé côté salles projets et une route par défaut vers le routeur NAT de la salle. C’est la base pour que la VM accède à Internet et puisse, ensuite, NATer les clients WiFi.

=== Interface privée (VLAN 409) ===
Le réseau privé associé à <code>X=09</code> est <code>172.16.9.0/24</code>. La VM termine ce VLAN avec l’adresse <code>172.16.9.1/24</code> (gateway & DNS pour les clients).
Dans notre mise en place, l’interface privée est <code>eth1</code>.

<syntaxhighlight lang="linux-config">
# /etc/network/interfaces (complément)
auto eth1
iface eth1 inet static
address 172.16.9.1/24
</syntaxhighlight>

Vérifications :
<syntaxhighlight lang="bash">
ip a
ip r
ping -c3 172.26.145.251
ping -c3 8.8.8.8
</syntaxhighlight>

== Point d’accès Cisco – SSID WPA2-PSK (29/09) ==
Connexion '''console série''' (9600 8N1, sans control flow) avec Minicom.
Après habilitation, création d’un SSID attaché au <code>VLAN 409</code>.

<syntaxhighlight lang="bash">
dot11 ssid SE5-SSID09
vlan 409
authentication open
authentication key-management wpa version 2
wpa-psk ascii Cisco2025
exit

interface dot11radio 0
encryption mode ciphers aes-ccm
ssid SE5-SSID09
station-role root
no shutdown
</syntaxhighlight>

Nous laissons de cote cette partie car elle n'est pas bloquante pour la suite du TP.

== Serveur DHCP (29/09) ==
Distribution automatisée d’adresses <code>172.16.9.100–200</code> aux clients du VLAN 409, avec routeur et DNS pointant vers la VM.

Installation :
<syntaxhighlight lang="bash">
apt-get update
apt-get install -y isc-dhcp-server
</syntaxhighlight>

Configuration :
<syntaxhighlight lang="linux-config">
# /etc/dhcp/dhcpd.conf
default-lease-time 600;
max-lease-time 7200;
authoritative;

subnet 172.16.9.0 netmask 255.255.255.0 {
range 172.16.9.100 172.16.9.200;
option routers 172.16.9.1;
option domain-name-servers 172.16.9.1;
}
</syntaxhighlight>

== Mascarade (NAT) – Accès Internet (29/09) ==
Activation du routage IPv4 et NAT du réseau <code>172.16.9.0/24</code> vers <code>eth0</code>.

<syntaxhighlight lang="bash">
sysctl -w net.ipv4.ip_forward=1
sed -i 's/^#\?net\.ipv4\.ip_forward.*/net.ipv4.ip_forward=1/' /etc/sysctl.conf

iptables -t nat -F
iptables -t nat -A POSTROUTING -o eth0 -s 172.16.9.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -s 172.16.9.0/24 -j MASQUERADE

iptables -t nat -L -n -v
</syntaxhighlight>

; Pourquoi la mascarade ?
: Les clients WiFi utilisent des adresses privées. Le NAT traduit leurs paquets pour qu’ils sortent avec l’IP de la VM côté salles projets.
: Sans NAT, pas d’Internet pour le VLAN 409.

Persistance :
<syntaxhighlight lang="bash">
apt-get install -y iptables-persistent
netfilter-persistent save
</syntaxhighlight>

== Interception de flux (04/10) ==

=== Redirection par DNS (zone locale) ===
On implémente une '''zone primaire''' sur la VM pour rediriger <code>picoctf.org</code> et tous ses sous-domaines vers la VM.
Service '''BIND''' sous Devuan : nom de service systemd = <code>named</code>.

Déclaration :
<syntaxhighlight lang="linux-config">
# /etc/bind/named.conf.local
zone "picoctf.org" {
type master;
file "/etc/bind/db.picoctf.org";
};
</syntaxhighlight>

Zone :
<syntaxhighlight lang="dns">
$TTL 200
@ IN SOA ns.picoctf.org. admin.picoctf.org. (
2025100403 ; Serial
3600 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ) ; Minimum

IN NS ns.picoctf.org.
ns IN A 172.16.9.1
@ IN A 172.16.9.1
www IN CNAME ns
</syntaxhighlight>

Options (écoute VLAN) :
<syntaxhighlight lang="linux-config">
# /etc/bind/named.conf.options (extrait)
options {
directory "/var/cache/bind";
recursion yes;
allow-query { 172.16.9.0/24; 127.0.0.1; };
forwarders { 1.1.1.1; 8.8.8.8; };
listen-on { 172.16.9.1; 127.0.0.1; };
dnssec-validation auto;
};
</syntaxhighlight>

Service & vérifs :
<syntaxhighlight lang="bash">
systemctl enable named
systemctl restart named
named-checkconf
named-checkzone picoctf.org /etc/bind/db.picoctf.org
dig @127.0.0.1 picoctf.org +short
dig @127.0.0.1 www.picoctf.org +short
dig @127.0.0.1 test.picoctf.org +short # wildcard
</syntaxhighlight>[[Fichier:Screenshot from 2025-10-04 08-33-01.png|centré|sans_cadre|600x600px]]

== Redirection réseau ==
Mise en place d’une REDIRECT pour capter le HTTP et le diriger vers un service local.

<syntaxhighlight lang="bash">
# Table nat propre
iptables -t nat -F

# Interception HTTP
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-ports 8080

# NAT format TP (409)
iptables -t nat -A POSTROUTING -o eth0 -s 172.16.9.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -s 172.16.9.0/24 -j MASQUERADE

iptables -t nat -L -n -v
</syntaxhighlight>

== Serveur Apache sécurisé (08/10) ==

Dans cette partie, l’objectif est de mettre en place un serveur web sécurisé en HTTPS avec un certificat signé par une autorité locale.
J'utilise ici le domaine d’exemple <code>picoctf.org</code>, déjà intercepté par notre DNS.

=== 1. Création d’un certificat auto-signé ===
Avant toute chose, je génère un certificat auto-signé permettant à Apache de servir du HTTPS localement.

<syntaxhighlight lang="bash">
openssl req -x509 -nodes -days 365 \
-newkey rsa:2048 \
-keyout /etc/ssl/apache/apache-selfsigned.key \
-out /etc/ssl/apache/apache-selfsigned.crt \
-subj "/C=FR/ST=Nord/L=Lille/O=Polytech/CN=picoctf.org"
</syntaxhighlight>

=== 2. Configuration d’Apache2 ===
Je crée un nouveau fichier de configuration HTTPS dans <code>/etc/apache2/sites-available/secure-site.conf</code>.

<syntaxhighlight lang="apache">
<VirtualHost *:443>
ServerName picoctf
DocumentRoot /var/www/html

SSLEngine on
SSLCertificateFile /etc/apache2/sites-available/apache.crt
SSLCertificateKeyFile /etc/apache2/sites-available/apache.key

# Logs SSL
ErrorLog ${APACHE_LOG_DIR}/ssl-error.log
CustomLog ${APACHE_LOG_DIR}/ssl-access.log combined
</VirtualHost>

# HTTP vers HTTPS
<VirtualHost *:80>
ServerName picoctf.org
Redirect permanent / https://picoctf.org/
</VirtualHost>
</syntaxhighlight>

Cette configuration active le service sur le port '''443''' et redirige automatiquement les connexions HTTP vers HTTPS.

=== 3. Création d’une autorité de certification locale ===
Afin de simuler un certificat signé par une autorité de confiance, je crée une CA interne appelée "Certif".

<syntaxhighlight lang="bash">
openssl req -x509 -new -nodes \
-keyout ca.key -sha256 -days 365 \
-out ca.crt -subj "/CN=Certif"
</syntaxhighlight>

=== 4. Signature du certificat Apache avec l’autorité locale ===
Je commence par créer une demande de signature (CSR) pour le serveur Apache :

<syntaxhighlight lang="bash">
openssl req -new -newkey rsa:2048 -nodes \
-keyout apache.key -out apache.csr \
-subj "/CN=picoctf.org"
</syntaxhighlight>

Puis je signe cette requête avec notre autorité <code>Certif</code> :

<syntaxhighlight lang="bash">
openssl x509 -req -in apache.csr \
-CA ca.crt -CAkey ca.key -CAcreateserial \
-out apache.crt -days 365 -sha256
</syntaxhighlight>

Je remplace ensuite dans la configuration Apache les fichiers de certificat auto-signés par ceux nouvellement générés :
 - <code>/etc/apache2/sites-available/apache.crt</code>
 - <code>/etc/apache2/sites-available/apache.key</code>

Redémarrage du service :
<syntaxhighlight lang="bash">
a2enmod ssl
a2ensite secure-site.conf
systemctl reload apache2
</syntaxhighlight>

== Machine virtuelle Android ==
Lorsque je tente d’accéder à <code>https://picoctf.org</code> depuis un appareil Android récent, le certificat de l’autorité “Certif” n’est pas reconnu.[[Fichier:Screenshot from 2025-10-10 15-30-32.png|centré|sans_cadre|954x954px]]Pour contourner cela, il est possible d’installer une ancienne machine Android (par exemple sous '''Android 4.x'''), où l’ajout manuel d’une autorité de certification est encore possible.

Sur cette Android, après quelques ajustements réseau, il est possible d’importer le certificat racine Certif et ainsi naviguer vers le faux site <code>picoctf.org</code>.
== Appareil Android physique (08/10) ==
Enfin, le même test a été reproduit sur la tablette Android 4.4 de mon camarade, une version qui permet encore l’ajout d’autorités de certification manuellement.

En important le fichier `ca.crt` dans les paramètres de sécurité, le site `https://picoctf.org` devient totalement “sécurisé” : le navigateur affiche le cadenas vert , confirmant que la connexion est chiffrée et que le certificat est reconnu par le système.

[[Fichier:Screenshot 2025-10-08-10-04-04.png|droite|sans_cadre|419x419px]]
[[Fichier:Screenshot 2025-10-08-09-21-51.png|sans_cadre|706x706px]]

== Problèmes rencontrés ==
* Console Cisco muette : causée par le '''flow control'''. Solution : désactiver hardware & software flow control dans minicom (9600, 8N1, <code>/dev/ttyUSB0</code>).
* 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.

== Partie 2 : Casse d'objets connectés - Alarme incendie (IoT) ==
L'objectif est d'intercepter les communications HTTPS de l'application mobile Nedis SmartLife pour récupérer la localKey de l'alarme.

=== 1. Approche Logicielle : Virtualisation Android ===

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 ====
Première tentative avec une image ISO Android-x86.

'''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.

Modification du fichier <code>/etc/network/interfaces</code> (ou configuration via console selon la version) :
<syntaxhighlight lang="bash">
auto eth0
iface eth0 inet static
address 172.16.9.150
netmask 255.255.255.0
gateway 172.16.9.1
dns-nameservers 172.16.9.1
</syntaxhighlight>

==== 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">
# Test basique en mode user net
qemu-system-x86_64 -net nic -net user -m 1024 -enable-kvm -display sdl -drive file=android.img,format=raw

# Boot sur ISO pour installation
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

# Tentative avancée (USB passthrough et 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>

; Problème rencontré
;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
Pour comprendre, nous avons analysé le fichier APK lui-même en le convertissant en archive ZIP pour explorer son contenu.
<syntaxhighlight lang="bash">
# Renommage pour extraction
mv nedis-smartlife.apk nedis-smartlife.zip
unzip nedis-smartlife.zip -d analyse_apk

# Inspection des bibliothèques natives
ls -R analyse_apk/lib/
</syntaxhighlight>

; 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>.
* 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.

==== 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.

'''1. Tentative d'émulation ARM (Android 4.4)'''

Sur conseil, j'ai tenté d'émuler une architecture ARM pour être compatible avec les librairies de l'application.
<syntaxhighlight lang="bash">
sudo apt install qemu-system-arm
# Lancement de l'image Android 4.4 ARM
</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.

; Bilan des tests QEMU
[[Fichier:Screenshot 2025-11-18 16-15-27.png|droite|sans_cadre|488x488px]]
[[Fichier:Screenshot 2025-11-18 17-58-08.png|gauche|sans_cadre|494x494px]]

Aucune VM n'a été exploitable pour des raisons variées :
* Pas de Google Play Services (impossible de télécharger l'app).
* Version trop ancienne.
* Impossibilité de passer root sur les versions récentes.

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

'''1. Installation'''
<syntaxhighlight lang="bash">
# Décompression et déplacement dans /opt ou ~/
tar -xvf android-studio-*.tar.gz
sudo mv android-studio /opt/
/opt/android-studio/bin/studio.sh
</syntaxhighlight>
Le SDK s'installe dans <code>~/Android/Sdk/</code>.

'''2. Création de l'AVD (Attention à l'architecture)'''
* 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.
* Correction : Choix d'une image Google APIs x86_64 (Android 12 / API 31).

'''3. Installation de l'application'''

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)'''

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 :
<syntaxhighlight lang="bash">
# Commandes ADB classiques (insuffisantes seules)
adb root
adb shell avbctl disable-verification
adb reboot
adb wait-for-device root
adb remount
</syntaxhighlight>

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
[[Fichier:Perso.png|centré|sans_cadre|547x547px]]
* 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.

==== 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.

=== 2. Approche Matérielle ===

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 ====
Après démontage, nous avons 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 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).

'''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.

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) ====
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 :'''

La première difficulté a été de trouver la vitesse de communication. J'ai testé les vitesses standards (9600, 115200) avec l'outil `minicom`.
* À des vitesses incorrectes, je recevais des caractères illisibles.
* En testant 38400 bauds, j'ai commencé à voir apparaître une structure répétitive cohérente en hexadécimal.
[[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) ====
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 :'''

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".
 <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-33.png|sans_cadre|547x547px]][[Fichier:Screenshot 2025-12-16 17-56-16.png|sans_cadre|1018x1018px]]
; 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.

==== 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]]

'''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.