TRAVAUX PRATIQUES

Ce chapitre vous permettra de vous familiariser avec le monde des cartes (M4 et B4B0, M9, SIM, EMV). Il est nécessaire d'utiliser le logiciel PCCAM que vous pouvez télécharger sur ce site. L'utilisation de ce logiciel ne doit être fait qu'à des buts didactique.

Un lecteur de carte, préférentiellement de type PC/SC est également nécessaire. Avec de très anciennes cartes avec les contacts en position AFNOR, un lecteur de type GCR200 de Gemplus ou TLP224 de Bull devra être utilisé. Ces lecteurs ne sont plus fabriqués et ne peuvent se trouver qu'en occasion.

Carte M4 et B4B0'

Identification des cartes

Une CAM exécute des ordres conformément à un programme qui se trouve dans sa mémoire permanente et selon un état mémorisé dans son EPROM, E²PROM ou flash. Dans le jargon de la micro-électronique, on appelle masque, le cache qui a permis d'implanter la ROM. Par analogie, c'est par le nom ou le numéro du masque que l'on définit une CAM et ses possibilités. On parlera ainsi de la carte de masque 4 de Bull CP8 ou du masque A2 de la carte M64 de Schlumberger, ou du masque TB100 de TRT-Bull.

Note : dans certaines cartes, ce programme ne se trouve plus en ROM mais en flash. Il ne s'agit donc plus de mémoires masquées mais l'habitude est restée de désigner le programme de la carte sous le nom de masque

On a longtemps identifié les cartes par leur référence de masque. Toutefois, cette identification est ambigüe. Plusieurs fabricants peuvent proposer des cartes ayant les mêmes fonctionnalités mais n'ayant pas les mêmes masques. Par exemple, plusieurs fabricants proposent des cartes EMV utilisées dans le monde du paiement mais aucune n'a les mêmes masques, ni le même programme. Dans les années 1980, Bull-CP8 proposait un masque M4 mais afin de disposer d'une seconde source (demandée par les clients), la société TRT (Philips) proposa également une carte ayant les mêmes fonctionnalités que celle de Bull-CP8 mais développé sur un autre processeur. Le masque programme était donc différent de celui de Bull-CP8 mais on continua de l'appeler M4.

L'identification d'une carte n'est donc pas quelque chose d'aussi évident qu'il apparait au premier abord. En pratique, une CAM dépend :

• de son composant électronique (microcontrôleur sécurisé) qui a une identification
• de la référence du programme qu'elle exécute. Et lorsqu'il y a plusieurs programmes possibles (cartes multi-applications), des références de ces programmes.
• parfois, de la référence à plate-forme d'interprétation JavaCard, (de plus en plus souvent le cas depuis le début des années 2000).
• et parfois, d'autres éléments.

Tout cela n'est pas fait pour simplifier cette identification alors qu'elle est cruciale pour les émetteurs de cartes. Pour illustrer ce point, considérons des organismes bancaires qui émettent des cartes EMV. En 2012, on trouvera des fournisseurs tels que Morpho, Gemalto, Oberthur ou G&D par exemple. Supposons qu'une des cartes d'un de ces fournisseurs ait un problème de sécurité. La simple mention de l'application "carte EMV" ne sera pas suffisante pour identifier clairement la carte de ce fournisseur particulier.

Comme on le verra par la suite, la normalisation s'est emparée de ce problème et a proposé une solution avec les normes ISO7816-5 et ISO7816-6.

L'acteur le plus visible pour l'émetteur de la carte est le personnalisateur qui est souvent un concepteur de "masque". L'identification du produit sera donc celle proposée par le masqueur sous la forme d'un nom commercial (par exemple, "IdealCitiz" de Morpho) et d'une suite de références permettant de retrouver:

• la version du composant utilisé
• la version de la plate-forme lorsqu'il s'agit d'une JavaCard  (ou autre interpréteur comme par exemple, Multos)
• la version des applications embarquées (par exemple, EMV, Monéo...)

Une fois ceci énoncé, quelles informations sont accessibles ?

Sur les anciennes cartes, on devait tenter de discriminer les octets renvoyés par la carte lorsqu'on la mettait sous-tension. On parle d'ATR (Answer To Reset) ou d'Octets de Mise Sous Tension (OMST). Ce terme d'ATR est important car encore aujourd'hui (en 2012), leur interprétation est souvent le moyen de procéder à un premier tri entre les cartes.

Quelle forme a un ATR ?

Pour répondre à cette première question, il faut mettre en oeuvre une fonctionnalité de base de PCCAM qui est la mise sous tension à froid. Pour ce faire, il faut connecter un lecteur à un ordinateur, PCCAM est supposé installé.

Sélectionnez le lecteur On sélectionne le lecteur via le menu "Contexte->Choix Lecteur". Ceci fait, on tape "MST" en ligne de commande ou on sélectionne l'option "Ordres->Mise sous tension carte à froid". On peut déduire que la réponse qui ci-dessous provient d'une carte Axalto émise en 2006

*-- Carte B4B0
*-- ATR = 3F 65 25 08 58 04 6C 90 00
*-- ME1 = 90 : ordre bien exécuté
*-- ME2 = 00

Les octets 3B 65....90 00 correspondent à la réponse reçue à la mise sous tension. Si vous vous attendiez à quelque chose de lisible par un humain normalement constitué, c'est un peu raté. Mais le programme a néanmoins déterminé qu'il devait s'agir d'une carte B4B0.

Une partie des valeurs de ces octets est normalisée et correspond à des informations techniques sur la façon dont l'environnement (le lecteur de carte) devra dialoguer avec la carte. Ces octets sont donc peu utiles pour identifier les cartes car beaucoup d'entre-elles ont les mêmes caractéristiques. Dans la réponse citée, une demande de décodage de ces octets par PCCAM (commande "ATR" ou via le menu, "Outils->Décode ATR") donnera le résultat suivant :

*-- ATR = 3F 65 25 08 58 04 6C 90 00
*-- TS = 3F : Convention inverse
*-- T0 = 65 : TB(1) TC(1) 5 octet(s) d'historique
*-- TB(1) = 25 : Vpp = 5V, Ipp = 25mA
*-- TC(1) = 08 : Extra Guard Time = 8
*-- Protocole T=0 imposé
*-- Fi = 372, Di = 1 (valeurs par défaut)
*-- MCF = 58 : référence de composant
*-- MCE = 04 : référence de masque
*-- MCH = 6C : zone de transaction protégée en lecture
*-- MCH = 6C : zone de transaction protégée en écriture
*-- MCH = 6C : carte valide
*-- MCH = 6C : fabrication achevée
*-- MCH = 6C : personnalisation achevée
*-- MCH = 6C : clé 2A active
*-- ME1 = 90 : ordre bien exécuté
*-- ME2 = 00
*-- Carte [...]

ME1 et ME2 (SW1 et SW2 en anglais) sont des mots d'états et sont donc peu discriminants. Les octets nommés TS, T0, TB et TC fournissent des informations techniques à l'environnement. Les seuls octets susceptibles d'être spécifiques sont les octets d'historique qui sont propres, soit à un standard particulier, soit au constructeur.

Dans le cas présent, le programme a trouvé que ce qui se rapprochait le plus d'une telle réponse correspondait à une carte B4B0'. Il peut donc interpréter les octets d'historiques qui en l'occurrence, sont les mêmes que ceux de la carte M4 d'origine. On a le n° du masque (MCE=4, masque 4), une référence de composant (MCF=58, il faut disposer d'une table de correspondance pour savoir de quel composant il s'agit réellement) et l'octet "chronologie" de la carte M4. La carte ne répond qu'au protocole T=0.

En pratique, la discrimination des cartes par l'interprétation de l'ATR est sujet à caution et d'autres moyens s'avèrent nécessaires pour confirmer l'identification. On peut citer :

• L'envoi d'un ordre qui n'est reconnu que par la carte que l'on cherche à identifier (les autres répondant "ordre incorrect" ou ne répondant pas). Ce moyen était utilisé dans les débuts de la carte mais la normalisation a tendance à limiter cette possibilité
• La lecture dans la carte d'une information particulière. C'est en effet le moyen qui tend à s'imposer.

Lecture d'une carte M4B0 ou B4B0'

Puisque l'on suppose avoir à faire à une carte de type M4, tentons une lecture de la zone de fabrication qui contient les adresses des différentes zones de la carte et le type d'application (terminologie Bull). Pour cela, nous envoyons l'ordre sortant de lecture en commençant à l'adresse #9C0 jusqu'à la fin de la mémoire qui se trouve en #A00 (cf. les spécifications de la carte M4). L'ordre de lecture est #B0. La classe d'instruction de la carte est #BC. Tentons un ordre de lecture de 32 octets en suivant la norme ISO7816-3.

CMD #BCB009C020, T1

Dans la syntaxe PCCAM, "CMD" désigne une commande à émettre vers la carte. Le premier paramètre qui suit peut être la valeur en hexadécimal de l'ordre à émettre ou un tableau d'octets (T0 à T9 dans PCCAM) qui contient cet ordre. Dans le cas présent, on a CLA=#BC, INS=#B0, ADR1=#09, ADR2=#C0 (adresse quartet de la carte = #9C0), LG=#20=32.

Le deuxième paramètre est séparé du premier par une virgule et est optionnel. Il désigne un tableau d'octets (T0 à T9) qui recevra la réponse, si réponse il y a. Dans le cas présent, l'ordre de lecture est dit "sortant" car il implique une sortie d'octets de la carte. Le deuxième paramètre est donc nécessaire. Le résultat sera donc dans T1. La réponse de la carte est la suivante

CMD #BCB009C020, T1
*-- ME1 = 90 : ordre bien exécuté
*-- ME2 = 00

ME1=#90 et ME2=#00 signifie que l'ordre a été correctement exécuté. Si l'on tape "T1" en ligne de commande ("T1" sans paramètre signifie "dump du contenu de T1"), PCCAM affiche :

T1
*-- T1[ 0, 15] = 1B 5F 64 1E 1F 45 10 D0 0B EB 0B 7F 0B 10 08 D9 ·_d··E··········
*-- T1[ 16, 31] = 3F E5 20 02 08 4D 00 DE 16 63 19 E2 E0 00 9F FF ?· ··M···c······
*-- T1[ 32, 47] = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ················
*-- .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
*-- T1[1008,1023] = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ················

On note le #3FE5 au début de la deuxième ligne. Il s'agit du type d'application désignant les cartes bancaires. Le reste est moins évident... La lecture de la documentation de la carte M4 permettrait de savoir que les premiers 16 bits contiennent une adresse dont les 2 premiers bits doivent être à 0 (bits V et C de la carte M4) et les 5 derniers bits correspondent à un code détecteur d'erreur., et ainsi de suite. La figure qui suit donne une idée du contenu de cette zone pour une carte M4. Pour une B4, il y a quelques différences minimes.

En l'absence de la documentation de la carte M4, PCCAM propose un décodage automatique de cette zone et en fait, une lecture avec interprétation intelligente de la carte. Tapez "MAP" en ligne de commande ou en utilisant le menu, sélectionnez "Outils->Mapping..."

Suite à cette commande, PCCAM va tenter de lire l'intégralité de ce qui est lisible dans la carte. Si la carte n'est pas invalidée, son code porteur vous demandé. Si vous annulez la saisie, PCCAM ne pourra lire que la zone en lecture libre de la carte. Si vous saisissez un PIN correct, PCCAM lira également la zone de transaction et la zone d'état.

Si la carte est invalidée, il n'y a plus besoin de présenter le PIN pour lire la zone de transaction ou la zone d'état (un ordre de validation en lecture suffit). Vous devriez obtenir les écrans suivants :

Voila qui est plus clair. Les ADx correspondent aux adresses mémoire des différentes zones de la carte. Certaines sont inaccessibles (celles qui contiennent les clés). D'autres sont accessibles sous certaines conditions.

Les CCR sont les codes détecteurs d'erreurs. A l'origine, ils n'étaient pas vérifiés par la carte mais devaient être vérifiés par l'environnement.

"Test" est un des octets de test qui visaient à vérifier que l'on n'avait pas tenté d'effacer la mémoire aux UV.

A l'aide de "NI" et I (numéro de lot de la carte) et du numéro de série ainsi que d'une clé, il était possible de calculer la clé (en fait, un code) dite "de fabrication" nécessaire pour pouvoir personnaliser la carte

"EP" à 0 signifie, écriture protégée" dans la zone de transaction. "LP" à 0 signifie lecture protégée dans la zone de transaction (à 1, écriture et lecture non protégée). Donc, pour lire, il faut présenter un des codes de la carte (par exemple, le PIN) et pour écrire le bit de validation d'un mot (le bit V), il faut présenter un code conforme à ce qui est codé dans "C" et "CA" (voir le chapitre sur la carte M4 pour plus de précision).

Les "E1, L1..." correspondent aux condition d'effacement des différentes zones.

Si l'on sélectionne l'onglet "zones", on obtient les adresses quartet des différentes zones de la carte ainsi que leur taille :

Il est possible de jeter un oeil sur le contenu de la zone de transaction en sélectionnant l'onglet "Transaction" :

Et ainsi de suite.

Deux boutons sont disponibles sur la fenêtre. Si on clique sur le bouton "Capture Carte M4/B4", le programme propose d'enregistrer le contenu de ce qu'il a lu dans un fichier. PCCAM dispose d'un simulateur de carte M4. PCCAM est en mesure d'utiliser cette image de la carte pour en simuler le fonctionnement à l'exception près qu'il ne peut pas connaître pas les codes et les clés réelles de la véritable carte.

Pour mettre sous tension une carte simulée, le plus simple est de passer par le menu "Ordres->Mise sous tension carte Simulée". PCCAM propose les différents fichiers disponibles (.SIM) et effectuera la une mise sous tension. On peut ensuite dialoguer avec les ordres connus de la carte comme s'il s'agissait d'une vraie.

Note: le programme ne simule que les cartes M4, pas les B4. D'autre part, le programme triche lorsque l'on utilise l'outil "MAP". PCCAM ne demande pas le code de la carte et lit tout son contenu (y compris les clés).

Si on clique sur le bouton "Analyse Carte Bancaire", le programme effectue une vérification de la cohérence des données contenues dans la carte et en fait également une traduction en clair qui est proposée dans les écrans suivants :

Dans l'écran ci-dessus, certaines valeurs réelles ont été remplacées par d'autres en caractères gras. On note la présence de deux informations en rouge. La première signale que la carte est périmée par rapport à la date du système. La seconde signifie que PCCAM n'a pas pu authentifier correctement la signature statique de la carte (il ne dispose pas de la clé publique pour le faire). Enfin, il n'a pas reconnu le composant (la liste n'est pas publique). Ces informations sont récapitulées dans l'onglet "Err/Info".

Si l'on sélectionne l'onglet "Transaction", on peut obtenir la liste des transactions réalisées et mémorisées dans la carte.

Si l'on clique sur l'onglet "Plafonds", on peut obtenir la liste des plafonds de paiement inscrits dans la carte.

A noter que d'autres onglets peuvent apparaître selon la présence ou non de certains services mémorisés dans la carte

Voila qui clôt provisoirement cette partie des travaux pratiques sur la carte M4 et qui permet également de se familiariser avec le logiciel PCCAM

Carte M9

Identification des cartes

Avertissement : la lecture du TP sur les cartes B4B0' ou M4 est fortement conseillée avant d'aborder ce TP

Pour ce TP, j'utilise une carte VITALE 1, n'ayant plus d'autres carte M9 sous la main. Celle que j'utilise date de 1998.

Pour cette carte, PCCAM a une petite particularité. Il existe plusieurs modèle de carte M9 qui diffèrent en particulier sur la taille mémoire. Or, pour lire cette carte correctement, il faut commencer (comme pour la M4) par lire la zone de fabrication afin de récupérer les adresses des autres zones. Cette zone de fabrication se trouve dans les adresses hautes de la carte. Il y a deux façon de connaître l’adresse haute de la carte courante :

• La première consiste à interpréter l’octet MCE rendu par la carte à la mise sous tension
• La seconde consiste à interroger la carte via une commande de « lecture de résultat » (commande #BCC0000008). Lorsque cette commande est envoyée juste après une mise sous tension, les octets 2 et 3 contiennent l’adresse de fin de la carte.

PCCAM enchaine la mise sous tension avec l’exécution de cette commande. Si pour une raison ou une autre, cette commande échoue, PCCAM tente de déterminer l’adresse de fin à partir de l’octet MCE. Pour certaines cartes, il est possible que cette adresse ne soit pas correcte. En effet, le programme ne connait que les cartes SCOT de Bull CP8 mais d’autres cartes sont apparues par la suite dont les spécifications ne sont pas disponibles.

Dans le cas présent, voici le résultat de la mise sous tension.

MST
*-- Carte M9
*-- ATR = #3F 65 25 00 2C 09 69 90 00
*-- ME1 = #90 : ordre bien exécuté
*-- ME2 = #00

Voici ce que donne le décodage de l’ATR.

ATR
*-- ATR = #3F 65 25 00 2C 09 69 90 00
*-- TS = #3F : Convention inverse
*-- T0 = #65 : TB(1) TC(1) 5 octet(s) d'historique
*-- TB(1) = #25 : Vpp = 5V, Ipp = 25mA
*-- TC(1) = #00 : Extra Guard Time = 0
*-- Protocole T=0 imposé
*-- Fi = 372, Di = 1 (valeurs par défaut)
*-- MCE = #2C : référence de composant M9 Vitale, adresse de fin= #2188
*-- MCF = #09 : référence de masque
*-- MCH = #69 : zone de transaction non protégée en lecture
*-- MCH = #69 : zone de transaction protégée en écriture
*-- MCH = #69 : carte valide
*-- MCH = #69 : fabrication achevée
*-- MCH = #69 : personnalisation achevée
*-- MCH = #69 : clé 2A active
*-- ME1 = #90 : ordre bien exécuté
*-- ME2 = #00
*-- Sesam Vitale (French health card)

Et voici ce que donne une nouvelle lecture de résultat :

cmd #BCC0000008,T1
*-- ME1 = #90 : ordre bien exécuté
*-- ME2 = #00
T1
*-- T1[ 0, 15] = 00 00 21 88 00 00 0E 08 FF FF FF FF FF FF FF FF ··!·············
*-- T1[ 16, 31] = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ················
*-- .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
*-- T1[1008,1023] = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ················

Dans le décodage de l'ATR, on remarque que MCF=#09 ce qui correspond au masque 9 de Bull et MCE=#2C. Cette valeur donne le type du composant et son adresse de fin. Voici celles que je connais :

Dans le cas présent, on a donc une adresse de fin théorique égale à #2188 ce qui correspond bien à ce qui est rendu suite à la commande de lecture du résultat

Les ordres et la structure de la carte sont détaillés dans le chapitre consacré à la carte M9. On peut faire quelques lectures comme par exemple, la lecture du dernier mot de la carte.

CMD #BCB0218004, T1
*-- ME1 = #90 : ordre bien exécuté
*-- ME2 = #00
T1
*-- T1[ 0, 15] = 58 16 9F FF 00 00 0E 08 FF FF FF FF FF FF FF FF X···············
*-- T1[ 16, 31] = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ················
*-- .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
*-- T1[1008,1023] = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ················

On peut aussi utiliser la commande « mapping » (à condition que la carte ait été reconnue par PCCAM) ce qui évite d'avoir à enchaîner des ordres unitaires.

Après lecture de la mémoire, on peut obtenir ceci avec les informations correspondantes dans les onglets (zone de fabrication, les différentes zones et leur taille, le dump binaire-hexa-ascii de ces zones (celles qui sont accessibles).

On note que les zones de travail sont protégées en écriture et en lecture libre (bits EPi). Pour le reste, l'interprétation est très proche de ce que l'on a vu pour la carte M4. Pour les protections, on a une vue plus lisible dans l'onglet correspondant.

Les tailles de zones sont fournies ci-dessous. A noter que ces tailles varient en fonction des modèles de carte et surtout, que toutes ne sont pas toujours présentes en fonction de la personnalisation. Dans le cas présent, on a une zone en lecture libre de 4 octets (inutilisée) alors que dans d'autres cartes, cette zone peut être absente.

Et voici le résultat d'un dump de la zone de travail. J'ai choisi un endroit où il n'y a pas de données utiles, ce qui n'est pas très difficile à trouver, la carte est quasiment vide d'informations

Un bouton proposé dans la fenêtre permet (Capture) permet de sauver l’image lue de la carte. PCCAM dispose d’un simulateur de carte M9 qui permet de jouer avec la carte comme si elle était réelle sauf que les clés et codes réels qui ont été personnalisés ne sont pas accessibles.

L’autre bouton (Analyse) permet d’avoir un décodage (très) partiel des informations lues dans la carte Vitale, « partiel » car les spécifications du codage ne sont pas publiques. Toutefois, on retrouve assez facilement le n° de sécurité sociale et la date de naissance qui sont codées en BCD à condition de bien comprendre le rôle des bits V, C et CA en début de chaque mots.

La valeur par défaut d’un bit dans la mémoire est 1. Dans une zone protégée en écriture, le bit V (le bit 31 de poids fort de chaque mot) peut être positionne à 0 si les bits C et CA sont positionnés correctement en fonction de celui qui écrit (et qui est porteur d’une clé ou d’un code particulier), comme pour la carte M4.

Ainsi, pour pouvoir positionner le bit V à 0, il vous faudra :

• Soit positionner les bits C et CA à 1 (donc les laisser à leur valeur initiale) et présenter la clé 1A de la carte,
• Soit positionner les bits C et CA à respectivement 1 et 0 et présenter la clé 1B de la carte,
• Soit positionner le bit C à 0 et présenter le code porteur (ou la clé de fabrication). Dans ce cas, le bit CA peut être utilisé comme bit de données.

Ainsi :

• les valeurs 0111 (7) ou 0110 (#C) en tête signifient que le mot a été écrit sous contrôle de la clé 1A
• les valeurs 0101 (5) ou 0100 (4) en tête signifient que le mot a été écrit sous contrôle de la clé 1B
• la valeur 00xx (0000, 0001, 0010, 0011 ou 0, 1, 2, 3) en tête signifient que le mot a été écrit sous contrôle de la clé porteur
• la valeur 1xxx signifie que le mot n’a pas été validé. Dans ce cas, les bits xxx peuvent servir de bits de données.

Tous les mots qui commencent par le bit 31 à 0 ont donc été écrits sous contrôle d’un code. Et s’ils commencent par 00 en binaire, cela signifie qu’il ne s’agit pas de bits de données et doivent être ignorés dans les analyses. Lorsqu’on lit la carte et que des données tiennent sur plusieurs mots commençant par le bit 0, il faut donc ignorer les 2 ou 3 premiers bits.

On rappelle que tout cela n’est vrai que pour les zones protégées en écriture.

Cartes EMV

Avertissement : la lecture du TP sur les cartes B4B0' ou M4 est fortement conseillée avant d'aborder ce TP

En Europe et dans beaucoup d'autres pays, les personnes disposent généralement d'une carte bancaire à puce : depuis la fin des années 1980 en France, depuis la fin des années 1990 au Royaume Uni, normalement, depuis 2009 en Europe, etc.

Le standard actuel (2014) pour les cartes à puce est EMV, basé en partie sur la norme ISO7816-4. Ce standard est en fait une boîte à outils dans laquelle les différents réseaux de paiement (CB, VISA, MASTERCARD...) puisent ce dont ils ont besoin pour construire leur carte. Le résultat est qu'il peut y avoir beaucoup de différences entre les cartes émises par ces réseaux et aussi, en fonction des années... Cela ne simplifie pas forcément leur analyse.

Vous trouverez ci-dessous quelques exemples commentés sur ces différentes cartes. Cela permet de savoir ce qu'il y a dedans sans avoir à analyser complètement la norme et aussi, de voir quelques différences de comportement significatives.

En fait, les ennuis commencent dès la mise sous tension de la carte. Si vous avez lu le TP sur les cartes B4B0' ou M4, vous savez pourquoi. En résumé, il est assez aléatoire de déterminer le type d'une carte à partir de ce qu'elle renvoie à la mise sous tension. Or, PCCAM a besoin de connaitre le type de carte pour interpréter correctement les résultats des commandes.

Considérons une ancienne carte bancaire du milieu des années 2000. A la mise sous tension, on peut être dans la situation suivante :

• PCCAM ne reconnait pas la carte. Il affecte alors CAM au type de carte.
• PCCAM reconnait une carte mais ce n'est pas la bonne. Par exemple, il indique qu'il s'agit d'une carte MP.

Dans ces deux cas, si l'on a de bonne raison de penser qu'il s'agit d'une carte bancaire, on peut forcer le type via la commande CARTE ou le menu ou la lise déroulante. Mais quel type mettre ?

Avant de répondre à la question, il faut lister les autres réponses possibles à la mise sous tension :

• PCCAM indique la carte est une B4B0.
• PCCAM indique que la carte est une EMV.

Les deux sont des cartes bancaires. Il faut savoir que jusqu'à une certaine époque, les cartes utilisées dans le système CB étaient soient B4B0' seules, soit B4B0' et EMV. Ensuite, elles sont devenues uniquement EMV.

Comme nous sommes dans la partie EMV des TP, le cas de la carte B4B0' n'est pas pertinent. Mais avant de forcer le type de la carte, tentez une mise sous tension à chaud ("Ordres->Mise sous tension à chaud"). Si l'ATR change, alors, il y a fort parier que la carte est aussi une EMV. Mais pour accéder à cette application, il faut impérativement faire une double mise sous tension, une fois à froid, l'autre fois à chaud. Le chapitre sur la normalisation explique les raisons de cette curiosité.

Récapitulons : si PCCAM ne reconnait pas correctement la carte, soit on a de bonnes raisons de penser qu'il s'agit d'une carte EMV (sans B4B0') et l'on peut alors forcer le type de la carte à EMV, soit il faut tenter une mise sous tension à chaud. Si l'ATR change, il est fort probable que c'est une carte qui a les deux applications. On peut donc forcer le type à EMV après la deuxième mise sous tension.

Mais heureusement, PCCAM reconnait beaucoup de cartes et en général, ça se passe bien...

A ce stade, la carte est sous tension et il s'agit d'une EMV. On peut tenter de décoder l'ATR en entrant "ATR" (ou "Outils->Décode ATR" ou le bouton dans la barre de menus). Voici ce que vous pouvez obtenir (ici, il s'agit d'une carte comportant les deux applications et PCCAM les reconnait à chaque fois) :

MST
*-- Carte B4B0
*-- ATR = #3F 65 25 08 58 04 6C 90 00
*-- ME1 = #90 : ordre bien exécuté
*-- ME2 = #00
ATR
*-- ATR = #3F 65 25 08 58 04 6C 90 00
*-- TS = #3F : Convention inverse
*-- T0 = #65 : TB(1) TC(1) 5 octet(s) d'historique
*-- TB(1) = #25 : Vpp = 5V, Ipp = 25mA
*-- TC(1) = #08 : Extra Guard Time = 8
*-- Protocole T=0 imposé
*-- Fi = 372, Di = 1 (valeurs par défaut)
*-- MCF = #58 : référence de composant
*-- MCE = #04 : référence de masque
*-- MCH = #6C : zone de transaction protégée en lecture
*-- MCH = #6C : zone de transaction protégée en écriture
*-- MCH = #6C : carte valide
*-- MCH = #6C : fabrication achevée
*-- MCH = #6C : personnalisation achevée
*-- MCH = #6C : clé 2A active
*-- ME1 = #90 : ordre bien exécuté
*-- ME2 = #00
*-- Carte Bancaire B4B0 mode (French banking card)
MST WARM
*-- Carte EMV
*-- ATR = #3B 65 00 00 58 04 6C 90 00
ATR
*-- ATR = #3B 65 00 00 58 04 6C 90 00
*-- TS = #3B : Convention directe
*-- T0 = #65 : TB(1) TC(1) 5 octet(s) d'historique
*-- TB(1) = #00 : Vpp non connecté, génération courant prog. par carte
*-- TC(1) = #00 : Extra Guard Time = 0
*-- Protocole T=0 imposé
*-- Fi = 372, Di = 1 (valeurs par défaut)
*-- Historique propriétaire = #58 04 6C 90 00
*-- Carte Bancaire EMV mode (French banking card)

Une une petite différence sur la gestion du Vpp (tension de programmation) est visible. Dans un cas, il est indiqué qu'on doit lui fournir du 5V, dans l'autre, qu'il n'est pas connecté ce qui semble incohérent : en pratique, il ne fallait pas perturber les terminaux de paiements en risquant de les planter parce qu'on avait changé l'ATR pour les cartes B4B0'.

Selection de l'application EMV

Comment être sûr que l'on a bien une carte EMV ? Dans un premier temps, en vérifiant qu'elle se comporte comme une carte EMV. Dans un second temps, en l'authentifiant cryptographiquement

Pour commencer à dialoguer avec l'application EMV, il faut la sélectionner. Normalement, cela se fait par un ordre ISO7816-4 de sélection d'application. Le nom normalisé est "1PAY.SYS.DDF01" pour les cartes accédées en mode contact et "2PAY.SYS.DDF01" pour les cartes accédées en mode sans contact. Ceci dit, le standard EMV le précise bien, ce nom d'application est optionnel. Dans certains, cas, il y a donc un code d'erreur (fichier non trouvé) si l'on tente de sélectionner cette application.

En pratique, ce cas est rare et ne concerne que les premières cartes EMV.

Tentons donc la commande SELECT de sélection de l'application EMV en utilisant par exemple, le menu "Ordre -> ISO7816-4 -> Select". Pour cela, on sélectionne "O4 - Select by DF name", on entre le nom entre quotes '1PAY.SYS.DDF01' dans le champ de données, et on laisse les autres champs à leur valeur par défaut puis on appuie sur "OK".

On peut parfois tomber sur une carte qui ne connait pas ce nom d'application. Son étude sera faite plus tard. Voila ce que l'on devrait obtenir dans la majorité des cas :

CMD #00A404000E315041592E5359532E4444463031
*-- ME1 = #61 : Des octets sont prêts à être lus. Voir ME2 pour nombre d'octets.
*-- ME2 = #2D : GET_RESPONSE attendu, octets disponibles = 45

L'application a donc bien été trouvée et la carte souhaite renvoyer des données suite à cette sélection, c'est ce qu'indique le code retour dans ME1 et ME2.

Tentons un GET_RESPONSE, toujours en utilisant le menu "Ordre -> ISO7816-4 -> Get Response". On notera que le champ longueur est déjà rempli, PCCAM y met par défaut la valeur de ME2. Si on appuie sur OK, on obtient quelque chose qui ressemble à ça :

CMD #00C000002D,T1
*-- ME1 = #90 : ordre bien exécuté
*-- ME2 = #00

Le tableau T1 contient la réponse. En tapant T1 dans le champ commande, le tableau T1 est dumpé. Le dump ci-dessous est un exemple de ce que l'on peut obtenir :

T1
*-- T1[ 0, 15] = 6F 2B 84 0E 31 50 41 59 2E 53 59 53 2E 44 44 46 o+··1PAY.SYS.DDF
*-- T1[ 16, 31] = 30 31 A5 19 88 01 02 9F 11 01 01 5F 2D 02 66 72 01·········_-·fr
*-- T1[ 32, 47] = BF 0C 0A DF 60 02 0B 1E 9F 4D 02 0B 1E FF FF FF ····`····M······
*-- T1[ 48, 63] = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ················
*-- .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
*-- T1[1008,1023] = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ················

Il faut savoir que la plupart des réponses de la carte sont codés dans des TLV (pour Type, Longueur, Valeur ou en anglais, Tag, Length, Value), qui peuvent être parfois imbriqués. Le décodage étant un peu fastidieux, on peut essayer la commande "Decode" de PCCAM qui tente de fournir, au mieux, la valeur en clair des TLV, au pire, les T, V et L séparés en hexa.

decode 45,T1
*-- T=#6F L=43 : FCI
*-- T=#84 L=14 : Dedicated File (DF) Name = 1PAY.SYS.DDF01
*-- T=#A5 L=25 : Information de contrôle de fichier (FCI), modèle propriétaire
*-- T=#88 L=1 : Identificateur court (SFI) de l'EF = 02
*-- T=#9F11 L=1 : Index table code émetteur = #01
*-- T=#5F2D L=2 : Langage préféré = fr (Français)
*-- T=#BF0C L=10 : Information de contrôle du fichier (FCI), Informations propriétaires
*-- T=#DF60 L=2 : Log propriétaire = #0B 1E
*-- T=#9F4D L=2 : Entrée Log = 11, Nb = 30

On trouve en particulier :

• le nom de l'application sélectionné (T=#84),
• un nom d'EF court (T=#88) qui vaut 2,
• la langue préférée du porteur (T=#5F2D), en l'occurence le français,
• un Type non normalisé qui est #DF60 et qui en général, correspond à un format de log propriétaire,
• le nom du fichier de Log qui vaut 11, son nombre d'enregistrement qui vaut 30, le tout dans le Type #9F4D.

Lecture du fichier contenant les références des applications

Le nom de l'EF court va permettre par la suite de savoir quelles sont les applications de paiement (correspondant aux différents systèmes de paiement) disponibles dans la carte. Mais avant d'en arriver là, quelques mots sur les Logs.

Les cartes peuvent mémoriser les transactions dans leur mémoire. Ca ne sert pas à grand chose mais c'est historique (voir les raisons initiales dans l'historique de la carte). Le nom du fichier est donné par le premier octet du Type #9F4D. Les données du Log sont stockées selon un format qui est spécifié dans un autres type (#9F4F) associé au fichier de Log. Parfois, ce format n'est pas indiqué (format de log propriétaire). C'est ce que semble indiquer le Type #DF60. Lorsqu'il est présent, le format des données du fichier de Log est prédéterminé et le type #9F4F décrivant le format n'est donc pas forcément présent.

Si on souhaite connaitre les applications contenues dans la carte, il faut exploiter les données contenues dans l'EF 2. Dans l'exemple ci-dessous, le premier READ RECORD permet d'avoir un statut de la carte (ok et le nombre d'octets de l'enregistrement, pas ok), le deuxième READ RECORD permet de lire l'enregistrement lorsque la réponse était ok, puis, on termine par une tentative de décodage de ce qui a été lu. On doit sélectionner "Read Record number n" pour P1/P2.

CMD #00B2011400, T1
*-- ME1 = #6C : longueur incorrecte. Voir ME2 pour longueur correcte
*-- ME2 = #25 : longueur de données disponibles = 37
CMD #00B2011425, T1
*-- ME1 = #90 : ordre bien exécuté
*-- ME2 = #00
decode 37,T1
*-- T=#70 L=35 : Enregistrement de fichier
*-- T=#61 L=33 : Modèle d'application
*-- T=#4F L=7 : Identification de l'application = #A0000000421010
*-- CB (France)/Carte sans demande systématique d'autorisation
*-- T=#50 L=2 : Nom de l'application = CB
*-- T=#87 L=1 : Indicateur de priorité de l'application = 1
*-- T=#9F12 L=14 : Nom de l'application préférée = TRANSACTION CB
CMD #00B2021400, T1
*-- ME1 = #6C : longueur incorrecte. Voir ME2 pour longueur correcte
*-- ME2 = #29 : longueur de données disponibles = 41
CMD #00B2021429, T1
*-- ME1 = #90 : ordre bien exécuté
*-- ME2 = #00
decode 41,T1
*-- T=#70 L=39 : Enregistrement de fichier
*-- T=#61 L=37 : Modèle d'application
*-- T=#4F L=7 : Identification de l'application = #A0000000041010
*-- MasterCard/Classique (crédit ou débit)
*-- T=#50 L=10 : Nom de l'application = MASTERCARD
*-- T=#87 L=1 : Indicateur de priorité de l'application = 2
*-- T=#9F12 L=10 : Nom de l'application préférée = MASTERCARD
CMD #00B2031400, T1
*-- ME1 = #6A : paramètres (P1,P2) incorrects (voir ME2)
*-- ME2 = #83 : enregistrement non trouvé

Lecture des données d'une application de paiement

Dans cet exemple, la carte comporte deux applications de paiement :

• La première est CB (ou Cartes Bancaires) avec comme priorité, 1. Cela signifie que le terminal de paiement essayera d'abord d'utiliser cette application pour les paiements.
• La seconde est Mastercard. Elle n'est utilisée que si le terminal ne connait pas l'application CB (typiquement, à l'étranger).

Sélectionnons une des applications, par exemple, l'application #A0000000421010, la carte devrait renvoyer quelque chose ayant cette forme :

CMD #00A4040007A0000000421010
*-- ME1 = #61 : Des octets sont prêts à être lus. Voir ME2 pour nombre d'octets.
*-- ME2 = #3B : GET_RESPONSE attendu, octets disponibles = 59
CMD #00C000003B,T1
*-- ME1 = #90 : ordre bien exécuté
*-- ME2 = #00
decode 59,T1
*-- T=#6F L=57 : FCI
*-- T=#84 L=7 : Dedicated File (DF) Name = #A0000000421010
*-- CB (France)/Carte sans demande systématique d'autorisation
*-- T=#A5 L=46 : Information de contrôle de fichier (FCI), modèle propriétaire
*-- T=#50 L=2 : Nom de l'application = CB
*-- T=#87 L=1 : Indicateur de priorité de l'application = 1
*-- T=#9F11 L=1 : Index table code émetteur = #01
*-- T=#5F2D L=2 : Langage préféré = fr (Français)
*-- T=#9F12 L=14 : Nom de l'application préférée = TRANSACTION CB
*-- T=#BF0C L=10 : Information de contrôle du fichier (FCI), Informations propriétaires
*-- T=#DF60 L=2 : Log propriétaire = #0B 1E
*-- T=#9F4D L=2 : Entrée Log = 11, Nb = 30

Get Processing Option

L'application est bien reconnue. Pour aller plus loin, il est nécessaire d'envoyer la commande GET PROCESSING OPTION propre à EMV. il n'y a pas d'aide pour la construction de cette commande dans les ordres 7816-4 de PCCAM.

cmd #80A80000028300
*-- ME1 = #61 : Des octets sont prêts à être lus. Voir ME2 pour nombre d'octets.
*-- ME2 = #10 : GET_RESPONSE attendu, octets disponibles = 16
CMD #00C0000010,T1
*-- ME1 = #90 : ordre bien exécuté
*-- ME2 = #00
decode 16,T1
*-- T=#80 L=14 : AIP-AFL
*-- AIP = #3C 00
*-- Authentification statique (SDA) non supportée
*-- Authentification Dynamique (DDA) supportée
*-- Vérification du PIN porteur supportée
*-- Gestion de risque du terminal (TRM) demandée
*-- Authentification de l'émetteur supportée
*-- Combinaison DDA et Generate AC (CDA) non supportée
*--
*-- AFL = #08 01 02 00 08 03 03 01 10 01 04 01
*-- Fichier 1
*-- SFI = #01
*-- Premier enregistrement= 1
*-- Dernier enregistrement= 2
*-- Nb d'enregistrements pour SDA= 0
*-- Fichier 2
*-- SFI = #01
*-- Premier enregistrement= 3
*-- Dernier enregistrement= 3
*-- Nb d'enregistrements pour SDA= 1
*-- Fichier 3
*-- SFI = #02
*-- Premier enregistrement= 1
*-- Dernier enregistrement= 4
*-- Nb d'enregistrements pour SDA= 1

L'AIP indique quelles sont les caractéristiques sécuritaires supportées par la carte, en termes d'authentification (ici, seule l'authentification dynamique est supportée par exemple). L'AFL indique au terminal de paiement quels sont les fichiers contenant les données permettant de réaliser une transaction.

Lecture des données d'une application

Il ne reste plus qu'à lire ces fichiers. Pour être certain de tout lire, la méthode consiste à partir du premier SFI, puis lire tous les enregistrements de ce SFI, puis, lorsqu'on détecte une fin de fichier, incrémenter le SFI de 1 et lire tous les enregistrements, etc. jusqu'à ce qu'on ait le code d'erreur indiquant que le SFI courant n'existe pas. Pour cela, on peut réaliser une macro-commande qui va simplifier les manipulations.

Echo on
*'------------------------------------------'
* Macro pour lire les SFI d'une application
*'------------------------------------------'
* * lecture, SFI=1, N° Enr = 1
T0=#00B2010C00
repeat
      repeat
            CMD T0
            if (ME1<>#6A) and (ME2<>#83)
               T0[4]=ME2
               CMD T0, T1
               decode T0[4], T1
               * incrémente le n° d'enregistrement
               T0[2]=T0[2]+1
                   T0[4]=0
            endIf
      Until (ME1=#6A) and ((ME2=#83) or (ME2=#82))
      * SFI suivant
      T0[3]=T0[3]+#08
      * Enregistrement 1
      T0[2]=#01
      * longueur à lire = 0
      T0[4]=0
until (ME1=#6A) and (ME2=#82)

Les résultats de la lecture sont les suivants, en ayant éliminé les traces d'exécution de la macro pour alléger la présentation et en ayant modifié quelques résultats correspondant à des données personnelles...

*-- T=#70   L=48  : Enregistrement de fichier
*-- T=#9F1F L=24  : Données propriétaires de la piste 1 = XXXXXXXXXXXXXXXXXXXXXXXX
*-- T=#57   L=19  : Données équivalentes de la piste 2
*-- PAN        : XXXX XXXX XXXX XXXX
*-- Date AA/MM : 08/09
*-- Serv. code : 201
*-- Disc. Data : XXXXXXXXXXXXX

*-- T=#70   L=97  : Enregistrement de fichier
*-- T=#5F20 L=26  : Nom étendu du porteur = XXXXXXXXXXXXXXX
*-- T=#5F30 L=2   : Code service = #02 01
*--   Usage interbancaire international à puce qu'il faut utiliser si possible.
*--   Transactions autorisées selon les règles standards
*--   Pas de restriction sur les services
*-- T=#8C   L=27  : Liste d'objets de données pour la gestion de risque (CDOL1)
*--   T=#9F02 - L=6, Montant autorisé (numérique)
*--   T=#9F03 - L=6, Montant, autre (numérique)
*--   T=#9F1A - L=2, Code pays du terminal
*--   T=#95   - L=5, Terminal Verification Results (TVR)
*--   T=#5F2A - L=2, Code devise de la transaction
*--   T=#9A   - L=3, Date de la transaction
*--   T=#9C   - L=1, Type de la transaction
*--   T=#9F37 - L=4, Nombre non prédictible (UN)
*--   T=#9F45 - L=2, Code d'authentification de données
*--   T=#9F4C - L=8, Nombre dynamique de l'ICC
*-- T=#8D   L=26  : Liste d'objets de données pour la gestion de risque (CDOL2)
*--   T=#8A   - L=2, Authorisation Response Code (ARC)
*--   T=#9F02 - L=6, Montant autorisé (numérique)
*--   T=#9F03 - L=6, Montant, autre (numérique)
*--   T=#9F1A - L=2, Code pays du terminal
*--   T=#95   - L=5, Terminal Verification Results (TVR)
*--   T=#5F2A - L=2, Code devise de la transaction
*--   T=#9A   - L=3, Date de la transaction
*--   T=#9C   - L=1, Type de la transaction
*--   T=#9F37 - L=4, Nombre non prédictible (UN)
*--   T=#9F4C - L=8, Nombre dynamique de l'ICC
*-- T=#9F49 L=3   : Liste d'objets de données (type et longueur) pour 'Internal Authenticate' (DDOL)
*--   T=#9F37 - L=4, Nombre non prédictible (UN)

*-- T=#70   L=26  : Enregistrement de fichier
*-- T=#5F25 L=3   : Date d'effet de l'application = 01/07/10
*-- T=#5F24 L=3   : Date d'expiration de l'application = 30/08/12
*-- T=#5A   L=8   : PAN=XXXX XXXX XXXX XXXX
*-- T=#5F34 L=1   : N° de séquence du PAN (PSN) = X

*-- T=#70   L=54  : Enregistrement de fichier
*-- T=#9F07 L=2   : Contrôle d'usage de l'application(AUC) = #FF00
*-- Valide pour des transactions cash domestiques
*-- Valide pour des transactions cash internationales
*-- Valide pour des biens domestiques
*-- Valide pour des bens internationaux
*-- Valide pour des services domestiques
*-- Valide pour des services internationaux
*-- Valide sur des DAB/GAB
*-- Valide sur d'autres terminaux que des DAB/GAB
*-- T=#8E   L=14  : Méthode de vérification du porteur (CVM) List
*--   Montant 1 = 0.00
*--   Montant 2 = 0.00
*--   PIN chiffré vérifié en ligne
*--      si le terminal supporte le Card Verification Holder (CVM)
*--      Echec de la vérification de la carte du porteur si ce CVM est échec
*--   Vérification du PIN en clair réalisé par le composant
*--      si le terminal supporte le Card Verification Holder (CVM)
*--      Echec de la vérification de la carte du porteur si ce CVM est échec
*--   Pas de CVM demandé
*--      Toujours,
*--      Echec de la vérification de la carte du porteur si ce CVM est échec
*-- T=#9F0D L=5   : Code action de l'émetteur - Defaut
*--   98 00 B4 20 00
*-- T=#9F0E L=5   : Code action de l'émetteur - Refus
*--   00 50 48 00 00
*-- T=#9F0F L=5   : Code action de l'émetteur - en ligne
*--   B8 20 B4 F8 00
*-- T=#5F28 L=2   : Code pays de l'émetteur = 250 (France)
*-- T=#9F4A L=1   : Liste des Tag pour l'authentification statique des données (SDA) = #82

*-- T=#70   L=50  : Enregistrement de fichier
*-- T=#9F08 L=2   : N° de version de l'application = #00 02 (Dec=2)
*-- T=#8F   L=1   : Index de la clé publique de l'autorité de certification (ICP) =06
*-- T=#9F32 L=1   : Exposant public de l'émetteur
*--   03
*-- T=#92   L=36  : Module de la clé publique de l'émetteur
*--   21 4E 4B 2C 07 E7 D4 D5 AE 5F 55 06 77 1D AB E4
*--   54 4F CD 5B 48 EA 0C 94 B5 DB CA 41 F8 34 82 AA
*--   62 07 19 E7

*-- T=#70   L=173 : Enregistrement de fichier
*-- T=#9F46 L=144 : Certificat de la clé publique du circuit (ICC)
*--   44 58 59 25 54 AA CE 7E 3D 71 38 B6 CA 1C 2D A4
*--   B4 2E 68 F4 AD 28 50 87 35 EB AF E1 AB 19 C0 92
*--   ...
*--   A9 5A 96 AC 46 BD AA 0D 67 B6 23 AD F2 8D D1 C8
*--   93 6A 6E AC 74 96 77 BD 2E A8 8C 14 83 43 DC 59
*-- T=#9F47 L=1   : Exposant du bi-clé du composant (ICC)
*--   03
*-- T=#9F48 L=18  : Module du bi-clé du composant (ICC)
*--   A7 75 F3 BB 95 12 49 01 DC 97 A7 22 0D BB 8F CC
*--   23 3D

*-- T=#70   L=147 : Enregistrement de fichier
*-- T=#90   L=144 : Certificat de la clé publique de l'émetteur
*--   6F 7A 06 FB A8 63 E5 DC 7B 5C 11 3F E4 EF 52 E3
*--   2D FF 85 A9 98 27 8F 37 A0 19 F7 C5 03 B4 87 82
*--   ...
*--   7A F4 F0 AF 15 76 F1 E1 A1 83 79 30 73 59 AF EA
*--   D9 87 7C 6D 2D 99 56 94 99 38 72 53 6E 09 A8 65

On note la présence d'informations applicatives (nom, n° de PAN, usage de la carte, données piste équivalentes...), d'informations de gestion de risque (comment une transaction est-elle considérée comme valide par la carte), d'informations de sécurité (certificats de clés publiques, index de clé de certification, etc.) et d'informations de gestion (n° version de l'application...).

A ce stade, plusieurs choses sont possibles. On peut authentifier la carte, présenter un PIN, etc. La suite du cours donne un exemple d'authentification dynamique

Exemple de mise en oeuvre de fonctions de sécurité de la carte

En cours de rédaction

Autres données de la carte

Plusieurs autres données à caractère dynamique sont accessibles via des commandes GET DATA. Il s'agit en particulier du nombre d'essais restants pour la présentation du PIN et des Application Transaction Counter ou ATC très importants pour la sécurité : ce sont des compteurs qui s'incrémentent à chaque transaction et qui entrent dans les calculs cryptographiques afin d'éviter les rejeux.

Voici ce que donne la lecture du nombre d'essais restants pour la présentation du PIN :

CMD #80CA9F1704,T1
*-- ME1 = #90 : ordre bien exécuté
*-- ME2 = #00
decode 4,T1
*-- T=#9F17 L=1 : PIN, essais restants = 3

Retour sur la sélection d'applications

Lorsque l'application EMV n'est pas présente dans la carte, la seule façon de procéder est d'essayer de sélectionner les applications de paiement. Ce mode de fonctionnement est autorisé par EMV mais n'est pas des plus pratiques ! Elle ne se rencontre que très rarement.

La liste des noms des applications de paiement se trouve facilement sur internet. PCCAM utilise un fichier (AID.txt) qui contient les noms les plus courants. Vous pouvez en ajouter à votre guise en n'oubliant pas de compléter son fichier associé, AID-PIX.txt.

Utilisation de la commande MAP

Tout ce que nous venons de voir peut être réalisé automatiquement grâce à une unique commande, MAP (ou le bouton correspondant sur la barre de menu) pour peu que la carte soit bien une EMV (la commande MAP sait traiter les cartes EMV, SIM, M4, B4B0 et M9). Plutôt qu'une longue explication, voici ce que donne l'application de cette commande sur la carte précédemment utilisée pour illustrer ce TP.

Cette commande enchaîne les ordres afin de présenter la carte sous une forme arborescente. On peut ensuite cliquer sur un élément de l'arbre pour afficher les données correspondantes, soit décodées (si PCCAM sait décoder), soit sous forme de dump, soit en pseudo XML. On peut également capturer le contenu lu dans un fichier (texte ou XML selon l'option choisie). Enfin, vous disposez d'un outil de recherche de Types (TAG) ou de texte pour retrouver des données dans l'arborescence.

Le bouton "vue application" permet d'avoir une vision de type "machine de banque" du contenu de la carte.

La commande MAP présente quelques particularités :

L'énumération ci-dessous résume certaines particularités de la commande MAP :

• La commande MAP commence par tenter de sélectionner l'application EMV en mode contact (1PAY.SYS.DDF01). Si cette application n'est pas trouvée, elle tente une sélection en mode sans contact (2PAY.SYS.DDF01).
• Si cela ne donne rien, une sélection directe par nom doit être tentée (voir ci-avant).
• Cette commande tente de corriger certains dysfonctionnement rencontrés sur certaines cartes. En particulier, certaines cartes (anciennes) n'acceptent pas une nouvelle sélection d'application si une application de paiement a déjà été sélectionnée. Dans ce cas, la commande MAP effectue une mise sous tension à chaud de la carte et re-tente la sélection de la nouvelle application
• Certaines cartes ne comportent pas de définition du format du log des transactions. Dans ce cas, PCCAM considère qu'il s'agit d'un format propriétaire et tente de décoder les transactions selon ce format.

Ce point clôt le TP sur les cartes EMV

 

Cartes SIM

Avertissement : la lecture du TP sur les cartes B4B0' ou M4 est fortement conseillée avant d'aborder ce TP

Avant toute chose, il faut se procurer une carte SIM. Si vous avez des difficultés pour vous procurer un lecteur qui lit les cartes au format SIM (ID-000), utilisez une carte au format ISO qui contenait une carte SIM pré-découpée. Il faut replacer y la carte SIM qu'on solidarise avec la carte au format bancaire avec un bout de scotch.

L'étape suivante consiste à effectuer une mise sous tension de la carte afin de vérifier si PCCAM reconnait la carte SIM. Si ce n'est pas le cas, on peut forcer le type avec la commande "CARTE=SIM" ou en sélectionnant la carte SIM via le menu "Contexte->Carte->SIM". Le fait de sélectionner une carte SIM positionne la classe d'instruction (CLA) à #A0.

Avec la carte utilisée comme exemple (il s'agit d'une ancienne carte de 2002 émise par SFR), on obtient :

MST
*-- Carte SIM
*-- ATR = #3F 2F 00 80 69 AF 02 04 01 36 00 00 0A 0E 83 3E 9F 16
*-- ME1 = #9F : ordre bien exécuté
*-- ME2 = #16 : longueur de données disponibles = 22

En entrant "ATR" (ou "Outils->Décode ATR"), on obtient

ATR
*-- ATR = #3F 2F 00 80 69 AF 02 04 01 36 00 00 0A 0E 83 3E 9F 16
*-- TS = #3F : Convention inverse
*-- T0 = #2F : TB(1) 15 octet(s) d'historique
*-- TB(1) = #00 : Vpp non connecté, génération courant prog. par carte
*-- Protocole T=0 imposé
*-- Fi = 372, Di = 1 (valeurs par défaut)
*-- CIB = #80 : un indicateur de status codé en compact BER doit être présent dans l'ATR
*-- P₁D = #69 : données de pré-émission présentes = AF 02 04 01 36 00 00 0A 0E
*-- SW = #83 : LCS, ME1 et ME2 présents
*-- LCS = #3E : Etat propriétaire
*-- ME1 = #9F : ordre bien exécuté
*-- ME2 = #16 : longueur de données disponibles = 22
*-- SFR GSM-SIM

On notera le mot d'état (#9F) inhabituel mais spécifié dans la norme de la carte SIM. La valeur #16 pour ME2 indique que 22 octets sont prêts à être lus. Il faut faire un Get Response avec comme paramètre, 22 octets. On peut utiliser le menu "Ordres->ISO7816-4->get response". Par défaut, PCCAM initialise le champ longueur à la valeur courante de ME2 et propose T1 comme variable pour stocker le résultat. Pour afficher ce résultat, on entre "T1" ce qui donne le résultat suivant :

CMD #A0C0000016,T1
*-- ME1 = #90 : ordre bien exécuté
*-- ME2 = #00
T1
*-- T1[ 0, 15] = 85 14 09 F8 3F 00 01 80 00 EE FF 43 09 09 02 08 ····?······C····
*-- T1[ 16, 31] = 04 00 83 8A 83 8A FF FF FF FF FF FF FF FF FF FF ················
*-- T1[ 32, 47] = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ················
*-- .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
*-- T1[1008,1023] = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ················

La norme explique comment décoder ce résultat sachant que dans le cas présent, la carte n'est pas conforme à la norme. Les deux premiers octets sont notés RUF (Réservé à un Usage Futur) dans la norme alors qu'ici, ils valent #85 et #14. Ces valeurs rappellent les "Types" et "Longueurs" de la norme ISO7816-4. Il s'avère que le deuxième octet correspond effectivement à la longueur du champ "Valeur" du TLV.

Peut-être la commande "DECODE" donnera-t-elle quelque chose. Entrons "DECODE 22,T1" c'est à dire, demande de décodage du tableau T1 avec comme longueur 22. Dans le cas présent, cela donne :

DECODE 22,T1
*-- T=#85 L=20  : Réponse au select
*-- Taille mémoire en octets disponible dans le répertoire courant : 2552
*-- Identificateur de fichier : #3F00
*-- Type de fichier : Master File
*-- RFFU : #80 00 EE FF 43
*-- Longueur en octets des données spécifiques : 9
*-- Caractéristiques du fichier : #09
*-- CHV1 (code porteur) activé
*-- Carte SIM en 5V seulement (RFFU)
*-- Arrêt horloge autorisé, niveau bas préféré
*-- Fréquence demandée pour algo auth. ou téléchargement : 13/8MHz
*-- Nombre de DF enfants : 2
*-- Nombre d'EF enfants  : 8
*-- Nombre de CHV, CHV de déblocage et codes d'administration : 4
*-- RFFU : #00
*-- Status de CHV1 (code porteur)  : #83
*-- Nombre de codes restant à présenter : 3
*-- Code initialisé
*-- Status du code de déblocage de CHV1  : #8A
*-- Nombre de codes restant à présenter : 10
*-- Code initialisé
*-- Status de CHV2 (code porteur)  : #83
*-- Nombre de codes restant à présenter : 3
*-- Code initialisé
*-- Status du code de déblocage de CHV2  : #8A
*-- Nombre de codes restant à présenter : 10
*-- Code initialisé

En pratique, tous les répertoires et les fichiers de l'application SIM une entête de ce type (un peu différente pour les EF, voir plus loin). Les informations applicatives concernent les status sur les codes secrets ainsi que le nombre de fichiers et de répertoires se trouvant sous le répertoire courant (ici, le fichier maître (Master File ou MF) sélectionné automatiquement à la mise sous tension.

Note : la même expérience avec une carte de test GemXplore de Gemplus ne vous permettra pas d'utiliser la commande "decode" car pour cette carte, les deux premiers octets qui étaient à #8514 dans l'exemple précédent seront à #0000, c'est à dire, conformes à la norme. La commande decode utilise les "Types" (Tags) pour savoir comment décoder.

Voici ce que donne la mise sous tension d'une carte GemXplore :

MST
*-- Carte SIM
*-- ATR = #3B 9F 96 80 1F C3 80 31 E0 73 FE 21 1B B3 E2 02 7E 83 0F 90 00 82
*-- ME1 = #90 : ordre bien exécuté
*-- ME2 = #00
ATR
*-- ATR = #3B 9F 96 80 1F C3 80 31 E0 73 FE 21 1B B3 E2 02 7E 83 0F 90 00 82
*-- TS = #3B : Convention directe
*-- T0 = #9F : TA(1) TD(1) 15 octet(s) d'historique
*-- TA(1) = #96 : FI = 512, fmax = 5, Di = 20
*-- TD(1) = #80 : TD(2) T=0, communication asynchrone caractère à l'alternat
*-- TD(2) = #1F : TA(3) T=15 Interface octet
*-- TA(3) = #C3 : X = arrêt horloge sur état bas ou haut, U = A + B
*-- TCK = #82 : TCK (somme de contrôle) correct
*-- CIB = #80 : un indicateur de status codé en compact BER doit être présent dans l'ATR
*-- CSDB = #31 : Card Service Data byte présent
*-- sélection d'application par nom de DF complet
*-- sélection d'application par nom de DF partiel
*-- BER-TLV disponible dans EF.DIR
*-- EF.DIR et EF.ATR accessible par READ RECORD, carte sans MF
*-- Capab.= #73 : possibilités de la carte
*-- Sélection du DF par nom complet
*-- Sélection du DF par nom partiel
*-- Sélection du DF par chemin
*-- Sélection du DF par identificateur
*-- Sélection du DF implicite
*-- Nom court d'EF supporté
*-- Numéro d'enregistrement supporté
*-- Comportement écriture propriétaire
*-- Taille d'une unité de donnée en quartet (dec) = 2
*-- FF = valeur de bourrage par défaut dans un TLV
*-- Détermination de canal logique par la carte ou le terminal
*-- Nombre max de canaux logiques = 2
*-- Tag = #B3 : Type Propriétaire = #E2 02 7E
*-- SW = #83 : LCS, ME1 et ME2 présents
*-- LCS = #0F : Etat terminaison
*-- ME1 = #90 : ordre bien exécuté
*-- ME2 = #00
*-- GemXplore 3G, version 2, Gemplus

Et pour suivre, la sélection du DF #7F20 suivi d'un GET RESPONSE et d'une demande de décodage :

CMD #A0A40000027F20
*-- ME1 = #9F : ordre bien exécuté
*-- ME2 = #16 : longueur de données disponibles = 22
CMD #A0C0000016,T1
*-- ME1 = #90 : ordre bien exécuté
*-- ME2 = #00
T1
*-- T1[ 0, 15] = 00 00 4E 98 7F 20 02 00 00 00 00 00 09 11 00 31 ··N·· ·········1
*-- T1[ 16, 31] = 08 00 83 8A 83 8A FF FF FF FF FF FF FF FF FF FF ················
*-- T1[ 32, 47] = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ················
*-- .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
*-- T1[1008,1023] = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ················
decode T0[4],T1
Désolé, je ne sais pas décoder...

Cette carte suit strictement la norme et les deux premiers octets sont à 0. La commande "decode" ne sait pas décoder ce type. Mais on peut forcer les valeurs à #85 pour le type et à 20 pour la longueur (22 moins les deux octets d'entête) ce qui donne :

.

T1[0]=#85
T1[1]=20
decode 22,T1
*-- T=#85 L=20  : Réponse au select
*-- RFFU : #85 14
*-- Taille mémoire en octets disponible dans le répertoire courant : 20120
*-- Identificateur de fichier : #7F20 - DFgsm : Répertoire GSM
*-- Type de fichier : Dedicated File
*-- RFFU : #00 00 00 00 00
*-- Longueur en octets des données spécifiques : 9
*-- Caractéristiques du fichier : #11
*-- CHV1 (code porteur) activé
*-- Carte SIM en 3V
*-- Arrêt horloge autorisé, pas de niveau préféré
*-- Fréquence demandée pour algo auth. ou téléchargement : 13/8MHz
*-- Nombre de DF enfants : 0
*-- Nombre d'EF enfants  : 49
*-- Nombre de CHV, CHV de déblocage et codes d'administration : 8
*-- RFFU : #00
*-- Status de CHV1 (code porteur)  : #83
*-- Nombre de codes restant à présenter : 3
*-- Code initialisé
*-- Status du code de déblocage de CHV1  : #8A
*-- Nombre de codes restant à présenter : 10
*-- Code initialisé
*-- Status de CHV2 (code porteur)  : #83
*-- Nombre de codes restant à présenter : 3
*-- Code initialisé
*-- Status du code de déblocage de CHV2  : #8A
*-- Nombre de codes restant à présenter : 10
*-- Code initialisé

Revenons à la carte précédente qui continue à nous servir d'exemple. L'étape suivante consiste à sélectionner le DF correspondant à l'application GSM de la carte SIM comme ce qui vient d'être fait pour la carte GemXplore. Son nom est donc #7F20.

CMD #A0A40000027F20
*-- ME1 = #9F : ordre bien exécuté
*-- ME2 = #16 : longueur de données disponibles = 22

22 octets sont prêts à être lus qui pourront être décodés comme précédemment.

CMD #A0C0000016,T1
*-- ME1 = #90 : ordre bien exécuté
*-- ME2 = #00
T1
*-- T1[ 0, 15] = 85 14 00 00 7F 20 02 00 FF EE EE 03 09 19 00 15 ····· ··········
*-- T1[ 16, 31] = 04 00 83 8A 83 8A FF FF FF FF FF FF FF FF FF FF ················
*-- T1[ 32, 47] = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ················
*-- .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
*-- T1[1008,1023] = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ················
decode 22,T1
*-- T=#85 L=20  : Réponse au select
*-- Taille mémoire en octets disponible dans le répertoire courant : 0
*-- Identificateur de fichier : #7F20
*-- Type de fichier : Dedicated File
*-- RFFU : #00 FF EE EE 03
*-- Longueur en octets des données spécifiques : 9
*-- Caractéristiques du fichier : #19
*-- CHV1 (code porteur) activé
*-- Carte SIM en 3V
*-- Arrêt horloge autorisé, niveau bas préféré
*-- Fréquence demandée pour algo auth. ou téléchargement : 13/8MHz
*-- Nombre de DF enfants : 0
*-- Nombre d'EF enfants  : 21
*-- Nombre de CHV, CHV de déblocage et codes d'administration : 4
*-- RFFU : #00
*-- Status de CHV1 (code porteur)  : #83
*-- Nombre de codes restant à présenter : 3
*-- Code initialisé
*-- Status du code de déblocage de CHV1  : #8A
*-- Nombre de codes restant à présenter : 10
*-- Code initialisé
*-- Status de CHV2 (code porteur)  : #83
*-- Nombre de codes restant à présenter : 3
*-- Code initialisé
*-- Status du code de déblocage de CHV2  : #8A
*-- Nombre de codes restant à présenter : 10
*-- Code initialisé

Lisons maintenant l'IMSI qui se trouve dans le fichier #6F07.

CMD #A0A40000026F07
*-- ME1 = #9F : ordre bien exécuté
*-- ME2 = #0F : longueur de données disponibles = 15
CMD #A0C000000F,T1
*-- ME1 = #90 : ordre bien exécuté
*-- ME2 = #00
decode 15,T1
*-- T=#85 L=13  : Réponse au select
*-- Taille du fichier (octets) : 9
*-- Identificateur de fichier : #6F07
*-- Type de fichier : Elementary File
*-- Fichier transparent
*-- UPDATE  : Sous contrôle ADM
*-- SEEK, READ  : Sous contrôle CHV1
*-- INCREASE  : Jamais
*-- INVALIDATE  : Sous contrôle ADM
*-- REHABILITATE : Sous contrôle CHV1
*-- Status fichier : #03
*-- Non invalidé
*-- Non lisible ni modifiable quand invalidé
*-- Longueur des données à suivre après l'octet 13 : 2
*-- Taille d'un enregistrement (excepté fichiers transparents) : 0
CMD #A0B0000009,T1
*-- ME1 = #98, ME2 = #04 : erreur, CHV1 n'a pa été présenté correctement

Premier point notable, le contenu du get response suite à la sélection du fichier. Si T1 avait été dumpé, on aurait retrouvé le pseudo TL du TLV (#85 et #0F) comme dans le cas précédent lors de la sélection du fichier maitre. Dans les données utiles, on note une liste de conditions d'accès, un type de fichier (ici, "transparent"), la taille des données contenues dans le fichier (9 octets), l'état courant du fichier (ici, valide), etc.

Ayant mal lu toutes ces informations, l'opérateur a enchaîné une commande de lecture binaire du fichier (Read Binary) avec comme réponse, un refus du à une non présentation du code porteur (CHV1).

Pour présenter le code porteur, il suffit d'utiliser la commande Verify Pin avec comme paramètre, le code en ASCII complété à #FF à concurrence de 8 octets. Ce qui donne pour le code 1234 la commande ci-dessous :

CMD #A02000010831323334FFFFFFFF
*-- ME1 = #90 : ordre bien exécuté
*-- ME2 = #00

Cette fois-ci, la lecture du fichier contenant l'IMSI peut aboutir ce qui donne :

CMD #A0B0000009,T1
*-- ME1 = #90 : ordre bien exécuté
*-- ME2 = #00
T1[0,8]
*-- T1[ 0, 8] = 08 29 80 01 26 50 09 82 60 ·)··&P··`

On trouve une macro-commande fournie avec PCCAM (SIM.MAC) qui enchaîne cette suite d'opération automatiquement.

On peut aussi tester la commande "outils->MAP" qui enchaîne ces opérations sur tous les fichiers qu'elle peut trouver. Pour la carte SIM, cette commande demande de saisir le code porteur (PIN). Si on appuie sur "annuler", la carte sera lu mais pas les fichiers protégés. Sinon, tous les fichiers accessibles sous le contrôle de ce code seront également lus. Le PIN attendu est le CHV1. Voila ce qui sera obtenu pour une carte GemXplore :

A SUIVRE...

Bibliographie

Une grande partie des spécifications techniques des cartes SIM est en libre accès et est plutôt claire et compréhensible. En particulier, vous pouvez lire :

• "3rd Generation Partnership Project; Technical Specification Group Terminals Specification of the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface"
• ETSI TS 102 221, Smart Cards; UICC-Terminal interface; Physical and logical characteristics

Cartes CALYPSO/NAVIGO

Les cartes Navigo répondent aux spécifications Calypso (CD97) qui sont propriétaires. Toutefois, la documentation publique générale du produit permet d'avoir quelques idées sur ce que l'on peut trouver dedans.

En particulier, on peut trouver une liste de noms d'applications CALYPSO (qui se trouve dans le fichier "Calypso.txt" pour PCCAM).

Certaines cartes ne réagissent pas à ces noms d'application (erreur : ME1=#67, ME2=#00, longueur incorrecte a priori). Par contre, elles autorisent la sélection du fichier MF (#3F00, MasterFile) et la sélection directe des fichiers.

Vous trouverez ci-dessous un exemple d'utilisation des macro-commandes de PCCAM pour explorer rapidement une carte.

Dans un premier temps, on cherche à savoir quels sont les fichiers présents. La macro CalypsoFile.mac réalise une sélection de tous les fichiers accessibles à la racine de la carte

MST
*
CMD #00A40000023F00
*
W1 = 0
T0=#94A40000020000
repeat
   T0[5,5] = (W1 sr 8) and #FF
   T0[6,6] = W1 and #FF
   T0[0,6]
   CMD T0
   if ME1 = #90
      MANUEL
   endif
   W1 = W1+1
until W1 = #FFFF

On reconnait la commande de mise sous tension de la carte. On envoie ensuite une commande SELECT sur le fichier #3F00 (le MF de la carte) pour vérifier que la carte réagit correctement. Le résultat doit être ME1=#90 et ME2=#00.

La commande T0=#94A40000020000 permet d'initialiser T0 à la commande de sélection. W1 sert de compteur pour sélectionner les noms de fichier de #0000 à #FFFF. La classe d'instruction est celle des cartes Calypso (#94) mais ça aurait pu être #00.

Ensuite, on a une boucle repeat qui permet d'essayer toutes les sélections dans l'intervalle considéré et qui rend la main à PCCAM à chaque fois qu'un fichier est trouvé. Il faut faire un "CONTINUE" si l'on veut poursuivre l'explorationse.

Sur la carte utilisée, les fichiers trouvés ont été : #2, #3, #18, #2000, #2001, #2010, #2020, #202A, #202B, #202C, #202D, #202E, #202F #2030, #2040,#2060, #2061, #2062, #2069.

On reconnait certains noms de fichiers de la spécification. D'autres sont plus exotiques.

La suite des opérations consiste à lire le contenu de ces fichiers. Etant donné que la carte ne renvoie pas d'informations sur ces fichiers, la méthode a été de lire les fichiers octet par octet, enregistrement par enregistrement.

On commence par sélectionner le fichier à explorer. Ici, le #2040.

CMD #94A40000022040

Ensuite, on lit le premier enregistrement octet par octet jusqu'à ce que la carte signale une erreur.:

T0=#94B2010400
repeat
   T0[4,4]=T0[4,4]+1
   CMD T0,T1
until ME1 <> #90
T0[4]=T0[4]-1
T0[4]

Pour connaitre le nombre d'enregistrements, la méthode est similaire

T0=#94B201041D
repeat
   CMD T0,T1
   if ME1=#90
      T0[2]
      T1
      T0[2]=T0[2]+1
   endif
until ME1 <> #90
ABORT

Il est possible de faire beaucoup plus simple et d'enchaîner automatiquement toutes ces opérations. Le résultat est dans le fichier CalypsoRead.Mac qui contient les ordres de sélection de tous les fichiers précités et la lecture du nombre d'enregistrements qui a été déterminé. Voila une trace partielle que donne l'exécution de la macro finalisée avec PCCAM.

MST
*-- Carte CALYPSO
*-- ATR   = #3B 6F 00 00 80 5A 08 03 03 00 00 00 24 2C C9 91 82 90 00 
*-- ME1   = #90 : ordre bien exécuté
*-- ME2   = #00
*
Fill(T0,#FF)
*
CMD #94B201041D,T1
*-- ME1   = #90 : ordre bien exécuté
*-- ME2   = #00
T1[0,#1C]
*-- T1[   0,  15] =  04 F9 28 48 08 02 32 C0 03 C8 A0 00 00 00 00 00   ··(H··2·········
*-- T1[  16,  28] =  00 00 00 00 00 00 00 00 00 00 00 00 00            ·············   
*
* lecture 2010
CMD #94A40000022010
*-- ME1   = #90 : ordre bien exécuté
*-- ME2   = #00
Fill(T1,#FF)
CMD #94B201041D,T1
*-- ME1   = #90 : ordre bien exécuté
*-- ME2   = #00
T1[0,#1C]
*-- T1[   0,  15] =  46 56 10 90 00 68 A1 88 18 A6 00 88 10 00 68 93   FV···h········h·
*-- T1[  16,  28] =  00 23 00 24 00 00 00 00 00 00 00 00 00            ·#·$·········   
Fill(T1,#FF)
CMD #94B202041D,T1
*-- ME1   = #90 : ordre bien exécuté
*-- ME2   = #00
T1[0,#1C]
*-- T1[   0,  15] =  46 55 B6 10 00 68 A1 88 18 B1 00 88 20 00 08 93   FU···h······ ···
*-- T1[  16,  28] =  00 23 00 24 00 00 00 00 00 00 00 00 00            ·#·$·········   
Fill(T1,#FF)
CMD #94B203041D,T1
*-- ME1   = #90 : ordre bien exécuté
*-- ME2   = #00
T1[0,#1C]
*-- T1[   0,  15] =  46 55 48 90 00 68 A1 88 18 A4 00 88 08 00 40 93   FUH··h········@·
*-- T1[  16,  28] =  00 23 00 24 00 00 00 00 00 00 00 00 00            ·#·$·········   
Fill(T1,#FF)
*
* Lecture 2020
CMD #94A40000022020
*-- ME1   = #90 : ordre bien exécuté
*-- ME2   = #00
Fill(T1,#FF)
CMD #94B201041D,T1
*-- ME1   = #90 : ordre bien exécuté
*-- ME2   = #00
T1[0,#1C]
*-- T1[   0,  15] =  52 00 E0 00 00 20 00 AF 3B 92 29 7C 47 B9 83 80   R···· ··;·)|G···
*-- T1[  16,  28] =  AA 00 00 00 00 00 00 00 00 00 00 00 00            ·············   
Fill(T1,#FF)
CMD #94B202041D,T1
*-- ME1   = #90 : ordre bien exécuté
*-- ME2   = #00
T1[0,#1C]
*-- T1[   0,  15] =  52 00 E0 00 00 20 07 CC 72 D2 29 EE 88 CB 01 80   R···· ··r·)·····
*-- T1[  16,  28] =  AB 00 00 00 00 00 00 00 00 00 00 00 00            ·············   
Fill(T1,#FF)
CMD #94B203041D,T1
*-- ME1   = #90 : ordre bien exécuté
*-- ME2   = #00
T1[0,#1C]
*-- T1[   0,  15] =  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ················
*-- T1[  16,  28] =  00 00 00 00 00 00 00 00 00 00 00 00 00            ·············   
Fill(T1,#FF)
CMD #94B204041D,T1
*-- ME1   = #90 : ordre bien exécuté
*-- ME2   = #00
T1[0,#1C]
*-- T1[   0,  15] =  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ················
*-- T1[  16,  28] =  00 00 00 00 00 00 00 00 00 00 00 00 00            ·············   
*

* Lecture 2069
CMD #94A40000022069
*-- ME1   = #90 : ordre bien exécuté
*-- ME2   = #00
Fill(T1,#FF)
CMD #94B201041D,T1
*-- ME1   = #90 : ordre bien exécuté
*-- ME2   = #00
T1[0,#1C]
*-- T1[   0,  15] =  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ················
*-- T1[  16,  28] =  00 00 00 00 00 00 00 00 00 00 00 00 00            ·············   
ABORT
*-- Macro aborted
*-- Fin Macro sur commande ABORT calypsoRead.MAC

Il est fort possible que l'exécution de la macro CalypsoRead.mac ne fonctionne pas à 100% mais avec l'explication donnée, il est possible de corriger le fichier.

Comme pour les autres cartes, la commande MAP permet d'enchaîner ces commandes élémentaires de façon automatique.