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 4 May 2009

Quickpost: Using Your Poken as a Lowcost LF RFID Detector

Filed under: Hardware,Quickpost,RFID — Didier Stevens @ 0:01

Here’s an alternate use for your Poken: use it to detect 125 kHz RFID readers. Its led will blink red when you bring it next to a LF RFID reader (125 kHz). It will not react with a 13.56 MHz reader; and I haven’t tested with a 134.2 kHz reader.


Quickpost info

Thursday 26 March 2009

Poken Peek

Filed under: Encryption,My Software,RFID — Didier Stevens @ 7:35

OK, after getting side-tracked by /JBIG2Decode PDFs, let’s get back on the smartcard and RFID track.

The Poken is a little USB stick you keep on your keychain. You link it to your online identities. To befriend other Poken owners, you just have to hold your Pokens together for a second, and they’ll exchange IDs through RFID. The Poken is popular in The Netherlands, not only among children, but adults too. No more need to exchange business cards.

My 2 guinea pig Pokens were delivered last week. If you want to meet them in person, come to Brucon for my workshop.


When plugged into a PC, the Poken simulates a USB memory stick containing 3 files:

  • autorun.inf
  • help.txt
  • Start_Poken.html

Start_Poken.html (started by autorun.inf or by you) will navigate to the Poken website and automatically login to your Poken account. It contains a URL with the necessary data to identify you to the Poken website. Having your Poken lost or stolen is an issue (as explained in the Poken FAQ), because of the auto-login feature.

But loosing physical control over your Poken is not the only way to get your account compromised. The URL is actually the only thing needed to gain access to your account. And because this URL uses the HTTP protocol (the Poken site doesn’t support HTTPS), it’s easy to intercept on insecure networks. Insecure networks are not the only issue. Because all the data is in the URL, it will also leave a copy of the URL in different systems on a network, for example in proxy logs.

To prevent unwanted access to your account, disable auto-login for your account (it was enabled by default for my account).


I was told by the Poken help-desk that they will support HTTPS in the future. But the current Pokens are hard-coded to use HTTP.

When I read the Poken FAQ stating that your data is protected by a “very advanced encryption method” (sic), I interpret that all the data is encrypted with a cipher like AES.
But this isn’t the case. Not all the data is encrypted. Your Poken ID (a 4-byte integer that uniquely identifies your Poken) is not encrypted. And neither are the IDs of the Pokens you befriend. Your personal account data entered on the Poken site is not stored on your Poken. The link between a Poken ID and an account is kept in the database of the Poken web site and is visible for its owner.

The data of a Poken is stored in the URL in file Start_Poken.html:


The path (ABCDEFGH…) is encoded in BASE64 (more precisely, a BASE64 variant compatible with URL encoding). I’ve identified the purpose of some of the first 96 bytes of data. It contains your Poken ID and various counters. 2 4-byte integers are changing with each use and appear to be random. These could be a (cryptographic) hash to guarantee the authenticity of the Poken data.
The rest of the data is used to store the IDs of the Pokens you befriended. There is room for 64 records (friends) of 16 bytes each. If you befriend more than 64 Pokens without connecting to the Poken site, the old records get overwritten by new records (like in a circular buffer) and you lose friends.

I’ve a tip for you: if you can’t connect to the Poken web site while befriending more than 64, connect your Poken to your laptop and backup file Start_Poken.html. Later, when you’ve access to the Poken site, open the backuped files in the order you backed them up. Each file will update your data. And after that, use your Poken.

The 16 byte record contains the befriended Poken ID, a status byte (discreet befriending), 3 bytes that look like a timestamp and 8 bytes that appear to be random. These 8 bytes could be a (cryptographic) hash to guarantee the authenticity of befriended Poken data and prevent spoofing or replaying.
So not all the data is encrypted: the Poken IDs are in cleartext. As the link between a Poken ID and the account is safely protected by the Poken web site, even if your data is stolen or intercepted, not much would be disclosed. Traffic analysis could be applied if data of several Pokens is intercepted during an event. Since most people make their friend list public, they shouldn’t care about the interception of the Poken IDs they befriended anyways.

And how about the strenght of the encryption? Well, contrary to what is stated in the Poken FAQ, I don’t believe it is state of the art. Modern, secure ciphers like AES work with blocks of at least 128 bits (16 bytes). In the Poken data, we have blocks of maximum 64 bits (8 bytes). 64 bit encryption is not state of the art anymore. For comparison, DES (and 3DES) work on 64 bits block. You shouldn’t use DES anymore, because it can be brute-forced, although that’s still not trivial to do.

Conclusion: the biggest risk of using a Poken is getting your account compromised, but this can be mitigated. And the encryption of the data on a Poken is not designed to protect your data, but to prevent fraud with the befriending process. The cipher isn’t AES or an equivalent cipher. Yet it is possible to build a small USB device that uses AES to encrypt all data: the YubiKey does it.


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.

Blog at WordPress.com.