New Wireshark USB CCID Dissector Functionality

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 I²C 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“:

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:

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.

Contributing an AT Commands Dissector to Wireshark

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).

An ISI/PhoNet-over-USB dissector for Wireshark

Whilst working on Project Iris, I have found Sebastian Reichel‘s Wireshark dissector plug-in invaluable for identifying the content of ISI packets generated by my handset.

However, it relies upon the ability to use the Linux PhoNet stack – which isn’t always possible under certain circumstances.

For example, the stack may not be available at all under the running Linux kernel version; or the USB device generating ISI traffic may be connected to a virtual machine running a Windows-based application – which is obviously invisible to the host’s network stack.

With that in mind, I’ve decided to release a modified version of the aforementioned plug-in on BitBucket (in source code form only, at present), and I’ve uploaded a sample trace file to test it against, here.

Rough instructions for building it against an SVN release version of Wireshark under Fedora are provided in the repository; as are a copy of my colouring rules for working with USB and ISI traffic.

At present, the dissector has the following features:

• Basic support for dissection of ISI/PhoNet packets encapsulated in USB framing (AKA “CDC PhoNet”) – for USB CDC_DATA class packets
• Basic support for dissecting ISI GPS and SIM Authentication packets (inherited from the original version of the dissector)
• Basic support for identifying specific types of CDC_DATA packets (works for ISI, PPP and AT/Hayes commands)

However, there are also a number of limitations and bugs – especially when compared to the original version:

• ISI packets encapsulated in Linux Cooked framing are currently unsupported
• Due to lack of heuristics, this dissector will override the PPP dissector (and the ISO/IEC 13818-1 dissector) when working with USB trace files
• The length indicator may not always be accurate – although a lot of effort was spent on attempting to make it work

When working with this dissector, I recommend either using the isi.usbtype == 0x1b display filter, or individually filtering out various other types of USB packets, in order to avoid confusion.

For curious folks, a screenshot of the dissector in action is provided:

I hope that others find this useful for something.

That aside, I’d like to thank the following:

• Chris Maynard for his USB patches (especially the CDC Ethernet one), which were useful for figuring out how to integrate with the USB dissector
• Sebastian for providing the initial version of the dissector
• William Roberts for providing the Nokia N73 that’s serving me well as my primary handset (and its USB cable, of course), and for persisting with me whilst I grappled with various stupid mistakes during learning C and C++

I wish readers a happy Christmas, and all of the best for 2011! 🙂

Reverse-engineering an IrDA/USB Multiplexing Protocol : Part 1

Last month, I acquired a USB IrDA transceiver based upon a chipset from a seemingly defunct vendor (either the S110 or S110-SG1 from Tanic Electronics Ltd.), since it was fairly cheap (just under £12), and I had a spare phone with a washed-out display and an IrDA port sitting in my drawer to test it against.

Unfortunately, it seems that not only does this chipset/device not comply with the USB IrDA Bridge Device spec, but there is also no public data sheet, which makes writing a driver for non-Windows operating systems difficult. Theoretically, the Windows driver could be used under a modified version of NDISWrapper, or a similar NDIS API/ABI implementation – although that’s suboptimal in many ways (which should be obvious to some readers).

Those caveats aside, the device works fairly well when coupled with Windows XP’s primitive IrDA stack and associated utilities…

However, being the curious sort; and since the state of IrDA and USB debugging/tracing under Windows is dire, I decided to use Wireshark for analysis, coupled with the USB tracing functionality in recent versions of LibPCap and the Linux kernel – but in order to keep this post concise, I’ll provide more details in a follow-up post.