Les outils réseau qu'Apple a retirés, sur tous vos appareils Apple

Toutes les différences de plateforme de cette section se ramènent à une question : qu'une application en bac à sable a-t-elle réellement le droit d'ouvrir. L'ICMP n'a pas de numéros de port. Pour envoyer une requête echo et lire la réponse, un processus a besoin d'un socket qui parle directement le protocole IP 1, et l'on suppose généralement qu'il s'agit d'un socket brut : réservé à root, et catégoriquement refusé par le bac à sable. C'est cette supposition qui a tenu le ping et le traceroute hors de bien des applications App Store, et elle est fausse. Darwin propose aussi un socket ICMP datagramme, socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP), que tout processus non privilégié peut ouvrir et que le bac à sable autorise. C'est la raison pour laquelle /sbin/ping a perdu son bit setuid il y a des années, et c'est ce qu'utilise l'exemple SimplePing d'Apple sur iOS. Le ping et le traceroute n'ont donc qu'une seule implémentation, pas plusieurs. SSHive assemble lui-même les requêtes Echo, calcule la somme de contrôle ICMP, positionne IP_TTL quand une trace le demande, et lit ce qui revient : sur macOS via un petit addon natif N-API, sur iPhone et iPad via le type Swift équivalent. Les réponses sont appariées sur l'identifiant, le numéro de séquence, l'adresse source et un cookie aléatoire de huit octets dans la charge utile, car un socket ICMP datagramme reçoit aussi une copie des réponses destinées aux autres processus de la machine. Une exigence a été découverte par la mesure plutôt que par la documentation, et elle mérite d'être répétée car elle échoue en silence. Sous sandbox-exec avec com.apple.security.network.client seul, socket() réussit, sendto() réussit, et recvfrom() renvoie EPERM : la sonde part et rien ne revient jamais, ce qui est indiscernable d'un réseau qui filtre l'ICMP. com.apple.security.network.server est également nécessaire. SSHive déclare les deux, et c'est pourquoi la version App Store, sous bac à sable, mesure de vrais allers-retours au lieu d'expirer en silence. Une sonde TCP reste proposée, mais comme choix délibéré pour les hôtes qui filtrent l'ICMP, non comme substitut : une connexion vers un port que vous désignez, chronométrée de la demande à l'état prêt, signalée par un badge TCP. Une subtilité s'y attache : une connexion refusée compte comme une réussite, car un RST prouve qu'un hôte vivant a répondu. Le port est simplement fermé, et le journal le dit. Le DNS, le whois et le DNSBL n'exigent aucun privilège : aucune plateforme n'a rien à contourner, seule la portée diffère. Sur Mac, le DNS interroge A, AAAA, CNAME, MX, TXT et NS en parallèle ; l'iPhone et l'iPad ajoutent SOA et donnent la durée de vie de chaque réponse. Chaque type est protégé séparément : un domaine sans MX affiche quand même son enregistrement A. Le WHOIS est une simple session TCP sur le port 43 : on envoie la requête, on termine par CRLF, on lit jusqu'à la fermeture par le serveur. Sur Mac, il suit la chaîne de renvois jusqu'à trois sauts, soit deux renvois, avec dix secondes de délai par saut ; l'iPhone et l'iPad partent de l'IANA et suivent les renvois à partir de là. Une vérification DNSBL est une résolution d'enregistrement A sur les octets inversés d'une adresse IPv4 sous chaque zone, lancées en parallèle, et les verdicts dépendent de l'appareil. Le Mac rend « listée » ou « propre », et lit une erreur DNS comme propre. L'iPhone et l'iPad rendent trois verdicts, listée, propre ou sans réponse : une zone restée muette, ou qui renvoie un code de refus plutôt qu'un signalement, n'y est jamais comptée comme propre.