Contexte et problème

iChat AV, introduit par Apple en 2003, utilisait un serveur SNATMAP hébergé sur configuration.apple.com pour découvrir l’adresse IP publique des participants. Le client envoie une requête UDP, reçoit la réponse contenant l’IP et le port externes, puis établit une connexion RTP peer‑to‑peer. En 2026, le fichier snatmap.txt n’est plus accessible via HTTP ; il redirige vers HTTPS, que la suite TLS d’OS X Leopard ne supporte pas. Le résultat est l’échange d’adresses LAN privées, entraînant l’échec de la traversée NAT.

Pour contourner ce blocage, l’auteur a modifié /etc/hosts afin de rediriger configuration.apple.com vers un serveur web contrôlé, mais le serveur SNATMAP d’Apple ne répond plus, laissant iChat sans source de découverte d’adresse publique.

Analyse du protocole SNATMAP

Grâce à des captures tcpdump et à l’exécution d’iChat en mode debug (/Applications/iChat.app/contents/MacOS/iChat -errorLogLevel 7), les auteurs ont identifié la structure binaire du protocole. Chaque paquet occupe exactement 16 octets :

# Request (type=1)
struct.pack('!HHII', 1, nonce, 0, 0)
# Response (type=2)
struct.pack('!HHII', 2, nonce, external_ip, external_port)

Le champ nonce assure la corrélation entre requête et réponse. Les deux champs « client local IP/port » sont ignorés par le client, ce qui simplifie l’implémentation serveur. Le serveur renvoie le external_ip et le external_port observés sur le paquet UDP entrant, permettant ainsi à chaque client de connaître son point d’accès NAT.

Mise en œuvre du serveur et tests

En 2026, les deux auteurs ont développé un serveur SNATMAP minimal en Python, conforme à la spécification générée par un LLM. Le serveur écoute sur le port UDP 5678 et répond immédiatement avec les valeurs extraites du paquet reçu. Pour valider le fonctionnement, ils ont créé un laboratoire réseau : deux routeurs OpenWrt exécutés comme VM sous Proxmox, chaque routeur assurant la translation NAT pour un Mac connecté via NIC USB. Un troisième VM Debian hébergeait les services Jabber (ejabberd), HTTP (lighttpd) et le serveur SNATMAP. Cette topologie reproduit fidèlement le trajet « Internet » entre deux clients NAT, tout en offrant un contrôle total sur les flux.

Les tests ont montré que, une fois le serveur SNATMAP opérationnel, iChat AV échange correctement les adresses publiques, initie la connexion RTP et établit des flux audio/vidéo fonctionnels entre les deux machines Leopard. La capture tcpdump confirme la séquence : requête UDP → réponse SNATMAP → paquets RTP bidirectionnels.

Limites et perspectives

La solution repose sur la persistance du protocole SNATMAP tel qu’il était implémenté en 2003 ; toute modification future d’iChat (par exemple, un passage à ICE ou à STUN) rendrait le serveur obsolète. De plus, le serveur ne gère pas les scénarios où le routeur ne préserve pas le port source ; les utilisateurs de pfSense ou OPNsense doivent activer explicitement la préservation du port dans leurs règles NAT. Enfin, la dépendance à XMPP (Jabber) pour l’échange de texte reste un point de friction, car les serveurs publics comme jabb.im peuvent disparaître. Malgré ces contraintes, l’expérience démontre qu’une rétro‑ingénierie ciblée, combinée à un environnement de test isolé, suffit à restaurer des fonctionnalités disparues d’applications legacy.