I just announced our just-about-functional rewritten ZD1211 driver on the zd1211-devs mailing list. The driver is actually usable (and reliable!) on unencrypted networks.
A fully usable (WLAN client) driver is now well within sight, we just need to implement connecting to encrypted networks and automatic rate management.
More advanced features (such as ad-hoc connectivity, master mode, monitor mode, …) will come later. Hopefully the community will help us out there.
I was lucky enough to spend most of last week in Portland, Oregon. After a chaotic flight all day Tuesday, several of us met on Wednesday and attended a larger social meeting that evening. It was really nice meeting so many active kernel developers who were previously just names in my inbox.
For those that don’t know, wireless networking is one of the weaker areas of the Linux kernel in terms of hardware support, general usability, and excess functional code duplication.
The actual summit took place over Thursday/Friday at OSDL‘s offices. The main topics addressed at the summit were unification of the various generic wireless “stacks” that exist, how we can get more drivers ready for kernel inclusion, and how we can improve communication with vendors and the FCC.
On Friday, I met for dinner with 5 other Gentoo developers. Corey Shields (cshields), Donnie Berkholz (spyderous) and Michael Marineau (marineam) travelled up from OSU. Aaron Kulbe (SuperLag) joined us, who already resides in Portland. Henrik Brix Andersen (brix) was also attending the conference, and brought along two Gentoo users. We had a good time, and I’m going to have to visit OSL if I ever get the opportunity again.
There wasn’t much opportunity for hacking at the summit, but a few us of got together on Saturday and went through some issues. I have never worked on kernel stuff with other kernel hackers in-person before, and this was highly productive. Johannes Berg monitored the wireless traffic produced from our ZD1211 driver rewrite, and threw around some suggestions and softmac patches. Michael Buesch went through the driver source and pointed out a few bugs. Ulrich Kunitz improved the locking. At the end of the session, we had our ZD1211 device associated to the hotel network and browsing the web!
I travelled home on Sunday, just when I was getting used to the timezone. Many thanks to Greg KH who was in the right place at the right time when I realised I had misread my flight timetable (oops!). Also thanks to OSDL for sponsoring my travel and the event itself.
I’ll write more about the Linux Wireless Summit when I am back at home, but here’s a taster.
One item that was discussed was vendor interaction with the Linux wireless development community, or the lack of it. The wireless networking market is still young and lack of vendor cooperation is one of the things that has resulted in Linux’s support for wireless networking being below par.
Without direct company contacts, there’s not a lot we can do to actively improve this, other than be friendly to those who have cooperated, and be patient. With that, we identified the vendors who have been cooperative:
Please keep these vendors in mind when purchasing hardware in the future, and be sure to thank them for their contributions.
After a couple of weeks of head-scratching, I managed to get the rewritten USB-wireless ZD1211 driver transmitting data.
The code has been written for a while, and although it seems to work (the device doesn’t indicate any form of failure), the frames simply weren’t “hitting the air”.
The problem originates from the huge number of undocumented physical registers in the vendor driver. Rather than list all 200 of them in our driver source in the ugly manner which ZyDAS do so, we devised a quick one-line macro to perform the same task:
#define CR(reg) CTL_REG((reg)*4)
However, it appears that ZyDAS have some trouble counting. A snippet from the vendor driver:
#define ZD_CR1 0x0004 #define ZD_CR2 0x0008 #define ZD_CR3 0x000C #define ZD_CR5 0x0010 #define ZD_CR6 0x0014 #define ZD_CR7 0x0018 #define ZD_CR8 0x001C #define ZD_CR4 0x0020 #define ZD_CR9 0x0024
1,2,3,5,6,7,8,4,9… Our macro obviously doesn’t match the unordered nature of those low CR addresses.
After inserting the appropriate hacks into our driver, packets start flying, as confirmed by another wireless card in monitor mode.
Be warned: although we have transmit and receive working to some degree, the driver isn’t ready for users wanting to connect to networks yet.
I’m attending the OSDL Wireless Developer Summit in the first week of April, and I’m hoping that we’ll have a partially usable driver in time for that.
A bit later than anticipated, I have created initial releases for the dpfp project, a driver for DigitalPersona and Microsoft USB fingerprint readers.
My last attempt at the driver/library thing failed – I learned more about the device, and decided I should take a few steps back and work with a different design.
So far, the rewrite is working out, so I’m releasing an early version for people to try. The driver provides a simple character device interface, and the library provides a nice API to that interface. libdpfp includes an example program which you can use to scan your fingerprint to a PGM file.
This isn’t for general usage yet. There are basic instructions in the README file in the dpfp-driver distribution.
If you have questions, please don’t ask them in comments on my weblog, use the mailing list instead. Enjoy!
Mikko gave his Black Hat Europe presentation about the security issues with Microsoft/DigitalPersona’s fingerprint readers recently, which seems to have been a success.
It has gained media attention, with a few reports floating around in addition to the one I linked to recently. itnews.com.au has one of the better ones, including comments from Digital Persona. At least Mikko found one way to get through to them :)
Mikko’s slides are online here and it looks like audio will be published soon on this page. Mikko explains the lack of encryption and references the dpfp project in a few places for some of the discoveries. He also explains some of the device optics and demonstrates how the lack of encryption can be exploited to allow finger replay attacks.
After the end of this academic year, I am taking a “year in industry” before returning for a final 2 years of study at The University of Manchester.
For the industrial year, I’ve been fortunate enough to find a position with a company building a product based on open-source. The product is not yet released and everything is being kept quiet, so I’ll have to spare the details for now. The company also contributes back to the community, which makes things even better.
The company is based in Boston, MA, and I’ll be moving out there for the duration. I can’t explain how excited I am about the whole thing. The company is nice and small and has a great working atmosphere, and the product will hit the market soon after I start in September.
Hopefully we’ll have published some marketing material at some point, so that people can gape in awe at the amazing technology :)
Danny van Dyk pointed out an interesting article about Mikko’s work on the Microsoft fingerprint scanners: Forscher hacken Microsofts Fingerprint Reader.
It’s in German, here’s Google’s English translation: Researchers chop Microsofts finger print reader.
The last paragraph, in real English:
Kiviharju wonders why Microsoft didn’t implement any Encryption. Quote: “Some experts who contacted me were as astonished as I was. It would have been a good product, but in the end, Microsoft screwed it.”
I’ve been spending some time over the last few weeks hacking on a USB Wireless-LAN adapter based on the ZyDAS ZD1211 chip. There are actually 40+ ZD1211-based products available on the market so Linux support for this device has some big implications.
ZyDAS themselves produce a Linux driver which is updated semi-regularly, however the code is horrible and the driver is unreliable for many. On the other hand, it’s good that they have released a full GPL driver and have also been cooperative with providing technical documentation and flexibility on redistributing the firmware. There have been some forks which try to stabilise the vendor driver, the latest being zd1211.ath.cx, but none of these forks have been aiming for kernel inclusion.
In January, myself and Danny van Dyk started a driver rewrite project and published some initial code. Soon after doing so, I was contacted by Ulrich Kunitz, a hacker who had spent several weeks previously developing a rewritten driver. We switched over to Ulrich’s driver base and continued from there.
Unlike the vendor driver, we are taking full advantage of Linux’s IEEE 802.11 wireless stack. As the driver must do most things in software, we are also using the softmac extension which simplifies many generic operations (scanning, authentication, etc). A nice side effect of this is that when we have written the code to send and receive packets, the driver is almost complete (the other layers do the rest of the work).
Yesterday, I hacked together an initial scanning implementation and successfully scanned my local area for wireless networks. This means that receiving packets is more-or-less working – a nice milestone to reach.
Some information and links to the code can be found here. Be warned, this is useful for users yet. Watch this space for updates.
dpfp driver and library are progressing steadily, hoping to make an initial release within the next few days.
Looking for hardware hackers
I’d like to thank Joaquin Custodio for donating a Digital Persona U.are.U 4000B fingerprint reader, which completes my collection of every type of product in the range! It will be interesting to finally confirm whether there are any differences at all between the 4000B device and the MS hardware.
Actually, Joaquin sent me a total of 7 UareU 4000B readers! 6 of them are incomplete: no chassis or cable, and they have defects in the glass surface.
These standalone units are intended for distribution to interested hardware hackers. There is some persistant and flashable memory on the device (some form of EEPROM) as well as a central IC. There is also an easily accessible 15-pin interface to the board.
It’s not clear if dumping the device memory contents will prove useful, but it’s an interesting possibility. If anyone is interested and has access to the kind of equipment needed to hack on this kind of thing, please send me an email and I’ll send you a device. Joaquin also tells me that there are plenty more units available.
Encryption, round 2
I was sent the URL to Black Hat Europe‘s list of accepted papers. Particularly interesting is a paper titled Hacking fingerprint Scanners – Why Microsoft’s Fingerprint Reader Is Not a Security Feature.
The speaker, Mikko Kiviharju, made the same discovery that the fingerprints from the Microsoft devices are not encrypted at all, and will be talking about ways that the lack of encryption can be used to fool the system.
After reading that blurb, I found Mikko’s email address and sent him an email detailing my findings with the encryption control bit in the device firmware.
Naturally, Mikko was interested and is now investigating the encryption mechanism in use. And he’s quite the man for the job:
Mikko Kiviharhju has worked several years as a research scientist in the fields of data security and cryptology within Finnish government.
There’s not much to report yet, I am sending Mikko the various logs we have so that he can perform further analysis. So far, he has identified a possible bug in the encryption algorithm: 3 rows of every encrypted image are never encrypted. You can see this clearly in the image I posted last time. That is slightly weird.