S'approprier la technologie sans contact NFC

Véritable « serpent de mer », la NFC (Near Field Communication ou « communication en champ proche » en français) peine désespérément à se déployer sur le terrain. Pratiquement pas sécurisées, ses applications les plus simples méritent pourtant toute notre attention, afin de déterminer dans quelles limites on pourra raisonnablement leur faire confiance.

« Le développeur doit être conscient du fait que des données malicieuses peuvent être placées dans le champ « titre », afin de présenter un faux nom de service à l'utilisateur. Celui-ci croira ainsi être en présence de quelquechose de complètement différent de ce qui sera, en réalité, une tentative de « phishing ». Par exemple, si le champ « titre » contient le texte http://www.internetbanking.com et que le champ « URL » contient http://myevilsite.com, l'utilisateur pourra être trompé et envoyer ses identifiants bancaires, en toute confiance, vers un faux site ».

On croit rêver : cette traduction provient de la « note » plus que convaincante qui figure en toutes lettres dans le paragraphe 3.3.2 de la spécification SPR 1.1 du NFC Forum, téléchargeable sous licence gratuite (NFC Forum and the NFC Forum logo are trademarks of the Near Field Communication Forum) ! Bien au delà d'une mise en garde ô combien nécessaire, on pourrait voir là une surprenante invitation au piratage...
En réalité, cette faille de sécurité béante concerne surtout une des applications « vitrine » de la technologie NFC, le Smart poster (affiche intelligente). En principe, les applications plus sensibles telles que le paiement sécurisé, par exemple, ne devraient donc pas être affectées. Il n'empêche que cela fait désordre, et qu'une enquête approfondie s'impose ! Il ne faudrait surtout pas, en effet, partir du principe que seuls des émetteurs institutionnels auront les moyens de développer des applications NFC, car nous allons montrer de ce pas comment n'importe qui peut d'ores et déjà s'immiscer, avec des moyens dérisoires, dans ce domaine au demeurant fort prometteur.

Au delà de la RFID

En tant que concept « sans contact », la NFC n'est finalement qu'une évolution de la RFID, venant se greffer sur des normes et protocoles déjà déployés (ISO 14443, par exemple). Il s'agit, à la base, de faire communiquer à très courte distance (quelques centimètres) des objets qui peuvent aussi bien être de simples tags (étiquettes intelligentes) que des téléphones portables ou des terminaux de toutes sortes (paiement, billettique, etc.).
Au pied de la lettre, un « vrai » équipement NFC doit pouvoir fonctionner tour à tour en mode « lecteur » et en « émulation de tag » : un téléphone portable compatible, par exemple, devra être capable de lire une carte Mifare configurée en tag NFC, mais aussi d'être lui-même reconnu comme un tag par tout lecteur NFC duquel on voudra bien l'approcher. Cela ouvre évidemment la porte à des échanges de données de toutes sortes, comme par exemple de cartes de visite électroniques entre téléphones portables, comme on le fait déjà par Bluetooth ou infrarouge.
Cela n'exclut pas pour autant des cas de figure plus simples, dans lesquels un tag en forme de carte à puce ou d'étiquette adhésive est simplement lu ou écrit par un lecteur sans contact tout à fait courant. C'est précisément dans ce contexte qu'il suffit de se placer pour créer soi-même des Smart posters, avec une facilité tout à fait déconcertante...
Le principe de cette application phare est séduisant : un tag NFC fort peu coûteux est incorporé dans une affiche, un plan de ville, voire un magazine ou une marchandise, et dès qu'un téléphone portable compatible en sera approché, il se connectera à Internet pour obtenir plus de détails. Par exemple l'horaire (en temps réel) d'une ligne de bus, ou encore l'itinéraire à suivre pour rejoindre un magasin ou le lieu d'un spectacle depuis l'endroit où l'on aura été préalablement géolocalisé. Mais cela pourrait aller jusqu'à des possibilités de réservation, de passation de commande, ou même de paiement en ligne...
Le hic, c'est que les mobiles compatibles sont encore fort rares, mais des projets pilotes comme celui de Nice ont vocation à débloquer rapidement la situation. Parallèlement, des adaptateurs adhésifs se proposent de doter n'importe quel téléphone Bluetooth de fonctionnalités NFC pas du tout ridicules. Anticipons donc un peu, et créons nos propres Smart posters avant même que les « vrais » n'envahissent (peut-être) notre quotidien !

Des outils de développement accessibles

Il est indéniable que la voie royale pour se mettre à la NFC consiste à se procurer l'un des kits de développement spécialisés disponibles sur le marché. Depuis peu, des modèles d'un prix abordable sont ainsi proposés, notamment par SCM Microsystems. Le Contactless Smart Card/NFC Software Development Kit de cette société allemande part ainsi à la conquête des milieux de l'enseignement, grâce à des conditions préférentielles consenties notamment aux universités.

Typiquement, un tel SDK réunit un ou même plusieurs lecteurs sans contact, un CD bourré de logiciels et de documentation, ainsi qu'un échantillonnage de cartes et de tags, pré-programmés ou complètement vierges. Par rapport à des offres antérieures incluant carrément un téléphone portable (genre Nokia 6212 ou 6131 NFC), le prix est naturellement sans commune mesure ! L'astuce consiste à émuler les fonctionnalités NFC du téléphone avec un logiciel pour PC, afin de pouvoir lire les tags NFC que l'on rencontrera « dans la nature » ou... que l'on aura confectionnés par ses propres moyens.

Le point fondamental qu'il faut assimiler dès à présent est que les tags NFC ne constituent pas une nouvelle famille d'objets sans contact, que le commun des mortels ne pourrait pas se procurer au détail. Bien au contraire, les spécifications des plates-formes actuellement définies s'appuient sur des composants RFID très courants, auxquels on fait simplement subir un formatage particulier.
Ainsi, le tag NFC Forum « type 2 » est tout simplement un Mifare Ultralight dans la zone OTP (One Time Programmable) duquel est programmé, de façon irréversible, le bloc de quatre octets que voici : E1 10 06 00. Il s'agit d'un Capability Container (CC) permettant de reconnaître un tag NFC parmi la multitude des autres applications du Mifare Ultralight (tickets de métro, par exemple). L'octet E1h constitue ainsi le magic number (nombre magique) annonçant que le contenu de la zone de données du Mifare Ultralight est réputé conforme aux spécifications du NFC Forum. 10h précise que la version applicable de la spécification de lecture est la 1.0, tandis que 06h indique que la taille de la mémoire utilisateur est de 48 octets. 00h, enfin, signifie que l'accès est totalement libre en lecture comme en écriture. 0Fh signifierait que l'écriture est interdite, mais... pas forcément impossible, selon que les bits de verrouillage (locks) auront ou non été vraiment positionnés dans la zone système du tag. Encore une sérieuse faille de sécurité, donc, dans la mesure où ces deux mécanismes de protection en écriture sont totalement indépendants et pas forcément employés d'une façon cohérente.
Par ailleurs, comme les spécifications autorisent qu'une valeur aléatoire soit émise par les tags en tant qu' UID (ce fameux identifiant en principe unique et inaltérable), il doit être bien clair que leur clonage est parfaitement possible et même facile. Bien pire, rien n'empêcherait de modifier les données lors de la copie, au cas où l'on aurait l'intention de tromper l'utilisateur final. Cela ne rappelle-t-il pas le cas de l'inénarrable carte Vitale ? En pratique, on peut fort bien imaginer un pirate décollant (ou détruisant électromagnétiquement) un vrai tag dans un lieu public, avant de le remplacer par un autre, programmé par ses soins : de quoi mettre en oeuvre les supercheries les plus croustillantes !

Assez comparable, mais utilisant un protocole de communication pas systématiquement supporté par les lecteurs RFID courants, le tag NFC Forum « type 1 » est basé sur la puce Topaz développée par la firme britannique Innovision. Actuellement plus difficile à se procurer au détail, cet intéressant concurrent du Mifare Ultralight se formate en tag NFC Forum par simple écriture des quatre octets E1 10 0E 00 en tête de sa mémoire utilisateur (96 octets utiles), et non plus dans une zone OTP. Tant que les bits de verrouillage ne sont pas activés, l'opération est donc parfaitement réversible !
Passons rapidement sur le « type 3 » (Felica) utilisé essentiellement en Asie, et sur le type spécifique introduit par NXP pour promouvoir l'utilisation du Mifare Classic en tant que tag NFC Forum. En effet, le fabricant ne souhaite pas rendre publiques les règles de formatage (d'ailleurs bien compliquées !) qu'il a dû définir, alors même qu'il est parfaitement possible de les reconstituer en analysant le contenu de quelques tags programmés, par exemple, avec le SDK de SCM Microsystems... Qu'à cela ne tienne, nous avons beaucoup mieux à proposer à nos lecteurs ! Nous verrons, en effet, que le « type 4 » constitue la plate-forme idéale pour effectuer les manipulations les plus ambitieuses, et s'approprier ainsi pour de bon la NFC sans rien devoir à personne.

Parlez vous NDEF ?

Une fois qu'un tag est formaté de façon à être reconnu en tant que type NFC Forum, il reste à y charger les données utiles de l'application pratique. Cela suppose de coder celles-ci selon le NFC Forum Data Exchange Format ou NDEF, décrit dans une spécification distincte (TS-NDEF_1.0). Evoquant un peu le SIM Application Toolkit de la téléphonie mobile, ce « langage » s'inspire de la structure TLV (Tag Length Value). En gros, un ou plusieurs contenus utiles (payloads) peuvent être encapsulés dans un seul et unique message NDEF, chacun étant muni d'un préfixe composé d'un type, d'une longueur, et éventuellement d'un identifiant. Cela permet évidemment de faire une foule de choses (voir encadré). Quelques types courants sont qualifiés de well-known, autrement dit « bien connus » dans le monde de la NFC, et le Smart poster (Sp) en fait évidemment partie. Ils bénéficient notamment d'un codage simplifié.
Deux voies concurrentes peuvent être suivies pour créer un message NDEF : utiliser (même en l'absence de tout lecteur !) un outil de développement basé, par exemple, sur le NDEF wrapper fourni dans le kit SCM Microsystems, ou alors programmer à la main en se référant à la spécification du NFC Forum. Une bonne démarche autodidactique consiste à faire composer différents messages NDEF par un utilitaire spécialisé, puis à en analyser la structure à la lumière de la spécification. Allons-y donc !
Imaginons que nous souhaitions créer un Smart poster accédant à l'URL http://www.acbm.com tout en affichant le texte « Pirates Mag' » sur l'écran du mobile utilisé. Parmi de multiples variantes conduisant exactement au même résultat, un message NDEF possible se présenterait comme suit :

D1 02 27 53 70 91 01 09 55 01 61 63 62 6D 2E 63
6F 6D 11 01 0F 54 02 66 72 50 69 72 61 74 65 73
20 4D 61 67 27 51 03 01 61 63 74 00

Le premier octet (D1h) constitue l'en-tête indiquant que nous sommes en présence d'un message NDEF de type bien connu (well-known). Le second (02h) précise que la description de ce type tient sur les deux octets qui suivent, soit 53h et 70h pour « Sp » exprimé en ASCII. Entre les deux, 27h fournit la longueur du Smart poster proprement dit, soit 39 octets allant du 91h au 00h inclus. 91h marque donc le début du Smart poster, et par la même occasion du premier enregistrement (record) de celui-ci. L'octet 01h qui suit donne la longueur du type de ce premier enregistrement, soit un seul octet. Il s'agit de 55h, soit « U » en ASCII, annonçant une URL Internet. La longueur de celle-ci est précisée entre les deux : 09h, soit 9 octets. Le premier octet de cette « charge utile », 01h, est l'abréviation de « http://www. », tandis que les huit suivants ne sont autres que « acbm.com » en ASCII. A noter que « http:// » tout court serait codé 03h.
Vient maintenant un octet 11h qui introduit le second enregistrement (record) du message NDEF. Son type (de longueur 01h) est 54h (T pour Text) et sa charge utile (de longueur 0Fh soit 15 octets) est elle-même scindée en deux parties : un champ de longueur 02h octets (66 72) indiquant la langue (ici « fr » pour le français), puis le texte lui-même, long de 12 octets (« Pirates Mag' » en ASCII), soit le total de 15 qui était annoncé.
51h introduit le dernier enregistrement (record) du message, dont le type (act pour « action ») est long de 03h octets (61 63 74), suivi d'une charge utile de longueur 01h octet : 00h, dont la signification est « execute ». Cela veut tout simplement dire que le téléphone mobile est invité à aller directement à l'URL http://www.acbm.com, tout en affichant « Pirates Mag' » sur son écran, à moins que l'utilisateur n'ait paramétré l'appareil pour que l'autorisation lui soit systématiquement demandée avant toute connexion au réseau (sage précaution, comme nous allons le voir sans plus tarder !).
Modifions en effet ce message NDEF comme suit :

D1 02 24 53 70 91 01 09 55 01 61 63 62 6D 2E 63
6F 6D 11 01 0C 54 02 66 72 4D 61 20 42 61 6E 71
75 65 51 03 01 61 63 74 00

Tout en allant toujours à la même URL, le téléphone affichera désormais « Ma Banque », trompant ainsi potentiellement son utilisateur sur ce qui est en train de se passer. CQFD...
Nous laissons le soin à nos lecteurs d'analyser, à titre d'exercice, les quelques changements intervenus dans les octets de longueur, afin de se rendre compte combien l'ajout ou la suppression ne serait-ce que d'un seul octet de charge utile quelque part peut avoir des répercussions en plusieurs endroits du message. Il faut d'ailleurs savoir qu'une anomalie, même minime, dans cette structure parfaitement codifiée rendra le message inutilisable, car incompréhensible pour tout analyseur automatique (NDEF parser) chargé de son interprétation. D'où l'intérêt de se référer aussi souvent que nécessaire à la spécification, à laquelle ce dossier n'a aucunement vocation à se substituer.

Mise en oeuvre pratique

A ce stade, il s'agit maintenant de charger ce message NDEF dans le tag qui servira de support physique à notre Smart poster. Malgré un résultat final strictement identique, les choses sont sensiblement différentes selon le type de tag utilisé, et suivant l'équipement dont on dispose. Bien des lecteurs RFID courants, par exemple, ne savent pas gérer correctement les tags Topaz (type 1). En ce qui concerne les tags Mifare (et notamment le type 2), les fabricants rivalisent d'ingéniosité pour empêcher que les logiciels développés pour leurs lecteurs puissent fonctionner avec ceux de leurs concurrents : un lamentable croche-pied à l'esprit des spécifications PC/SC, en somme ! A vrai dire, c'est surtout avec des tags « type 4 » (à l'origine des DESFire spécialement formatés) que l'on pourra opérer confortablement dans un environnement PC/SC, quelle que soit la marque du lecteur sans contact utilisé. Et la bonne nouvelle, c'est que nous avons réussi à émuler très convenablement ce type de tag avec la toute récente BasicCard sans contact (ZC 7.5) !
Mais chaque chose en son temps, commençons tout de même par charger notre second Smart poster dans un Mifare Ultralight préalablement formaté en tag NFC Forum type 2.
Les heureux possesseurs d'un lecteur ACR122 pourront effectuer ce formatage (irréversible) en utilisant tout simplement notre petit programme ULNFC.BAS :


REM Init NFC Type 2 (version pour ACR122)

#Include CARDUTIL.DEF

#Include COMMERR.DEF

ComPort=101

Declare Command &HFF &HD6 WRPAGE(S$)

CLS:Print"ULNFC (c)2010 Patrick GUEULLE"

Call WaitForCard()

ResetCard:Call CheckSW1SW2()

P$=Chr$(&HE1)+Chr$(&H10)+Chr$(&H06)+Chr$(&H00)

Call WRPAGE(P1P2=&H0003,P$,Disable Le)

P$=Chr$(&H03)+Chr$(&H03)+Chr$(&HD0)+Chr$(&H00)

Call WRPAGE(P1P2=&H0004,P$,Disable Le)

P$=Chr$(&H00)+Chr$(&HFE)+Chr$(&H00)+Chr$(&H00)

Call WRPAGE(P1P2=&H0005,P$,Disable Le)

Call WaitForNoCard

Compilé en un exécutable ULNFC.EXE au moyen du kit logiciel BasicCard (toujours téléchargeable gratuitement), il commence par écrire E1 10 06 00 dans la page n° 3 (zone OTP) du tag, puis il charge provisoirement un message NDEF vide (03 03 D0 00 00 FE selon la spécification) dans ses pages 4 et 5. Avec un lecteur différent, il pourrait être nécessaire de modifier légèrement le code source, le CardMan 5321 d'Omnikey, par exemple, ne pouvant écrire que des blocs de 16 octets consécutifs, soit quatre pages à la fois. A noter, d'ailleurs, que les entorses que font ainsi (sciemment ?) la plupart des lecteurs contactless aux bonnes intentions des spécifications PC/SC sont sanctionnées par une classe ISO de la commande d'écriture fixée à FFh au lieu de 00h (ce qui signifie que la compatibilité n'est que partielle avec la spécification PC/SC 2).
Pour charger notre Smart poster, il suffit maintenant d'écrire les données suivantes à partir de la page 4 (autrement dit immédiatement à la suite de la zone OTP) et jusqu'à la page 14 (0Eh) incluse :

03 29 D1 02
24 53 70 91
01 09 55 01
61 63 62 6D
2E 63 6F 6D
11 01 0C 54
02 66 72 4D
61 20 42 61
6E 71 75 65
51 03 01 61
63 74 00 FE

On reconnaît là notre message NDEF (de D1h à 00h inclus), précédé des octets 03h et 29h annonçant que ce qui suit est justement un message NDEF (03h) d'une longueur de 41 octets (soit 29h en hexadécimal). Il lui est enfin ajouté un octet FEh faisant office de marqueur de fin de message. A défaut d'un outil plus commode (par exemple l'un de ceux fournis dans le SDK de SCM Microsystems), on arrivera au même résultat en ajoutant simplement quelques commandes d'écriture de pages à ULNFC.BAS avant de le recompiler.
Les choses seraient assez comparables dans le cas d'un tag Topaz (type 1), les quatre octets du Capability Container (E1 10 0E 00) étant cependant écrits non plus dans une zone OTP, mais tout simplement au début de la mémoire utilisateur (c'est-à-dire dans la première moitié du bloc n° 1). Contrairement aux Mifare Ultralight qui sont organisés en « pages » de quatre octets, les Topaz sont constitués de « blocs » de huit octets. Dans la seconde moitié du bloc n° 1, on écrirait ainsi 03 29 D1 02, tandis que le bloc n° 2 recevrait 24 53 70 91 01 09 55 01, et ainsi de suite.
Ces tags n'étant pour le moment pas très faciles à se procurer au détail, nous ne fournirons pas ici de logiciel permettant d'y écrire, d'autant que l'opération se fait au moyen de commandes qui diffèrent assez sensiblement selon les marques et modèles de lecteurs.

Type 4 et BasicCard

Contrairement aux tags NFC Forum de types 1 et 2, qui sont basés sur des puces « à mémoire » toutes simples, le type 4 met typiquement en oeuvre une puce à microprocesseur, autrement dit « intelligente ». Conformément à la spécification ISO 7816-4, la communication avec les lecteurs se fait par échange d'APDUs, c'est-à-dire de commandes en tout point comparables à celles supportées par les cartes à puce « à contact » T=0 ou T=1.
Il en résulte que les tags « type 4 » peuvent non seulement stocker des données, mais aussi exécuter, en interne, de véritables programmes informatiques, voire reconnaître des commandes supplémentaires n'ayant plus rien à voir avec les applications NFC. En poussant ce raisonnement jusqu'au bout, on pourrait même songer à ajouter simplement une fonctionnalité NFC à une carte sans contact initialement destinée à tout autre chose (porte-monnaie électronique, par exemple).
Au départ, la plate-forme de type 4 a été définie à partir de puces DESFire, de marque NXP comme les Mifare, puis des développements plus ambitieux ont été faits autour des familles 16RF (STMicroelectronics), SLE66CL (Infineon), et surtout JCOP (de nouveau NXP). Programmables en Java, ces dernières puces se prêtent tout spécialement à la mise en oeuvre de ce qu'il est convenu d'appeler des « contenus actifs » : en termes simples, les données enregistrées dans le tag peuvent être modifiées non seulement de l'extérieur (par un lecteur ou un autre objet NFC), mais aussi en interne (par le programme embarqué dans le tag). Par exemple, un compteur pourrait s'incrémenter lors de chaque lecture d'un Smart poster, permettant de déterminer a posteriori combien de fois il a été pris connaissance de son contenu (ce qui peut être important dans des applications de type marketing).
Sachant que la spécification du NFC Forum (TS-Type-4-Tag_1.0) ne définit pas le tag lui-même mais la façon dont il faut procéder pour y accéder, n'importe qui est parfaitement libre de développer un tag fonctionnant de façon similaire, sur la plate-forme matérielle de son choix. Ne nous en privons pas, et restons donc fidèles à notre bon vieux ZCBasic !

La BasicCard sans contact (ZC 7.5) qui a été lancée au printemps 2009 fonctionnant en protocole ISO 14443-A, elle se prête idéalement à l'émulation du type 4 ! A vrai dire, le « dictionnaire » des commandes que doit reconnaître un tag NFC Forum type 4 se limite à trois grands classiques : Select (00 A4), Read Binary (00 B0), et Update Binary (00 D6).
Tout dialogue doit commencer par la sélection de l'application NFC Forum, grâce à une commande 00 A4 04 00 07 D2 76 00 00 85 01 00. L'AID (identifiant d'application) ainsi transmis à la puce ayant été attribué à NXP, il pourra être sage de prendre quelques précautions si l'on fait usage de composants de marques concurrentes...
Notons toutefois que le préfixe D2 76 étant partagé par de nombreuses applications d'origine allemande, nul ne peut s'en arroger l'exclusivité. D'un autre côté, les trois octets 85 01 00 pourraient figurer à la fin de 65536 identifiants distincts, et demeurent donc anonymes quand ils sont séparés des deux octets (ici 00h) qui les précèdent.
Une fois cette sélection effectuée avec succès, seuls deux fichiers sont indispensables au fonctionnement du tag NFC Forum : le Capability Container (CC), dont l'identifiant est obligatoirement E1 03h, et le fichier NDEF dont l'identifiant (bien souvent E1 04h) figure dans les dixième et onzième octets du fichier CC.
Le contenu de ce second fichier sera tout bonnement le même message NDEF que dans un tag de type 1 ou 2, simplement précédé de sa longueur exprimée sur deux octets (00 29 dans notre cas). A noter qu'il n'y a pas de marqueur de fin de message comme dans un tag de type 2.
Une différence intéressante par rapport à un tag de type 1 ou 2 est que le contenu par défaut d'un « type 4 » peut être pré-défini au niveau du code source de l'application, puis modifié librement par la suite (sauf activation de la protection en écriture). Voyons donc ce que cela donne en ZCBasic avec notre programme NFC4.BAS :


#Include Misc.Def

Declare ApplicationID="NFC4spy"

REM (c)2009 Patrick GUEULLE

Declare Sub Note(S$)

Public C$ As String

Public T$ As String

Public SL$ As String*2

Public NFC As Byte=0

Public ID$ As String*2=&HD2,&H76

Public PX$ As String*3=&H85,&H01,&H00

Public CAP$ As String*2=Chr$(&HE1)+Chr$(&H03)

EEPROM SPY As Byte=0



#Pragma UID(Double)

#Pragma ATS(HB=Chr$(&H80))

#Pragma ATR(Direct,T=1,HB="NFC4spy")



EEPROM CC$ As String*512 = _

&H00,&H0F,&H10,&H00,&H3B,&H00,&H34,&H04,&H06,&HE1, _

&H04,&H02,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00





EEPROM NDEF$ As String*512 = _

&H00,&H29,&HD1,&H02,&H24,&H53,&H70,&H91,&H01,&H09, _

&H55,&H01,&H61,&H63,&H62,&H6D,&H2E,&H63,&H6F,&H6D, _

&H11,&H01,&H0C,&H54,&H02,&H66,&H72,&H4D,&H61,&H20, _

&H42,&H61,&H6E,&H71,&H75,&H65,&H51,&H03,&H01,&H61, _

&H63,&H74,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00





EEPROM ACBM$ As String*512 = _

&H00,&H24,&HD1,&H02,&H1F,&H53,&H70,&H91,&H01,&H09, _

&H55,&H01,&H61,&H63,&H62,&H6D,&H2E,&H63,&H6F,&H6D, _

&H11,&H01,&H07,&H54,&H02,&H66,&H72,&H41,&H43,&H42, _

&H4D,&H51,&H03,&H01,&H61,&H63,&H74,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00





EEPROM INIT$ As String*512 = _

&H00,&H00,&H85,&H01,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00, _

&H00,&H00,&H00,&H00,&H00,&H00



IF SPY=1 Then Open "Card.Log" For Append As #1 : Write#1,""



Command &HC8 &H04 COP(Lc=0,S$)

Close#1

S$="(c)2009 Patrick GUEULLE"

End Command



Command &HC8 &HA2 FLUSH()

Close#1

Kill "Card.log"

NDEF$=INIT$ : Right$(CC$,1)=Chr$(&H00)

End Command



Command &HC8 &HA0 SPYONOFF(S$,Disable Le)

SPY=P2

IF P2=0 Then Right$(CC$,1)=Chr$(&HFF)

IF P2=1 Then Right$(CC$,1)=Chr$(&H00)

IF P1=0 Then NDEF$=ACBM$

IF P1=1 Then NDEF$=INIT$

End Command



Command Else SAVE(S$)

Call Note(S$)

End Command



Command &H00 &HA4 SEL(S$,Disable Le)

SW1SW2=&H6A82

SL$=Left$(S$,2)

If SL$=ID$ And Lc=7 And Right$(S$,3)=PX$ Then SW1SW2=&H9000 : NFC=1

If S$=CAP$ Then SW1SW2=&H9000

If S$=Mid$(CC$,10,2) Then SW1SW2=&H9000

IF SPY=1 Then Call Note(S$)

End Command



Command &H00 &HB0 RBIN(Lc=0,S$)

IF SPY=1 Then Call Note(S$)

SW1SW2=&H6982

If NFC=0 Then Exit Command

If SL$=CAP$ Then S$=Mid$(CC$,P1P2+1,Le) : SW1SW2=&H9000

If SL$=Mid$(CC$,10,2) Then S$=Mid$(NDEF$,P1P2+1,Le) : SW1SW2=&H9000

End Command



Command &H00 &HD6 UBIN(S$,Disable Le)

T$=S$ : IF SPY=1 Then Call Note(S$)

SW1SW2=&H6982

If NFC=0 Then Exit Command

If Mid$(CC$,15,1)=Chr$(&HFF) Then SW1SW2=&H6900:Exit Command

If SL$=CAP$ Then Mid$(CC$,P1P2+1,Lc)=T$ : SW1SW2=&H9000

If SL$=Mid$(CC$,10,2) Then Mid$(NDEF$,P1P2+1,Lc)=T$ : SW1SW2=&H9000

End Command



Sub Note(S$)

C$=CHR$(CLA)+CHR$(INS)+CHR$(P1)+CHR$(P2)+Chr$(Lc)+S$+Chr$(Le)

S$=String$(Le,&HCD)

Write#1,C$

End Sub

La taille importante de ce code source provient du fait que nous avons généreusement défini des chaînes EEPROM de 512 octets pour représenter les fichiers du tag. C'est considérablement plus que les quelques dizaines d'octets d'un tag de type 1 ou 2 (d'où la longueur exprimée sur deux octets), et encore nous sommes très loin du maximum théorique ! Cela justifie le prix bien plus élevé de la ZC 7.5 par rapport au Mifare Ultralight dont les possibilités sont infiniment moindres, tandis que la carte reste reprogrammable à volonté pour des applications complètement différentes.
Aucun outil de développement autre que le kit logiciel BasicCard (version 6.24 ou supérieure) n'est nécessaire pour compiler le programme et le charger dans une ZC 7.5 soit sans contact, soit combi (à double interface). N'importe quel lecteur PC/SC fera cette fois l'affaire : un ACR122 (purement contactless), le CardMan 5321 (à double interface) des kits BasicCard sans contact du commerce, ou le SCL010 du kit SCM Microsystems, pour ne citer que les principaux modèles que nous avons eu l'occasion d'essayer avec satisfaction.

Et avec quelques lignes de plus...

Dès le chargement terminé, la BasicCard est prête à se faire passer pour un « vrai » Smart poster : soumettons la par exemple aux logiciels du kit SCM Microsystems, ou approchons la d'un téléphone portable compatible NFC. Cela devrait déclencher une tentative d'accès à http://www.acbm.com, et simultanément l'affichage du titre « Ma Banque ».
Mais notre application va bien plus loin que cette fonctionnalité de base ! Nous y avons par exemple intégré notre technologie BasicSpy, capable d'enregistrer toutes les commandes reçues par le tag.
Voici ce que l'on récupère de cette façon grâce à notre utilitaire BSPYUTIL.EXE, après que le tag ait été lu par le kit SCM Microsystems, le mode « espion » ayant bien sûr été préalablement activé :

00 A4 04 00 07 D2 76 00 00 85 01 00
00 A4 00 00 02 E1 03
00 B0 00 00 00 02
00 B0 00 02 00 0F
00 A4 00 00 02 E1 04
00 B0 00 00 00 02
00 B0 00 02 00 26

Le programme exécutable est obtenu par compilation, avec le kit BasicCard, du code source BSPYUTIL.BAS que voici :


#Include CARDUTIL.DEF

#Include COMMERR.DEF

ComPort=101

Declare Command &HC8 &HA0 SPY()

Declare Command &HC8 &HA2 FLUSH()

Declare Sub SpyON()

Declare Sub SpyOFF()

Declare Sub FlushBS()

Declare Sub ReadSpy()

CLS:PRINT"Utilitaires BasicSPY Copyright (c)2001,2008 Patrick GUEULLE":PRINT

Call WaitForCard

ResetCard:Call CheckSW1SW2:PRINT

menu:PRINT

PRINT:PRINT"1 -->  Transfert fichier interne"

PRINT:PRINT"2 -->  Activation mode espion"

PRINT:PRINT"3 -->  Desactivation mode espion"

PRINT:PRINT"4 -->  Vidage du fichier interne"

PRINT:PRINT"0 -->  Quitter"

PRINT:PRINT"Votre choix, puis ENTER"

LINE INPUT X$:PRINT:PRINT

ResetCard:Call CheckSW1SW2()

IF X$="1" THEN Call ReadSpy()

IF X$="2" THEN Call SpyON()

IF X$="3" THEN Call SpyOFF()

IF X$="4" THEN Call FlushBS()

IF X$="0" OR X$="" THEN EXIT

GOTO menu

Sub SpyON()

Call SPY(P1P2=&H0001):Call CheckSW1SW2

IF SW1SW2=&H9000 THEN CLS:PRINT "Mode espion actif !"

End Sub

Sub SpyOFF()

Call SPY(P1P2=&H0000):Call CheckSW1SW2

IF SW1SW2=&H9000 THEN CLS:PRINT "Mode espion inactif !"

End Sub

Sub FlushBS()

Call FLUSH():Call CheckSW1SW2

IF SW1SW2=&H9000 THEN CLS:PRINT "Fichier interne vide !"

End Sub

Sub ReadSpy()

Open"@:card.log" For Input As #1

Open"card.log" For Output As #2

While Not EOF(1)

Input#1, Z$

For F=1 To LEN(Z$)

Z=ASC(MID$(Z$,F,1))

Y$=Hex$(Z)+" "

If Len(Y$)=2 THEN Y$="0"+Y$

Print Y$;:Print#2,Y$;

Next F:Print:Print#2

Wend

Print:Print"---- Fin de fichier ----"

Close

End Sub

Mais ce n'est pas tout, loin s'en faut ! La commande SpyOnOff servant à gérer l'activation et la désactivation du logger incorporé a été enrichie de quelques fonctionnalités supplémentaires, mettant à contribution les paramètres P1 et P2. Lorsque P1 (jusqu'alors inutilisé) est à 00h, le contenu du Smart poster se trouve écrasé par les données présentes dans la chaîne ACBM$ (une version moins provocatrice, dans laquelle le titre « Ma Banque » est remplacé par « ACBM »). Lorsque P1 est à 01h, c'est le contenu de la chaîne INIT$, correspondant à un message NDEF vide, qui est utilisé. Il suffit ainsi d'envoyer une commande C8 A0 01 01 00 pour « initialiser » le tag, au sens de la spécification NFC Forum. Indépendamment de la valeur de P1, P2 sert comme de coutume à activer (01h) ou à désactiver (00h) le logger incorporé (mode espion). La nouveauté, c'est que cela agit en même temps sur le mécanisme de protection en écriture : quand on désactivera le logger, il sera possible de lire le tag sans pouvoir y écrire, mais lorsqu'il sera activé l'écriture se trouvera alors autorisée.
Ce n'est évidemment là qu'un exemple tout à fait arbitraire de ce que l'on peut faire ; à nos lecteurs de laisser libre cours à leur imagination pour monter leurs propres applications à partir de cette base longuement éprouvée.

Pour aller plus loin...

Le Smart poster n'est qu'un type de contenu parmi bien d'autres pouvant être hébergés, sous la forme de messages NDEF, dans des tags NFC Forum.
Une très classique vCard peut ainsi être enregistrée dans un tag au format « carte de visite », et transférée quasi instantanément dans tout téléphone portable compatible NFC dont on voudra bien l'approcher. Là encore, le SDK de SCM Microsystems fait cela très bien, toujours sans nécessiter l'écriture d'une seule ligne de code ni l'étude des spécifications.
Plutôt qu'une URL Internet, il est également possible de charger, dans un tag NFC Forum, un SMS prêt à être envoyé par le téléphone qui en sera approché. Ce moyen concurrent de demander un renseignement ou de passer une commande est particulièrement adapté aux clients d'opérateurs étrangers, car largement plus économique en situation de roaming. Il pourrait notamment servir à recharger commodément des services prépayés.
Dans le même ordre d'idées, le téléphone pourrait tout aussi bien appeler automatiquement un numéro de téléphone enregistré dans le tag qui lui est présenté. L'intérêt est évident en matière d'appels d'urgence, mais certains vont jusqu'à imaginer de coller le tag NFC au dos de la photo d'une personne dont il suffirait d'approcher le téléphone pour entrer en contact avec elle ! Pratique pour les enfants ou les personnes âgées...
Plus technique, l'application connue sous le nom de Handover consiste à enregistrer dans un tag les informations nécessaires pour appairer deux équipements Bluetooth ou WiFi. Un tag incorporé dans l'étiquette d'une box et contenant sa clef WEP ou WPA permettrait ainsi à tout smartphone équipé NFC de se connecter à Internet par son intermédiaire, sans avoir à saisir manuellement cette longue chaîne de caractères.
Toutes les spécifications régissant la mise en oeuvre pratique de ces idées sont d'ores et déjà disponibles dans des documents diffusés par le NFC Forum et n'attendent plus que des volontaires pour les déployer sur le terrain.

Patrick Gueulle

Tous les ouvrages de l'auteur

Vous voulez soutenir une information indépendante ? Rejoignez notre Club privé !

[homepage] [RSS] [archives]
[contact & legal & cookies] [since 1997]