Les iButton™ (Maxim/Dallas) sont des circuits intégrés conçus pour être maltraités et intégrés dans plein de choses.
Le package F5 en lui-même peut contenir différents circuits, allant de la simple mémoire, au logger de température protégé par mot de passe.
Ils sont souvent confondus avec des piles bouton (piles de montre) à cause de leur apparence.

Ils sont couramment utilisés dans les badges et autres systèmes d'identification (certaines entreprises de location de véhicules s'en servent à la place d'autocollants RFID).
Les applications sont vastes et avantageuses dans de nombreuses situations.
Ils utilisent la technologie 1-Wire, tous les transferts de données se font entre la masse (bord) et le contact (centre) du boitier.
La plupart s'auto-alimentent "avec les données": L'énergie necessaire pour que le iButton fonctionne est tirée d'un faible courant absorbé pendant les états haut sur le contact.

Une catégorie d'iButtons est spécialement faite pour contenir des données sensibles;où la lecture et l'écriture de données ne doit pas être à la portée du premier abruti venu (Challenge/Response SHA1, ça rappelle malheuresement les cartes téléphoniques). Mais là où les décisions sont prises en faveur du cout initial plutôt que de la sécurité, on peut se retrouver avec de simples RAMs non-volatiles contenant des sommes d'argent pas tout à fait négligeables.

La face de contact des iButtons est gravée avec leur numéro de série (unique), leur CRC ROM, et leur "reférence silicium". Elle est souvent illisible sur les clés utilisées par des bourrins.

C'est un ami [yotienpluche], qui a son travail, dispose de machines à bouffe et à boisson fonctionnant soit avec des pièces, soit avec une clé iButton ("clé Dallas" ou encore "Clé Nespresso Professional" comme certains revendeurs les appellent). En la regardant de plus près, on s'attendait à lire "DS1961" soit un iButton monétaire (SHA1 1KBit NVRAM), mais c'est "DS1992" (1KBit NVRAM) que nous avons lu.

Je doute beaucoup que ce genre de jeton monétaire tenant sur de la simple RAM soit très répandu mais... On en tient un, pourquoi ne pas en profiter ?

On pensait alors au départ noter la somme indiquée par le distributeur, et la comparer avec le contenu brut du iButton, pour d'abord savoir si elle était écrite en clair, et sinon, trouver une éventuelle correspondance avec les différentes données (somme, CRCs, numéro de série, valeur fixe imposée par le constructeur des monnayeurs...).
En sachant que le distributeur peut lire le numéro de série du iButton, et qu'il pourrait facilement coder la somme avec celui-ci, on a vite oublié l'idée de vraiment "forger" des données avec une somme variable à souhait.

Une méthode beaucoup plus simple consisterait à recharger l'iButton avec une image copiée.
Voici une illustration de ce qui pourrait être possible, moyennant quelques bricolages et écritures de programme:

- L'utilisateur recharge sa clé iButton normalement, avec 10 Euros par exemple.
- Il fait ensuite un "backup" de l'image mémoire du iButton avec un montage portable, qui la retiendra indéfiniment.
- Une certaine quantité de nourriture et de boissons peut alors être achetée tout à fait légalement, avec les 10 Euros.
- Une fois le crédit écoulé, l'utilisateur pourrait récharger lui-même sa clé avec l'image précedement enregistrée depuis le montage.
- Il peut donc recommencer à acheter avec 10 Euros virtuels tout frais, en parfaite illégalité.
Comme écrit ci-dessus, cette pratique serait tout à fait illégale et est punie par la loi. Ne faites donc jamais ça, n'y pensez même pas. D'ailleurs je l'ai jamais fait.

Pour des raisons similaires à celles qui motivent ce projet (radinerie excessive), j'ai construit un petit montage sur plaque d'essai pour lire et écrire dans ces types d'iButtons (NVRAM DS1992/DS1993).
Le premier µC à me tomber dans les pattes était un AtMega8, mais au final, n'importe quel µC ayant un UART et un bon 2Ko de flash fera l'affaire (Tiny2313, Tiny26, PIC16F88...).
Le circuit consiste en une LED rouge, l'AtMega8 et un Max232.
J'utilise un adaptateur série/USB chinois à $4, un vieux câble de modem coupé et un bloc d'alim à 5 euros chez Castorama (qui, au passage donne généreusement 7.4V quand on en veut 5).

Les premiers éssais furent menés avec HyperTerminal et un gros firmware de 7120 octets. Il permettait de lire le ROM, identifier le type d'iButton, de lire une partie de la RAM et de la réécrire, le tout par liaison série. La LED rouge servait au début à confirmer simplement la détéction du iButton.

Les détails techniques suiveront plus tard. Le firmware d'essais actuel fait maintenant juste l'intermédiaire entre la liaison série et la liaison 1-Wire, sans réflechir. Un pauvre programme fait avec Visual Basic permet de s'occuper des messages à transmettre et de déchiffrer ceux qui sont reçus. Toute la RAM (128 ou 512 octets) des deux types de composants peut être lue et écrite.
Toutes les vérifications sont assurées par le microcontrolleur, et les erreurs sont reportées dans le logiciel.

La RAM ne peut être écrite que par "banks" de 32 octets, le DS1992 possède 4 de ses banks. Si il faut écrire des données sur deux banks, il faut écrire le début sur l'une, valider, écrire la fin sur l'autre, puis revalider.
L'étape de validation est nécéssaire car les données sont d'abord écrites dans le "scratchpad", une sorte de mémoire temporaire pour pouvoir être vérifiée avant d'être copiée dans la vraie RAM.
C'est d'ailleurs dans cette étape que se trouve la plus évidente des vulnérabilité avec les iButtons à mot de passe: si le scratchpad n'est pas remis à zéro après un accès à une bank protégée, il y a de grandes chances qu'il traîne encore dessus même après avoir retiré l'iButton...

Malheuresement, les données dans les iButtons DS1992 pour ces distributeurs ne suivent pas de conventions précises données par Maxim, et utilisent des UDP (Universal Data Packet).
Les seuls octets significatifs que l'on connais à ce jours sont:

Le CRC16 de la page en rouge.
La Longueur du contenu en vert.

Le logiciel et le montage ont été testés et fonctionnent. L'essai sur le terrain a finalement été fait, et ça marche.

Désolé, je ne fournis plus les sources ni les firmwares compilés. Les corbeaux rodent...

MAXRETRY définit le nombre d'essais de lecture ou d'écriture avant de déclarer un échec (LED rouge clignotante), fixé par défaut à 5.
RWSWITCH PB3 broche du switch R/W
IBUTTON PB2 broche du contact iButton
GREENLED PB1 broche de la LED verte
REDLED PB0 broche de la LED rouge

Selon les specs officielles du DS1992 et du book of standards:
WRITEONE 10 // min:1µs max:15µs Temps du l'état bas pour l'écriture d'un 1
WRITEZERO 90 // min:60µs max:120µs Temps de l'état bas pour l'écriture d'un 0
TIMESLOT 120 // min:60µs max:120µs Temps total d'écriture d'un bit
RESETLOW 500 // min:480µs Temps de l'état bas pour décharger et redemarrer un iButton
RESETHIGH 500 // min:480µs max:960µs Temps de l'état haut entre deux requètes de presence
PRESENCE 70 // min:60µs Temps à attendre avant de lire une éventuelle réponse

MINWAIT 100 // Ralentissement arbitraire pour des questions d'ergonomie et de fiabilité (en millisecondes)