Repackaged CryptoRF/LibNFC Example Code

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 “libnfc.so.0” 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

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

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.

Notes on installing the MDaemon BlackBerry Enterprise Server component under Windows 7

Recently, I decided to try and install a demo version of Alt-N’s MDaemon Messaging Server for Windows, out of curiosity.

It seems that the main server component installation completes successfully – although I didn’t try to use any of the newly-installed components, immediately.

Unfortunately, installation of the optional BlackBerry Enterprise Server component fails with:

According to a page on the FalconView Wiki; and an MS KnowledgeBase article, this error relates to a permissions issue on a non-existent directory (C:\Documents and Settings\NetworkService\Application Data\Microsoft\Protect).

Under Windows 7, the equivalent directory is supposed to exist at C:\Windows\ServiceProfiles\NetworkService\AppData\
Roaming\Microsoft\Protect – but I had to manually create it, after gaining permission to access C:\Windows\ServiceProfiles\NetworkService\.

It seems that a similar error that occurred whilst trying to install a slightly older version of MS SQL Server under Windows XP, has also been reported.

I also ended up uninstalling some existing MS SQL Server 2008 components that were supplied as with other software.

Afterwards, I re-launched the installation process, and got a little further – only to encounter another error:

It appears that rebooting Windows is the favoured workaround for this issue (that apparently relates to a (Microsoft.SqlServer.Setup.Chainer.Workflow.
ActionExecutionException) being triggered)  - which worked for me, in this scenario, and meant that I was able to successfully use the product.

Unsurprisingly, the official product support KnowledgeBase has limited information regarding installation failures.

That said, others have reported seeing a related error under Windows XP – despite using an Administrator account; and it appears that the problem also occurred with earlier releases of MS SQL Server.

Anyway, I hope that this belated, short post is vaguely useful.

Workaround for VMAlloc errors from Linux-ZFS under Ubuntu 11.10

Earlier on, today, I decided to stress-test the “ZFS on Linux” project’s drivers under my Ubuntu VirtualBox VM, by creating a new ZPool spanning two virtual SATA hard disks, and trying to extract a Wireshark SVN source archive within it.

However, after my initial attempt at extracting the archive seemingly stalled, and discovering that the kernel logs were full of “vmap allocation for size 4198400 failed: use vmalloc=<size> to increase size” errors, I ended up reading a page on the MythTV Wiki detailing a similar problem.

Unfortunately, the suggestions provided there weren’t entirely up-to-date with the configuration of GRUB in that version of Ubuntu – although they provided some useful recommendations for identifying a remedy for this issue.

Finally, after searching for “3.0.0-14-generic” within ”/boot/grub/grub.cfg”, appending “vmalloc=400M” to the line beginning with “linux /boot/vmlinuz-3.0.0-14-generic“, and rebooting the VM, I was able to successfully unpack the archive, and build the software itself.

Obviously, this is just a temporary method that will probably get broken when upgrading the GRUB, or Linux kernel versions – but I thought that I’d quickly share this workaround, for future reference.

A renovated PureDarwin XMas disk image

Recently, I spent a few hours on modifying the “PureDarwin XMas” disk image, in the hope of trying to boot it under VirtualBox, and QEMU, with mixed success.

The modifications themselves entailed the following steps…

• Using an installation of Mac OS X 10.6 under VirtualBox to mount said disk image
• Extracting its primary partition from the rather Byzantine partitioning scheme in use using Disk Utility’s new disk image creation feature
• Re-partitioning the original image to use a standard x86 MBR partitioning scheme, and creating a single partition
• Mounting the newly created partition image using Disk Copy, again
• Copying the raw sector contents of the mounted partition image to the newly created MBR partition, using “DD”
• Installing the Chameleon v2.0-RC4 r684 bootloader

Under some versions of QEMU, it seems to be possible to boot it as far as a working shell, where the startx command can be issued, in order to launch a customised version of WindowMaker:
 However, under VirtualBox on my AMD Phenom II-based HP G62 laptop, booting fails at:

If I attach the modified image to a Ubuntu virtual machine, copy its raw sectors to an SD card, and reboot my laptop with it inserted into a USB card reader, I can also attempt to boot it, and launch WindowMaker with some success:

Unfortunately, the ancient version of XFree86 supplied in the image doesn’t support the AMD graphics chipset in this G62-series model – so graphical corruption, similar to that seen when trying to boot certain old Linux distributions on incompatible hardware can be witnessed.

There is also an unresolved glitch where the image fails to reboot, under certain circumstances, seemingly due to some issues involving file system drivers, and replaying the volume journal during mounting. This problem may also be encountered when trying to boot it from a locked SD card, for the first time.

Anyway, for others wishing to try it, I’ve uploaded a copy of the modified disk image to Google Code.

Let’s Try RTL-SDR! – Part 1

Recently, I received a device that was originally marketed as a USB DAB/DVB/FM receiver, containing a chipset compatible with the utilities from the RTL-SDR project.

It cost £17.50 (roughly €22.42/2159円/US$27.45, according to WolframAlpha) including free shipping from the US.

What’s in the kit?

The receiver that I ordered was supplied with only a remote control, and a stubby antenna with a magnetic base. No CD-ROMs, or user manuals were included.

About the hardware

The eBay listing page claims that it contains an Elonics E4000 tuner IC, and a RealTek RTL2832U DVB-T demodulator IC.

lsusb -v Reports:

Installing RTL-SDR, and associated utilities

Download and run the build-gnuradio script, as recommended by Andrew Back:

At this stage, the script will request elevated privileges, in order to search for prerequisite packages using the system package management utilities.

Since the disclaimer warns that the process may take a long time, I’d recommend obtaining one’s favourite beverage; ensuring that the PC used has a sufficient amount of free disk space, and is well-ventilated (if using a laptop), to prevent it from potentially overheating, and unexpectedly shutting down; and searching for something else to do in the meantime…

For some reason, the Checking for package python-gtk2 step seems to take an unusually long time on my laptop; and temporarily stopping the script yielded:

It seems that despite my best efforts to prepare things in advance, I ran out of disk space at that stage:

Eventually, I resorted to running apt-get clean && apt-get autoclean, and moving some large files to an external disk, in order to free 1.5GB of 9.4GB; and re-ran the script, with more successful results:

It seems that on a 64-bit Ubuntu installation, a full instance of the script’s working directory (containing all source code, and binaries) is about 520MB in size.

Notes on AirProbe installation

For readers wishing to install AirProbe using the instructions on the project’s Website, I recommend running sudo ln -s /usr/local/include/gruel/swig/gruel_common.i /usr/local/include/gnuradio/swig/ && ldconfig, after installing GNURadio, in order to avoid some frustrating bugs in various build scripts related to missing “Gruel”, and “SWIG”-related files.

Testing the result

Since this post is becoming rather long, and I’m unsatisfied with the content that I planned for this section, I’ll follow up with a second post related to testing the software post-installation, soon.