PC/SC NDEF reader/writer for NFC forum type 2 and type 4 tag for Linux

Projects
1

Here is my latest effort to fully exploit the Apex under Linux.

This little utility reads and writes NDEFs to and from NFC forum type 2 and type 4 tags using the PC/SC stack. Examples of type 2 tags are the xNT or flexNT, and examples of type 4 tags are the flexDF2 or Apex running the Vivokey NDEF applet.

and as always, the pre-built Debian package is here:

I wrote it for 3 reasons:

  1. The current crop of NFC tools for Linux is very poor and doesn’t work terribly well with type 4 tags. nfcpy in particular, despite being one of the least sucky Linux tools for non-Mifare stuff, doesn’t deal with them well, if at all.

  2. Almost all existing Linux NFC tools work with libnfc. I wanted one that works with PC/SC.

    The problem with libnfc is, it doesn’t support as many readers as libccid. Also, unlike PC/SC, you can’t share readers between several applications. That’s why all the stuff I code works with PC/SC: I can run all the NFC tools I’ve made, as well as others - such as the Finnish application to read my ID card for example - concurrently.

    With libnfc, I always have to stop everything else just to do one itty bitty job with the libnfc tool I need to use, then I have to restart everything and reconnect my reader because it’s been left all weirded out by libnfc that didn’t clean up before exiting. Annoying…

  3. I believe I’ve discovered a bug in the OpenJavaCard NDEF applet (which is what the Flex NDEF applet deployed on Apex implants is almost a verbatim copy of - @Amal hear hear): when reading memory chunks, if the amount of data requested per chunk is over 58 bytes, the applet returns 6700 (SW_WRONG_LENGTH) despite the CC advertising R_APDU sizes of up to 128 bytes.

    I’m pretty sure it works with most cellphones because they probably don’t request too much data per chunk, but it’s fragile: in theory, they could very well request up to R_APDU - 2 bytes per chunk, and then the read would fail. In fact, maybe it already does with certain cellphones or non-Android cellphones. So, worth looking into I think.

    But anyway, with the NDEF applet as it is today, my little tool is the only one that works properly in Linux to dump NDEF data from T4 tags, because it works around the bug by overriding the CC’s R_APDU’s value and using 60 bytes instead.

Hopefully you’ll find this tool useful.

5 Likes
2

I see our repo is behind on commits.

Since we haven’t made any significant changes, I’d be okay abandoning our repo and working directly with the master branch above. If you submit a pull request to fix this issue and they merge it, we can republish the updates to fidesmo.

3

The thing is, I looked at the code of both the OpenJavaCard NDEF and your fork, there’s only one place where it returns 6700 for a ReadBinary, and I see absolutely no reason why it would barf on larger chunk sizes. Especially a weird value like 58: I might expect a signed variable to roll over at 128 or something, but 58 doesn’t correspond to anything.

And yet it does.

I’ll have a go at debugging it when I have a minute.

1 Like
4

I added support for NFC forum type 2 tags to the tool (e.g. xNT, flexNT). And so, inconveniently, I had to rename it because it doesn’t just deal with type 4 tags anymore. It’s now called “PC/SC NDEF” instead of “T4T NDEF” and I updated the first post of the thread to point to the new repo and debian package.

Sorry for the mess…

3 Likes