Posted tagged ‘Wireshark’

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?

Advertisements

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.

Workaround for VMAlloc errors from Linux-ZFS under Ubuntu 11.10

October 13, 2012

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.

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”http://htn.to/pRdVY8 

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 (nfc-wireshark.so) 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.

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.

University

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.

Conclusion

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.

Contributing an AT Commands Dissector to Wireshark

May 11, 2011

Whilst working on enhancing the Wireshark ISI dissector to add support for the USB encapsulation thereof, and a number of new resource dissectors, I felt that it would be useful to cleave off a generic dissector framework based upon the main packet-isi.c source file.

Whilst I never actually committed and released that generic code, I decided to hack up an AT commands dissector plug-in based upon it (plus some quick-and-dirty hacks to the main Makefile), and left it alongside the ISI dissection code in my BitBucket repository for a while…

That code was mostly written “in anger”, as a means of identifying and filtering out the uninteresting AT commands traffic from other, more interesting stuff; and it generally served its purpose well – although it was extremely rudimentary (due to unfamiliarity with certain APIs and uncertainty over the best way to handle strings of an unknown length).

For example:

  • The initial version didn’t support displaying commands text in Wireshark’s “Info” column.
  • Because I only had access to trace files containing AT commands packets where the text was wrapped in CRLF bytes, the initial heuristics used to detect these packets were rather weak.

Still, despite those limitations, I signalled my intentions on the 26th of April to contribute the aforementioned dissector on the Wireshark developers’ mailing list; and two days later, I decided to file Bug #5868.

Shortly afterwards, Chris Maynard chimed in with some suggestions on ways of improving the code – which I implemented over the course of a few hours; and I ended up submitting copies of my modified versions of various source files that the new dissector relied upon.

On the 5th of May, I managed to stumble upon a trace file containing an AT commands packet sans the CRLF encapsulation – and before I could even finish addressing the suggestions that were made earlier, Chris stormed ahead and delivered an enhanced version of the dissector, a few hours later.

As a prerequisite, an updated version of the the patch from Bug #4814 (which implements support for dissection of USB-encapsulated MPEG-2 Transport Stream packets, and generic infrastructure for USB Bulk URB heuristics support) was finally committed.

Not too long afterwards, Chris checked in his modified version of the dissector (in SVN revision 37045, and slightly updated in 37046) – which meant that my first ever upstream submission to Wireshark was complete. 🙂

(As an aside, some additional fixes have been performed; and the old Ethernet CDC dissector was finally committed last night).