La face cachée des tickets RATP
Publié le 24 février 2012

Grand utilisateur de tickets de métro (émis par le STIF/RATP), je me suis posé la question un jour (oui, j’ai de ces idées pourries des fois) de savoir comment sont codées les informations sur ce support magnétique. L’idée m’a semblé intéressante à creuser, mais nécessitait un brin de bidouille électronique. L’occasion de tester mon nouveau fer à souder reçu à Noël, et de découvrir l’univers des bandes magnétiques et plus particulièrement celui des tickets de la RATP.

Les bandes magnétiques

J’ai fureté pendant des heures sur Internet, à la recherche de documentation sur la lecture des bandes magnétiques, ainsi que sur les normes de codage employées. J’ai déniché quelques papiers intéressants :

Ces trois ressources sont très intéressantes, le white paper du CCC étant celle qui m’a apporté le plus. J’en ai discuté au boulot avec Tixlegeek, et il m’a lui aussi soumis l’idée d’utiliser la carte son de mon ordinateur portable pour échantillonner les données stockées sur le ticket (à l’instar de ce qui est documenté dans le papier de Joseph Battaglia). Il s’agit là d’un hack archi-simple, vu qu’il suffit de trouver une tête de lecture d’un vieux lecteur cassette et de la souder sur un jack 3.5 puis de le brancher dans la prise micro. La carte son fera le reste.

En ce qui concerne le codage des données sur bande, celui-ci peut se faire de deux manières :

La première méthode est celle employée pour stocker des données audio, mais est peu robuste. La seconde permet de stocker de manière plus robuste, et indépendamment de la vitesse de lecture ou d’écriture, des données binaires. C’est celle qui est préférée dans la grande majorité des systèmes de stockage numériques sur bande.

Le codage de fréquence le plus classique a un joli surnom : F2F. Ou plus généralement connu sous le nom de Aiken Biphase. L’idée est de coder le 0 avec un signal de fréquence F, et le 1 avec un signal de fréquence 2F. L’avantage de ce codage, c’est que peu importe la vitesse de lecture (qui est variable selon les périphériques), le décodage reste fiable. Bon par contre ça complique un brin la phase de décodage. Patrick Gueulle explique très bien cela dans son livre "Carte magnétique et PC".

Traitement du signal

Le papier du CCC [2] présente deux programmes (nommés DAB et DMBS) visant à respectivement décoder le codage Aiken Biphase (F2F) et à extraire les données selon les normes ISO781X. Ces mêmes programmes ont été utilisés par K1wy dans [1]. Le souci c’est que ceux-ci ont été principalement conçus pour les cartes magnétiques rigides à trois pistes, pas forcément pour les tickets de métro. De plus, selon les réglages audio de l’ordinateur servant à la capture (Mic-Boost notamment). Il me fallait une solution plus malléable, car ces deux programmes sont écrits en C et pas forcément bien documentés.

J’ai trouvé plusieurs modules python permettant de réaliser la capture d’un signal sur l’entrée micro et le traitement de celui-ci :

A l’aide de ces modules, j’ai réalisé quelques scripts de capture de signal et de sauvegarde des données sous format PCM et WAV. l’avantage de pouvoir sauvegarder les captures audio est double : on peut facilement refaire des analyses et surtout on peut les lire avec des outils comme Audacity. J’ai donc réalisé un script de capture du signal, et un script de traitement visant à traiter le signal afin de mettre en évidence le codage fréquentiel.

J’ai réalisé les tests de capture à l’aide d’un micro, et utilisé pylab pour afficher l’allure du signal. Pour le coup, c’était assez efficace :

Il m’a fallut ensuite réaliser mon lecteur de bande magnétique à la manière du CCC, à l’aide d’un vieux lecteur de cassette audio, d’un fer à souder, d’un jack 3.5 et d’un cable IDE =). J’ai du sacrifier mon super lecteur CD/K7 de mes 18 ans (de toute façon je n’ai plus de K7), mais c’est pas grave.

Fabrication du lecteur de bande magnétique maison

Premièrement, j’ai démonté le lecteur pour pouvoir accéder à la partie électro-mécanique au niveau du lecteur de K7 :

Une fois les têtes de lecture et d’écriture démontées, j’ai pu souder la tête de lecture (stéréo, mais on s’en moque) sur le jack 3,5mm. Bon la méthode de connection étant pas trop documentée, j’ai un peu galéré mais j’y suis arrivé. Pour information, si vous essayez de refaire le montage chez vous et que vous employez un jack 3,5mm stéréo, faites très attention au contact central : il délivre du 5V (cette tension est utile pour les microphones de type Electret). Pour ma part j’ai pas gazé car j’aurais du relier la sortie de la seconde bobine de lecture à la première, pour cumuler les tensions de sortie, alors que dans mon montage je l’ai mise à la masse (donc je n’utilise qu’une seule des deux bobines de lecture).

J’ai utilisé trois fils couplés d’un cable IDE, de manière à avoir de quoi manipuler la tête de lecture et l’éloigner de l’ordinateur portable (pour limiter les interférences). Bon au final ça n’a pas tellement aidé, le cable IDE faisant une merveilleuse antenne. Une meilleure solution serait d’utiliser un cable blindé à trois brins dont le blindage est mis à la masse. Une fois celui-ci connecté à mon ordinateur portable, j’ai pu balayer un ticket de métro et capturer avec mon précédent script le signal issu de la tête de lecture (signal brut).

Décodage du signal et analyse

A l’aide de ce lecteur de bande magnétique fait maison et de mes quelques scripts, j’ai codé un second script permettant de mettre en évidence les données codées sur la bande magnétique, et ça n’a pas été une paire de manche. J’ai réalisé trois décodages pour la forme :

Et voilà les données codées (Aiken Biphase, ou F2F) extraites des captures de signaux :

Le premier est issu d’un ticket neuf, et les deux suivants de deux tickets a priori validés à Saint Lazare (Paris). Il est flagrant de voir qu’un motif général est présent, motif que l’on retrouve en partie dans le ticket de métro neuf. Chose intrigante, le ticket de métro neuf possède moins d’information que les tickets compostés. J’en déduis donc que des données sont ajoutées lors de la validation, et qu’un ticket de métro neuf est codé d’une manière particulière.Si vous regardez bien, il y a de légères variations de période, mais cela est dû au fait que je scanne manuellement, et ma vitesse de balayage n’est pas constante.

J’ai donc entrepris de décoder les premiers bits significatifs communs aux trois tickets, et voici ce qui en ressort :

Ticket neuf:
11111111 00100 11111 11111 11111 0

Ticket #1:
11111111 00100 11111 00110 01001 0

Ticket #2:
11111111 00100 11111 00110 01110 1

Les espaces sont de mon fait ;). J’ai pu déduire le rôle de chacun (ou du moins tenter de deviner) à partir des informations décodées :

Si on regarde de plus près le codage, on peut voir que sur le premier ticket validé les troisième et quatrième séquences de 5 bits correspondent aux valeurs 69 et 6E. Ou plus précisemment aux valeurs 6 et 9, et 6 et 14. Cela ressemble bien aux codes de stations connus de Paris, tels que décrit sur Wikipédia. Cela signifie qu’un de mes tickets a été validé à Saint-Lazare même (code station 0609), l’autre à la station ayant pour code 0614 (inconnu sur Wikipédia oO). Le dernier bit que j’ai repéré semble être un bit de parité.

Le plus drôle dans l’histoire, c’est de voir que le ticket vierge n’a aucune valeur paramétrée, si ce n’est le type de ticket (première séquence de 5 bits). Donc facile à cloner.

Conclusion

La sécurité des tickets de métro ... heuu.... quelle sécurité ? Il est a priori aisé de dupliquer des tickets neufs (aucune limite dans le temps ni dans l’espace, la seule limitation est technique (il faut un matériel particulier). De même, je n’ai pas détaillé ici le décodage complet mais la suite des bits stockés représentent très certainement la date de validation et l’heure de validation, mais je n’ai pas vraiment cherché à le décoder.

Heureusement qu’il y a le passe Navigo pour tous nous sauver (spéciale dédicace à Nono2357 ;).