Une forme revient sans cesse dans mes projets : quelque chose existe, c'est utile, et ça ne vous dira pas comment ça marche. J'ai écrit un keygen pour Balsamiq Mockups comme exercice de recherche — une étude en C# de la façon dont ses clés de licence étaient dérivées, sans rien distribuer. J'ai construit un scraper qui extrait des statistiques par pays des infobox de Wikipédia, qui encodent le même fait de quinze manières différentes. J'ai construit un job serverless qui sauvegarde mes playlists SoundCloud, ce qui a supposé d'extirper un client ID d'une page parce qu'il n'existait aucune voie d'entrée documentée. Trois projets sans rapport, une seule activité en dessous : observer ce que fait le système, formuler une théorie, la tester, noter ce qu'on a appris.
On parle de rétro-ingénierie comme si c'était l'affaire des chercheurs en sécurité et des gens qui cassent les DRM. Mais si vous vous intégrez à quoi que ce soit que vous n'avez pas construit, vous en faites une version en permanence. La documentation est périmée. Les messages d'erreur mentent. Le champ marqué obligatoire est facultatif et le facultatif est celui qui porte tout. Toute intégration est en partie de l'archéologie, et celles qui tournent mal sont généralement celles où quelqu'un a supposé que ce ne serait pas le cas.
La méthode n'a rien de sophistiqué. On change une entrée et on regarde ce qui bouge. On garde l'onglet réseau ouvert et on lit chaque requête que fait la page, pas seulement celle qu'on attendait. On enregistre une réponse avant et après une action et on les compare. Quand un endpoint vous rejette, on lit le rejet comme une donnée : il vient de vous livrer une règle que vous ignoriez. L'essentiel du travail consiste à restreindre : ce champ compte, celui-là est décoratif, l'ordre de ces deux appels porte tout et personne ne l'a écrit.
La partie que les gens sautent, c'est de le noter au fur et à mesure. Une théorie qu'on garde en tête se dégrade d'une session à l'autre ; une théorie dans un fichier texte, à côté de la requête qui l'a prouvée, survit. La moitié de mes scrapers, c'est en fait ce fichier avec du code autour — une liste qui s'allonge de « si ça ressemble à ça, ça veut dire ça », accumulée une surprise à la fois. Quand le système source change six mois plus tard, ce fichier fait la différence entre une après-midi et une réécriture.
On apprend aussi où s'arrêter. Vous n'avez pas besoin d'un modèle complet du système, seulement d'assez pour terminer la tâche devant vous et pour remarquer quand une hypothèse se casse. Chercher à comprendre entièrement quelque chose qu'on ne touchera qu'une fois est sa propre forme de gâchis.
Une partie du travail où cela a le plus compté est un travail que je ne peux pas exposer ici — fait pour d'autres, sous des conditions qui gardent les détails privés. La technique était la même que tout ce qui précède ; seul le compte rendu manque.
Ça vaut la peine de s'y appuyer parce que c'est la porte d'entrée de celui qui vient de l'extérieur. Vous n'avez besoin ni de permission, ni de partenariat, ni de contrat de support : il vous faut de la patience et une tolérance à vous tromper plusieurs fois avant d'avoir raison. Une fois à l'aise avec ça, toute une catégorie de « on ne peut pas, ils n'ont pas d'API » se transforme discrètement en « laissez-moi une après-midi ».
Il y a une ligne, et elle est rarement floue en pratique : étudier comment fonctionne quelque chose — une copie sous licence sur votre propre machine, une réponse dans votre propre navigateur — n'est pas la même chose que s'introduire dans un système que vous n'avez pas le droit de toucher, ni que faire circuler ce que vous avez construit à partir de ce que vous avez appris. Je reste du bon côté. Tout ce qui précède vise à rendre lisible ce qui est permis, pas à rendre accessible ce qui est interdit.
Les fondations sont posées ; maintenant, il faut construire.