Mooltipass, libusb and paracetamol

As I’ve already said, I love my Mooltipass. It is a great device, but it is missing one major thing. Integration. So far it only works in the way it was designed, with Chrome. I have a bunch of usages that don’t have any web interface, so this is a little frustrating to me.

Towards the end of April, I dusted off my “Tiny Little” library template and started writing a native lib to communicate with the mooltipass. Today, I finally have it talking.

Now, I won’t pretend that it took the entire time. Of course I’ve got a full time job. I also enjoy doing other things in my “free time”. The current line-count is on 815. That’s including comments and whitespace. So not a huge amount of code by any means.

It has caused me no end of pain though.

I decided that libusb was a sensible solution as I could “easily” communicate with a USB device without caring too much (or so I thought) about which OS I was running on. The documentation provided on the libusb website seemed comprehensive and helpful. Until I started using it. I assume that there is some kind of previously expected knowledge but when trying to work out the correct order to call libusb functions in, it seemed to me that it would omit them sometimes. I eventually found a few by trawling through vaguely relevant forum threads.

At this point I’m still only using synchronous communication with the mooltipass device, which for my test case (device status) is acceptable. For retrieving credentials you’re almost certainly going to want an asynchronous interface. For the synchronous case, this appears to be the correct sequence (semi-pseudocode):

 if(libusb_kernel_driver_active(handle, 0))
    libusb_detach_kernel_driver(handle, 0);
 
libusb_claim_interface(handle, 0);

libusb_interrupt_transfer(handle,
            LIBUSB_ENDPOINT_OUT | 2,
            buffer, size, &size, 0);

libusb_release_interface(handle, 0);

if(detachedKernelDriver)
    libusb_attach_kernel_driver(handle, 0);

My first major mistake, which I discovered only far too late, is that not all OSs are created equal. I had been prodding the mooltipass with a small sample program I created, running on my MacBook, simply because it was the first computer I got to. I could not get it to work at all. If I called libusb_claim_interface, it returned LIBUSB_ERROR_ACCESS, claiming that I didn’t have the correct permissions to access the device. It even did this if I tried to run it as root. If I ignored the claim, and went on to attempt to send the data anyway, I would get LIBUSB_ERROR_NOT_FOUND, which wasn’t even documented as a valid return value for that function. Clearly it wasn’t having it.

When I changed to working on my Linux netbook, everything worked a little bit smoother. I still got a LIBUSB_ERROR_ACCESS when attempting to claim the interface, but I could set the udev rule to  give me access. This uncovered some differences with how Linux distros handle groups but I got it working. I also discovered that I had to detach the kernel driver, as I believe the OS doesn’t allow you to attach to something that it’s attached it’s generic HID driver to.

So, what does this mean? Well, right now, it means I can find the current status of a connected Mooltipass. That isn’t particularly great. Soon, hopefully I will have the ability to retrieve and store credentials on the device. That is when it gets a bit more interesting. My first proof of concept, I think, will be to attempt to hook it into slock, which I’m currently using on my netbook. Once that works, maybe I’ll see what other things I can hook up to have mooltipass support.

And if anyone wants to help and contribute, please give me a shout!

Leave a Reply

Your email address will not be published. Required fields are marked *