veilletech.frCe qui se passe
Le point de départ est modeste : un ami partage sa position via « Localiser » sur iOS, et l'auteur veut dessiner quelques zones géographiques pour recevoir une notification à chaque arrivée ou départ. Il avait déjà bâti un petit traqueur d'activité de jeu sur le même principe, et s'attendait à une requête authentifiée, du JSON, et une soirée de travail.
Premier obstacle : l'API web d'iCloud renvoie volontiers ses propres appareils et leurs positions, mais le partage de position entre personnes n'y figure pas. Second obstacle : en cherchant des travaux existants, il constate que personne n'a publié de solution complète.
Sans Mac pour exécuter ou instrumenter l'application officielle, il part de clients open source, puis — quand deviner les noms de champs cesse d'être amusant — travaille sur les décompilations de trois démons système d'Apple.
La méthode
C'est ce qui rend le billet utile bien au-delà de son sujet. La boucle de travail tient en une phrase : garder la session fixe, changer un seul champ ou un seul encodage, et observer si le code de statut renvoyé bouge. Puis recommencer.
C'est lent. C'est aussi la seule façon d'obtenir un résultat interprétable face à un système fermé : en modifiant deux choses à la fois, un changement de code de statut ne dit plus laquelle est en cause. Le principe est le même que celui d'un diagnostic sérieux — isoler une variable, mesurer, conclure.
Le périmètre, posé d'emblée
L'auteur délimite explicitement ce que son client fait et ne fait pas, et cela mérite d'être souligné sur un sujet de géolocalisation :
- Il lit uniquement un partage déjà accepté sur son propre compte Apple.
- Aucune méthode pour envoyer des invitations, modifier des partages, ajouter des membres à la famille ou déclencher une action sur un appareil.
- Le géorepérage se fait localement, après déchiffrement — rien n'est créé côté Apple.
L'accord de la personne concernée a été demandé avant la première ligne de code, avec une réserve explicite sur ce qui ne devait pas être publié. C'est la différence entre de l'exploration technique et de la surveillance.
Ce que ça change
Deux enseignements se dégagent, indépendants d'Apple.
D'abord qu'une API web « complète » ne l'est jamais tout à fait : les fonctionnalités sociales passent souvent par des chemins distincts de ceux des appareils, avec leurs propres formats et leur propre chiffrement.
Ensuite qu'un travail de rétro-ingénierie honnête commence par écrire son périmètre. Le billet ouvre par un encadré qui dit ce que le client ne peut pas faire — avant même d'expliquer ce qu'il fait.
À retenir
Une méthode reproductible sur un système opaque : une variable à la fois, un signal observable, et un périmètre écrit avant de commencer.
Source : zerotistic.blog