Monthly Archives: February 2006

ZD1211 wireless hacking

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

More fun with fingerprints

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.