Didier Stevens

Tuesday 19 May 2009

Another Lowcost RFID Detector

Filed under: Hardware,RFID,smart card — Didier Stevens @ 21:30

Patrick Gueulle published a logging program (French article) for BasicCards. A BasicCard is a smartcard programmable in a variant of the BASIC language. Patrick’s BasicSPY program logs all APDU requests to a file stored on the smartcard. After using the BasicCard programmed with BasicSPY in a reader, you can retrieve the log file and observe the commands send by the reader to the card.

Patrick’s terminal program to manage the internal file (I translated the menu to English):


A new type of BasicCard was announced in January: the Dual Interface BasicCard. This smartcard also has a contactless ISO14443/A interface. In other words, this smartcard has a HF RFID interface!

This smartcard is handy to make another lowcost RFID detector: I install BasicSPY on my Dual Interface BasicCard and hold it against an (unknown) RFID reader. When the reader supports ISO14443/A , it will send APDUs to the BasicCard which will log them in the internal file. Later retrieval of the internal file reveals the APDUs send to the smartcard:



Monday 23 February 2009

Shellcode On a MIFARE RFID Tag

Filed under: RFID,smart card — Didier Stevens @ 21:29

This posts kicks-off a series of posts on smart cards and RFID tags.

First a little bit of fun. I’ve written a Python program to read and write 1K MIFARE RFID tags with my ACR122 contactless reader/writer.


I store shellcode on an MIFARE tag (MIFAREACR122.py write shellcode.bin); and then I read it from the tag and execute it (MIFAREACR122.py shellcode).


Of course, this is just a little trick, it’s not a vulnerability. Just find it funny to store shellcode on a RFID tag.

Monday 6 October 2008

Forensic Time Dilatation

Filed under: Forensics,smart card — Didier Stevens @ 6:42

When you compile a forensic report, it’s crucial to report facts objectively and avoid potential misinterpretation.

Although this statement shouldn’t be a surprise to you, sometimes, the devil is in the details.

Take the electronic purse (EP) in use in many European countries (Proton, Chipknip, …). These EP systems are based on ATM smart cards and are used to pay small amounts. A main advantage of these cards is that terminals performing EP debit transactions don’t require a network connection to check the purse owner’s credit or credentials. The debit transactions are self-contained and protected by cryptographic protocols.

The EP also supports a couple of simple unencrypted commands to read the balance of the EP and list the last transactions. When you send the EP an APDU to get the last transaction (0xE1, 0xB6, 0x00, 0x01, 0x24), it will reply with a binary record of 36 bytes. 2 bytes in this record are used to encode the timestamp of the transaction using the following format:

4 bits I called M are used to encode the month (0-15).
5 bits D are used to encode the day (0-32).
The year the transaction took place is not documented.
7 bits T are used to encode the time the transaction occurred (0-127). 128 possible values is by no means enough to encode the time with a precision of 1 second (86400 possible values). The resolution of the EP timestamp is 675 seconds long (that’s 11 minutes and 15 seconds).

And herein lies the difficulty to print timestamps in a forensic report. I came across a forensic tool (TULP2G) that gets it wrong. TULP2G will print the above timestamp in its forensic report like this:

24/09 11:37:30

Can you spot the error? If the time is encoded with units covering a period of 675 seconds (i.e. an error margin of 675 seconds), you cannot print the time in a forensic report in HH:MM:SS format without any indication that the represented value is not precise up to the second! Because there will always be people reading your report that have no notion of the (in)accuracy of the EP timestamp, and they will interpret the timestamp like you wrote it: 11 hours, 37 minutes and 30 seconds precisely. According to the cash register ticket, I bought my lunch at 11:44, not at 11:37:30.

If you print timestamps in a forensic report, think about the resolution of the values you’re representing. If you use the HH:MM:SS time-format to represent a value that is measured in units longer than 1 second, add a qualification to each printed timestamp to indicate this.

You can add a footnote explaining the error margin, use the scientific error notation, …

For example, write 24/09 11:37:30 ± 675s.

Personally, I would write 24/09 11:37:30 + 675s – 1s (1), because I’ve observed only terminals that seem to perform an integer division: current time expressed in seconds / 675. (1) refers to a footnote explaining the resolution of the timestamp. But this is in all likelihood too confusing.

Your takeaway: if you compile or interpret forensic reports, take particular care to avoid the pitfalls of timestamps. Take into account desynchronized clocks, clock drift, time-zones and time unit resolution.

I contacted the author of the TULP2G software, but got no reply. If you’ve contacts inside the NFI, please inform them of my opinion.

Blog at WordPress.com.