NFC – Lego Dimensions NFC Tags

In de vorige post vertelde ik over het defecte Lege Dimensions poppetje van mijn zoontje. De tovenaar zag er als figurine leuk uit maar in-game had hij zichzelf weggetoverd. Na wat op en neer e-mailen met Lego ontvangen we netjes en zonder kosten een nieuw poppetje. Ik blijf me echter afvragen wat er mis is met de originele Lego tag en besluit om dit wat verder te onderzoeken. Ik weet namelijk dat de Lego tags gebruik maken van NFC (Near Field Communication) technologie. Interessant, dus let’s Go!

Alvorens we beginnen 2 dikke tips:

1. Lees deze post voor meer informatie over RFID en het verschil tussen RFID en NFC.

2. Lees de disclaimer goed door:

Zo nu we dat gehad hebben is het goed om eerst eens even te kijken naar NFC. Near Field Communication een communicatiemechanisme is welke magnetische inductie gebruikt om twee elektronische apparaten met elkaar te laten communiceren op een geringe afstand van 3 tot 10 cm. NFC heeft geen elektriciteitsbron omdat de benodigde elektriciteit verkregen wordt uit de NFC-lezer/schrijver (bijvoorbeeld een mobiele telefoon). Een NFC-tag bestaat uit een microchip met daaromheen een antenne. Deze antenne is in feite een klein spoeltje om het hoogfrequent magnetisch veld (13,56MHZ). NFC wordt gebruikt voor stickers (b.v. op kleding), tags, sleutelhangers, pasjes, visitekaartjes etc.

Binnen NFC bestaan er 2 soorten, namelijk:

• NFC Reader
• NFC Tag

De NFC Reader is het elektronische apparaat welke de tags leest en van stroom voorziet. De NFC reader moet dus zelf ook continue van stroom worden voorzien.

De NFC tag wordt alleen door de NFC Reader voorzien van stroom. Op het moment dat deze van stroom voorzien wordt vind er data uitwisseling plaats. NFC tags houden data vast en laten deze keer op keer uitlezen. Er zijn verschillende soorten NFC tags:

• NFC Forum Type 1
  Lezen: Ja
  Schrijven: Ja
  Af te sluiten (zodat het een alleen lezen tag wordt): Ja
  Beschikbare formaten: tussen 92 bytes en 2K bytes
  Communicatie snelheid: 106 kbit/sec
• NFC Forum Type 2
  Dit is de meest voorkomende NFC tag.
  Lezen: Ja
  Schrijven: Ja
  Af te sluiten (zodat het een alleen lezen tag wordt): Ja
  Beschikbare formaten: tussen 48 bytes en 2K bytes
  Communicatie snelheid: 106 kbit/sec
• NFC Forum Type 3
  Lezen: Ja
  Schrijven: Ja
  Af te sluiten (zodat het een alleen lezen tag wordt): Ja
  Beschikbare formaten: tussen 48 bytes en 1MB
  Communicatie snelheid: 212 kbit/sec
• NFC Forum Type 4
  Lezen: Ja
  Schrijven: Ja
  Af te sluiten (zodat het een alleen lezen tag wordt): Ja
  Beschikbare formaten: tussen 48 bytes en 32K bytes
  Communicatie snelheid: 106 kbit/sec
• Mifare Classic
  De Mifare Classic is geen NFC Forum goedgekeurde tag maar kan wel gelezen en geschreven worden met de meeste NFC devices.

Het zou mooi zijn als we de Realtek Ameba kunnen programmeren als geemuleerde Lego Dimensions tag. Bekijk deze post voor meer informatie over de Realtek Ameba.

De Ameba communiceert data volgens de NDEF (NFC Data Exchange Format) standaard. Deze standaard is gedefinieerd volgens het NFC Forum. Hierbij een schematisch voorbeeld van NDEF data

Omdat de Ameba standaard geen NFC kan lezen (en ik eerst de data van de Lego tag nodig heb om deze te kunnen schrijven) wordt het zaak om eerst een NFC lezer aan te sluiten.

Maar first things first. Hoe zit dat met de Lego Dimensions Tags. Zijn deze niet speciaal?

De Lego Dimensions Tags

Het volgende kan ik achterhalen over de Lego Dimensions Tags. Deze tags zijn van het Mifare Ultralight NTAG213 type. Deze tags werken op de 13.56 MHz. frequentie en hebben een bruikbaar geheugen van 144 bytes (in totaal 180 bytes). Deze tags hebben een nette lees- en schrijf snelheid. Deze tag is NFC Forum Compliant en kunnen voorzien worden van een 32-bit wachtwoord. Ook beschikken ze over MIFARE SAM AV2 veiligheidsopties. Ze beschikken over een 7-byte lang serienummer en bieden geen ondersteuning voor cryptografie.

De Lego Dimensions tags hebben een aantal versleutelde blokken. Het wachtwoord om deze blokken vrij te geven wordt berekend met het UID (Unique ID) van de tag. Vervolgens beschikken de blokken/pages 0x25 & 0x26 over de character code welke ook weer met bovenstaande wachtwoord versleuteld moet worden.

Simpelweg een tag kopiëren zal dus niet werken.

Een tool die veel gebruikt wordt voor het kopiëren van de tags en het genereren van de juiste wachtwoorden is Node-ID. Ik ga deze tool niet opnemen in deze post want dit is toch wel een heel illegaal tooltje welke we natuurlijk niet willen gebruiken… !

Character codes e.d. zijn hier te vinden.

Ok. Nu gaan we een reader aansluiten om de tag uit te lezen.

RFID Reader ID-20-MF7

De eerste lezer die ik ga aansluiten is de ID-20-MF7. De ID-20-MF7 is een lezer met zeer hoge prestaties. Deze goed ontworpen lezer heeft een gemiddeld bereik van 5 cm. De MF7-lezer is heeft een 9600bps TTL/RS232 uitgang met Magnetic, Wiegand of ASCII codering interface. Deze lezer wordt vaak gebruikt voor toegangscontroles.

De ID-20-MF7 werkt op de 13.56 MHz frequentie en is in staat om ook Mifare tags te lezen.

De ID-20-MF7 is een product van “ID Innovations”. De datasheet is hier te vinden!

De pin layout van deze reader is:

Het is belangrijk om de reader te voorzien van een stroomsignaal (pin 14 = 5V), ground aansluiting en natuurlijk data. De data 0 pin (9) gaan we aansluiten aan de digitale RX pin (0) van de Arduino en ook pin 7 verbinden we met de ground om ASCI mode te gebruiken. Het geheel ziet er dan als volgt uit:

Na een paar avonden stoeien krijg is helaas met de ID-20-MF7 (in combintie met de Arduino) geen goede data inzichtelijk. Vele verschillende connecties en Arduino Schema’s geprobeerd maar geen van allen hadden veel succes. Ik denk dat ik met een Raspberry Pi en Python meer succes heb. Maar aangezien ik meer equipment heb gaan we eerst een andere reader proberen. We gaan nu de RFID ID-12LA proberen.

RFID ID-12LA

De RFID Reader “ID-12LA” is van dezelfde producent als de ID-20-MF7. Maar zoals je kunt zien is deze een stuk kleiner en is de pin-layout ook anders. De pinnen staan korter op elkaar waardoor deze niet allemaal van jumperkabels kunnen worden voorzien.

De pinlayout is als volgt:

In theorie moeten we minimaal de volgende pinnen aansluiten:

1 – Ground
2 – 5V
7 – Ground
9 – RX (0)
11 – 5V

Maar omdat de pinlayout van de RFID ID-12LA niet breadboard compatible is en ik vergeten ben om er een breadboard compatible board bij te bestellen (zie onder) moet ik de pinnen gaan solderen. Mmmm what to do. Ik besluit om snel het ID-12LA Breakout Board bestellen. Maar daar kom ik later op terug. Daar hebben we nu niets aan.

FAAL… again. Het ziet er naar uit dat het niet meer gaat lukken. Mijn laatste wapen in de strijd is nu de RC522 RFID Reader. Laten we deze proberen.

RC522 RFID Reader

De RC522 (voluit de MFRC522) is een MiFare tag reader dus dat komt in dit geval goed uit. De volgende MiFare kaartsen worden sowieso ondersteund:

• MIFARE Mini
• MIFARE 1K
• MIFARE 4K
• MIFARE Ultralight
• MIFARE DESFire EV1
• MIFARE Plus RF

De RC522 werkt op 13.56 MHz ondersteund de volgende standaarden: ISO/IEC 14443 A/MIFARE & NTAG. Er zijn 3 host interfaces gebundeld in deze kaart, namelijk SPI (Serial Peripheral Interface) tot 10 Mbit/s, Serial UART tot 1228.8 kBd en I2C-bus tot 3400 kBd in High-speed mode. De RC522 heeft een programmeerbare time en werkt op 2.5 tot 3.3V. Let dus op dat je hem niet per ongeluk aansluit op de 5V poort van je Arduino want dan is het gebeurt met je RC522 RFID reader.

Een versimpelde layout van de RC522 is als volgt:

De pin layout is:

Ok. Laten we er eens wat stekker inprikken.

Ik kies ervoor om de RC522 aan te sluiten op de SPI interface. De volgende PIN layouts zijn mogelijk voor de 3 verschillende interfaces:

Als library kies ik voor de MFRC522 RFID library. Deze library is speciaal ontwikkeld voor dit board…dus waarom niet gebruiken 🙂 Je kunt de library hier downloaden, of je gebruikt de download link van mijn website.

Na de installatie van de library wil ik eerst informatie van bestaande tags lezen. Dit doe ik met de DumpInfo sketch.

In de sketch staat ook exact de pinlayout uitgelegd:

Deze komt overeen met dit voorbeeld:

En dan in het echt:

Nadat de sketch ge-compiled is en geupload is starten we de seriële monitor. En wat zien we dan…

EUREKA!!!

Dit ziet er goed uit. Laten we nu bijgeleverde token MiFare 1kb) eens scannen, hoe ziet dat eruit…

NICE! We zien hier dat het gaat om een MiFare 1kb kaart. De 1kb slaat op het EEPROM geheugen van de kaart. Het UID (Unieke ID) is 36A9A9AC en 4 bytes lang (hexadecimaal). De kaart bestaat uit 16 sectoren (0-15) en elke sector bestaat uit 4 blokken, dus een totaal van 64 blokken. Elke sector heeft zijn eigen schrijfrechten. De blokken in de sector worden beheerd door deze toegepaste schrijfrechten. Elk blok beschikt over 16 bytes, dus 64 bytes per sector en 1024 bytes per kaart.

Alle bits zijn gevuld met hexadecimale waardes. Als we dit terugrekenen naar binaire waarden dan ziet het eerste (0) blok er als volgt uit:

36 a9 a9 ac 9a 08 04 00 62 63 64 65 66 67 68 69
0011 0110 1010 1001 1010 1001 0000 1000 0000 0100 0000 0000 0110 0010 0110 0011 0110 0100 0110 0101 0110 0110 0110 0111 0110 1000 0110 1001

Het eerste blok op de MiFare kaarten bestaat uit manaufacturer. Zoals je ziet bestaan de eerste 4 bytes uit het unieke ID nummer van de kaart gevolgd door meestal 4 bytes manaufacturer informatie. De laatste 8 bytes in het eerste blok zijn meestal leeg.

Het 3e blok in elke sector noemen we ook wel de “Sector Trailer”. Dit blok bevat de 2 veiligheidssleutels (KeyA en KeyB) evenals de toegangsrechten voor de blokken binnen het sector.

Elke sector kan ingesteld worden als “leesbaar” of als “schrijfbaar”. Dit is afhankelijk van de permissies die het “access bit” definieert.

Laten we nu de 2 Lego tags eens scannen:

Zoals je ziet zijn dit andere MiFare kaarten. Lego Dimension tags zijn MiFare Ultralight tags welke bestaan uit 16 pages (pagina’s) met elk 4 bytes (hexadecimaal). De MiFare Ultralight tags zijn zeer goedkope tags die vaak gebruikt worden in weggooi artikelen zoals tickets, orderdozen etc. Ook Lego gebruikt deze dus. Deze tags bieden alleen simpele basisbeveiligingsfuncties zoals een eenmalige programmeerbare (OTP) bits en een schrijfbeveiligingsfunctie om het opnieuw herschrijven te voorkomen. Deze tags bevatten echter geen cryptografische beveiliging zoals vaak wel aanwezig is in andere MiFare kaarten.

Als we gaan kijken naar de opbouw van de Lega Dimensions tags dan kunnen we het volgende ontdekken.

De UID bestaat uit 7 bytes. De 4e byte uit de eerste page wordt hiervoor niet gebruikt.

Verder zien we dat bepaalde data (laatste 5 pages) niet gebruikt wordt en is er identieke data te herkennen. Vooral de data in page 1 t/m 6 komen overeen. Page 2, 8,9 en 10 zijn volledig anders. Het vermoeden is dan ook dat de data in de pages 3 t/6 de data bevat van het karakter.

Laten we het vervolgens eens vergelijken met een andere Lego tag, namelijk Lego Dimensions Batman:

We zien ook bij de Batman tag het UID terug in page 1 + 2, ongebruikte ruimte in page 11 t/m 15 en identieke data op page 3 t/m 6.

Page 2, 8,9 en 10 beschikken over werkelijk unieke data.

Als we kijken naar de MiFare Ultralight datasheet dan zien we het volgende:

Page 0, 1 en 2 bevatten inderdaad het serienummer. Byte 4 op page 0 en byte 1 op page 2 zijn check bytes:

Page 2 heeft de 1e byte gereserveerd voor een serienummer, 2e byte voor “internal” gebruik. Deze byte (48) is write-protected en wordt geprogrammeerd door de leverancier. De laatste 2 bytes zijn t.b.v. de zogenaamde “lock bytes”. Lock byte is “00011111” en lock byte 2 is “00000000” in binary. Als we verder kijken naar de lock bytes dan zien we dat de pagina’s 4 + OPT gelocked zijn als read only en dat 4-15 + OPT niet geblokkeerd zijn voor het geheugen.

Page 3 bestaat dus uit OPT bytes (binair: 11100001 00010000 00010010 00000000). Deze bytes zijn OR bytes. De standaardwaarde is 00000000 00000000 00000000 00000000 en elke keer als er bytes geschreven worden, wordt de waarde ge-OR’d. Page 4 t/m 15 zijn bestemd voor user data. Omdat page 4 t/m byte 3 in page 7 identieke waardes hebben moet de character code e.d. zich bevinden in page 7, 8, 9 of 10.

Nu weet ik toevallig (internet) dat de code voor Gandalf “9591283R2215” is.

Als we de hexadecimale waardes van byte 4 pagina 7 + pagina 8,9 en 10 gaan vergelijken in binary en in decimalen ziet dat er als volgt uit:

Gandalf OK:

Binair
00111000
00110010 00110010 00110001 00110010
00111000 01010011 00110010 00110010
00110001 00110110 11111110 00000000

Decimaal
56
50 50 49 50
56 83 50 50
49 54 254 00

Gandalf Defect:

Binair
00110111
00110001 00110000 00110000 00110101
00110011 01010011 00110101 00110000
00110001 00110101 11111110 00000000

Decimaal
55
49 48 48 53
51 83 53 48
49 53 254 00

Ik zie nog steeds de Gandalf code hier niet tussen staan. Dit komt omdat de code versleuteld is. Elk blok op de MiFare Ultralight kaart is versleuteld volgens een algoritme. Het UID is onderdeel van de versleuteling. Zou je de data van de tag willen kopiëren naar een andere Ultralight tag dan zal dit nog niet werken omdat de UID op de nieuwe tag niet overeenkomt met de versleuteling die gebruikt is. Je kunt nu 2 dingen doen om de tag te kopiëren. Je kopieert alle data incl. UID over naar een zogenaamde “magic card”. Deze magic cards zijn Chinese RFID kaarten waarbij de UID wel te overschrijven is. Deze kosten gemiddeld 2 euro per stuk op E-bay. Je kunt natuurlijk ook de tag kopiëren naar een geëmuleerde tag zoals de Realtek Ameba. Het nadeel daarvan is dat deze altijd stroom nodig heeft.

Wat je ook kunt doen is de code opnieuw versleutelen in combinatie met je UID. De programmatuur om dit te doen heb ik al eerder in deze post vermeld.

Deze acties ga ik hier niet voordoen. Uiteraard is het illegaal kopiëren van andermans content illegaal en daar ben ik dan ook zwaar op tegen…

Maar wat was er dan defect aan het Gandalf poppetje? De tag functioneert prima en heeft een nette UID. Alle statische data lijkt aanwezig. Mijn beste gok is dan toch dat de tag niet goed beschreven is in de fabriek waardoor de Gandalf code incompleet is of dat mijn zoontje met een magneet aan het spelen is geweest waardoor de Gandalf code beschadigd is geraakt.

Tot zover mijn onderzoek naar de Lego Dimensions RFID tags.