Posted tagged ‘NFC’

Repackaged CryptoRF/LibNFC Example Code

March 30, 2013

Earlier, I tried to build the “NFC-CryptoRF” example code from the LibNFC Wiki, without success against LibNFC 1.7.0-rc4-9-g3584338, under Ubuntu 12.10.

Unsurprisingly, thanks to the LibNFC developers constantly changing their public APIs (for good reasons, I’m sure), said example code has succumbed to bit-rot, and only builds against obsolete versions of LibNFC.

Therefore, it seems that the only immediately obvious way for this code to be useful is to either downgrade the installed library version, or attempt to fix the hacky code to compensate for changes.

Luckily, after temporarily uninstalling my trunk version; downloading, and installing a LibNFC 1.3.4 source archive, applying the patch from a member of the LibNFC Forums to the example code, and attempting to rebuild everything, it seems that the example code works as it should.

After reinstating my modern LibNFC version; configuring 1.3.4’s build process to install to a temporary directory, copying the resulting ancient shared object file to “” in the example code directory, and creating a wrapper shell (“crf134“) script based upon the arguments passing technique mentioned here, it seems that I can now enjoy being able to use this tool, alongside more modern, “global” versions of LibNFC…

Anyway, to save others the hassle, I’ve uploaded the resulting product to Google Code.

As proof of peaceful co-existence with a more modern version of LibNFC:

Finally, in order to satisfy the terms of the (L)GPL, I have also included the original, uncompressed LibNFC 1.3.4 archive, the patched example source code, a copy of the patch, and the unpacked LibNFC directory containing both source, and 32-bit Linux binaries.

Finally, CryptoRF

March 29, 2013

Yesterday, I finally received a package from Atmel USA containing some sample ISO/IEC14443 Type-B CryptoRF tags, after numerous failed attempts at requesting some via their sample request form.

I ordered 1 sample of the 8KB AT88SC0808CRF-MX1 variant, and 2 samples of the 4KB AT88RF04C-MX1G variant.

The 4KB tags seem to be unusually packaged, and I don’t know if it’d be safe to carefully attempt to cut the strip in half using scissors, in order to make it easier to work with each:

I was probably expecting to receive paper-mounted tags, similar to my FeliCa Lite, and MiFare UltraLight ones – but the product seems to work as advertised.

Curiously, I was able to trigger an unusual hardware glitch in the PN532 chipset, if I carefully placed the strip of 4KB tags in the reader’s field in a specific way, which manifested in the following output from nfc-list -v:

I’ve also uploaded a USB trace file demonstrating this phenomenon, here.

It seems that I’m supposed to see this, instead:

Unsurprisingly, I can’t seem to be able to reliably read either of these two, without even more careful positioning – which suggests anti-collision problems (probably since both have the same unique ID, as supplied)…

The 8KB version, and its accompanying protective packaging looks like:

(Hand not included!)

…and nfc-list -v says:

When I get time, I intend to study the datasheet, and probably play with building TAMA shell scripts, with a view to trying to write another command set dissector.

That said, I have, however tried to compile the sample code on the LibNFC wiki, without success.

Maybe someone else has succeeded in building it against the latest revisions of LibNFC?

Minor Wireshark NFC/RFID Dissector Updates

March 6, 2013

Recently, I updated my FeliCa, and NXP PN532 Wireshark dissectors to support the following functionality:

PN532 dissector:

  • Support for dissection of MiFare command payloads in PN532 InDataExchange packets (bug #8291)
    • This means that command packets (but not responses) from tools such as MFOC, and the tools from LibNFC for accessing MiFare Classic, and MiFare UltraLight tokens are dissected.
  • Support for dissection of FeliCa payloads in PN532 InCommunicateThru packets (bug #8246)
    • This means that dissection of packets from almost all of an “NFC Tag Type 3” (barring NDEF payload data) tag reading session should be dissected, using the FeliCa “flavour” of notation.

FeliCa dissector:

  • Support for the FeliCa Plug system code (bug #7767)
    • This theoretically means that Sony’s new FeliCa Plug should be identified in “Polling Response” packets.
  • Update to identify commands from the full FeliCa Standard profile (bug #8243)
    • This theoretically means that commands related to enciphered reading/writing, authentication, searching for system/service codes, and requesting system information from the latest FeliCa Standard tokens should be at least identified.

I have also been trying to update Google’s dissectors to work with the latest SVN revisions of Wireshark, with mixed success. However, it seems that project has temporarily stalled – save for some brief exchanges on its mailing list, that didn’t really go anywhere.

Anyway, I remain willing to assist with that effort; and in the interim, I hope that this new functionality is useful.

Google’s Wireshark Dissectors for NFC

May 25, 2012

Earlier, I noticed that @hiro99ma had ReTweeted a post from @eggman stating the following:

欲しかったやつだ。Googleの作ってるね。 / “wireshark-nfc – NFC dissectors for Wireshark. – Google Project Hosting” 

The Japanese text roughly means something like “Fellows wanted. People inside Google are making this”, from what I understand.

That aside, after cloning the Git repository into my local Wireshark SVN plugins directory, my initial attempt at building the code failed with:

However, I was quickly able to rectify the problem by exporting some environment variables:

export WIRESHARK_INCLUDE=$HOME/wireshark/
export WIRESHARK_LIB=$HOME/wireshark/lib/

Under my VirtualBox-based Ubuntu installation, the plug-in binary ( was installed in /home/tyson/.wireshark/plugins, after running make install again.

However, after starting Wireshark using sudo, it appears that the plug-in itself was undetected – since the aforementioned path isn’t the default plug-in search path for the root user.

When the dissector plug-in is unavailable, it is possible to open an LLCP trace file – but packets are displayed in a generic manner:

After moving the binary to /usr/local/lib/wireshark/plugins/1.7.2/, and restarting Wireshark, I was successfully able to dissect the packets in the example trace file:

Hopefully, Google will work with the upstream Wireshark developers in order to integrate this functionality into mainline, so that I can investigate integration of the NDEF payload dissector into my FeliCa and MiFare dissectors; and also see if it’s possible to integrate the main LLCP dissector with my NXP PN532 chipset-specific protocol one.

Interfacing with a PayPass card under Linux using LibNFC

March 14, 2012

This morning, I received an Orange Cash prepaid debit MasterCard, and preceded to see if I could use its ISO/IEC 14443-A interface to access its EMV application directory.

After spending some time searching the Web, I realised that not many people have successfully attempted to do so using LibNFC (or if they have, they’ve decided to remain quiet about it, for reasons unknown); and resorted to trying to use CardPeek‘s EMV script – which worked successfully with the ISO/IEC 7816 contact interfaces of all of the cards that I’ve tried (until I accidentally broke one of the contact interface pins), but doesn’t work with my reader’s RFID transceiver…

Using LibNFC’s nfc-list -v command, I was able to obtain the following information regarding the contactless interface:

1 ISO14443A passive target(s) found:
    ATQA (SENS_RES): 00  04
* UID size: single
* bit frame anticollision supported
       UID (NFCID1): 29  8b  cf  51
      SAK (SEL_RES): 28
* Compliant with ISO/IEC 14443-4
* Not compliant with ISO/IEC 18092
   ATS: 78 80 82 02 80 31 80 66 b0 84
 12 01 6e 01 83 00 90 00
* Max Frame Size accepted by PICC: 256 bytes
* Bit Rate Capability:
  * Same bitrate in both directions mandatory
* Frame Waiting Time: 77.33 ms
* Start-up Frame Guard Time: 1.208 ms
* Node ADdress not supported
* Card IDentifier supported
* Historical bytes Tk: 80 31 80 66 b0 84 12 01 6e 01 83 00 90 00
  * Tk after 0x80 consist of optional consecutive
      COMPACT-TLV data objects;
    the last data object may carry a status indicator of one,
      two or three bytes.
    See ISO/IEC 7816-4 for more info
Fingerprinting based on ATQA & SAK values:
* JCOP31 v2.3.1
* SmartMX with Mifare 1K emulation

I’ve modified the formatting of that command’s output slightly, so that it fits within this blog’s template boundaries –  but the data is identical to what I see when running it.

Since I couldn’t find any useful example code in C or C++ for exchanging ISO/IEC 7816 APDUs with contactless cards, I decided to investigate the possibility of modifying one of the TAMA scripts (UltraLightRead.cmd) in the LibNFC repository, and discovered that by prefixing the EMV commands mentioned in Saush’s blog post with 40 01, I was able to make the card respond to a request for the Payment System Environment.

The resulting script looks like this:

02; // Get firmware version
4A 01 00; // 1 target requested
// Select the payment system environment
40 01 00 A4 04 00 0E 31 50 41 59 2E 53 59 53 2E 44 44 46 30 31;

And the resulting packet received from the card reader’s PN532 chipset looks like:

If I get chance, I’ll probably see if I can modify CardPeek’s EMV script somehow to generate APDUs with InDataExchange (0x40) framing, and hopefully get contactless mode working with my reader (so that I don’t have to implement EMV by myself, in order to test other commands) – but I have my doubts, somehow.

In the meantime, I hope that this discovery is vaguely helpful for others…

New Wireshark USB CCID Dissector Functionality

March 4, 2012

As I mentioned in my previous post, I’ve been working on improving support for dissecting smartcards-related protocols in Wireshark, and delivered preliminary support for the USB CCID specification in November 2011.

Since then, I decided to implement support for switching the protocol used for dissection of payloads sent from the PC to the card reader using Wireshark’s preferences mechanism, after reading the source code for the I2C dissector.

This functionality was accepted upstream in SVN revisions 41151 and 41156, and consisted of two patches – one of which implemented it in a hackish manner, and the other served to clean things up in the hopes of making the code more readable and maintainable.

Prior to implementing this, I decided to conservatively treat data flowing to and from a card and reader in a generic manner, since users are likely to use a diverse range of standardised and proprietary protocols – the result of which looked like:

Now, right-clicking on the “USB CCID” row of the protocol tree reveals a “Protocol Preferences” submenu, which contains another one entitled “PC -> Reader Payload Type“:

The Protocol Preferences Submenu

As you can probably tell, I’ve retained the generic dissection support, in addition to providing the option of dissecting payloads using the dissector for the GSM SIM profile of the ISO/IEC 7816 contact smartcard standard, as developed by the Osmocom SIMTrace project.

Upon activating the SIM dissector, PC_to_RDR_XfrBlock (0x6f) packet payloads should be dissected in a slightly more useful manner:

The GSM SIM dissector

Obviously, there are still some outstanding bugs that I’m aware of (the CCID dissector’s info column text overrides that of the selected dissector, and the GSM SIM dissector itself doesn’t cope with packets without status words well, at present), although I aim to resolve those in time – along with adding support for new payload protocols.

In the meantime, I hope that others will find this enhancement useful.


February 5, 2012

Since it’s been a while since I last posted anything here, I thought that I’d briefly summarise what I’ve been doing over the past few months. If I get chance, I’ll probably follow up with more detailed posts, later.

I’ll also apologise in advance, if the quality of this post is below my usual standards – since I’m tired, and I’ll admit that it’s been quite a long time since I’ve produced any prose that’s more complex than one of my typical Tweets, e-mails, or IM/IRC sessions.

A Japanese Redux

As you can probably tell from this post’s title (Kon’nichi wa Wakusei/Hello, Planet), I’ve recently decided to resume learning Japanese using new techniques, after a multi-year hiatus – so that I can enjoy, and understand a multitude of content (music, blogs, and technical documentation, amongst other things); along with hopefully engaging in even more insightful and interesting conversations.

I’m already somewhat able to read and recognise text written in Katakana and Hiragana (providing that I’m undisturbed); and I seem to have a decent recall rate, according to the SayJack Hiragana listening quiz – although I’ll need to keep reading, listening and practising, in order to succeed in the long-term.

Obviously, I’m already capable of writing in Japanese using an Input Method Engine (I’m currently using Google’s – but I’ve also got a trial copy of ATOK in my “Downloads” folder), and can sort-of write a handful of characters on paper.  My listening skills are also constantly improving.

I also realise that my Japanese vocabulary leaves much to be desired for – although I’m acquiring words and phrases as I progress; and I guess that it’s something that I’ll continue to do, long after understanding the basics.

The Epiphany

At ~5:03 am GMT, I had an epiphany in comprehending the phrase 「僕は日本語を学んでいます」(Boku wa nihongo o manande imasu/”I have learned [the] Japanese“) , after reading comments on a Google+ greeting post that I addressed to the author of the hiro99ma blog, and looking up the meaning of  「を」 (wo – pronounced “o”).

Collectively concluding that 「は」(ha) is pronounced differently, depending upon the context (it is pronounced “wa”, when used as a particle) probably also helped.

With a hint of irony, I also had to learn the Japanese words for “learning” and “learn” . (「学んで」(mana-n-de), and 「学ぶ」(mana-bu), respectively), in order to actually state “I’m (trying to) learn Japanese”), beforehand.

That aside, I’ll move on to my…

Personal and Commercial Projects

After obtaining an ACS ACR122U RFID/NFC/smartcard reader, I have been performing research into various proprietary, and standardised smartcard protocols; and have discovered a useful hardware modification – which I’ll document at a later date. Some of my research has culminated in writing Wireshark dissectors for the USB CCID class, MiFare, and FeliCa application protocols – all of which have been accepted upstream.

Regular readers of my posts on the OMAP3530 board, who have probably observed that I haven’t said much about it, after my last aborted attempt at getting Symbian^3 running on it might be interested in knowing that I’ve partially succeeded in getting RISC OS running.

I’ve also been working on an Android application, as part of my first ever contacting position – although I can’t provide any more information, right now.


As far as university is concerned, my first year was fairly successful. However, I’m having to resit an exam for the Computer Architecture & Systems Software module – since I struggled with my initial attempt, and ultimately failed (despite trying extremely hard, and participating in class/tutorial sessions).

I partially blame a combination of stress and exhaustion – from having to wake up at 5:30am, and spending hours on travelling,  along with the  “rapid-fire” lecture delivery style provided by tutors in cramped theatres (whilst having to cope with aching knees, and inferior long-distance vision (compared to ~10 years ago)), for my failure.

Obviously, that problem was only exacerbated by having to transcribe handwriting in poorly-chosen colours (usually orange or lime green) from dimly-lit whiteboards in “real-time”, along with listening to the lecture content – which meant that my understanding of the rather complex subjects involved was hindered.

I’m tempted to see if I can adapt some of the techniques that I developed for learning Japanese, in order to to make revision easier, and surviving lectures more bearable – although computational mathematics is obviously more of a theoretical subject than language learning, or software development are.

I’m hoping to be more successful at this attempt – since I realise that failure isn’t an option, when my future hinges on the outcome of said exam.


Although I’ve got a lot to say, and I’ve over-egged the pudding a little, I’ll stop here. I hope that gives others a good idea of what I’m doing these days, though.