Reading and writing data in a Mifare UltraLight Card, with a Prox’N’Roll

DOWNLOAD AND READ THE DOCUMENTATIONS

First thing to do is to obtain the documentation of the card from the manufacturer (NXP in this case) and the Prox’N’Roll developer’s reference manual.

From the card’s functional specifications, we can see that the memory is structured in 16 pages of 4 bytes. The four first pages (0-3) contain special bytes: so, we’ll only cover pages 4 to 16.

STEP BY STEP PROCEDURE

The goal is to read and write the card memory.

READ BINARY

In the developer’s reference manual, the READ BINARY instruction is described in §2.2.4 at the time of this writing.

The APDU is :

  • CLA: FF
  • INS: B0
  • P1: Address MSB
  • P2: Address LSB
  • Lc: not needed
  • Data in: not needed
  • Le: number of bytes to be read

The specifics to read Mifare Ultralight cards are detailed in §4.3.3.a (at the time of this writing).
Here, we can see that :

  • P1 must be 00
  • P2 is the address of the first page to be read
  • Le must a multiple of 4.

We want to read the whole memory, starting from page 4: this means we want to read 12 pages of 4 bytes, so 48 bytes (ie: 30 in hexadecimal).
So the APDU is :
FF B0 00 04 30

To send this APDU, please use our PC/SC Diagnostic tool, available on our main site (QuickStart for PC/SC).

Put the card on the reader: its ATR prints. To understand what this means, you can check §4.1.2 (at the time of this writing) in the developer’s reference manual.

ATRNow, double-clic on the line corresponding to the reader and enter the above-mentioned APDU :

read_capduClic on Transmit, or press “Enter”: the APDU is sent to the card and its response is printed in the bottom.

read_rapduThe card has obviously been previously written and the ASCII translation is provided: “Mifare Ultralight card, used with Prox’N’Roll”.
Please note that the card’s reponse ends with “90 00”, which means success.

UPDATE BINARY

In the developer’s reference manual, the UPDATE BINARY instruction is described in §2.2.5 at the time of this writing.

The APDU is :

  • CLA: FF
  • INS: D6
  • P1: Address MSB
  • P2: Address LSB
  • Lc: Lenght of Data In
  • Data in: Bytes to be written
  • Le: not needed

The specifics to write Mifare Ultralight cards are detailed in §4.3.3.b (at the time of this writing).
Here, we can see that :

  • P1 must be 00
  • P2 is the address of the unique page to be written
  • Le must be 4.

We want to replace “Prox’N’Roll” by “SpringCard” in the card memory, so we first have to determine which pages must be updated. Remember that Le must be 4 : this means that we can write exactely 4 bytes at a time (one page), no more, no less.

To determine the content of each page, just use the READ BINARY APDU.
For example, for page 12, the APDU should be : FF B0 00 0C 04

read_single_pageUsing those commands, we can see that:

  • content of page 12 (0x0C) is 68 20 50 72 (in ASCII : “h Pr”)
  • content of page 13 (0x0D) is 6F 78 27 4E (in ASCII: “ox’N”)
  • content of page 14 (0x0E) is 27 52 6F 6C (in ASCII: “‘Rol”)
  • content of page 15 (0x0F) is 6C 00 00 00 (in ASCII: “l” followed by invalid characters)

So, we’ll need to change 4 pages : pages 12, 13, 14 and 15.

SpringCard in ASCII is : “53 70 72 69 6E 67 43 61 72 64”

The 4 APDUs (one for each page) should be:

  • page 12: FF D6 00 0C 04 68 20 53 70 (the first two bytes remain unchanged)
  • page 13: FF D6 00 0D 04 72 69 6E 67
  • page 14: FF D6 00 0E 04 43 61 72 64
  • page 15: FF D6 00 0F 04 00 00 00 00 (we replace the first byte)

Enter those APDUs and click on “Transmit” :

write_single_pageOperation is successful if the card answers 90 00.

Now, you can read back the whole memory, using FF B0 00 04 0C:

final_readWe can see that “Prox’N’Roll” has been replaced by “SpringCard” in the card memory.

 

 


Posted

in

by

Tags: