DonutBlog

Etude d’une balance connectée

2025-08-04T01:00:00+02:00

En août 2017, je m’étais amusé à pirater ma balance connectée de marque Withing afin de récupérer directement mes mesures de poids sans passer par l’interface Withings.

L’idée mise en place était une technique classique de man in the middle, exécutée from scratch pas à pas (l’exercice fut didactique).

Aujourd’hui, 8 ans plus tard, je remets la main par hasard sur ce projet que j’avais un peu oublié.

Je reproduis ci-dessous pour garder une trace. A noter que la plupart des informations ont été anonymisées… mais après 8 ans et un renouvellement intégral de mon matériel informatique (box, pc, raspberry etc.), il n’y a plus grand chose de sensible de toutes façon. Et je me suis depuis débarrassé de cette balance (coucou la Quadrature du Net).

Liste des outils utilisés
Introduction
Installation du système
- Passer en Azerty, mettre à jour le timezone et activer le serveur ssh
- Changer le nom et le mot de passe de l’utilisateur par défaut
Mise en place du point d’accès WiFi
Un premier sniffing du réseau
Sniffing de la balance
Pistes pour continuer

Liste des outils utilisés

hostapd
iptables
isc-dhcp-server
systemctl
syslog
tcpdump
lsof
netcat
nmap
arp
dig

Introduction

Je dispose depuis quelques temps d’une balance Withings Body WS-50. Cette balance fait partie des objets dits “connectés” : lorsque je me pèse, la balance envoie mon poids aux serveurs Withings. Je dois par la suite me connecter à ces serveurs pour voir l’évolution de mon poids.

Je trouve dommage de ne pas pouvoir récupérer directement les informations de la balance pour en faire ce que je souhaite et j’ai donc eu envie de capturer les trames que cette balance envoie régulièrement.

Pour ce faire, je vais utiliser un vieux Raspberry Pi que je vais reconfigurer en mode point d’accès.

Je pense procéder en deux étapes.

Tout d’abord il faut faire du Reverse Engineering sur la balance afin de déterminer comment les informations utiles sont envoyées aux serveurs Withings. Cela se décompose en plusieurs étapes :

Mettre en place un point d’accès Wi-Fi sur le Raspberry via hostapd
Mettre en place un partage de connection entre les interfaces Wifi et Ethernet du Rasberry
Filtrer les accès au Raspberry via Iptables et filtrage par adresse MAC
Tester la connection internet d’un portable
Tester la connection de la balance au Raspberry
Capture des trames émises par la balance via tcpdump sur le Raspberry

Dans un second temps, il faudra automatiser la récupération de ces informations. J’essaierai de faire ça le plus proprement possible via la programmation d’un service. Les étapes seront donc :

Mise à jour des règles d’Iptables (inutile de garder le partage de connection Internet…)
Programmation d’un service pour gérer la capture des trames et l’extraction des informations utiles
Eventuellement mise en forme des données de poids via un petit script Python

Je dispose du matériel suivant :

un “vieux” Raspberry Pi B embarquant 512 Mo de RAM
un dongle WiFi qui traînait chez moi
une balance connectée Wihtings Body WS-50
deux pc sous Ubuntu qui, placés à deux endroits différents de mon réseau, me permettront de vérifier que tout se passe comme convenu.

Au final, la topologie du réseau que je souhaite mettre en place est résumée ci-dessous (les IPs sont anonymisées).

Installation du système

Nous récupérons la dernière version de Raspbian Jessie sur www.raspberrypi.org. Deux versions de Rasbian Jessie¹ sont désormais proposées : Desktop et Lite. La version Lite, comme son nom l’indique, est livrée avec le strict minimum applicatif et n’intégre pas d’environnement graphique. C’est cette version que j’ai choisi pour notre bridge.

On prépare tout d’abord la carte SD avec l’incontournable commande dd. L’option conv=sync,noerror est un petit raffinement qui permet en cas d’erreur de padder le bloc de données avec des 0. Ainsi seul le bloc où l’erreur survient est illisible et ça ne décale pas le reste des données. Bon, personnellement en cas d’erreur je relance la commande ou alors je change de carte SD…

$ sudo dd bs=1m if=2017-07-05-raspbian-jessie-lite.img
of=/dev/rdisk2 conv=sync,noerror

On installe ensuite la carte SD dans le raspberry et on boot. L’utilisateur par défaut s’appelle pi et son mot de passe est raspberry, le serveur ssh n’est pas activé et le clavier est en qwerty… Bref, y’a du boulot !

Passer en Azerty, mettre à jour le timezone et activer le serveur ssh

La première étape est de lancer la commande raspi-config pour passer en azerty, régler le timezone sur Europe/Paris et d’activer le serveur ssh. On en profitera également pour renommer la machine “donutbridge”.

$ sudo raspi-config

Petite subtilité de raspbian : il faut créer un fichier ssh dans /boot/ pour activier le serveur !

$ sudo touch /boot/ssh

On édite avant de rebooter le fichier /etc/ssh/sshd_config, essentiellement pour changer le port par défaut de ssh

On vérifie au reboot que le service ssh est bien lancé :

$ systemctl status ssh
ssh.service - OpenBSD Secure Shell server
	Loaded: loaded
	Active : active (running)

Changer le nom et le mot de passe de l’utilisateur par défaut

Changer le nom et le mot de passe de l’utilisateur principal est étonnament une tâche assez délicate. Il faut commencer par autoriser le login root avec sudo passwd root puis on utilise la commande usermod. L’option -l donne le nouveau login, -d définit l’emplacement du nouveau $HOME et enfin -m indique à usermod qu’il faut déplacer le répertoire utilisateur initial.

$ mkdir /home/donut
$ usermod -l donut -m -d /home/donut pi

On se déloggue de root et on se loggue en tant que donut : ça marche ! Première chose à faire : désactiver le login root via sudo passwd -l root. On remarque au passage que l’utilisateur donut est toujours sudoer, usermod fait bien les choses.

Il ne reste plus qu’à changer les droits de /home/donut et à supprimer /home/pi

$ sudo chown -R donut:pi /home/donut
$ sudo rm -rf /home/pi

Mise en place du point d’accès WiFi

On va commencer par voir ce qu’il se passe lorsqu’on branche notre dongle WiFi

$ lsusb
[...]
Bus 001 Device 005: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter
[...]

Bon le dongle semble être correctement détecté. Vérifions qu’il supporte le mode point d’accès, AP :

$ iw list
[...]
Supported interface modes:
	* IBSS
	* managed
	* AP
	* monitor
	* P2P-client
	* P2P-GO
[...]

Installation de Hostapd

On installe ensuite hostapd :

$ sudo apt install hostapd

On copie le fichier de configuration par défaut de hostapd

$ cd /etc/hostapd/
$ sudo cp /usr/share/doc/hostapd/examples/hostapd.conf.gz ./
$ sudo gunzip hostapd.conf.gz

On prendra également soin d’indiquer l’emplacement de ce fichier de configuration dans le fichier /etc/default/hostapd :

DAEMON_CONF="/etc/hostapd/hostapd.conf"

Le fichier de configuration contient plusieurs paramètres que j’ai configuré ainsi :

interface=wlan0
driver=nl80211
logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=2
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
ssid=bridge
country_code=FR
hw_mode=g
channel=1
beacon_int=100
dtim_period=2
max_num_sta=255
rts_threshold=2347
fragm_threshold=2346
macaddr_acl=1
accept_mac_file=/etc/hostapd/hostapd.accept
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=totorototoro
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
rsn_pairwise=CCMP

On remarquera le “channel=1” qui a été choisi particulièrement pour ne pas interférer avec le WiFi de la maison. Le champ macaddr_acl permet de définir la politique de gestion des adresses MAC (liste noire, liste blanche ou désactivé). Je n’ai pas vu d’impact pour le moment… Enfin, le champ ignore_broadcast_ssid permet de ne pas diffuser le ssid : pratique en conditions opérationnelles, pour ajouter encore un peu de sécurité !

On tente notre première connexion : on lance manuellement le serveur côté Raspberry et on tente de s’y connecter via un portable. Ca passe crème !

$ sudo systemctl stop hostapd # lancement en manuel
$ sudo hostapd ./hostapd.conf 
Configuration file: ./hostapd.conf
Using interface wlan0 with hwaddr 00:13:ef:d0:2e:bc and ssid "test"
wlan0: interface state UNINITIALIZED->ENABLED
wlan0: AP-ENABLED 
wlan0: STA 9c:f3:87:aa:fe:62 IEEE 802.11: associated
wlan0: AP-STA-CONNECTED 9c:f3:87:aa:fe:62
wlan0: STA 9c:f3:87:aa:fe:62 RADIUS: starting accounting session 597E4C38-00000000
wlan0: STA 9c:f3:87:aa:fe:62 WPA: pairwise key handshake completed (RSN)

Filtrage par adresse MAC via Hostapd

Commençons maintenant les bonnes pratiques : on va mettre en place un filtrage par adresses MAC directement dans hostapd. Toujours dans notre fichier de configuration hostapd.conf nous indiquons :

macaddr_acl=1
accept_mac_file=/etc/hostapd/hostapd.accept

Le fichier hostapd.accept contiendra uniquement les adresses MAC de mon portable et de la balance.

Comme indiqué plus haut, cela n’a pas l’air d’avoir d’impact pour le moment : je peux tout à fait me connecter avec un autre poste. A faire : regarder la doc de Hostapd en détail pour voir à quel moment le filtrage se fait…

Serveur DHCP

A ce stade, les équipements peuvent se connecter sur le réseau “bridge” mais ils ne peuvent pas faire grand chose d’autre. Pour commencer il leur faut une adresse IP. Etant donné que seule la balance est sensée se connecter sur “bridge” on pourrait passer par un adressage fixe mais qui peut le plus peut le moins : on va passer par un serveur DHCP qui écoutera en permanence sur wlan0 en attente de datagramme “DHCP Discover”. On le définiera de telle sorte que deux postes tout au plus pourront se connecter en même temps sur l’interface.

On va tout d’abord définir un réseau d’accès en 192.168.8.0 sur l’interface wlan0

$ sudo ifconfig wlan0 down
$ sudo ifconfig wlan0 192.168.10.1 netmask 255.255.255.0 up
$ ifconfig
eth0    Link encap:Ethernet  HWaddr b8:27:eb:9e:fa:cd  
	inet addr:192.168.0.38  Bcast:192.168.0.255  Mask:255.255.255.0
	inet6 addr: fe80::328c:d511:1ca0:895d/64 Scope:Link
	UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
	RX packets:10439 errors:0 dropped:1 overruns:0 frame:0
	TX packets:3542 errors:0 dropped:0 overruns:0 carrier:0
	collisions:0 txqueuelen:1000 
	RX bytes:2023402 (1.9 MiB)  TX bytes:596809 (582.8 KiB)

lo      Link encap:Local Loopback  
	inet addr:127.0.0.1  Mask:255.0.0.0
	inet6 addr: ::1/128 Scope:Host
	UP LOOPBACK RUNNING  MTU:65536  Metric:1
	RX packets:0 errors:0 dropped:0 overruns:0 frame:0
	TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
	collisions:0 txqueuelen:1 
	RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan0   Link encap:Ethernet  HWaddr 00:13:ef:d0:2e:bc  
	inet addr:192.168.10.1  Bcast:192.168.10.255  Mask:255.255.255.0
	UP BROADCAST MULTICAST  MTU:1500  Metric:1
	RX packets:0 errors:0 dropped:8 overruns:0 frame:0
	TX packets:0 errors:0 dropped:41 overruns:0 carrier:0
	collisions:0 txqueuelen:1000 
	RX bytes:28355 (27.6 KiB)  TX bytes:11913 (11.6 KiB)

Alors là, ça marche bien mais ce n’est pas perenne. Pour que le système se souvienne, il faut éditer le fichier /etc/network/interfaces et ajouter les lignes :

auto wlan0
iface wlan0 inet static
	address 192.168.10.1
	netmask 255.255.255.0

On rédémarre ensuite le réseau avec :

$ sudo systemctl daemon-reload

Le serveur DHCPD n’étant pas installé par défaut, on l’installe avec $ sudo apt install isc-dhcp-server. Alors là, le serveur échoue lamentablement au démarrage, ce qui est normal : il est configuré par défaut pour gérer eth0…

On modifie le fichier de configuration /etc/dhcp/dhcpd.conf pour définir le réseau ainsi que la plage d’adresse IP disponibles :

option domain-name-servers 192.168.10.0;
authoritative;

# Declaration du subnet
subnet 192.168.10.0 netmask 255.255.255.0 {
        option domain-name "WiFi.localhost";
	option routers 192.168.10.1;
	option subnet-mask 255.255.255.0;
	option broadcast-address 192.168.10.0;
	option domain-name-servers 192.168.10.1;
	range dynamic-bootp 192.168.10.10 192.168.10.11;
	}

On remarquera au passage que le domain-name-servers pointe vers la box Internet (192.168.0.254). Ceci signifie que lorsqu’une machine du réseau 192.168.10.0 demandera une résolution d’adresse (du genre “quelle est l’IP de www.forum.ubuntu.org ?), le raspberry lui répondra en substance “oh je ne sais pas trop, demande à la box Internet”. C’est une solution simple qui nous évite de devoir mettre en place un serveur cache DNS mais il a un coût : si 50 machines sur 192.168.10.0 demandent l’IP de www.forum.ubuntu.org, notre raspberry devra relayer 50 fois cette demande à la box.

Quoiqu’il en soit on prendra soin de définir l’interface à gérer dans /etc/default/isc-dhcp-server :

DHCPD_CONF=/etc/dhcp/dhcpd.conf
INTERFACES="wlan0"

On redémarre les services hostapd et isc-dhcp-server via systemctl et cette fois-ci losqu’on se connecte via le portable, on a une IP en 192.168.10.0 ! Parallèlement nous pouvons vérifier l’ensemble des machines connectées sur l’interface wlan0 avec hostapd_cla. Cette commande va nous retourner un certain nombre d’informations par poste connecté, dont son adresse MAC. La commande arp permet dans un second temps de voir la correspondance Adresse MAC / Adresse IP.

$ sudo hostapd_cli all_sta
Selected interface 'wlan0'
9c:f3:87:aa:fe:62
flags=[AUTH][ASSOC][AUTHORIZED]
aid=0
capability=0x0
listen_interval=0
supported_rates=
timeout_next=NULLFUNC POLL
dot11RSNAStatsSTAAddress=9c:f3:87:aa:fe:62
dot11RSNAStatsVersion=1
dot11RSNAStatsSelectedPairwiseCipher=00-0f-ac-4
dot11RSNAStatsTKIPLocalMICFailures=0
dot11RSNAStatsTKIPRemoteMICFailures=0
hostapdWPAPTKState=11
hostapdWPAPTKGroupState=0
rx_packets=0
tx_packets=0
rx_bytes=0
tx_bytes=0
connected_time=11
$ arp | grep 9c:f3:87:aa:fe:62
192.168.10.10            ether   9c:f3:87:aa:fe:62   C                     wlan0

Arrivé à ce stade c’est un peu mieux mais on est loin d’avoir terminé… Il nous reste à établir le partage de la connection Internet. Ca tombe bien, c’est l’enjeu de la section suivante.

Néanmoins avant de passer à la section suivante, il est intéressant de regarder un moment les log de notre serveur DHCP.

$ tail -f /var/log/syslog | grep -i dhcp
Aug  2 06:30:43 donutbridge dhcpd: DHCPDISCOVER from 00:13:ef:d0:2e:bc (donutbridge) via wlan0
Aug  2 06:30:44 donutbridge dhcpd: DHCPOFFER on 192.168.10.10 to 00:13:ef:d0:2e:bc (donutbridge) via wlan0
[...]

Tiens, des messages DHCP Discover sont envoyés par l’adresse MAC 00:13:ef:d0:2e:bc ? Si on regarde la sortie de notre ifconfig (cf. les sections précédentes), on se rend compte que cela correspond à notre interface wlan0 ! Notre serveur DHCP tente régulièrement d’adresser une IP à wlan0, ce n’est pas du tout correct !

Pourquoi est-ce que wlan0 émet régulièrement des datagrammes DHCP Discover ? La réponse se trouve grâce à systemctl :

$ sudo systemctl status dhcpcd.service 
	dhcpcd.service - dhcpcd on all interfaces

Notre système embarque un client DHCP qui, par défaut, écoute sur TOUTES les interfaces (donc également sur wlan0 !). Il nous faut changer ce comportement pour être plus propre. Il suffit de rajouter la ligne suivante dans /etc/dhcpcd.conf :

# Donut 2017-08-02 : we DO NOT listen on wlan0 interface
denyinterfaces wlan0

On recharge ensuite la configuration avec systemctl daemon-reload. A présent si on regarde les logs de dhcpd, on ne voit plus passer de datagrammes DHCPDISCOVER sur wlan0 ! Passons maintenant au partage de connection proprement dit.

IP Forwarding et règles de routage

Pour commencer, il faut autoriser sur notre Raspberry l’IP Forwarding, c’est-à-dire la capacité à trasmettre sur une interface (ex: wlan0) des trames reçues sur une autre interface (ex: eth0). Encore une fois deux solutions existent : la temporaire et la pérenne.

Pour activer l’IP Forwarding le temps de la session, il suffit de mettre un “1” dans le fichier /proc/sys/net/ipv4/ip_forward. pour la solution pérenne, il faut éditer le fichier /etc/sysctl.conf et ajouter la ligne :

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

A ce stade, les interfaces devraient être correctement configurées et notre Rasberry devrait savoir où envoyer n’importe quel paquet qu’il reçoit. Vérifions cela :

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.254   0.0.0.0         UG    202    0        0 eth0
192.168.0.0     *               255.255.255.0   U     202    0        0 eth0
192.168.10.0    *               255.255.255.0   U     0      0        0 wlan0

Comme nous le voyons, il sait que :

les paquets à destination du réseau 192.168.10.0 sont à envoyer sur l’interface wlan0
les paquets à destination du réseau 192.168.0.0 sont à envoyer sur l’interface eth0
tous les autres paquets (principalement à destination d’internet donc) devront être envoyé au routeur par défaut, ici 192.168.0.254, autrement dit ma box internet… qui est accessible sur l’interface eth0

A ce stade, les routes sont correctes et le Rasberry est autorisé à faire de la redirection de paquet. Si depuis le réseau 192.168.10.0 je ping une machine sur 192.168.0.0, la machine destinataire devrait voir arriver le ping. Elle va y répondre mais notre émetteur ne recevra jamais la réponse.

Regardons cela plus en détail et rappelons-nous la topologie actuelle de notre réseau (voir la figure en début d’article). J’utilise deux PC additionnels que je place judicieusement sur le réseau :

$PC_1$, d’IP 192.168.10.11, est placé au même niveau que la balance,
$PC_2$, d’IP 192.168.0.39 est placé au même niveau que l’interface eth0 du Raspberry.

Les IP de nos différents équipements sont donc résumées dans le tableau ci-dessous

Machine	Interface	IP
$PC_1$	eth0	192.168.10.11
$PC_2$	eth0	192.168.0.39
Raspberry	eth0	192.168.0.38
Raspberry	wlan0	192.168.10.1
Box internet	eth0	192.168.0.1

Maintenant regardons ce qu’il se passe si, à ce stade de nos développements, nous

essayons de pinger $PC_2$ depuis le Raspberry
essayons de pinger $PC_2$ depuis $PC_1$

Voici ce que nous obtenons dans le premier cas : la colonne de gauche représente le Raspberry, celle de droite $PC_2$. Je me sers de la commande ping pour envoyer des pings et tcpdump pour écouter (remarquez l’option -p icmp qui me permet de n’afficher que les trames du protocole icmp auquel ping appartient). On remarque non seulement $PC_2$ reçoit bien les ping du Raspberry, mais le Raspberry reçoit les réponses de $PC_2$ !

Raspberry :

$ ping -c 3 192.168.0.39 # Terminal du raspberry
PING 192.168.0.39 (192.168.0.39) 56(84) bytes of data.
64 bytes from 192.168.0.39: icmp_seq=1 ttl=64 time=0.469 ms
64 bytes from 192.168.0.39: icmp_seq=2 ttl=64 time=0.521 ms
64 bytes from 192.168.0.39: icmp_seq=3 ttl=64 time=0.534 ms
--- 192.168.0.39 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.469/0.508/0.534/0.028 ms

Terminal de $PC_2$

$ sudo tcpdump -p icmp # Terminal de PC_2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp7s0, link-type EN10MB (Ethernet), capture size 262144 bytes
23:29:17.783149 IP 192.168.0.38 > 192.168.0.39: ICMP echo request, id 2107, seq 1, length 64
23:29:17.783160 IP 192.168.0.39 > 192.168.0.38: ICMP echo reply, id 2107, seq 1, length 64
23:29:18.785152 IP 192.168.0.38 > 192.168.0.39: ICMP echo request, id 2107, seq 2, length 64
23:29:18.785171 IP 192.168.0.39 > 192.168.0.38: ICMP echo reply, id 2107, seq 2, length 64
23:29:19.786414 IP 192.168.0.38 > 192.168.0.39: ICMP echo request, id 2107, seq 3, length 64
23:29:19.786437 IP 192.168.0.39 > 192.168.0.38: ICMP echo reply, id 2107, seq 3, length 64

Maintenant, refaisons la même manip mais cette fois-ci c’est $PC_1$ qui envoie les pings. On s’aperçoit bien que $PC_2$ reçoit bien les pings et qu’il y répond, ce qui prouve que le routage et l’IP Forwarding du Raspberry fonctionnent bien comme il faut. En revanche, le echo reply ne parvient jamais à $PC_1$, car ni $PC_1$ ni le Rasberry ni même la box Internet ne savent où diable se cachent les machines en 192.168.10.XX. Il nous manque bien une étape, et c’est la NAT.

Terminal de $PC_1$

$ ping -c 3 192.168.0.39 # Terminal de PC_1
PING 192.168.0.39 (192.168.0.39) 56(84) bytes of data.
Request timeout foricmp_seq 1
Request timeout foricmp_seq 2
Request timeout foricmp_seq 3
--- 192.168.0.39 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss

Terminal de $PC_2$

$ sudo tcpdump -p icmp # Terminal de PC_2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp7s0, link-type EN10MB (Ethernet), capture size 262144 bytes
23:29:42.560148 IP 192.168.10.11 > 192.168.0.39: ICMP echo request, id 22340, seq 1, length 64
23:29:42.560161 IP 192.168.0.39 > 192.168.10.11: ICMP echo reply, id 22340, seq 1, length 64
23:29:43.549379 IP 192.168.10.11 > 192.168.0.39: ICMP echo request, id 22340, seq 2, length 64
23:29:43.549394 IP 192.168.0.39 > 192.168.10.11: ICMP echo reply, id 22340, seq 2, length 64
23:29:44.549742 IP 192.168.10.11 > 192.168.0.39: ICMP echo request, id 22340, seq 3, length 64
23:29:44.549756 IP 192.168.0.39 > 192.168.10.11: ICMP echo reply, id 22340, seq 3, length 64

Petit aparté avant de poursuivre : afin de partager la connection Internet, nous aurions pu choisir de mettre en place un pont réseau, c’est-à-dire une interconnection de réseaux de niveau 2 au niveau du Raspberry (donc wlan0 et eth0). Dans ce cas, toutes mes machines connectées sur wlan0 auraient eu une IP en 192.168.0.X attribuée directement par ma box internet. Le serveur DHCP aurait été superflu, de même que le routage NAT. C’est une autre option possible mais qui n’est pas détaillée ici.

Quoiqu’il en soit, regardons comment modifier la NAT pour gérer les machines connectées sur wlan0. Principalement deux solutions existent : la SNAT et l’IP Mascarade. Etant donné que l’IP de mon interface eth0 peut-être définie en statique (via les options du serveur DHCP de ma box Internet), j’ai opté pour la SNAT qui est je pense plus légère.

La commande pour mettre en place la SNAT est la suivante :

$ sudo iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 192.168.0.38

Cette commande demande au Rasberry de modifier sa table NAT (-t nat), et d’ajouter une nouvelle règle dans la chaîne POSTROUTING (-A POSTROUTING) pour les paquets s’apprétant à sortir sur son interface eth0 (-o eth0). Pour ces paquets là, et ces paquets là seulement, on met en place une SNAT (-j SNAT) et on spécifie que l’IP source du paquet sera celle de l’interface eth0 du Raserry (--to-source 192.168.0.38).

En clair, cela veut dire que tout paquet qui s’apprête à sortir du Rasberry via son interface eth0 (par exemple le ping du $PC_1$ de tout à l’heure) verra son IP source changée en celle du Raspberry/eth0 et le Raspberry se charge tout seul comme un grand de garder les comptes et, lorsque les paquets retour lui sont adressés, de redispatcher ensuite sur le réseau 192.168.10.0.

Ainsi, après avoir appliqué la règle iptables, refaisons notre manip du ping $PC_1 \to$ Raspberry. Cette fois-ci, on remarque ça marche et que les requêtes reçues par $PC_2$ ne proviennent non plus de $PC_1$ (192.168.10.11) mais du Raspberry (192.168.0.38) !

Terminal de $PC_1$

$ ping -c 3 192.168.0.39 # Terminal de PC_1
PING 192.168.0.39 (192.168.0.39) 56(84) bytes of data.
64 bytes from 192.168.0.39: icmp_seq=1 ttl=64 time=0.469 ms
64 bytes from 192.168.0.39: icmp_seq=2 ttl=64 time=0.521 ms
64 bytes from 192.168.0.39: icmp_seq=3 ttl=64 time=0.534 ms
--- 192.168.0.39 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.469/0.508/0.534/0.028 ms

Terminal de $PC_2$

$ sudo tcpdump -p icmp # Terminal de PC_2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp7s0, link-type EN10MB (Ethernet), capture size 262144 bytes
23:29:17.783149 IP 192.168.0.38 > 192.168.0.39: ICMP echo request, id 2107, seq 1, length 64
23:29:17.783160 IP 192.168.0.39 > 192.168.0.38: ICMP echo reply, id 2107, seq 1, length 64
23:29:18.785152 IP 192.168.0.38 > 192.168.0.39: ICMP echo request, id 2107, seq 2, length 64
23:29:18.785171 IP 192.168.0.39 > 192.168.0.38: ICMP echo reply, id 2107, seq 2, length 64
23:29:19.786414 IP 192.168.0.38 > 192.168.0.39: ICMP echo request, id 2107, seq 3, length 64
23:29:19.786437 IP 192.168.0.39 > 192.168.0.38: ICMP echo reply, id 2107, seq 3, length 64

Dernière façon amusante de voir la SNAT en action, nous allons utiliser ncat. C’est un outil qui permet de mettre en place des sockets réseau très simplement. Sur notre $PC_2$, nous écoutons sur le port (arbitraire) 52201 via la commande : $ sudo ncat -v -l 52201.

Sur notre $PC_1$, nous tentons une connection sur ce (mini) serveur via la commande : sudo ncat -v 192.168.0.39 52201.

Si tout se passe bien, les deux machines se connectent et tout ce qu’on écrit dans le terminal de l’une se retrouvera en miroir dans le terminal de l’autre ! Du côté du client $PC_1$ tout se passe comme si on dialoguait directement avec $PC_2$ d’IP 192.168.0.39 et sur son port 52201. Et comme on s’y attendait, on remarque que $PC_2$ est persuadé de communiquer avec notre Raspberry (d’IP 192.168.0.38, rappelons-le). On comprend désormais mieux le nom d’IP masquerade !

Terminal de $PC_1$ (client)

$ sudo ncat -v 192.168.0.39 52201 # Terminal de PC_1 (client)
found 0 associations
found 1 connections:
	1: flags=82<CONNECTED,PREFERRED>
	   outif en0
	   src 192.168.10.10 port 64333
	   dst 192.168.0.39 port 52201
	   rank info not available
	   TCP aux info available
Connection to 192.168.0.39 port 52201 [tcp/*] succeeded!
Hello
Coucou

Terminal de $PC_2$ (serveur)

$ sudo ncat -v -l 52201 # Terminal de PC_2 (serveur)
Ncat: Version 7.01 ( https://nmap.org/ncat )
Ncat: Listening on :::52201
Ncat: Listening on 0.0.0.0:52201
Ncat: Connection from 192.168.0.38.
Ncat: Connection from 192.168.0.38:64333.
Hello
Coucou

Bref, tout marche bien dans le meilleur des mondes. Il nous reste néanmoins encore une dernière étape pour iptables : rendre notre régle persistente après un reboot. On va faire ça à l’ancienne avec une démarche à la SystemV. L’intérêt est plus didactique qu’autre chose, vu que je verrai après les scripts d’init systemd, on verra la différence de philosophie ! Si j’ai bien compris de toute façon, c’est systemd qui va gérer notre script systemV en rétro-compatibilité.

La démarche pour SystemV est la suivante. Si je veux créer un nouveau service, je crée un script de lancement dans /etc/init.d/ avec un entête contenant différentes informations comme le runlevel où le service doit être activé et les dépendances (par exemple, pour iptables il faut attendre que le réseau soit activé). Notre script devra également contenir les actions à effectuer lorsqu’on arrête, démarre ou interroge le service. On utilise ensuite la commande update-rc.d mon_service defaults pour mettre en place le service. Init.d va lire l’entête de notre fichier et placer des liens symboliques dans les différents /etc/rcN.d/.

Mais dans notre cas, c’est une démarche bien trop lourde : notre commande iptables a vocation à être exécutée une seule fois au démarrage du raspberry. Pour cela, on dispose du script /etc/rc.local/ : il suffit de rajouter notre règle là dedans et le tour est joué !

Voici l’état actuel de notre table NAT :

$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
SNAT       all  --  anywhere             anywhere             to:192.168.0.38

On demande à iptables de sauvegarder l’état actuel des règles dans un fichier de sortie grâce à la commande iptables-save. Cette commande est optionnelle dans la mesure où notre firewall est pour le moment très simple (une seule règle !) mais bon…

$ sudo sh -c "iptables-save > /etc/iptables.rules"
donut@donutbridge:~$ cat /etc/iptables.rules 
# Generated by iptables-save v1.4.21 on Fri Aug  4 07:14:07 2017
*nat
:PREROUTING ACCEPT [18:2088]
:INPUT ACCEPT [18:2088]
:OUTPUT ACCEPT [8:692]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j SNAT --to-source 192.168.0.38
COMMIT
# Completed on Fri Aug  4 07:14:07 2017
# Generated by iptables-save v1.4.21 on Fri Aug  4 07:14:07 2017
*filter
:INPUT ACCEPT [624:77121]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [335:33556]
COMMIT
# Completed on Fri Aug  4 07:14:07 2017

Il nous reste maintenant à ajouter une ligne dans /etc/rc.local/ pour charger notre règle :

# Donut 2017-08-04 : regle iptables pour SNAT wlan0 vers eth0
iptables-restore /etc/iptables.rules

Désormais lorsqu’on redémarre le raspberry, le réseau sera convenablement paramétré pour la SNAT !

Un premier sniffing du réseau

La topologie (simplifiée) de notre réseau est rappelée ci-dessous. Nous allons reprendre l’exemple du serveur minimaliste ncat de la section précédente afin de voir passer les trames sur le Raspberry. Rappelons que $PC_2$ écoute sur le port 52201 et que $PC_1$ va le contacter. $PC_1$ va envoyer le message “HELLO” auquel le $PC_2$ répondra “COUCOU”.

Les options de notre tcpdump sont les suivantes :

l’option -n impose l’affichage décimal des IP et des ports,
l’option -X demande l’affichage hexadécimal et ASCII des trames IP
l’option -v de mande à tcpdump d’être plus bavard, en particulier il va décortiquer plus en profondeur le header IP (pour notamment afficher le protocole de niveau supérieur)
l’option -c N demande à tcpdump de s’arrêter après avoir reçu N trames
et enfin l’option -i interface indique l’interface de capture, par exemple -i wlan0 ou -i any

On peut également spécifier à tcpdump une expression de filtrage comme argument, nous indiquons ici “port not 22 and host 192.168.0.27” qui demande de tout écouter sauf le port 22 (la session ssh qui me permet de piloter le Raspberry) du moment qu’un des interlocuteurs (émetteur ou destinataire) est $PC_2$ (d’IP 192.168.0.27). Pour des raisons de clarté, je ne remets pas les lignes netcat des clients/serveur mais juste les informations capturées par tcpdump.

Dans un premier temps, on ne capture que la connection entre client et serveur; c’est-à-dire qu’on arrête tcpdump juste après avoir exécuté nc -v 192.168.0.27 52201 sur le $PC_1$. Nous indiquons également à tcpdump de s’arrêter après avoir reçu 3 trames. J’ai remarqué que l’option -i any rencontrait quelques difficultés pour capturer le tout premier paquet. J’ai donc executé la même commande sur deux shells différents : l’une avec l’option -i wlan0 et l’autre avec l’option -i eth0. J’ai rajouté un grep ensuite pour ne garder que le header de chaque trame.

Nous obtenons le résultat suivant. Il y a plein de choses à en dire !

Tout d’abord, si on regarde bien, on se rend compte que chaque trame IP est dupliquée. La toute première trame IP est sur l’interface wlan0 et les correspondants sont 192.168.10.10.54064 > 192.168.0.27.52201. On voit que le raspberry émet aussitôt une trame sur sont interface eth0 dont les correpondants sont 192.168.0.38.54064 > 192.168.0.27.52201. Cette comparaison met en évidence le mécanisme de NAT : $PC_2$ cherche à contacter $PC_1$ sur son port 52201, il indique aussi son port de retour (ici 54064). Le Raspberry a modifié l’IP source en sa propre IP (ainsi 192.168.10.10 devient 192.168.0.38), le port source quant à lui n’a pas changé.

Par ailleurs, si on regarde l’entête de chaque trame (enrichi rappelons-le grâce à l’option -v de tcpdump) on remarque que le protocole de niveau supérieur est le TCP. On s’en rend compte également quand on remarque que les trois premières trames échangées (le -n 3 n’était pas choisi au hasard) ont le flag [S], [S.] et enfin [.]. Cela correspond aux trois indicateurs SYN, SYN-ACK et ACK qui constituent la fameuse triple poignée de main d’une ouverture de connexion TCP.

$ sudo tcpdump -n -X -c 3 -i wlan0 -v host 192.168.0.27 | grep -A 1 IP
53:19.542053 IP (tos 0x0, ttl 64, id 35611, offset 0, flags [DF], proto TCP (6), length 64)
168.10.10.54064 > 192.168.0.27.52201: Flags [S], cksum 0xb9ce (correct), seq 1191224222, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1045703083 ecr 0,sackOK,eol], length 0
53:19.543017 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
168.0.27.52201 > 192.168.10.10.54064: Flags [S.], cksum 0xd86f (correct), seq 3811497698, ack 1191224223, win 28960, options [mss 1460,sackOK,TS val 11781739 ecr 1045703083,nop,wscale 7], length 0
53:19.546340 IP (tos 0x0, ttl 64, id 46676, offset 0, flags [DF], proto TCP (6), length 52)
168.10.10.54064 > 192.168.0.27.52201: Flags [.], cksum 0x6840 (correct), ack 1, win 4117, options [nop,nop,TS val 1045703090 ecr 11781739], length 0

$ sudo tcpdump -n -X -c 3 -i eth0 -v port not 22 and host 192.168.0.27 | grep -A 1 IP
53:19.542387 IP (tos 0x0, ttl 63, id 35611, offset 0, flags [DF], proto TCP (6), length 64)
168.0.38.54064 > 192.168.0.27.52201: Flags [S], cksum 0xc3b2 (correct), seq 1191224222, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1045703083 ecr 0,sackOK,eol], length 0
53:19.542874 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
168.0.27.52201 > 192.168.0.38.54064: Flags [S.], cksum 0xe253 (correct), seq 3811497698, ack 1191224223, win 28960, options [mss 1460,sackOK,TS val 11781739 ecr 1045703083,nop,wscale 7], length 0
53:19.546498 IP (tos 0x0, ttl 63, id 46676, offset 0, flags [DF], proto TCP (6), length 52)
168.0.38.54064 > 192.168.0.27.52201: Flags [.], cksum 0x7224 (correct), ack 1, win 4117, options [nop,nop,TS val 1045703090 ecr 11781739], length 0

Bref tout ceci est plutôt positif. Regardons maintenant si nous pouvons, via tcpdump, récupérer les informations échangées entre $PC_1$ et $PC_2$. Ecouter sur les deux interfaces eth0 et wlan0 n’avait qu’un but didactique pour voir la SNAT en action, nous nous restreindrons désormais à la seule interface wlan0. Voici donc ce qu’on obtient lorsque $PC_1$ envoie le message “HELLO” auquel le $PC_2$ répond “COUCOU”.

Nous retrouvons bien au début notre triple poignée de main, suivie de deux messages avec leur acquittement. On remarque que les chaînes “HELLO” et “COUCOU” apparaissent bien en clair sur la sortie de tcpdump et qu’elles sont en fin de trame IP.

$ sudo tcpdump -n -X -v -i wlan0 host 192.168.0.27
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:48:51.967582 IP (tos 0x0, ttl 64, id 15450, offset 0, flags [DF], proto TCP (6), length 64)
    192.168.10.10.54265 > 192.168.0.27.52201: Flags [S], cksum 0x464a (correct), seq 4251772336, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1063428825 ecr 0,sackOK,eol], length 0
	0x0000:  4500 0040 3c5a 4000 4006 72e8 c0a8 0a0a  E..@<Z@.@.r.....
	0x0010:  c0a8 001b d3f9 cbe9 fd6c e5b0 0000 0000  .........l......
	0x0020:  b002 ffff 464a 0000 0204 05b4 0103 0305  ....FJ..........
	0x0030:  0101 080a 3f62 a2d9 0000 0000 0402 0000  ....?b..........
13:48:51.969090 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.27.52201 > 192.168.10.10.54265: Flags [S.], cksum 0xcfe8 (correct), seq 820279578, ack 4251772337, win 28960, options [mss 1460,sackOK,TS val 16214845 ecr 1063428825,nop,wscale 7], length 0
	0x0000:  4500 003c 0000 4000 3f06 b046 c0a8 001b  E..<..@.?..F....
	0x0010:  c0a8 0a0a cbe9 d3f9 30e4 791a fd6c e5b1  ........0.y..l..
	0x0020:  a012 7120 cfe8 0000 0204 05b4 0402 080a  ..q.............
	0x0030:  00f7 6b3d 3f62 a2d9 0103 0307            ..k=?b......
13:48:51.971944 IP (tos 0x0, ttl 64, id 37412, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.10.10.54265 > 192.168.0.27.52201: Flags [.], cksum 0x5fb8 (correct), ack 1, win 4117, options [nop,nop,TS val 1063428833 ecr 16214845], length 0
	0x0000:  4500 0034 9224 4000 4006 1d2a c0a8 0a0a  E..4.$@.@..*....
	0x0010:  c0a8 001b d3f9 cbe9 fd6c e5b1 30e4 791b  .........l..0.y.
	0x0020:  8010 1015 5fb8 0000 0101 080a 3f62 a2e1  ...._.......?b..
	0x0030:  00f7 6b3d                                ..k=
13:48:58.172315 IP (tos 0x0, ttl 64, id 52612, offset 0, flags [DF], proto TCP (6), length 58)
    192.168.10.10.54265 > 192.168.0.27.52201: Flags [P.], cksum 0x63df (correct), seq 1:7, ack 1, win 4117, options [nop,nop,TS val 1063435024 ecr 16214845], length 6
	0x0000:  4500 003a cd84 4000 4006 e1c3 c0a8 0a0a  E..:..@.@.......
	0x0010:  c0a8 001b d3f9 cbe9 fd6c e5b1 30e4 791b  .........l..0.y.
	0x0020:  8018 1015 63df 0000 0101 080a 3f62 bb10  ....c.......?b..
	0x0030:  00f7 6b3d 4845 4c4c 4f0a                 ..k=HELLO.
13:48:58.173811 IP (tos 0x0, ttl 63, id 4645, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.0.27.52201 > 192.168.10.10.54265: Flags [.], cksum 0x50a6 (correct), ack 7, win 227, options [nop,nop,TS val 16216396 ecr 1063435024], length 0
	0x0000:  4500 0034 1225 4000 3f06 9e29 c0a8 001b  E..4.%@.?..)....
	0x0010:  c0a8 0a0a cbe9 d3f9 30e4 791b fd6c e5b7  ........0.y..l..
	0x0020:  8010 00e3 50a6 0000 0101 080a 00f7 714c  ....P.........qL
	0x0030:  3f62 bb10                                ?b..
13:49:02.396522 IP (tos 0x0, ttl 63, id 4646, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.27.52201 > 192.168.10.10.54265: Flags [P.], cksum 0x4084 (correct), seq 1:9, ack 7, win 227, options [nop,nop,TS val 16217452 ecr 1063435024], length 8
	0x0000:  4500 003c 1226 4000 3f06 9e20 c0a8 001b  E..<.&@.?.......
	0x0010:  c0a8 0a0a cbe9 d3f9 30e4 791b fd6c e5b7  ........0.y..l..
	0x0020:  8018 00e3 4084 0000 0101 080a 00f7 756c  ....@.........ul
	0x0030:  3f62 bb10 2443 4f55 434f 550a            ?b..$COUCOU.
13:49:02.604305 IP (tos 0x0, ttl 63, id 4647, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.27.52201 > 192.168.10.10.54265: Flags [P.], cksum 0x4050 (correct), seq 1:9, ack 7, win 227, options [nop,nop,TS val 16217504 ecr 1063435024], length 8
	0x0000:  4500 003c 1227 4000 3f06 9e1f c0a8 001b  E..<.'@.?.......
	0x0010:  c0a8 0a0a cbe9 d3f9 30e4 791b fd6c e5b7  ........0.y..l..
	0x0020:  8018 00e3 4050 0000 0101 080a 00f7 75a0  ....@P........u.
	0x0030:  3f62 bb10 2443 4f55 434f 550a            ?b..$COUCOU.
13:49:02.683637 IP (tos 0x0, ttl 64, id 61743, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.10.10.54265 > 192.168.0.27.52201: Flags [.], cksum 0x2bb0 (correct), ack 9, win 4117, options [nop,nop,TS val 1063439532 ecr 16217452], length 0
	0x0000:  4500 0034 f12f 4000 4006 be1e c0a8 0a0a  E..4./@.@.......
	0x0010:  c0a8 001b d3f9 cbe9 fd6c e5b7 30e4 7923  .........l..0.y#
	0x0020:  8010 1015 2bb0 0000 0101 080a 3f62 ccac  ....+.......?b..
	0x0030:  00f7 756c                                ..ul
13:49:02.683664 IP (tos 0x0, ttl 64, id 44468, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.10.10.54265 > 192.168.0.27.52201: Flags [.], cksum 0x2b7c (correct), ack 9, win 4117, options [nop,nop,TS val 1063439532 ecr 16217504], length 0
	0x0000:  4500 0034 adb4 4000 4006 019a c0a8 0a0a  E..4..@.@.......
	0x0010:  c0a8 001b d3f9 cbe9 fd6c e5b7 30e4 7923  .........l..0.y#
	0x0020:  8010 1015 2b7c 0000 0101 080a 3f62 ccac  ....+|......?b..
	0x0030:  00f7 75a0                                ..u.

Maintenant que nous maîtrisons bien la manipulation de tcpdump, passons à l’espionnage de la balance !

Sniffing de la balance

Rappelons le fonctionnement de la balance :

quand je me pèse, mon poids s’affiche sur la balance (normal),
après un court instant, la balance me reconnaît et affiche mes initiales sur son écran,
régulièrement, la balance mesure le taux de CO2 dans l’air

A ce stade, je me pose plusieurs questions :

Est-ce que la balance chiffre ses données lorsqu’elle communique avec l’extérieur ? Si c’est le cas, toute mon opération tombe à l’eau !
Est-ce que la transmission du poids est synchrone avec le moment où je me pèse ? Existe-t’il un délai ?
A quelle fréquence est-ce que le taux de CO2 est-il mesuré ?
Est-ce une communication unilatérale ou bien la balance attend-elle un retour du serveur ?
En particulier, à quel endroit (côté balance ou côté serveur) s’effectue l’identification entre un poids et une personne ?

Il faudra garder tout ça en tête lorsqu’on regardera les trames…

Pour épurer au maximum les trames, je coupe la connexion WiFi de $PC_1$ et je vérfie que je ne le vois plus dans les associations de Hostapd :

$ sudo hostapd_cli all_sta
Selected interface 'wlan0'
9c:f3:87:aa:fe:62
flags=[AUTH][ASSOC][AUTHORIZED]
aid=0
capability=0x0
listen_interval=0
supported_rates=
timeout_next=NULLFUNC POLL
dot11RSNAStatsSTAAddress=9c:f3:87:aa:fe:62
dot11RSNAStatsVersion=1
dot11RSNAStatsSelectedPairwiseCipher=00-0f-ac-4
dot11RSNAStatsTKIPLocalMICFailures=0
dot11RSNAStatsTKIPRemoteMICFailures=0
hostapdWPAPTKState=11
hostapdWPAPTKGroupState=0
rx_packets=0
tx_packets=0
rx_bytes=0
tx_bytes=0
connected_time=20612

[ON COUPE LE WIFI DE PC_1]

$ sudo hostapd_cli all_sta
Selected interface 'wlan0'

Alors voici les trames intéressantes qui sont survenues juste après la pesée. Je remarque au passage que l’association poids-personne se fait vraisemblablement AVANT l’envoi d’une trame…

Tout d’abord, notre balance d’adresse MAC 00:24:e4:0d:34:38 se réveille et demande une IP à la cantonade. Notre serveur DHCP lui en servira une.

14:09:27.665777 IP (tos 0x0, ttl 255, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:24:e4:0d:34:38, length 300, xid 0x343606f7, Flags [none]

Peu après, notre balance qui a obtenu l’IP 192.168.10.12 demande à notre box internet quelle est l’IP du serveur wbs02-ws.withings.net. Notre box lui répond que ce serveur est accessible à l’adresse 89.30.121.150. Si on est parano, on peut contrôler que c’est bien correct grâce à la commande dig qui permet de faire des requêtes dns. Vraisemblablement, ce sera avec ce serveur que la balance va communiquer, retenons donc cette adresse elle sera sans doute utile dans la suite.

09:28.627479 IP (tos 0x0, ttl 255, id 2, offset 0, flags [none], proto UDP (17), length 67)
168.10.12.49153 > 192.168.0.254.53: 0+ A? wbs02-ws.withings.net. (39)
[...]
09:28.628502 IP (tos 0x0, ttl 63, id 38040, offset 0, flags [DF], proto UDP (17), length 112)
168.0.254.53 > 192.168.10.12.49153: 0 2/0/0 wbs02-ws.withings.net. CNAME ws.withings.net., ws.withings.net. A 89.30.121.150 (84)

$ dig wbs02-ws.withings.net

; <<>> DiG 9.10.3-P4-Ubuntu <<>> wbs02-ws.withings.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35231
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;wbs02-ws.withings.net.		IN	A

;; ANSWER SECTION:
wbs02-ws.withings.net.	926	IN	CNAME	ws.withings.net.
ws.withings.net.	1561	IN	A	89.30.121.150

;; Query time: 0 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sun Aug 06 14:19:31 CEST 2017
;; MSG SIZE  rcvd: 95

Les trois trames suivantes sont la triple poignée de main TCP avec le serveur 89.30.121.150. On se rend compte que la balance communique bien en TCP avec son serveur et pas en UDP comme je l’espérais… Mais pire, on remarque que le port de destination est le 443 et ça correspond à de l’https, autrement dit un port http sécurisé et chiffré… Je ne risque donc hélas pas de voir passer en clair les informations de ma balance.

14:09:28.649462 IP (tos 0x0, ttl 255, id 3, offset 0, flags [none], proto TCP (6), length 44)
    192.168.10.12.49153 > 89.30.121.150.443: Flags [S], cksum 0xe961 (correct), seq 672401143, win 8400, options [mss 1400], length 0
	0x0000:  4500 002c 0003 0000 ff06 1e60 c0a8 0a0c  E..,.......`....
	0x0010:  591e 7996 c001 01bb 2814 06f7 0000 0000  Y.y.....(.......
	0x0020:  6002 20d0 e961 0000 0204 0578            `....a.....x
14:09:28.651938 IP (tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto TCP (6), length 44)
    89.30.121.150.443 > 192.168.10.12.49153: Flags [S.], cksum 0xd24f (correct), seq 3580817429, ack 672401144, win 29200, options [mss 1460], length 0
	0x0000:  4500 002c 0000 4000 3006 ad63 591e 7996  E..,..@.0..cY.y.
	0x0010:  c0a8 0a0c 01bb c001 d56e f015 2814 06f8  .........n..(...
	0x0020:  6012 7210 d24f 0000 0204 05b4            `.r..O......
14:09:28.684596 IP (tos 0x0, ttl 255, id 4, offset 0, flags [none], proto TCP (6), length 40)
    192.168.10.12.49153 > 89.30.121.150.443: Flags [.], cksum 0x3b4d (correct), ack 1, win 8400, length 0
	0x0000:  4500 0028 0004 0000 ff06 1e63 c0a8 0a0c  E..(.......c....
	0x0010:  591e 7996 c001 01bb 2814 06f8 d56e f016  Y.y.....(....n..
	0x0020:  5010 20d0 3b4d 0000 

Pour tout n’est pas perdu pour autant mais l’affaire se complique drôlement… Le petit espoir que j’ai est que la balance ne semble communiquer qu’avec 89.30.121.150. En particulier, cela signifie qu’elle n’effectue jamais de demande OCSP à l’autorité tierce qui aurait donné son certificat à 89.30.121.150. Autrement dit, le serveur wbs02-ws.withings.net signe lui même son certificat.

Pistes pour continuer

Ajout d’un DNAT pour faire pointer les requêtes HTTPS vers un serveur local

$ sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp --dst 89.30.121.150 --dport 443 -j DNAT --to-destination 192.168.0.27:443

$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DNAT       tcp  --  anywhere             89.30.121.150        tcp dpt:https to:192.168.0.27:443

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
SNAT       all  --  anywhere             anywhere             to:192.168.0.38

Serveur HTTPS sur ma machine 192.168.0.38 :

$ sudo ncat -v --ssl -l 443
Ncat: Version 7.01 ( https://nmap.org/ncat )
Ncat: Generating a temporary 1024-bit RSA key. Use --ssl-key and --ssl-cert to use a permanent one.
Ncat: SHA-1 fingerprint: 4912 450C 3AA7 782D AAFC BA0B 6842 BABB 2C2B 16C8
Ncat: Listening on :::443
Ncat: Listening on 0.0.0.0:443
Ncat: Connection from 192.168.0.38.
Ncat: Connection from 192.168.0.38:49153.
Ncat: Failed SSL connection from 192.168.0.38: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac

On cherche le certificat

$ echo 'Q' | openssl s_client -connect wbs02-ws.withings.net:443 > withings_raw.cert
$ cat withings_raw.cert | sed -n '/BEGIN/,/END/p' > withings.cert

nous étions en 2017 ↩

Chiffrement par cheminement d’une fourmi de Langton

2025-05-22T01:00:00+02:00

Récemment, j’ai réalisé qu’une fourmi de Langton se promenant sur une image noir et blanc et la modifiant à la volée était un phénomène parfaitement réversible : en programmant une fourmi duale ayant des mécaniques inversées par rapport à la fourmi initiale, on peut en théorie reconstruire le film en sens inverse et retrouver in fine l’image originale. Chiche ? Chiche !

La fourmi de Langton
Image de départ
Algorithme de destruction
Dégradation de l’image par la fourmi
Emergence de boucles d’inversion
Quantification de la perturbation
Procédure de reconstruction
Programme de chiffrement (non.)
Considérations sur la sécurité de l’algorithme
Pour aller un peu plus loin

La fourmi de Langton

La fourmi de Langton est un petit automate cellulaire que j’aime beaucoup. Les règles, dans leur formulation originelle, sont très simples. La fourmi se déplace sur une grille bi-dimensionnelle dont les cases ne peuvent prendre que deux couleurs : noir ou blanc. La grille est historiquement blanche mais on peut envisager n’importe quel motif de départ (un damier d’échec, une image binarisée, du bruit etc.).

La fourmi est représentée par sa position, que nous notons $(x,y)$ et son orientation (haut, bas, gauche, droite).

Ses règles d’évolution sont les suivantes (l’ordre d’application est important) :

si elle est sur une case noire, elle fait un quart de tour vers la gauche; sinon (i.e. si elle est sur une case blanche) elle fait un quart de tour vers la droite
elle change la couleur de la case sur laquelle elle se trouve
elle avance d’une case

Voici un exemple d’évolution de la fourmi sur une grille $11 \times 11$ et pour les 200 premiers pas, tiré de Wikipédia :

La grille est supposée être infinie ce qui n’est pas réalisable en pratique. D’ordinaire, on peut choisir une grille suffisamment grande pour que la fourmi n’ait pas le temps d’atteindre les bords lors de sa pérégrination qui sera d’un temps fini. Mais on peut également définir des règles sur ce qu’il se passe lorsque la fourmi dépasse les limites de la grille. Habituellement, on considère un comportement à la pacman : si la fourmi sort à droite, elle réapparaît à gauche. Idem pour tous les autres bords (si elle sort en haut, elle réapparaît en bas etc.). C’est ce comportement là que nous envisagerons dans le cas du traitement de nos images (puisqu’idéalement, on aimerait que la fourmi se promène vraiment partout sur notre image et pas seulement “loin des bords”).

Une conjecture étonnante a été émise sur le comportement de la fourmi : au bout d’un certain temps, cette dernière partira à l’infini dans un schéma périodique appelé l’autoroute. Un exemple d’une telle autoroute est donnée ci-dessous (la fourmi y est représentée par un pixel rouge). C’est un comportement émergent, structuré, qui apparaît après une phase de mouvement en apparence chaotique (à tout le moins, irrégulière) de la fourmi. Cet attracteur apparaît systématiquement pour l’ensemble des damiers finis étudiés jusqu’à présent par la communauté scientifique.

Néanmoins, ce n’est pas le sujet de mon article. Je me concentre surtout sur la façon dont la fourmi désagrège, méthodiquement et sans perte d’information une image de départ.

La transformation est à chaque pas totalement réversible puisqu’il suffit d’effectuer les étapes en sens inverser (reculer d’une case, changer la couleur, tourner). A noter que cette caractéristique de réversibilité n’est pas propre à tous les automates cellulaires ainsi que l’illustre cet exemple du jeu de la vie tiré de l’hommage rendu par XKCD lors du décès de John Conway, l’inventeur du jeu. Dans cette configuration, le petit bonhomme se transforme en glyder, une structure qui se déplace à l’infini par translation. On devine bien qu’une fois le glyder établi, il sera impossible de reformer le bonhomme en passant le film en sens inverse : de l’information a été perdue à un moment du processus.

Image de départ

Mais revenons en au propos principal de mon article. Pour les besoins de l’expérience, je me suis basé sur une photo de moi prise à la webcam de mon ordinateur. Je vous prie de bien vouloir excuser le caractère quelque peu narcissique de cette initiative… Je me suis aussi limité à une image de 501 pixels de large par 501 pixels de haut, pour des raisons que nous discuterons bientôt.

C’est, comme vous pouvez le conster, une photo en couleur. Il faut donc la convertir en Noir et Blanc de façon purement binaire (soit Noir, soit Blanc, pas de nuances de gris).

Ma première idée a été de partir sur une fonction de seuillage classique. En choisissant le bon seuil (ici $76$) on garde une bonne compréhension de l’image.

Néanmoins, je trouve qu’on perd quand même pas mal d’information. Je suis alors parti sur une méthode de diffusion d’erreur (le dithering), par un algorithme de Floyd-Steinberg. L’idée est de rendre compte des nuances de gris en utilisant des techniques de propagation d’erreur. Un exemple récent de dithering dans l’univers du jeu vidéo est le réputé Return of the Obra Dinn.

Voici ce qu’on obtient si on applique l’algorithme sur mon image initiale.

Comprenons bien que l’image obtenue n’est constituée que de pixels soit Noir, soit Blanc; ainsi qu’on peut s’en rendre compte en regardant un zoom sur mon oeil droit.

Outre le fait qu’on a l’impression de perdre moins d’informations sur l’image, ce procédé créé un damier de départ assez complexe qui perturbera le cheminement de la fourmi.

Algorithme de destruction

L’algorithme est assez simple et se base sur la bibliothèque Pillow qui permet de manipuler (trop) simplement des images.

Paramètres globaux

Je commence par définir quelques constantes de l’automate :

WIDTH = 501
HEIGHT = 501

N = int(5*10**6) # Iteration of the Langton's ant

DIR = ['L', 'U', 'R', 'D'] # Ordered directions (Left, Up, Right, Down)
COLORS = ['B', 'W'] # Black or White

dither = [Image.Dither.NONE, Image.Dither.FLOYDSTEINBERG] # I should try which one is cooler


x = (WIDTH-1)//2
y = (HEIGHT-1)//2
d = 1

L’image est, comme nous l’avons dit, de taille constante : WIDTH = 501 pixels de large et HEIGHT = 501 pixels de haut. J’ai choisi une taille d’image assez grande pour qu’on puisse voir quelque chose mais pas trop afin de ne pas attendre trop longtemps que la fourmi ait marché un peu partout. Le choix d’un nombre impair permet de placer la fourmi exactement au centre de l’image. C’est un choix purement esthétique, la position de départ de la fourmi important au final assez peu.

On définit également le nombre N d’itérations maximum (ici 5 millions de pas) afin d’arrêter le processus.

Les variables DIR et COLORS contiennent respectivement les 4 orientations de la fourmi (gauche, haut, droite, bas) et la couleur des cases de l’image (noir ou blanc donc). Les orientations sont stockées de telle façon que l’évolution de la fourmi ne la fait se déplacer que d’une case vers l’avant ou vers l’arrière dans le vecteur d’état : étant intialement orientée “DROITE”, la fourmi ne peut ainsi passer que dans l’état “HAUT” (quart de tour vers la gauche) ou “BAS” (quart de tour vers la droite). J’aurai aimé coder ça sous la forme d’une liste circulaire. Je sais par exemple que la bibliothèque itertools dispose d’une fonction cycle qui permet de faire ce genre de chose. Mais j’ai été un peu fainéant et j’ai rajouté un gros modulo…

La liste dither contient les deux seuls algorithmes actuellement implémentés avec Pillow (version 11.2.1) permettant de réduire la palette chromatique d’une image : le seuillage simple (accessible avec Image.Dither.NONE) et l’algorithme de Floyd-Steinberg dont nous avons déjà parlé et qui s’applique avec Image.Dither.FLOYDSTEINBERG. Hélas, les fonctions proposées par Pillow sont souvent trop basique et il n’est pas possible de définir un paramètre de seuillage. J’ignore comment ce paramètre est choisi (peut-être un simple $255/2$). Mais en pratique, j’ai du me passer de cette fonction de Pillow pour le faire à la main.

L’état initial de la fourmi est finalement représenté par ses coordonnées x = (WIDTH-1)//2 et y = (HEIGHT-1)//2 et son orientation intiale, vers le haut, d = 1. C’est un choix qui est ici purement arbitraire. Remarquons au passage qu’avec Pillow, l’origine du repère est situé au bord supérieur gauche de l’image, comme c’est souvent le cas avec les autres bibliothèques de traitement d’image.

Préparation de l’image

Voici les quelques fonctions clefs qui m’ont permis de préparer mon image avant traitement. Je ne les détaille pas plus et je l’indique uniquement pour en garder une trace.

#%% Loading the picture

img = Image.open('./input.jpg')

#%% Pre-processing of the picture

(w, h) = img.size
s = min(img.size)

box = ((w-s)/2, (h-s)/2, (w-s)/2+s, (h-s)/2+s)
img = img.crop(box) # Crop to a square format

img.thumbnail((WIDTH, HEIGHT), Image.Resampling.BICUBIC) # Interpolation to a 501x501 picture

# Dithered picture
img_dithered = img.convert('1', dither=dither[1])

# Thresholded picture (with a custom threshold parameter)
img_thresholded = img.convert('L')
img_thresholded = img_thresholded.point(lambda p: p > 76 and 255)
img_thresholded = img_thresholded.convert('1', dither=dither[0])

Marche de la fourmi

Voici le coeur du programme, qui code l’évolution de la fourmi pas à pas. Il faut bien entendu encapsuler tout ça dans une boucle sur le nombre de pas (donc jusqu’à N qui vaut cinq millions). Ce n’est pas forcément très bien optimisé. Encore un fois, les listes circulaires pour éviter le recours systématique aux modulo (à la fois sur la direction et sur les pixels de l’image) pourrait améliorer un peu les choses. Mais je ne crois pas qu’on puisse drastiquement réduire le temps de calcul, la fourmi de Langton n’étant par définition pas parallélisable.

c = img.getpixel((x,y))//255

if c==0 : # Black case
    d = (d-1)%4
else :
    d = (d+1)%4
    
img.putpixel((x,y), ((c+1)%2) * 255)
    
match d : # (0,0) coin en haut à gauche !
    case 0 :
        x -= 1
    case 1 :
        y -= 1
    case 2 :
        x += 1
    case 3 :
        y += 1

if (x >= WIDTH) : x = 0
if (x<0) : x = WIDTH-1
    
if (y >= HEIGHT) : y = 0
if (y<0) : y = HEIGHT-1

Dégradation de l’image par la fourmi

Voici ce qu’on obtient lorsqu’on fait se promener la fourmi en partant du centre et que nous la laissons évoluer sur cinq millions de pas.

On voit que la fourmi finit bien par passer partout. Je ne sais pas si c’était attendu compte tenu de l’univers clôt et périodique de notre image, mais peut-être la fourmi aurait-elle pu partir à l’infini et rester cloisonnée dans une partie de l’image (par exemple, en allant uniquement de gauche à droite sur une petite bande en hauteur). Ce n’est ici heureusement pas le cas et on arrive cahin-caha à barbouiller l’intégralité de l’image jusqu’à obtenir une littérale bouillie de pixels.

Néanmoins, qu’est-ce que c’est lent ! Avec une image de $501 \times 501$ pixels, une fourmi bien disciplinée qui lirait les pixels ligne après ligne en allant de la gauche vers la droite aurait mis environ 250 000 mouvement pour parcourir l’image. Ici, il nous faut un nombre de mouvements de l’ordre du million, c’est à dire quatre fois plus. Compte tenu du mouvement en apparence erratique de la fourmi, ce n’est pas énormément plus, mais ça reste néanmoins très fastidieux.

On remarque également que, sur la durée de la simulation, la fourmi ne semble jamais être partie en autoroute. Son chemin a toujours été entravé par des pixels qui ont localement perturbé son évolution.

En revanche, il y a quelques chose de plus troublant qui m’a interpelé.

Emergence de boucles d’inversion

A plusieurs reprises, particulièrement au début de la vidéo, la fourmi repasse sur ses pas et rétablit l’image originelle. Je ne m’attendais pas du tout à ce comportement, que je décide d’appeler des boucles d’inversion faute d’un meilleur terme.

En voici un exemple ci-dessous, qui survient très grossièrement entre l’étape $1 \times 10^5$ et $2 \times 10^5$. La fourmi avait commencé à perturber mon crâne et mes joues (à gauche, étape 105 545). A un moment, elle a changé d’avis et a bien tout remis en place (au milieu, étape 177 760). Puis elle est parti barbouiller mes yeux (à droite, étape 205 535).

Elle reconstruit ainsi localement (en espace) et temporairement ce qu’elle a déconstruit avant de reprendre sa marche destructrice.

Elle ne repasse bien évidemment pas exactement sur ses pas (car sinon, elle reviendrait exactement au point de départ), mais pendant un certain nombre d’itérations ses actions font localement ressortir de l’information. Je me demande si cela n’est pas du aux motifs localement périodique introduits par l’algorithme de ditherisation et dont on peut voir un exemple dans le bord inférieur droit de mes lunettes, entouré en rouge ci-dessous.

Creuser un peu plus cette question m’aménerait trop loin mais j’ai néanmoins voulu tester ce que donnerait la marche de la fourmi sur une image seuillée plutot que dithérisée. J’ai donc refait tourner l’algorithme sur une telle image en ayant choisi le seuil de 76 que nous avions considéré en début d’article. En-deça d’une nuance de gris de $76/255$, le pixel devient Noir et Blanc sinon.

Un oeil attentif remarquera toujours quelques boucles, moins elles sont moins nombreuses et surtout beaucoup plus courtes (en temps et en espace). Il y a peut-être quelque chose à creuser dans le fait qu’une fourmi placée au voisinage du passage d’une autre fourmi est susceptible de reconstruire l’image originelle. Sans doute des blocs de transformations équivalent, quelque chose comme ça.

En revanche, les grands aplats uniformes introduits par le seuillage rendent beaucoup plus fréquentes l’émergence d’autoroutes.

Enfin, on remarque que la fourmi peine beaucoup plus à brouiller l’image, le processus semble sensiblement plus lent.

Quantification de la perturbation

Nous pouvons introduire deux mesures de la perturbation causée par la fourmi au fil de sa marche : l’écart quadratique moyen (EQM) par rapport à l’image initiale et l’entropie.

C’est ce qui est tracé ci-dessous pour l’image dithérisée (en bleu) et seuillée (en orange) avec l’EQM en haut et l’entropie en bas.

Plusieurs observations notables :

L’EQM part bien évidemment de zéro au tout début : la fourmi n’introduit initialement aucune modification
On le voit à la fois sur l’EQM et sur l’entropie : l’image dithérisée se brouille plus rapidement que l’image simplement seuillée. Nous nous en étions rendu compte en comparant les deux vidéos.
On observe bien les boucles d’inversion lorsque, tout à coup, l’EQM par rapport à l’image initiale chute avant de reprendre. On constate bien de nouveau que l’amplitude de cet effet est plus important pour l’image dithérisée. Gardons en tête que ces courbes sont fortement décimées (un point tous les 10 000 pas). De fait, on est susceptible de ne pas capturer les micro boucles d’inversion qui s’étalent sur moins de 10 000 pas.
L’entropie initiale est plus élevée pour l’image dithérisée que pour l’image seuillée. La encore c’est attendu puisque dans le cas de l’image seuillée on a tendance à avoir de grands aplats de couleur. L’image est en quelque sorte beaucoup plus ordonnée, beaucoup plus structurée. Alors qu’il s’agit à l’origine de la même image source !

Bien entendu, pour l’EQM il faut garder en tête que ce n’est qu’un indicateur. Un EQM maximal n’est pas forcément souhaitable en ce sens où on obtiendrait une image solarisée de l’image initiale… donc parfaitement lisible !

Procédure de reconstruction

Pour la reconstruction, on pourrait coder le comportement inverse de la fourmi et la faire aller à reculons. Néanmoins, il y a légéremment plus malin : il suffit de lui faire faire un virage à 180° et à lui laisser continuer sa marche. Elle reviendra ainsi sur ses pas et reconstruira méthodiquement tout ce qu’elle avait préalablement détruit.

Ainsi, la fourmi inverse consiste simplement à écrire à un moment :

d = (d+2) % 4

Voici le genre de résultat que nous obtenons alors, en partant de l’image dithérisée, en la brouillant pendant un milliard d’étapes (oui oui), en retournant la fourmi et en la laissant évoluer à nouveau pendant un milliard d’étape (on s’accroche petite fourmi !) :

J’ai trouvé ça très cool à regarder : la fourmi semble se promener de façon chaotique au milieu d’une bouillie de pixels et tout à coup un détail de l’image émerge ! Il grandit petit à petit. Puis la fourmi part faire autre chose… et d’autres détails arrivent, etc.

Programme de chiffrement (non.)

Bon, idéalement j’aurais aimé faire un petit code autonome qui chiffrerait/déchiffrerait une image donnée.

Je me suis alors posé plusieurs questions :

comment connaître le nombre minimal de pas à partir duquel l’image est bien brouillée ? Une étude dynamique de l’évolution de l’entropie et de l’EQM ? Une boucle qui ne s’arréterait que lorsqu’un seuil à définir aurait été atteint ? (avec un garde fou sur le nombre maximum d’itération quoi qu’il arrive ?)
comment estimer la montée en charge de l’algorithme ? Doit-on gérer tous les cas de figure de taille d’image ? Que faire si l’utilisateur branche l’algo sur une image 4K (pauvre fourmi !) ?
si l’utilisateur fournit une image couleur ou en nuances de gris, que fait-on ? Le paramètre de seuillage étudié ici a été estimé visuellement, doit-on coder cela ?
l’algorithme est-il sensé gérer différents types d’image ? Il est évident que le format de l’image de sortie DOIT ETRE conservateur (adieu le jpg, on n’écrit qu’en png)
idéalement, il faudrait coder ça en travaillant sur argv pour récupérer les différents paramètres
mettre ça dans un paquet qui se piloterait soit directement, soit en import python
en sortie de l’algorithme de chiffrement, il faudrait indiquer les paramètres permettant de déchiffrer l’image obtenue : position et orientation de la fourmi en fin de parcours ainsi que le nombre d’itérations à faire en sens inverse

Je pensais avoir la motivation de le faire mais je sens que je me dégonfle un peu. C’est précisément ce que je n’aime pas trop en informatique : parfois le decorum prend une place démesurée par rapport au coeur du code. Le diable est toujours, toujours, dans les détails.

Considérations sur la sécurité de l’algorithme

Mais in fine, je ne suis pas sûr que cet algorithme soit d’une quelconque utilité. Pour les raisons suivantes.

Déjà il est très lent. Nous l’avons déjà dit et il est inutile de s’attarder plus sur ce fait.

Ensuite, le nombre d’itérations nécessaires pour avoir un brouillage efficace n’est pas connu a priori et peut varier selon les images (comparons pour s’en assurer les performances obtenues avec les images dithérisée et seuillée). Ce n’est pas rédhibitoire en soit mais il faudrait s’interroger sur les performances en moyenne (et en moyenne sur quelle population d’images ?). Il pourrait s’avérer que l’algorithme ne soit pas simplement lent, il pourrait devenir très lent dans la plupart des cas. Notre image dithérisée possède des caractéristiques très particulières qui pourraient optimiser le parcours de la fourmi…

Par ailleurs j’ignore s’il existe des cas où la fourmi ne passe pas par tous les pixels, quel que soit le nombre d’itérations.

On pourrait attendre a minima que la fourmi soit passée au moins une fois par toutes les cases avant d’envisager de s’arrêter. A supposer que cet état puisse seulement être atteint (cf. ma remarque précédente), et en notant $N_0$ ce nombre d’étapes, on pourrait envisager de laisser tourner l’algorithme pendant, mettons, $2\times N_0$ pour s’assurer qu’on mélange vraiment bien toute l’image. Mais ne se pourrait-il pas que, ce faisant, nous arrêtions le processus en plein milieu d’une boucle d’inversion et que l’image, pourtnat longuement chiffrée, laisse transparaître des informations critiques ?

Finalement, le chiffrement n’est pas fort : quiconque dispose de la clef (le triplet $(x,y,d)$ à partir duquel faire cheminer notre fourmi inverse), quiconque dispose de cette clef donc, peut totalement reconstruire l’image. La sécurité de l’image brouillée réside notamment dans la sécurité entourant la clef !

Par ailleurs, si on souhaite décrypter une telle image chiffrée par force brute, il faut considérer ici $501 \times 501 \times 4$ clefs possibles pour la fourmi, soit un million de possibilités. Ajoutons à cela que nous ignorons le nombre d’étapes à attendre avant d’avoir une image lisible. Peut-être, sur ce point là précisément, est-on pas trop mal finalement ? Mais le nombre précis d’itération n’est pas super important, on peut accepter d’avoir une petite trace de fourmi résiduelle…

Pour aller un peu plus loin

Je me doute bien que je n’ai rien découvert de nouveau concernant la fourmi de Langton. Mais j’ai été bien content d’expérimenter un peu quelques trucs cool avec cet automate.

Je sais que la fourmi de Langton appartient à une catégorie assez large de machines de Turing appelées les turmites. En gros, si j’ai bien compris, les turmites sont des machines de Turing particulières qui évoluent sur un plan bi-dimensionnel (notre image) et qui sont caractérisées notamment par leur orientation. Je me demande trois choses.

La première : peut-on “accélérer” un peu le brouillage de l’image en plaçant un nombre arbitraire de fourmis ? Attention c’est casse-gueule car les fourmis risquent de se marcher sur les pieds (littéralement). Il faut bien garder l’ordre du déplacement des différentes fourmis.

La deuxième : nous avons travaillé ici sur des images en Noir et Blanc (soit Noir, soit Blanc) ce qui est le cadre de travail canonique de la fourmi de Langton. Mais peut-on généraliser le processus à des images en niveaux de gris (déjà) et en couleur (ensuite) ?

La troisième : j’ai évoqué en fin d’article l’impossibilité de choisir le jpeg comme format de sortie d’image. Mais j’aimerais bien savoir ce que ça donnerait de volontairement abîmer l’image avant de faire fonctionner la fourmi en sens inverse. Trouverait-on tout de même des bouts d’images reconnaissables ou bien n’obtiendrions-nous qu’une bouillie de pixels (les perturbations du jpeg, localisées au niveau des forts gradients de l’image, ayant en quelque sorte contaminé toute l’image) ?

Python et caméra virtuelle

2025-04-28T01:00:00+02:00

Un petit article rapide sur un petit projet de vacances qui me trottait en tête depuis quelques temps.

J’avais dans l’idée de développer un petit programme qui viendrait modifier en temps réel le flux d’une webcam et qui écrirait dans une webcam virtuelle. De cette façon, on peut utiliser le flux modifié dans un programme tiers comme VLC ou Zoom.

Je ne pensais pas spécialement faire d’article sur ce sujet (juste pas le temps) mais j’ai rencontré un problème curieux avec apt-get que j’ai réussi à résoudre donc allez c’est parti.

Le programme
Présentation des filtres
Ecriture dans une caméra virtuelle

Le programme

Le programme se trouve sur mon profil GitHub.

Je me suis inspiré du code présenté dans la chaîne YouTube de Giovanni Code. Il s’agit d’un script Python qui utilise les paquets suivants :

OpenCV2 pour la lecture et la manipulation des images d’une webcam
PyVirtualCam pour l’écriture d’un flux dans un périphérique de Webcam virtuelle
Numpy pour la création d’un filtre avancé de décalage temporel

A partir de maintenant je parle de “filtres” pour désigner les fonctions qui viennent modifier le flux de la caméra. Ce terme doit s’entendre par rapport aux filtres Unix qui lisent et écrivent des flux de données et non pas au sens du traitement du signal (ce qui n’aurait pas grand sens).

Les filtres qui modifient le flux de la webcam en temps réel sont au nombre impressionant de quatre.

On passe d’un filtre à l’autre en appuyant sur space et on quitte en appuyant sur q.

Le programme est perfectible, mais je voulais un petit prototype pour tester quelques idées rigolotes.

Présentation des filtres

Filtre des petits ronds

Celui là est directement inspiré du code de Giovanni Code : on crée des petits cercles colorés et ça donne une petite impression pixelisée très sympa.

Je ne détaille pas plus et vous renvoie vers sa chaîne pour plus d’information sur le sujet.

Filtre des disques verts

Pour celui la, j’ai fait une version modifiée où l’image est remplacé par une grille de disques verts. Le rayon des différents disques est proportionnel à la luminosité du point considéré.

Je suis parti sur une expression assez simple de la luminosité d’un pixel en partant de ses niveaux de rouge $r$, vert $g$ et bleu $b$ (des entiers compris entre 0 et 255) :

\[I = 0.2126 \cdot r + 0.7152 \cdot g + 0.0722 \cdot b\]

La primitive de la fonction qui trace les disques est :

cv2.circle(window, (centerX, centerY), radius, (r, g, b), thickness)

Prendre un paramètre de thickness de $-1$ trace un disque plein plutôt qu’un cercle. Pour les paramètres de (r,g,b), je suis parti sur un vert un peu foncé de (0,175,0).

Enfin, le rayon doit être un entier, ce qui fait qu’on aura un effet de seuilage de la luminosité perçue. Mais le rendu n’est pas trop mal pour autant bien que l’image soit moins claire que pour le filtre précédent.

Filtre des caractères ASCII

En gros ici, on représente chaque pixel par un caractère ASCCI. Plus le pixel est lumineux, et plus on choisira un caractère avec beaucoup de pixel.

Alors, bien entendu, ça dépendra de la police de caractères choisie, de la graisse etc. Par ailleurs, la variation du nombre de pixels entre deux caractères voisin n’est pas forcément toujours la même. Mais enfin, on arrive malgré tout à capturer l’effet.

Je me suis basé sur l’alphabet suivant, ordonné par luminosité croissante :

.-\':_,^=;><+!rc*/z?sLTv)J7(|Fi{C}fI31tlu[neoZ5Yxjya]2ESwqkP6h9d4VpOGbUAKXHm8RD#$Bg0MNWQ%&@

Le premier caractère de la liste est une espace, qui ne sera donc traduit par aucun pixel et qui codera la luminosité nulle. Le dernier caractère est l’arobase @ qui représentera la luminosité maximale.

On peut amplifier l’effet en donnant une intensité de couleur différente pour les différents caractères mais les combinaisons que j’ai testées ne m’ont pas parues convaincantes. J’ai gardé une couleur constante de (0,150,0)

L’effet est désormais beaucoup moins visuel : arrivez vous à distinguer les formes ? L’image est toujours peu ou prou la même que dans les deux cas précédent : je lève le bras droit pour faire coucou. On peut essayer d’affiner la grille et d’afficher plus de caractères mais je n’ai pas poussé plus avant ces investigations.

A noter qu’en vidéo, ça reste quand même un peu plus lisible. Si j’ai la foi, je rajouterai ça dans le corps de l’article

Filtre temporel

Alors ça c’est mon petit chouchou. Il y a longtemps j’avais vu je ne sais plus trop où (fête de la Science ?) une série de webcam qui introduisaient des décalages temporels dans le flux vidéo. Grosso modo, la Webcam écrit en permanence dans un buffer et le flux de sortie vient piocher dans le buffer pour afficher des pixels d’un temps passé. Si on note $E(x,y,t)$ la couleur du pixel de coordonnées $(x,y)$ à un instant $t$, tel que lu par la webcam d’entrée, alors la webcam de sortie verra un pixel $S$ défini par :

\[S(x,y,t) = E(x,y, t')\]

Avec bien entendu $t’<=t$ (on ne lit pas dans le futur)

On peut imaginer plein de façons différentes de mélanger espace et temps et d’une manière générale, on écrira :

\[t'(x,y) = f(x,y)\]

De mon côté, j’ai introduit un décalage ligne à ligne : ce qui se situe en haut de l’image est mis à jour plus rapidement que ce qui est en bas. Avec le repère qui va bien ($x$ selon la largeur, de gauche à droite; $y$ selon la hauteur, du haut vers le bas; origine du repère au coin supérieur gauche de l’image), on aurait donc quelque chose du genre :

\[t'(x,y) = t(x,y) + y\]

A ce niveau de la rédaction de l’article, il faudrait que je fasse un petit dessin de la façon dont le buffer se remplit. Il y a une analogie assez directe avec ce qu’on obtiendrait, dans le cadre de la Relativité Restreinte, si on se regardait dans un grand miroir crénelé incliné de 45° (la partie haute étant la plus proche de nous). Bon j’y reviendrait probablement plus tard…

Voici quoiqu’il en soit ce qu’on obtient. Une fois encore, on comprend mieux ce qu’il se passe avec une vidéo mais comment dire… on le sent que j’ai hâte de finir cette première version de l’article et de passer à autre chose ?

Ecriture dans une caméra virtuelle

Assez vite, je me suis dit que ça serait cool si je pouvais envoyer tout ça dans une caméra virtuelle.

Une petite recherche m’a orienté vers PyVirtualCam qui semble totalement répondre à mon besoin.

Ce paquet s’appuie, sur Linux, sur le paquet v4l2loopback-dkms qui est un module du noyau qui permet de créer des périphériques virtuels type webcam à la volée.

Un problème de paquet

Hélas, lors de l’installation de ce paquet via apt, mon système d’ordinaire courtois s’est mis à m’insulter :

$ sudo apt-get install v4l2loopback-dkms

[...]

Préparation du dépaquetage de 
.../v4l2loopback-dkms_0.12.7-2ubuntu2~22.04.1_all.deb ...
Dépaquetage de v4l2loopback-dkms (0.12.7-2ubuntu2~22.04.1) ...
Paramétrage de v4l2loopback-dkms (0.12.7-2ubuntu2~22.04.1) ...
Loading new v4l2loopback-0.12.7 DKMS files...
Building for 6.8.0-57-generic
Building initial module for 6.8.0-57-generic
ERROR: Cannot create report: [Errno 17] File exists: 
'/var/crash/v4l2loopback-dkms.0.crash'
Error! Bad return status for module build on kernel: 6.8.0-57-generic 
(x86_64)
Consult /var/lib/dkms/v4l2loopback/0.12.7/build/make.log for more 
information.
dpkg: erreur de traitement du paquet v4l2loopback-dkms (--configure) :
  le sous-processus paquet v4l2loopback-dkms script post-installation 
installé a renvoyé un état de sortie d'erreur 10
Des erreurs ont été rencontrées pendant l'exécution :
  v4l2loopback-dkms
E: Sub-process /usr/bin/dpkg returned an error code (1)

Le fichier de log de compilation indiqué dans l’erreur (que je n’ai pas eu la présence d’esprit de sauvegarder du coup je ne peux pas le reproduire ici) indiquait en gros que la fonction strlcpy appelée dans v4l2loopback.c n’était pas définie. Une petite recherche m’a appris qu’il s’agissait d’une fonction venant de l’univers BSD.

Ce problème précis est mentionné à divers endroit du net et pour différents systèmes (ArchLinux, LinuxMint, Ubuntu, et directement sur le github du projet v4l2loopback).

Le problème semble être une incompatibilité du paquet v4l2loopback-dkms avec les noyaux trop récents (ou les dépôts trop anciens, selon comment vous regardez le problème).

On peut résoudre ça en installant v4l2loopback depuis les sources ou alors, comme j’ai fait, en mettant une énorme rustine de fortune dans le code source du dépôt. A la réflexion ce n’est pas super propre car apt pense que le paquet provient du dépôt alors qu’on utilise une version modifiée… Mais enfin ça fera le job le temps du test…

La fonction strlcpy a son équivalent dans la librairie standard du C : strscpy :

Ok les prototypes sont les mêmes, on peut tenter un truc un peu bourrin :

$ sudo sed -i 's/strlcpy/strscpy/' ./src/v4l2loopback-0.12.7/v4l2loopback.c # PAS TESTE !

Attention, je n’ai pas testé ça. J’ai fait la modif sous vim :

$ sudo vim ./src/v4l2loopback-0.12.7/v4l2loopback.c
:%s/strlcpy/strscpy/

On tente ensuite la réinstallation (sans faire de remove/install avec apt sinon on écrase nos modifications) :

$ sudo dpkg --configure v4l2loopback-dkms
Paramétrage de v4l2loopback-dkms (0.12.7-2ubuntu2~22.04.1) ...
Removing old v4l2loopback-0.12.7 DKMS files...
Deleting module v4l2loopback-0.12.7 completely from the DKMS tree.
Loading new v4l2loopback-0.12.7 DKMS files...
Building for 6.8.0-57-generic
Building initial module for 6.8.0-57-generic
[...]
$ # Done, ça a marché !

Création d’une caméra virtuelle

On crée une caméra virtuelle en chargeant le module v4l2loopback avec modprobe

$ ll /dev/vid*

crw-rw----+ 1 root video 81, 0 avril 18 13:59 /dev/video0
crw-rw----+ 1 root video 81, 1 avril 18 13:59 /dev/video1
crw-rw----+ 1 root video 81, 2 avril 18 13:59 /dev/video2
crw-rw----+ 1 root video 81, 3 avril 18 13:59 /dev/video3

$ sudo modprobe v4l2loopback

$ ll /dev/vid*
crw-rw----+ 1 root video 81, 0 avril 18 13:59 /dev/video0
crw-rw----+ 1 root video 81, 1 avril 18 13:59 /dev/video1
crw-rw----+ 1 root video 81, 2 avril 18 13:59 /dev/video2
crw-rw----+ 1 root video 81, 3 avril 18 13:59 /dev/video3
crw-rw----+ 1 root video 81, 4 avril 21 07:47 /dev/video4

Ici on constate qu’une nouvelle caméra fait son apparition dans /dev/, la caméra video4

Mon code python prend la première caméra virtuelle qu’il trouve, il n’y a qu’à s’assurer que dans le fichier webcam.py la variable VIRTUAL_CAM est bien positionnée à True.

Utilisation dans des logiciels tiers

On peut ensuite connecter VLC sur le flux de cette caméra virtuelle. Il faut aller dans Média > Ouvrir un périphérique de capture... et ensuite sélectionner notre caméra (ici donc video4)

Et là, ça fonctionne !

Pareil avec Zoom, il suffit de sélectionner notre caméra au début du meeting. En appuyant sur space on pourra en outre changer les effets. On peut même imaginer ajouter un petit texte affichant le nom du participant et divers informations. Je crois d’ailleurs que c’est ce que propose ObsProject qui est une alternative à v4l2loopback un peu overkill pour d’autres plateformes mais enfin rien ne vaut le DIY ^^

Un jeu de l’oie coloré

2025-03-04T00:00:00+01:00

Avec ma fille Alice, nous aimons bien jouer au jeu de l’oie. Nous avons à la maison un coffret de jeux de société pour enfant de la marque Oxybul qui possède une particularité intéressante. En effet, enfin de permettre aux plus petits de jouer, l’un des dés à six faces présente des faces colorées en lieu et place des motifs à base de point.

La mécanique est intéressante et je me suis interrogé sur l’équivalence avec le jeu de l’oie classique.

Présentation du jeu de l’oie simplifié
Cas d’un dé pipé
Analyse des probabilités

Présentation du jeu de l’oie simplifié

Le plateau de jeu va de la case départ à la case d’arrivée en 36 cases avec trois échelles ci et là qui permettent d’avancer ou reculer plus rapidement si on s’arrête à leur niveau.

Les cases alternent les couleurs Rouge, Jaune, Bleu et Vert. Le motif périodique contient donc ces quatres couleurs et on remarque que le nombre total de cases est bien un multiple de 4.

Observons maintenant le dé. Je ne résiste pas au plaisir d’en faire un rapide patron sous TikZ.

Le dé dispose ainsi de :

deux faces Croix
une face Bleu¹
une face Jaune
une face Rouge
une face Vert

Si on tire une face Croix, on passe son tour². Si on tire une face colorée, le pion doit se rendre à la première case de cette couleur située devant lui. Nous pouvons donc avancer au maximum de 4 cases, dans le cas où nous tirons la couleur sur laquelle le pion est actuellement placé.

Le tableau ci-dessous résume de combien de cases nous avançons, d’une part selon la case où nous nous trouvons (axe horizontal du tableau) et d’autre part selon la couleur donnée par le dé (axe vertical du tableau).

Je tire la face \ Je suis sur la case	Bleu	Jaune	Rouge	Vert
Bleu	4	3	2	1
Jaune	3	4	1	2
Rouge	2	3	4	1
Vert	1	2	3	4

Dans le cas d’un dé parfaitement équilibré, on se rend bien compte que la mécanique de jeu est complétement équivalente à un jeu de l’oie classique où on remplacerait, dans le dé à six faces numérotées, les 5 et 6 par des Croix.

Oui mais, cela est-il toujours vrai dans le cas où on joue avec un dé pipé ?

Cas d’un dé pipé

Pour simplifier l’étude d’un dé pipé, je suis parti sur un jeu de l’oie particulier où les cases sont soit noires soit blanches. Nous remplaçons notre dé par une pièce présentant une face blanche et une face noire. La mécanique est similaire à notre jeu de période 4. Plus précisément, le tableau devient :

Je tire la face \ Je suis sur la case	Blanc	Noir
Blanc	2	1
Noir	1	2

Notons $p$ la probabilité que la pièce tombe sur Blanc. La pièce est truquée si $p \neq 1/2$.

On peut représenter les probabilités de transition par le petit diagramme simplifié ci-dessous (w pour white, c’est-à-dire blanc; b pour black, c’est-à-dire noir).

Analyse des probabilités

Si on note $p_1$ (respectivement $p_2$) la probabilité d’avancer d’une case (respectivement de deux cases), alors nous pouvons montrer assez facilement, d’une part que :

\[p_1 = 2 p \cdot (1-p)\]

et d’autre part que :

\[p_2 = 1 - p_1 = p^2+(1-p)^2\]

Si nous traçons $p_1$ en fonction de $p$, nous obtenons la figure ci-dessous.

La courbe rouge correspond à notre modèle et la courbe bleue correspond à une simulation informatique sur un million de tirage. L’adéquation est parfaite.

Analysons un petit peu ces résultats.

Si $p=0$, alors la pièce tombera toujours sur Noir. Dès le premier coup, le joueur tombera donc nécessairement sur une case Noir. Après cela, toute nouvelle face Noir fera avancer systèmatiquement de DEUX cases. Nous aurons donc $p_1=0$ et $p_2=1$.

De la même façon, si $p=1$ alors la pièce tombera toujours sur Blanc. Juste après le premier coup nous serons donc sur une case blanche et nous avancerons alors systématiquement de DEUX cases. Nous avons donc de même $p_1=0$ et $p_2=1$.

Si $p=0.5$, nous sommes dans le cas d’une pièce parfaitement équilibrée. Dans ce cas là, Blanc et Noir sont interchangeables et nous avons autant de chances d’avancer d’une case que d’avancer de deux cases. Nous avons donc $p_1 = p_2 = 0.5$.

Nous remarquons ensuite deux choses :

nous avons toujours $p_1 \leq 0.5$
la courbe de $p_1$ est symétrique par rapport à l’axe $p=0.5$

Du premier constat, nous en déduisons qu’un joueur avançant plus fréquemment d’une case plutôt que de deux est plus susceptible d’utiliser une pièce truquée numérotée plutôt qu’une pièce truquée colorée.

Du second constat, nous apprenons que truquer la pièce en favorisant un côté donnera le même résultat quel que soit le côté favorisé.

On pourrait généraliser cela en utilisant notre dé à six faces et en le truquant mais… la flemme.

Par ailleurs et d’une façon complétement indépendante, les tarifications de mon hébergeur Gandi étant devenues scandaleuses, je pense ne pas renouveler mon abonnement et migrer ce blog sur une autre adresse. Du coup, cet article ne sortira probablement pas à la date à laquelle il a été écrit. C’est facheux mais c’est comme ça.

je n’accorde pas “bleu” avec “face” parce que j’ai mis une majuscule… ↩
ce qui est en fait différent de dire “on avance de zéro”. Prenez le cas où le joueur est pile au niveau d’une échelle : s’il passe son tour, il ne se passe rien; s’il avance de zéro, je suppose qu’il doit utiliser l’échelle. ↩

Gagne ta Maman

2024-12-10T00:00:00+01:00

Il y a quelques temps, j’ai offert à ma fille ainée le jeu de société “Gagne ta Maman” (qui existe aussi en une version identique “Gagne ton Papa”).

Dans ce jeu, il faut remplir le plus rapidement possible un espace rectangulaire initialement vide à l’aide de polyominos. Formellement, un polyomino est une réunion connexe (i.e. en un seul morceau) de carrés unitaires, ces carrés se touchant par un côté entier.

Ce qui est très appréciable dans “Gagne ta Maman”, c’est que la difficulté s’adapte entre parents et enfants, ces derniers devant ainsi paver le rectangle avec des formes plus “simples” que celles des parents. Ou alors le rectangle des parents est initialement plus grand que celui des enfants.

Dans une variante du jeu, appelée les défis 3D, il faut constituer une figure géométrique tri-dimensionnelle (habituellement un cube ou un pavé) à l’aide d’un sous-ensemble prédéfinis de ces polyominos¹.

Dans un cas comme dans l’autre, je me suis rendu compte que mon algorithme instinctif de résolution était assez ruste : je procédais un peu par essai-erreur sans vraiment de méthode, en suivant l’intuition du moment. La plupart du temps, ça finissait par rentrer et je m’étonnais des performances de cette heuristique naïve.

Quelques rares fois pourtant, mon procédé ne terminait pas et j’avais l’impression d’arpenter un labyrinthe en aveugle sans jamais pouvoir trouver une sortie. Parfois j’avais l’impression de m’y perdre : cette configuration là n’a-t’elle pas déjà été testée précedemment ?

Depuis, j’ai eu l’occasion de creuser un peu la question et je me rends compte qu’algorithmiquement le problème revient bien à parcourir un (très grand) labyrinthe avec un nombre fini de sorties. Je trouve a posteriori que cette analogie est finalement assez profonde, comme nous le verrons.

Quoiqu’il en soit, cette question là traînait un peu dans un coin de ma tête et puis je l’avais oublié… Jusqu’à ce jour où un ami, à qui j’avais suggéré ce jeu pour son fils, me sollicite sur les réseaux sociaux à propos d’un défi 3D qu’ils n’arrivaient pas à résoudre. Je l’ai tenté et m’y suis moi aussi cassé les dents. Il s’agit du défi 28 où l’on doit reconstituer un cube $3\times 3 \times 3$ à l’aide des 7 polyominos suivants (un monomino, 4 tétraminos et 2 pentaminos) :

Nous avons bien $1+4+4+4+4+5+5 = 27 = 3^3$ ce qui est une condition nécessaire (mais pas suffisante) pour que le problème ait une solution.

Après bien des essais, j’ai enfin convergé vers UNE des multiples solutions de ce problème (voir ci-dessous). J’ai aussitôt averti mon ami et je me suis dit “plus jamais ça”, il faut que je comprenne comment résoudre ce genre de problème.

Je détaille ici quelques éléments pour systématiser la résolution de tels problèmes. Ca part vite dans tous les sens, j’espère réussir à en tirer quelques lignes claires.

Le problème du recouvrement
Premier cas : un seul polyomino qui rempli le cube $2\times 2 \times 2$
Deuxième cas : 8 monominos qui remplissent le cube $2\times 2 \times 2$
Troisième cas : le cube Soma
Quatrième cas : le défi 28
Pour aller plus loin

Le problème du recouvrement

La résolution du défi 28, comme le jeu standard “Gagne ton Papa/ta Maman” à base de rectangles à paver, rentre dans le cadre d’une vaste classe de problèmes mathématiques appelée problème du recouvrement.

Le problème des huits dames en est un exemple classique, de même que le cube Soma.

Au début des années 2000, le mathématicien Donald Knuth a développé un algorithme pour résoudre ces problèmes dans le cas général. Sa solution s’appelle l’algorithme X et il en a proposé une implémentation astucieuse grâce aux liens dansants. Le principe de base repose sur la possibilité d’effectuer un retour sur trace et d’effectuer un parcours en profondeur d’un arbre donné. Son article est librement accessible sur le site de l’Open Computing Facility de l’Université de Berkeley.

Au début, je voulais présenter une synthèse de son algorithme² ainsi qu’une implémentation minimaliste. Mais entre temps je suis tombé sur SageMath qui en contient une version robuste et éprouvée. Ce code est développé et maintenu par Sébastien Labbé qui est, à l’heure de rédaction de ce billet, chargé de recherches au Laboratoire Bordelais de Recherche en Informatique.

SageMath, que j’ai découvert à l’occasion des mes recherches sur ce sujet, est un logiel libre dédié aux mathématiques. De ce que j’en comprends c’est un enrobage d’outils Python comme Numpy, Scipy ou Matplotlib afin de présenter une interface unifiée à l’utilisateur ainsi qu’une collection d’un certain nombre d’outils mathématiques (algèbre linéaire, polynômes, graphiques etc.).

Avant de passer à la présentation de la résolution du défi 28, j’aimerais illustrer ce que je pressentais lorsque j’évoquais le parcours du labyrinthe.

La page Wikipédia dédiée à la modélisation mathématique des labyrinthes propose plusieurs algorithmes générant des labyrinthes dit “parfaits” (chaque cellule du labyrinthe est reliée à toutes les autres de manière unique). Très vite apparaît la correspondance avec les graphes orientés acycliques. La notion d’acyclicité me paraît immédiate : on ne peut pas former de “boucles” car ça contredirait l’hypothèse d’unicité de chemin. Ce qui m’a plu, ce sont ces deux figures qui relient labyrinthe et graphe :

L’article de Knuth illustre le parcours des solutions (ici dans le cas particulier du pavage de Scott) par la figure suivante :

On voit bien que la question est finalement similaire : sortir d’un labyrinthe et trouver un recouvrement exact reviennent tout deux à trouver une feuille de sortie en parcourant un arbre. Dans le cas du labyrinthe, cette feuille est généralement unique (il n’existe qu’une seule sortie) alors que dans le cas du pavage, il y a souvent plusieurs solutions.

Je vais maintenant tester le logiciel SageMath sur plusieurs cas particuliers afin de bien le prendre en main.

Premier cas : un seul polyomino qui rempli le cube $2\times 2 \times 2$

Tout d’abord, on s’attaque au problème trivial qui consiste à paver un cube $2\times 2 \times 2$ à l’aide d’un unique Polyomino qui est le cube lui-même. On s’attend à ne trouver qu’une seule solution (aux éventuelles symétries du Polyomino près).

from sage.combinat.tiling import TilingSolver, Polyomino
from sage.all_cmdline import *   # import sage library

L = [Polyomino([(0,0,0), (0,0,1), (0,1,0), (0,1,1), (1,0,0), (1,0,1), (1,1,0), (1,1,1)])];
T = TilingSolver(L, box=(2,2,2))

solution = next(T.solve())
G = sum([p.show3d(size=0.85) for p in solution], Graphics())
G.show(aspect_ratio=1, viewer='tachyon')

T.number_of_solutions()

Le solveur retourne $1$, ce qui est le résultat attendu. J’en déduis que l’implémentation SageMath de l’algorithme, lorsqu’elle construit sa matrice d’entrée, vérifie que les pièces tournées sont bien distinctes.

Deuxième cas : 8 monominos qui remplissent le cube $2\times 2 \times 2$

Cette fois-ci nous avons 8 petits cubes unitaires discernables (on va leur mettre à chacun une couleur différentes) qui doivent paver ce même cube $2\times 2 \times 2$. Les solutions sont là aussi triviales et on s’attend à en trouver autant qu’il n’y a de façons de permuter ces 8 petits cubes. Autrement dit, on devrait trouver $8! = 40 320$.

P1 = Polyomino([(0,0,0)], color='red')
P2 = Polyomino([(0,0,0)], color='green')
P3 = Polyomino([(0,0,0)], color='blue')
P4 = Polyomino([(0,0,0)], color='yellow')
P5 = Polyomino([(0,0,0)], color='magenta')
P6 = Polyomino([(0,0,0)], color='cyan')
P7 = Polyomino([(0,0,0)], color='black')
P8 = Polyomino([(0,0,0)], color='white')

L = [P1, P2, P3, P4, P5, P6, P7, P8];

T = TilingSolver(L, box=(2,2,2))
s = T.solve();


solution = next(s)


G = sum([p.show3d(size=0.85) for p in solution], Graphics())
G.show(aspect_ratio=1, viewer='tachyon')

T.number_of_solutions()
# 40 320 solutions, soit 8! --> OK les pièces sont discernables

Cette dernière instruction retourne bien $40 320$. Ci-dessous voici une de ces nombreuses solutions (telle que tracée par la fonction G.show()).

Remarquons que nous aurions pu utiliser des monominos indiscernables à l’aide de l’argument reusable qu’il faut positionner sur True, auquel cas nous retrouvons bien une et une seule solution.

P = Polyomino([(0,0,0)], color='red')
T = TilingSolver([P], box=(2,2,2), reusable=True)
T.number_of_solutions()
# 1 seule solution...

Troisième cas : le cube Soma

On augmente un peu en difficulté et on s’attaque maintenant à l’exploration du cube Soma.

Il s’agit d’un casse-tête inventé dans les années 1930 par Piet Hein. Le nom fait référence au Soma du Meilleur des Mondes d’Aldous Huxley, une drogue addictive grâce à laquelle chaque élément de la société est heureux et ne revendique rien.

L’objectif du casse-tête est de paver un cube $3\times 3 \times 3$ à l’aide de sept polyominos prédéfinis.

Le problème a été étudié par Martin Gardner et John Horton Conway et le livre “Winning Ways for your Mathematical Plays” en contient une analyse détaillée. Ce dernier livre, coécrit par Conway, est sorti en 1982 et se trouve aujourd’hui en occasion aux alentours de 90 € (dommage, il me branchait bien mais pas à ce prix là…). Il existe 240 façons distinctes de reconstituer le cube Soma à partir des sept polyominos de base. Arriverons-nous à retrouver ce résultat ?

P1 = Polyomino([(0,0,0), (0,0,1), (0,1,0)], color='red')
P2 = Polyomino([(0,0,0), (0,0,1), (0,1,0), (0,2,0)], color='red')
P3 = Polyomino([(0,0,0), (0,1,1), (0,1,0), (0,2,0)], color='red')
P4 = Polyomino([(0,0,1), (0,1,1), (0,1,0), (0,2,0)], color='red')
P5 = Polyomino([(0,0,0), (0,0,1), (1,0,1), (1,1,1)], color='red')
P6 = Polyomino([(0,0,0), (1,0,0), (1,0,1), (1,1,1)], color='red')
P7 = Polyomino([(0,0,0), (1,0,1), (1,0,0), (1,1,0)], color='red')


# G = P1.show3d()
# G.show(aspect_ratio=1, viewer='jmol')

T = TilingSolver([P1, P2, P3, P4, P5, P6, P7], box=(3,3,3))
T.number_of_solutions()

Cette fois-ci nous trouvons $11 520$ solutions ce qui est beaucoup trop ! Mais l’étude du pavage par huit petits cubes nous permet de comprendre que les symétries du cube ne sont pas prise en compte par l’algortihme ! On compte ainsi certaines solutions plusieurs fois !

Il nous faut donc diviser ce nombre par le nombre d’isométries du cube, qui est de $48$, et on retrouve bien le résultat attendu :

\[\frac{11 520}{48} = 240\]

En faisant cela, on fait l’hypothèse (vérifiée) que l’image de n’importe quelle solution du cube Soma par l’application d’une isométrie du cube est également une solution envisageable. Si les rotations ne posent généralement pas problème (en tournant le cube, on tourne également les pièces), ce n’est pas forcément le cas des symétries (qu’elles soient centrales ou planaires).

On ne peut par exemple pas exprimer une symétrie planaire comme composée de rotation 3D car la symétrie ne conserve pas l’orientation alors que la composée de rotation oui (une sombre histoire de signe du déterminant toute cette affaire là). Et lorsqu’on manipule les petites pièces avec nos gros doigts, on ne peut leur faire subir que des translations ou des rotations. On peut néanmoins s’en sortir si les pièces elles-mêmes possèdent certaines symétries de façon intrinsèque (quelque part, c’est lié à la chiralité des pièces).

Le fait que les cubes élémentaires constituant les polyominos sont indiscernables facilite grandement la non-chiralité des pièces. Mais ce n’est pas une condition suffisante, en témoigne cet exemple de pièce problématique que j’ai imaginé pour appuyer mon propos :

P = Polyomino([(0,0,0), (1,0,0), (0,1,0), (0,2,0), (0,0,1), (0,0,2), (0,0,3)])
G = P.show3d()
G.show(aspect_ratio=1, viewer='tachyon')

On voit bien que l’image de cette pièce par une symétrie planaire ne serait pas, il me semble, accessible par une combinaison de rotations…

Peut-être que la clef serait de se demander si ces pièces sont orientées, c’est-à-dire qu’elles nous permettraient de définir un repère orienté de façon univoque. En cherchant du côté des mathématiques voire de la chimie on trouverait très probablement une réponse rigoureuse à cette question là.

Mais tout compte fait, le fait que tous les polyominos de Gagne ta Maman / ton Papa sont planaires me fait penser que nous ne rencontrerons jamais le moindre problème de chiralité en fait. Désolé si c’est un peu décousu, je rédige à peu près en même temps que je réflechis car j’ai envie de clôturer cet article et passer à autre chose ^^

Je m’éloigne finalement de mon propos premier, donc raison de plus de laisser là ces considérations et de passer au dernier cas, qui nous intéresse le plus.

Quatrième cas : le défi 28

Nous pouvons maintenant nous attaquer au fameux défi 28.

P1=Polyomino([(0,0,0)], color='red')
P2=Polyomino([(0,0,0), (0,1,0), (0,2,0), (1,0,0)], color='green')
P3=Polyomino([(0,0,0), (0,1,0), (0,2,0), (1,1,0)], color='blue')
P4=Polyomino([(0,0,0), (0,1,0), (1,1,0), (1,2,0)], color='yellow')
P5=Polyomino([(0,0,0), (0,1,0), (1,0,0), (1,1,0)], color='purple')
P6=Polyomino([(0,0,0), (0,1,0), (0,2,0), (1,0,0), (2,0,0)], color='black')
P7=Polyomino([(0,0,0), (1,0,0), (1,1,0), (1,2,0), (2,2,0)], color='blue')


L = [P1, P2, P3, P4, P5, P6, P7]

T = TilingSolver(L, box=(3,3,3))

T.number_of_solutions()

iterT = iter(T.solve());

for index, solution in enumerate(iterT):
     print('- Iteration ' +  str(index))
     G = sum([p.show3d(size=0.85) for p in solution], Graphics())
     G.show(aspect_ratio=1, viewer='tachyon', camera_position=cpx, 
frame=False)
     G.save_image('./figures/solution_' + str(index) + '.png')

Cette fois-ci nous trouvons $1 152$ solutions.

Il me semble que le miroir des pièces du défi sont toutes atteignables. En particulier j’avais une méfiance envers $Z_4$, $Z_5$ et (dans une moindre mesure) $L_4$. Mais je n’ai pas réussi à imaginer un cas de figure où une symétrie planaire conduirait à une solution impossible à réaliser. Je suppose que c’est OK.

En prenant en compte les isométries du cube, nous nous ramenons in fine à 24 solutions. Ces 24 solutions ne peuvent pas se déduire l’une de l’autre par le biais des symétries et rotations du cube.

Voici les 9 premières solutions retournées par le solveur de SageMath.

Pour aller plus loin

Quelques idées que j’ai en tête :

ce défi 28 était-il particulièrement difficile ? Il faudrait tester les autres défis et calculer leur nombre de solutions
en mettant ce nombre de solutions en regard de certains paramètres (complexité des polyominos en terme de degré, nombre de polyominos, chiralité si cette dernière a un impact ?), des choses amusantes pourraient apparaître
on pourrait de même quantifier la difficulté du jeu standard (à savoir paver le rectangle)
on pourrait aussi étudier l’arbre des solutions : combien y-a-t’il de feuilles qui ne terminent pas ? Partant de cet arbre, nous pourrions générer le (gros) labyrinthe équivalent

Quelques liens utiles :

le jeu Quantumino dont s’inspire Gagne ta Maman.
une implémentation en C++ des liens dansants
la page Wikipédia de la couverture exacte
la page Wikipédia de l’algorithme X de Knuth
la définition des polycubes sur Wikipédia
la page officielle du jeu Gagne ta Maman / ton Papa
l’article de Knuth sur les liens dansants
une implémentation des liens dansants par Knuth
une vidéo illustrant les liens dansants sur la plateforme Viméo : on voit bien que ça danse !
la documentation du module Tiling Solver de SageMath
un article de Sébastien Labbé, issu de son blog personnel, sur le pavage par polyominos à l’aide de SageMath
le quadrilatère de Herzberger, un casse-tête similaire au cube Soma mais plus récent
le cube Soma sur Wikipédia
une animation interactive des liens dansants sur github.io

dans le cas tridimensionnel, on préfère parfois le terme “polycubes” à “polyomino”. Dans la suite de ce billet, j’emploierai toujours “polyomino” pour simplifier. ↩
la lecture de son article est très intéressante et instructive. Comme bien souvent en algorithmique, on se rend compte que la résolution élégante d’un problème passe en grande partie par la façon de modéliser les données du problème. Et l’algorithme proprement dit s’en déduit ensuite assez facilement. Je regrette juste qu’à un moment Knuth évoque la nomenclature de Golomb³ pour classifier les pentominos mais la référence associée pointe vers un livre assez rare (et donc cher)… Dommage… ↩
ça m’a néanmoins permis de découvrir le mathématicien américain Solomon Wolf Golomb ainsi que ses règles éponymes ↩

Vulgariser le triangle

2024-12-10T00:00:00+01:00

Soient trois nombres réels strictement positifs $(a,b,c) \in \mathbb{R}_+^3$. Sous quelle(s) condition(s) ce triplet forme-t’il les trois distances d’un triangle dans le plan euclidien ?

On répond assez vite à la question en faisant intervenir la bien-nommée inégalité triangulaire. En supposant que le triplet est ordonné, c’est-à-dire $a \leq b \leq c$, il est nécessaire et suffisant que :

\[a + b \geq c\]

L’égalité $a+b=c$ étant vérifiée lorsque le triangle est totalement aplati.

J’ai voulu tester cela avec ma fille de six ans qui vient de rentrer en CP et qui maîtrise désormais les additions et les comparaisons.

Dans ce but, j’ai créé un certain nombre de bandelettes de différentes tailles que j’ai coloriées puis découpées.

Avec Marie, nous choisissons ensuite trois bandes au hasard et nous essayons de les disposer en triangle. J’espérais qu’on puisse en déduire une loi sur le choix des trois bandes qui nous aurait assuré la possibilité de construire un triangle.

Hélas, l’expérience ne fut pas très fructueuse, pour plusieurs raisons :

le papier de l’imprimante, trop fin, n’est pas agréable à manipuler
la largeur des bandelettes, pourtant nécessaire afin de faire figurer le nombre de cases, rend possible la construction de certains triplets qui ne vérifient pas l’inégalité
on visualise mal les triangles, il aurait peut-être fallu utiliser des longueurs plus grande
l’exploration n’est pas facile, peut-être aurait-il été plus judicieux de fixer la longueur du plus grand côté

Sans doute faudrait-il une autre approche, peut-être utiliser des baguettes Mikado ou autre. La vulgarisation mathématique, ce n’est pas toujours très simple. Néanmoins, c’était amusant de tester cela.

Je laisse le fichier vectoriel des bandelettes en libre accès, si cela intéresse quelqu’un.

Un loups-garous maison

2024-11-05T00:00:00+01:00

Pour son prochain goûter d’anniversaire, ma fille Marie de six ans conviera quelques amis à elle. Je me suis demandé s’ils étaient en âge d’apprécier une petite partie de loups-garous simplifiée (et édulcorée).

Pour estimer cela, j’ai créé avec Marie un jeu de cartes simplifié et j’ai mis à contribution la famille proche pour une partie pilote.

Nous étions en tout six personnes : Marie, ses grands-parents (Pépé et Mémé), ma soeur et son mari (Tata et Tonton) et moi-même. Durant l’expérience nous étions donc trois joueurs aguerris (Tata, Tonton et Papa), deux joueurs débutant (Pépé et Mémé) et une enfant de six ans dont je scrutais les réactions et les stratégies lors de la partie. Notons que le cousin nous a rejoint en milieu de séjour et nous avons pu tester également quelques variations.

Je n’envisageais pas spécialement de billet de blog autour de cette histoire sauf que je me suis heurté rapidement à une petite difficulté : les Loups-Garous de Thiercelieux, tels qu’ils ont été conçus par leurs créateurs Philippe des Pallières et Hervé Marly, ne sont prévus que pour 8 à 18 joueurs.

Etant donné qu’il faut au moins un loup-garou pour que la partie ait un sens et qu’il y a exactement un loup-garou dans la partie minimale à 8 joueurs, le problème fut vite réglé : à six joueurs, nous devons avoir également 1 loup-garou. Néanmoins, je me suis dit que la partie sera plus facile pour ce loup-garou étant donné qu’il y a 2 villageois en moins.

Plus facile mais de combien exactement ?

Les nombres de villageois et de loups-garous étant par définition entiers, le ratio de loups-garous dans le village ne peut prendre que certaines valeurs rationnelles. Partant de là, la difficulté de la partie pour un loup-garou, doit sensiblement varier selon le nombre de participant.

Le présent billet de blog a la prétention d’étudier un peu tout cela par l’intermédiaire d’un modèle simplifié.

Les règles du loup-garou simplifié
Modèle du jeu
Loi discrète uniforme
Simulation du jeu selon les répartitions $(v, l)$ canoniques
Simulation du jeu avec une répartition $(v, l)$ quelconque
Améliorations du modèle
Le cas particulier à 6 joueurs
Le jeu de loups-garous maison

Les règles du loup-garou simplifié

Nous avons une ensemblée de $N$ habitant d’un village. Ces habitants comportent $N_l$ loups-garous, qui se transforment en loup la nuit, et $N_v$ villageois normaux. Nous avons donc :

\[N = N_v + N_l\]

Je fais ici la distinction entre habitant (qui peut être loup-garou ou non) et villageois (qui n’est par définition pas un loup-garou).

Un tour de jeu se déroule en deux phases : la nuit et le jour.

Pendant la nuit, les loups-garous se réveillent et éliminent un villageois de leur choix.

Pendant la journée, les habitants (qui incluent donc les loups-garous) discutent entre eux pour éliminer l’un des leurs. Avec un peu de chance, ils élimineront un loup-garou.

La partie s’arrête lorsqu’il n’y a plus de loup-garou auquel cas les villageois restant gagnent la partie; ou bien lorsqu’il n’y a plus de villageois auquel cas les loups-garous restant gagnent.

Remarquons déjà que les villageois ne peuvent gagner la partie que lors d’une phase de jour lorsqu’ils éliminent le dernier loup.

Les loups-garous de leur côté peuvent gagner de nuit comme de jour : de nuit, comme conséquence d’une de leur attaque; et de jour comme défaillance des villageois à éliminer un loup.

Dans le jeu de base se trouvent quelques autres personnages (Cupidon, le Voleur, la Voyante, la Sorcière, le Chasseur…) mais j’ai décidé de les ignorer afin de garder la mécanique la plus simple possible. Je garde toutefois à l’esprit que l’ensemble de ces personnages (à l’exception de Cupidon et du Voleur) ont tendance à favoriser les villageois (ainsi la Voyante est une villageoise qui peut une fois par nuit découvrir la véritable nature d’un habitant de son choix). Globalement ces cartes augmentent sensiblement le pouvoir des villageois (pensons à la Sorcière, une villageoise qui une fois dans la partie peut tuer la personne de son choix) : bien utilisé, ce pouvoir est profitable aux villageois mais il peut aussi se retourner contre eux.

Modèle du jeu

Un tour de jeu se déroule donc en deux phases successives : la nuit, puis le jour.

Nous pouvons représenter l’état du jeu en un instant $t$ comme un point sur le quart de plan $(v, l)$.

Voici un exemple dans le cas général, le point en rouge correspond à l’état courant :

Les règles du jeu font que nous ne pouvons créer ni de villageois ($v$ augmente) ni de loups-garous ($l$ augmente).

Afin de simplifier les schémas, nous considérons (sans perte de généralité) le cas particulier où $N_v=5$ et $N_l=2$

Lors d’une phase nuit et selon nos règles simplifiées, un villageois est nécessairement tué. Cet opérateur descend donc le compteur $v$ d’une unité avec une probabilité de $1$.

Lors d’une phase jour, ce sera soit un villageois soit un loup-garou qui sera tué. Si nous notons $p$ la probabilité qu’un loup soit tué, alors nous pouvons représenter un tour de jeu selon le diagramme suivant :

La partie s’arrête lorsque le point courant touche l’axe des abscisses, auquel cas $l=0$ et les villageois gagnent; ou bien lorsque ce point touche l’axe des ordonnées et dans ce cas $v=0$ et les loups-garous gagnent. Selon notre modèle, le point de coordonnées $(0,0)$ où il ne reste plus ni loups-garous ni villageois est indéterminé (qui est le vainqueur dans un village vide ?). Mais cela n’est pas important car ce point est inacessible sans passer au préalable par une condition de victoire.

Tout l’interêt du modèle est ici de choisir une valeur de $p$ réaliste. Alors bien sûr cela va dépendre de plusieurs facteurs qui peuvent difficilement être intégrés dans mon modèle :

les loups-garous peuvent être maladroit, faire du bruit, bousculer les voisins en désignant leur victime etc.
mais de la même façon, un villageois agité pendant la phase nuit pourra être accusé à tort d’être un loup
les joueurs peuvent être plus ou moins persuasifs dans leur argumentation, plus ou moins manipulateurs dans leur stratégie
les inimitiés ou les amitiés fortes peuvent influencer peut-être le vote

J’élimine rapidement le cas trop simplifié qui consisterait à prendre $p$ constant, par exemple $1/2$. Dans ce cas, lors de la phase jour, les habitants auraient une chance sur deux d’éliminer un loup-garou et une chanche sur deux de tuer un innocent villageois. La simplicité de ce modèle est attirante mais nous n’aboutirions pas à une situation réaliste : imaginez par exemple 100 habitants parmis lesquels se cache un unique loup-garou. Il faudrait avoir une sacré chance pour l’éliminer lors d’une phase jour.

Loi discrète uniforme

Une loi plus réaliste serait de choisir uniformément parmi les $v+l$ survivants la personne à éliminer. Nous utilisons donc une loi de probabilité discrète uniforme et chaque personne à la même probabilité $1/(v+l)$ d’être éliminé. Nous avons donc :

\[p = \frac{l}{v+l}\]

et donc logiquement :

\[1-p = \frac{v}{v+l}\]

Rappelons que $p$ représente la probabilité que les habitants désignent un loup-garou lors du vote. Le fait d’utiliser une loi uniforme traduit le fait que ces derniers n’ont aucun a priori sur l’identité des loups. C’est justifiable pour les villageois, qui n’auraient ainsi jamais aucune information sur les loups. Ca l’est quand même moins pour les loups qui, eux aussi, votent un peu au hasard. Notre modèle montrera donc ses limites dans le cas où le nombre de loups n’est plus négligeable devant le nombre de villageois. Mais enfin qu’importe c’est une premier essai.

Simulation du jeu selon les répartitions $(v, l)$ canoniques

Avec cette mécanique, nous pouvons modéliser le comportement des joueurs de loups pour les couples $(N_v, N_l)$ prévus dans les règles :

Rappelons que dans notre modèle simplifié, la voyante est une villageoise comme les autres.

Nous avons simulé 10 000 parties pour chaque couple $(N_v, N_l)$ prévus dans le livret. Nous en extrayons ensuite la fréquence de victoire des loups pour chaque cas. Nous obtenons alors le diagramme suivant :

Nous observons plusieurs faits remarquables :

globalement les loups sont super avantagés par le jeu ! Ils gagnent en moyenne dans 68% des cas. On peut penser que les personnages additionnels (le Chasseur, la Sorcière, la Voyante) peuvent potentiellement leur compliquer la tâche… à condition que leur pouvoir soit utilisé à bon escient
la gigue qu’on observe n’est pas due à un faible échantillon mais est caractéristique du modèle : les loups ont toujours un avantage supplémentaire avec un nombre initial pair de joueurs. Ceci peut sembler étrange mais s’explique facilement par la dissymétrie jour/nuit. Je serai intéressé de savoir si des gros gros joueurs du jeu ont noté cet effet…
on voit très nettement l’effet de l’introduction du 3eme loup-garou à partir de 12 joueurs

Je reste malgré tout perplexe devant les forts taux de victoire des loups… Ce n’est pas le sentiment que j’avais en jouant au jeu. Et n’oublions pas que nous modélisons des loups idiots qui peuvent potentiellement voter contre leurs congénères.

Peut-être ai-je minimisé notre capacité à débusquer la duperie.

Simulation du jeu avec une répartition $(v, l)$ quelconque

Voici cette même fréquence de victoire des loups lorsqu’on fait varier, d’une part le nombre de villageois entre 1 et 20 et d’autre part le nombre de loups entre 1 et 5.

Sans surprise on constate que ce taux augmente avec le ratio $l/v$. Nous retrouvons également la dissymétrie jour/nuit qui confère un avantage aux loups lorsque le nombre de joueur est pair.

Améliorations du modèle

Peut être faudrait-il modéliser plus finement les mécaniques du vote diurne. Ainsi, on pourrait particulariser chaque intention de vote en s’assurant que les loups n’ont qu’une faible probabilité de voter contre un des leurs.

On pourrait aussi imaginer une chaîne de Markov qui tiendrait compte, par exemple, des résultats des 2 tours précédents. Si un habitant a désigné et contribué à mettre-à-mort un innocent villageois au tour N, il augmente la suspicion à son égard et donc la probabilité qu’il soit désigné par les villageois au tour N+1. J’aimerais bien avoir un peu de temps pour faire ça.

Le cas particulier à 6 joueurs

Pour terminer concernant l’objet initial de ce billet, dans le cas d’un jeu à 6 joueurs parmi lesquels se cache un loup-garou.

Sur un million de parties selon nos règles simplifiées, les loups gagnent dans 53% des cas.

Le jeu de loups-garous maison

Pour terminer, voici notre réalisation du jeu du loups-garous. J’ai rajouté un loup supplémentaire pour tester.

Le jeu a été un grand succès et je crois que Marie a beaucoup aimé ! On a d’ailleurs été amené par la suite à créer des cartes supplémentaires (Sorcière et Capitaine).

Vertige d’un footballeur

2024-07-10T01:00:00+02:00

Hier, le mardi 9 juillet 2024, j’ai regardé le match France-Espagne de la coupe d’Europe.

A un moment, s’est affiché rapidement la disposition des joueurs français, avec un titre du genre “3-4-3”.

Alors je sais qu’il s’agit de la répartition des joueurs entre la défense (à gauche) et l’attaque (à droite). Mais en fait, il existe plein de façons différentes de disposer 10 joueurs sur le terrain.

Combien exactement ? C’est l’objet de ce billet de blog.

Le problème
La résolution
Exploration de l’intégralité des tactiques possibles
Deux résonances
Liens pour approfondir

Le problème

Donc en fait, il nous faut trouver de combien de façons différentes nous pouvons écrire 10 comme somme d’une suite d’entiers tous strictement positifs.

Par exemple nous avons $3+4+3 = 10$.

La page Wikipédia dédiée aux tactiques du football en dénombre au total 6, dans la version moderne du football. Ces dispositions sont :

$4+4+2=10$
$4+3+3=10$
$4+2+3+1=10$
$5+3+2=10$
$5+4+1=10$
$3+4+3=10$

Mais on sens bien qu’il y en a plein d’autres.

Quid par exemple de la configuration $1+1+1+1+1+1+1+1+1+1 = 10$ où tous les joueurs seraient alignés à la queue leu-leu sur une longueur du terrain ?

Quid également de la configuration $10=10$ où cette fois-ci tous les joueurs seraient alignés sur une largeur du terrain et présenteraient, pour ainsi dire, un front uni face à l’équipe adverse ?

Ceci n'est pas un penalty : l'équipe bleue se met simplement en configuration 10

La résolution

Répondre à cette question de dénombrement revient mathématiquement à s’interroger sur la composition des entiers. La page Wikipédia sur le sujet en parle très bien et avec de très jolis schémas. Je ne vais pas tout détailler mais simplement énoncer les faits qui me paraissent intéressant.

D’une façon générale, le nombre de compositions $c(n)$ d’un entier $n$ est égal à :

\[c(n) = 2^{n-1}\]

Dans notre cas de figure avec $n = 10$ joueurs, cela nous donne donc $2^9 = 512$ tactiques différentes.

Il s’agit bien entendu d’un nombre prenant en compte toutes les permutations : $4+3+3$ est différent de $3+4+3$ par exemple.

Si on ne souhaitait pas comptabiliser les permutations, alors le problème revient à calculer le nombre de partitions d’un entier, qui est un problème voisin très bien documenté également sur Wikipédia.

La formule générale qui donne le nombre de partitions $p(n)$ est assez complexe et n’a été obtenue qu’en 1937, par le mathématicien Hans Rademacher. Sa formule fait intervenir les suites de Farey, les cercles de Ford et l’analyse complexe !

Les premiers termes de la suite $p(n)$ apparaît dans l’OEIS sous l’identifiant A000041. Hardy et Ramanujan en ont donné de leur côté une approximation asymptotique :

\[p(n) \sim \frac{1}{4n \sqrt{3}} exp \left(\pi \sqrt{\frac{2n}{3}} \right)\]

J’ai tracé ci-dessous l’évolution du nombre de partitions (en noir) et de combinaisons (en rouge) pour $N<50$. L’échelle est logarithmique, on voit que le nombre de combinaisons croît beaucoup plus vite !

Pour terminer la présentation rapide des nombres de partitions, les diagrammes de Ferrers peuvent aider à visualiser les différentes possibilités de façon très schématique. Ci-dessous le cas pour $n=8$

Exploration de l’intégralité des tactiques possibles

Il existe une façon très élégante d’énumérer toutes les dispositions possibles en se basant sur l’écriture binaire des entiers de $0$ à $2^9$. Je me suis basé sur cette bijection pour établir les schémas exhaustifs du placement des joueurs.

Par exemple, pour avoir la configuration n°167, on remarque que

$167 \equiv 010100111|_{\textrm{bin}}$

On compte ensuite le nombre de 1 (potentiellement nul) entre deux 0 qui se suivent en partant de la gauche.

Dans notre cas de figure, on compte cinq groupes :

un premier groupe ne contenant pas de chiffre 1 : $\textcolor{red}{*}010100111$
un deuxième groupe contenant 1 fois le chiffre 1 : $0\textcolor{red}{1}0100111$
un troisième groupe contenant 1 fois le chiffre 1 : $010\textcolor{red}{1}00111$
un quatrième groupe ne contenant pas de chiffre 1 : $01010\textcolor{red}{*}0111$
un cinquième groupe contenant 3 fois le chiffre 1 : $010100\textcolor{red}{111}$

La séquence des tailles de groupe est donc ici $(0, 1, 1, 0, 3)$. On ajoute 1 à chaque élément pour obtenir in fine la configuration $1+2+2+1+4 = 10$.

Ca parait un peu artificel comme procédé, mais il faut se dire que les 0 qui apparaissent dans l’écriture binaire jouent le rôle de délimiteurs entre les joueurs de football.

Voici quoiqu’il en soit ce que me génère mon programme d’exploration des 512 tactiques différentes, regroupées par paquets de 64 tactiques. En rouge, les 6 tactiques qui sont mentionnées par la page Wikipédia précemment citée. Pour les voir en grand :

Deux résonances

Ces petites figures m’ont rappelées le tableau “Vertige d’une chaise” de Max Charvolen, tableau que j’aime beaucoup.

La capture d’écran est de mauvaise qualité et provient du catalogue de l’artothèque de la CMCAS de la ville de Nice.

Je me souviens m’être demandé à une époque s’il était possible de créer un “générateur de chaises” à partir des quelques 720 réalisations proposées par Charvolen. Mais le processus ne me semble pas évident. De mémoire, j’espérais une superposition de projections de chaises dont on aurait fait varier l’orientation (rotation) ou la dimension (homothétie). Mais ça semble plus complexe que cela, et il y a des perturbations sur la structure même de la chaise. Du coup, j’ai un peu laissé tomber. Mais cet article me permet de me souvenir de ce truc là tiens. Le résultat final du tableau fait penser à une écriture à base de sinogrammes.

Par ailleurs, régulièrement quand je me prête au jeu de dénombrer pour le simple plaisir de le faire, je repense toujours à Georges Perec qui disait :

Rien ne semble plus simple que de dresser une liste, en fait c’est beaucoup plus compliqué que ça n’en a l’air : on oublie toujours quelque chose, on est tenté d’écrire etc., mais justement un inventaire, c’est quand on écrit pas etc.

Le plaisir de la combinatoire mathématique, c’est justement quand on refuse d’écrire etc.

Liens pour approfondir

Un Rubik’s Cube Mirror

2024-05-22T01:00:00+02:00

A l’occasion de mon récent anniversaire, on m’a offert un Rubik’s cube dit “miroir”. Ce dernier a exactement la même mécanique qu’un Rubik’s cube traditionnel. La seule différence, redoutable, est que désormais les cubes ont la même couleur (miroir). Ce qui identifie de façon unique leur position et leur orientation, c’est les dimensions des cubes (qui ne sont ainsi plus des cubes mais des pavés).

Je n’ai jamais vraiment manipulé de Rubik’s cube et l’exercice a été parsemé de fausses manip qui m’ont fait quasiment tout recommencer ! Il y a plein de sites en ligne qui expliquent comment résoudre ce genre de casse-tête. Avec un peu d’entraînement, on y arrive.

Ca a aussi été l’occasion pour moi de découvrir que la famille des Rubik’s cube est très diversifiée avec plein de déclinaisons différentes (dont un magnifique cube 1x1x1).

Mais ce que j’aime beaucoup dans celui qu’on m’a offert c’est qu’en le manipulant, on obtient des formes complexes que je trouve agréable à regarder.

Sauf qu’après l’avoir dérangé, il faut résoudre le puzzle !

Du coup, je me suis dit que j’allais développer un petit programme qui allait explorer à ma place et de façon aléatoire, les différentes configurations du cube.

Le cube
Considérations sur l’implémentation

Le cube

Voici le résultat, obtenu en p5.js. J’ai utilisé pour la première fois les primitives de rendu 3D du moteur (qui s’appuie sur WebGL).

On peut bouger la vue en cliquant/déplaçant la souris. Désolé si ça ne s’affiche pas bien sur smartphone, je n’ai pas géré le côté responsive du truc. On réinitialise le cube en appuyant sur r (en fait j’adore ce bouton, compte tenu du temps qu’il m’a fallu pour résoudre le cube dans la vraie vie).

Considérations sur l’implémentation

La principale difficulté de ce programme a résidé en deux points :

Il faut tenir à jour un index de la position des différents cubes. En effet, souhaitant faire tourner la face supérieure selon l’axe vertical nécessite de connaître les 9 cubes qui composent cette face. J’ai décidé de stocker cette information dans une liste. D’une part pour des raisons de simplicité et d’autre part parce que je ne connais pas assez bien les autres solutions offertes par JavaScript. Le point qui fut délicat ici aura été de mettre correctement cette liste à jour après n’importe quel demi-tour.
Un cube participant à une rotation élémentaire verra son orientation propre évoluer, il faut garder cela à jour également. J’ai décidé de partir sur une représentation classique de l’orientation par angles d’Euler, comme nous le verrons.

La bibliothèque p5.js nous offre trois primitives qui vont nous permettre de tourner les cubes, à savoir rotateX(), rotateY() et rotateZ().

La documentation indique :

Rotates the coordinate system about the x-axis in WebGL mode.

The parameter, angle, is the amount to rotate. For example, calling rotateX(1) rotates the coordinate system about the x-axis by 1 radian.

Alors déjà, les angles de rotation sont exprimés en radian ce qui est une bonne chose. Ensuite, on s’aperçoit que p5.js fait tourner le système de coordonnées et pas le cube ! C’est la fameuse ambiguité entre alias et alibi, il nous faudra donc considérer systématiquement les transposées des matrices de rotation (tourner le cube d’un angle $\theta$ selon un axe donné revient à tourner le repère d’un angle $-\theta$ selon ce même axe). En pratique, ça ne me semblait pas super gênant vu que le sens de rotation m’importait peu, c’est une convention. Une petite difficulté surgira pourtant lorsqu’il faudra identifier quels cubes ont tourné.

Quoiqu’il en soit, on comprend que la rotation totale se calcule par l’intermédiaire des angles d’Euler. Pour des rotations du système de coordonnées selon les axes X, Y et Z, cela revient à considérer les trois matrices suivantes :

\[R_X(\alpha) = \begin{pmatrix} 1 & 0 & 0\\ 0 & \cos \alpha & \sin \alpha \\ 0 & -\sin \alpha & \cos \alpha \end{pmatrix}\] \[R_Y(\beta) = \begin{pmatrix} \cos \beta & 0 & -\sin \beta\\ 0 & 1 & 0 \\ \sin \beta & 0 & \cos \beta \end{pmatrix}\] \[R_Z(\gamma) = \begin{pmatrix} \cos \gamma & \sin \gamma & 0\\ -\sin \gamma & \cos \gamma & 0 \\ 0 & 0 & 1 \end{pmatrix}\]

En pratique, les transformations élémentaires ne sont que des quarts de tour et donc $(\alpha, \beta, \gamma) \in \{-\pi/2, 0, +\pi/2\}^3$. Les matrices d’Euler sont donc très simple et consistent essentiellement en des permutations d’axe. Plus précisément :

Axe	Sens	X devient	Y devient	Z devient
X	+	+X	-Z	+Y
X	-	+X	+Z	-Y
Y	+	+Z	+Y	-X
Y	-	-Z	+Y	+X
Z	+	-Y	+X	+Z
Z	-	+Y	-X	+Z

La documentation indique également :

Note: The order the rotations are called is important, ie. if used together, it must be called in the order Z-X-Y or there might be unexpected behaviour.

On comprend donc que la rotation totale s’écrit :

\[R = R_Y \cdot R_X \cdot R_Z\]

Mes premiers développements se heurtaient à des comportements étranges. Je me suis alors rendu compte que le repère de référence de p5.js ne forme pas un trièdre direct… J’ai commencé à prendre cela en compte dans le programme mais en fait, les choses semblent se compenser (rappelons-nous que nous faisons tourner le repère, pas l’objet).

Partant d’un état donné du cube, j’ai décidé de ne pas tenir compte de l’avertissement de la documentation (qui, je pense, ne traduit que le fait que les rotations ne commutent pas. Une fois qu’on sait ça, il faut juste savoir ce qu’on fait) et j’ai allégremment mélangé les rotations.

Partant d’un cube orienté $YXZ = (\beta, \alpha, \gamma)$ si je rajoute, mettons, une rotation $D$ d’un demi-tour positif selon l’axe X, comment s’exprimera la nouvelle orientation ? Cela revient à trouver $(\alpha’, \beta’, \gamma’)$ qui satisfait :

\[R_Y(\beta)\cdot R_X(\alpha) \cdot R_Z(\gamma)\cdot D = R_Y(\beta')\cdot R_X(\alpha') \cdot R_Z(\gamma')\]

La solution n’est pas unique et il suffit de trouver un triplet qui fonctionne pour mettre correctement les informations à jour.

Hormis le cas trivial d’un demi-tour selon l’axe Z, la résolution de ce système dépendra de l’état actuel des rotations pour savoir quel axe se transformera en quel autre axe. Il faut alors propager les permutations d’axe de rotation en rotation jusqu’à revenir sur la première. Regardant par exemple $R_X(\alpha)$ qui me demande de tourner d’un angle $\alpha$ autour de X, si entre temps, mon axe X est devenu -Y, alors il faudra mettre à jour en indiquant une rotation d’angle $-\alpha$ autour de l’axe Y.

Mon premier verger

2024-03-14T00:00:00+01:00

J’ai récemment joué quelques partie du jeu de société “Mon Premier Verger” avec mes enfants (Marie 5 ans et Alice 2 ans). Nous avons gagné toutes les parties et je me suis demandé dans quelle mesure nous avons eu de la chance.

Rien ne semble plus simple que de dresser une liste, en fait c’est beaucoup plus compliqué que ça n’en a l’air : on oublie toujours quelque chose, on est tenté d’écrire etc., mais justement, un inventaire, c’est quand on n’écrit pas etc.

Georges Perec, Penser/Classer

TL;DR
Description du jeu
Modélisation
Simulation de Monte-Carlo

TL;DR

Une simulation de Monte-Carlo sur un million de partie montre que les joueurs gagnent dans 63% des cas.

Description du jeu

Ce jeu de société, édité par Haba, est un jeu collaboratif où le but est de cueillir tous les fruits du verger avant que le corbeau ne les mange.

Voici le descriptif donné par le dos de la boîte de jeu :

Dans le verger, les arbres fruitiers croulent sous les fruits. Attention à l’effronté corbeau Théo qui aimerait tous les dérober ! Suivant le symbole du dé, ramassez un fruit et placez-le dans votre panier ou faites avancer Théo sur le chemin vers le verger. Vous gagnerez tous ensemble si vous cueillez tous les fruits dans que Théo n’arrive dans le verge.

Il est indiqué que le jeu est dimensionné pour 1 à 4 joueurs à partir de deux ans et qu’une partie dure environ 10 minutes.

Le jeu se compose de :

4 tuiles arbres sur lesquels sont initialement posés 4 fruits en bois (4 pommes rouge sur le premier, 4 pommes vertes sur le deuxième, 4 poires jaune sur le troisième et enfin 4 prunes bleues sur le quatrième)
un pion corbeau placé devant une piste de cinq cases
un dé
un panier

Le dé présente les six faces suivantes : Rouge, Vert, Jaune, Bleu, Panier et Corbeau.

Chacun à tour de rôle, les joueurs lancent le dé :

si le résultat est Rouge, Vert, Jaune ou Bleu, le joueur doit retirer un fruit de la couleur du dé et le déposer dans le panier. S’il n’y a plus de fruit dans l’arbre, il ne se passe rien.
si le résultat est Panier, le joueur choisit un fruit dans n’importe quel arbre et le dépose dans son panier
si le résultat est Corbeau, le corbeau avance d’une case sur sa piste

Si les joueurs arrivent à cueillir tous les fruits avant que le corbeau n’atteigne la dernière case de sa piste, ils gagnent la partie tous ensemble.

Si le Corbeau arrive sur la dernière case de sa piste avant que tous les fruits n’aient pu être cueillis alors les joueurs perdent la partie tous ensemble.

Modélisation

Alors déjà, commençons par remarquer que ce jeu de société n’est pas un jeu normal au sens de Raymond Smullyan.

Dans son livre Satan, Cantor and Infinity¹, ce dernier considérait en effet comme normal tout jeu à deux joueurs se terminant en un nombre fini de coups. Ce concept fut introduit par le mathématicien William Zwicker pour pouvoir ensuite parler d’hyperjeu. Les réflexions autour de l’hyperjeu ont pu conduire à une démonstration inédite du théorème de Cantor qui stipule que le cardinal d’un ensemble $E$ est toujours strictement inférieur au cardinal de l’ensemble de ses parties $\mathcal{P}(E)$.

Dans le cas qui nous intéresse, les joueurs peuvent entrer dans un jeu sans fin où, comble de malchance, le dé tombe systématiquement sur la face bleue. La probabilité associée à cet événement est certes nulle mais la possibilité existe.

Alors, je tords un peu la définition originale car Raymond Smullyan ne parle aucunement de hasard. Par ailleurs, cela n’a aucune incidence sur la suite de nos développements. Alors je ferme là cette petite parenthèse mais je suis bien content d’avoir parlé de ce logicien dont j’avais dévoré les ouvrages étant lycéen.

Concernant la modélisation du jeu, on constate déjà que le nombre de joueurs importe peu puisqu’ils ont tous le même objectif et que leur marge de manoeuvre est très faible. Le seul degré de liberté dont ils disposent est de choisir la couleur du fruit lorsque le dé tombe sur la face Panier. La solution la plus rationnelle est alors de dépeupler l’arbre le plus fourni, et de choisir aléatoirement en cas d’égalité.

Nous supposons le dé parfaitement équilibré. A chaque tour, une des six faces est susceptible de sortir avec une probabilité de $1/6$. Voyons déjà ce que nous pouvons en tirer

Défaite en N coups

Dans un premier temps, nous ne prenons pas en compte les mécanismes susceptibles de faire gagner les joueurs et nous nous concentrons sur le Corbeau.

Soit $F(N)$ la probabilité que le Corbeau gagne en exactement $N$ coups.

Comme il faut que la face Corbeau sorte cinq fois pour gagner, nous avons déjà trivialement $F(1) = F(2) = F(3) = F(4) = 0$.

Pour gagner en exactement 5 coups, il faut que le Corbeau soit sorti systématiquement lors des 5 premiers coups. Les lancés étant indépendant, nous avons donc :

\[F(5) = \frac{1}{6^5}\]

De façon générale, la probabilité que le Corbeau gagne en $N$ coups s’écrit :

\[F(N) = \frac{\Omega_F (N)}{\Omega}\]

Ici $\Omega$ représente l’ensemble des configurations accessibles après $N$ lancés de dé. Nous avons donc $\Omega = 6^N$.

$\Omega_F (N)$ représente l’ensemble des configurations pour lesquelles le Corbeau gagne en exactement $N$ coups. Un peu de combinatoire nous donne :

\[\Omega_F (N) = {N-1 \choose 4} \cdot 5^{N-5}\]

Dans cette équation le terme $n \choose k$ représente le coefficient binomial classique, il correspond ici au nombre de façons différentes d’avoir tiré $5-1=4$ Corbeaux lors des $N-1$ tours précédents. C’est trivialement un cas d’application de loi binomiale de paramètres $p=1/6$ et $n = N-1$ avec la condition supplémentaire que le Nème lancé soit exactement un Corbeau.

La probabilité que le Corbeau gagne en exactement $N$ coups s’écrit finalement :

\[F(N) = {N-1 \choose 4} \cdot \frac{5^{N-5}}{6^N}\]

En pratique, si nous simulons la mécanique du Corbeau sur un million de parties successives, nous avons une parfaite adéquation entre notre fonction $F(N)$ et l’histrogramme des victoires du Corbeau, ainsi que l’illustre la figure ci-dessous.

Sans cueillette des fruits, nous voyons que le Corbeau peut ainsi espérer gagner en moyenne en environ une trentaine de coups.

Il s’agit là pour lui d’une solution idyllique : il est quasi-certain (au sens des probabilités) de gagner en un nombre fini de coups. Dans les conditions de jeu réelles, les joueurs vont gagner cetaines parties ce qui va réduire drastiquement l’arbre des possibles pour notre pauvre corbeau. La figure ci-dessous illustre la modification de notre histogramme lorsqu’on introduit la possibilité de gagner pour les joueurs.

La surface d’histogramme manquante sur la figure de droite correspond exactement aux cas où les joueurs ont gagné.

Il nous faut donc affiner notre modèle. Mais avant cela, nous allons étudier de la même façon la possibilité de victoire pour les joueurs.

Victoire en N coups

Ici nous faisons l’hypothèse inverse : le Corbeau ne peut jamais gagner.

Par soucis de simplification, je désactive également l’effet de la face Panier : lorsqu’on tombe dessus, il ne se passe rien de particulier (mais le tour est tout de même consommé). On peut assimiler cela à une face dont l’effet est simplement “Passez votre tour”.

Soit $W(N)$ la probabilité que les joueurs gagnent en exactement $N$ coups.

L’estimation de $W(N)$ est cette fois-ci un peu plus complexe dans le calcul des différents dénombrements. Je note les différents évenements R (Rouge), G (Vert), B (Bleu), Y (Jaune), P (Panier) et C (Corbeau). Comme on l’a dit, les faces P et C sont sans effet.

Déjà, une partie victorieuse en exactement $N$ coups se terminera nécessairement avec R, G, B ou Y. Supposons que ce soit R. Parmi les N-1 tirages précédents, on sait qu’il y a :

Exactement 3 R
Au moins 4 G
Au moins 4 B
Au moins 4 Y

J’introduis le nombre $S(n_r, n_g, n_b, n_y, N)$ qui représente le nombre de façons différentes d’avoir exactement $n_r$ faces R, $n_g$ faces G, $n_b$ faces B et $n_y$ faces Y parmi $N$ tirages successifs. On suppose bien entendu que $(n_r+n_g+n_b+n_y)<=N$. Un peu de combinatoire me donne directement :

\[S = {N \choose n_r}\cdot{N-n_r \choose n_g}\cdot{N-(n_r+n_g) \choose n_b}\cdot{N-(n_r+n_g+n_b) \choose n_y}\cdot2^{N-(n_r+n_g+n_b+n_y)}\]

Le nombre $\Omega_W (N)$ de façons différentes de gagner en exactement $N$ coups s’écrit alors :

\[\Omega_W (N) = 4\cdot \sum_{k_g=4}^{N-12} \quad \sum_{k_b=4}^{N-8-k_g} \quad \sum_{k_y=4}^{N-4-(k_g+k_b)} S(3, k_g, k_b, k_y, N-1)\]

Ce qui peut éventuellement se réécrire :

\[\Omega_W (N) = 4\cdot \sum_{k_g=0}^{N-16} \quad \sum_{k_b=0}^{N-12-k_g} \quad \sum_{k_y=0}^{N-8-(k_g+k_b)} S(3, 4+k_g, 4+k_b, 4+k_y, N-1)\]

La probabilité $W(N)$ s’écrit finalement :

\[W(N) = \frac{\Omega_W (N)}{\Omega} = \frac{\Omega_W (N)}{6^N}\]

La formule est un peu complexe (d’aucuns diraient imbitable) mais est en adéquation avec la simulation (comme nous allons le voir). J’aurais aimé obtenir quelque chose de plus simple. Le point délicat qui survient systématiquement concerne le calcul du nombre de permutations. Ainsi, dans le cas particulier d’une suite victorieuse d’exactement 16 coups, nous avons 4 possibilités de base, selon la couleur du 16ème et dernier lancé. Les 15 tirages précédents comportent exactement : 3 R, 4 B, 4G et 4 Y. Combien de suites de 15 tirages contiennent ces quantités exactes de couleurs ? Il faut passer par les permutations et ce nombre est :

\[\frac{15!}{(4!)^3\cdot3!}\]

La probabilité de victoire en 16 coups est alors :

\[W(16) = 4\cdot \frac{15!}{(4!)^3\cdot3!\cdot 6^{16}} \approx 2.24\cdot 10^{-5}\]

On obtient exactement le même résultat avec la formule de la triple somme (qui dans ce cas se limite à un simple terme où, nous n’avons pas le choix, $k_g=k_b=k_y=4$).

Mais si nous considérons maintenant le calcul de $W(17)$, et en supposant (pour simplifier) que le 17eme lancé soit un R, alors nous devons envisager pour les nombres $[n_r, n_g, n_b, n_y]$ des 16 premiers lancés les cas suivants :

$[3, 4, 4, 4]$ : nous avons obtenu exactement un dé neutre (P ou C)
$[3, 5, 4, 4]$ : nous aurons tiré un G de trop et aucun dé neutre
$[3, 4, 5, 4]$ : nous aurons tiré un B de trop et aucun dé neutre
$[3, 4, 4, 5]$ : nous aurons tiré un Y de trop et aucun dé neutre

Pour chacun de ces 4 cas, le dénombrement des permutations possibles sera sensiblement différent, d’où la tronche de l’équation de $W(N)$. Peut-être qu’il y a une astuce (par exemple, compter plutôt le complémentaire, à savoir aucune victoire en exactement $N$ coups; ou encore compter dénombrer différemment). Il est également possible que la formule se simplifie, en se rappelant que :

\[{n \choose k} = \frac{n!}{k!\cdot(c-k)!}\]

En y regardant de plus près, il est possible que les termes de la sommation se regroupent en utilisant la formule de Pascal :

\[{n \choose k} +{n \choose k+1} = {n+1 \choose k+1}\]

par exemple, voici à quoi ressemble, sans simplification, la distribution des coefficients $n \choose k$ qui interviennent dans le calcul de $W(N)$ pour différentes valeurs de $N$ (entre 16 et 30).

Mais enfin, laissons cela de côté et restons sur cette expression de $W(N)$. Ce nombre représente, je le rappelle car il est facile de s’y perdre lorsqu’on manipule tous ces coefficients, la probabilité de gagner le jeu en exactement $N$ lancés de dé dans l’hypothèse simplificatrice où le corbeau ne peut pas gagner et où la face Panier ne fait rien.

Si nous comparons notre expression de $W(N)$ avec une simulation de Monte-Carlo de 1 million de parties jouées selon les règles de cette mécanique simplifiée, alors nous obtenons une excellente adéquation (comme pour le cas de $F(N)$) :

SI nous rajoutons la possibilité au Corbeau de gagner, nous observons de même que précedemment, un dépeuplement des états gagnants à haute valeur de $N$, comme on l’observe ci-dessous. C’est un comportement prévisible : faire durer une partie gagnante c’est augmenter la probabilité du Corbeau de gagner. Et de la même façon, si le Corbeau prend trop son temps pour gagner, il laisse la main aux joueurs pour cueillir tous les fruits !

Plus amusant, si on ajoute la mécanique de la face Panier, alors la distribution se resserre drastiquement ! La encore c’est prévisible : utiliser le Panier, c’est augmenter les chances de succès et donc diminuer les probabilités de succès associées aux longues parties.

Ces informations sont résumées dans le tableau ci-dessous (statistiques estimées sur un million de parties à chaque fois).

Dé Corbeau	Dé Panier	Nombre de coups moyen pour gagner
Désactivé	Désactivé	37
Activé	Désactivé	30
Activé	Activé	22

Cas général

Pour calculer les probabilités de gain ou de défaite en $N$ coups avec toutes les règles du jeu actives en même temps, il nous faut raisonner différement.

Par exemple, perdre une partie à l’étape $k$ avec $k < N$, c’est restreindre l’univers $\Omega$ des configurations possibles à envisager pour les parties de $N$ coups. Ainsi nous ne devrions plus normaliser par $6^N$ mais par un nombre plus petit. Pour le dire autrement, le fait qu’on gagne en $N$ coups présuppose que nous n’avons ni gagné ni perdu pendant les $N-1$ coups précédents.

La solution pour s’en sortir est, je pense, de faire appel aux probabilités conditionnelles. On aboutirait peut-être à quelque chose qui ressemble à ça :

\[W(n) = \frac{\Omega_W (N)}{\Omega}\] \[F(n) = \frac{\Omega_F (N)}{\Omega}\]

Avec :

\[\Omega = 6^N-\sum_{k=1}^{N-1} (\Omega_W(k) + \Omega_F(k))\cdot 6^{N-k}\]

Mais je ne suis pas trop sûr de ce truc là². Et par ailleurs, le fait de ne pas avoir d’expression simple de $W(N)$ est assez décourageant à ce stade. Peut-être aussi qu’il n’existe pas de formule simple pour capturer la dynamique de ce jeu.

Par ailleurs, une autre approche possible serait de modéliser le nombre de fruits restant sur un arbre par un automate fini probabiliste. On aurait un truc comme ça :

La matrice de transition pourrait s’écrire :

\[M = \begin{pmatrix} 5/6 & 0 & 0 & 0 & 0 \\ 1/6 & 5/6 & 0 & 0 & 0 \\ 0 & 1/6 & 5/6 & 0 & 0 \\ 0 & 0 & 1/6 & 5/6 & 0 \\ 0 & 0 & 0 & 1/6 & 1 \\ \end{pmatrix}\]

Et donc pour connaître la probabilité d’état au bout de $k$ lancés, il suffit de regarder le vecteur $M^k\cdot u_4$ avec $u_4 = (1\, 0\, 0\, 0\, 0)’$ qui représente l’état initial. On obtient alors ce genre de graphiques qui représente l’évolution en fonction du nombre de lancés de dé de la probabilité qu’il reste $n$ fruits sur un arbre donné (avec $0 \leq n \leq 4)$ :

Mais bon, je vais en rester là.

Simulation de Monte-Carlo

Il est en revanche beaucoup plus facile d’estimer les chances de succès et d’échecs en laissant l’ordinateur jouer un très grand nombre de parties différentes (un million). C’est ce que je présente ici.

Pour le modèle de jeu, la seule incertitude (si j’ose dire) concerne la face Panier qui laisse le joueur décider de l’arbre sur lesquel prélever un fruit. Paradoxalement, c’est quand notre action est certaine que cela rend mon programme plus incertain.

J’ai opté pour la stratégie suivante : si la face Panier sort, alors on prélève un fruit sur l’arbre qui en contient le plus. C’est la stratégie la plus efficace. Mais si plusieurs arbres possèdent exactement ce nombre maximal, alors je prélève selon un ordre arbitraire (toujours le même).

Au final, comme nous l’avons dit au début, ce qui ressort de ces simulations c’est que les joueurs gagnent dans 63% des parties environ.

Le Corbeau gagne en moyenne en 18 coups alors que les joueurs gagnent en moyenne en 22 coups, ce qui fait qu’une partie se déroule en moyenne en 20 coups. A raison de 30 secondes par tour, une partie moyenne dure 10 minutes ce qui est conforme aux indications fournies sur la boîte de jeu. Ces trente secondes peuvent paraître excessive mais n’oublions pas d’une part que ce jeu est à partir de 2 ans et que d’autre part on papote et on rigole pendant qu’on joue !

Plus amusant, on peut aussi modifier légéremment les règles du jeu et voir en quoi cela affecte les chances de succès.

Les paramètres d’entrées que nous faisons varier :

le nombre de cases du Corbeau (plus ce nombre est élevé, plus grandes sont nos chances de succès)
le nombre de fruits par arbre (plus ce nombre est élevé, plus faibles sont nos chances de succès)

Les paramètres de contrôle :

probabilité empirique de succès
durée moyenne d’une partie (en minute)

SMULLYAN, Raymond M. Satan, Cantor and infinity (and other mind-boggling puzzles). New York : Knopf, 1992. Plus d’informations sur la page de l’éditeur ↩
je me relis et je me rends compte que c’est faux. Dans les parties gagnantes en $N$ coups, il y en a nécessairement certaines qui ont échoués au bout de $k < N$ coups lorsque $N$ est suffisament grand. Pas le choix, il faut vraiment passer par les probabilités conditionnelles. ↩