What's Microstumbler ?The Microstumbler project is aimed at adding autonomous network scanning capabilities to a wireless card ; that's to say, your can scan wireless networks using just your wifi card and no computer : a LCD and a simple 3-key keypad are connected to it, and it's powered by a battery. This hack is in theory compatible with all hardware that contains an ISL38xx chip : PCI and PCMCIA SoftMAC and FullMAC cards, and USB version 1 and version 2 devices. All you need to be able to is to electrically power up the device outside of a computer, and tap two easily locatable signals on its circuit board !
Is it working now ?No, the software part is not finished yet. A big missing part is full access to the baseband processor of the device, which is needed for FreeMAC too.
Microstumbler development will resume once we have FreeMAC working.
However, the hardware is working. As you can see in the photo, it can be assembled on a piece of veroboard (no SMD, QFP, BGA or other hard-to-solder parts), and only requires 4 thin wires* to be connected to the circuit board of your wifi card !
* power supply (+5V and GND) and I2C bus (SCL and SDA)
HardwareThe external board is connected to the I2C bus of the wifi card. This bus can be easily located and tapped on the device, because all the cards contain an I2C EEPROM, on which you can easily locate and solder the SCL and SDA pins. On the photo, you can see clearly that EEPROM, it's the 8-pin chip with two wires soldered to it.
The hack board is based on very common and cheap parts :
- a classical LCD module based on some HD44780 clone
- three pushbuttons
- a PCF8574 GPIO expander for I2C bus, which is used to drive the LCD and get the status of the keys
- a 24C256 I2C EEPROM to store the software run on the ISL38xx to drive all this :)
SoftwareSome tricks are needed to execute the ARM code stored inside the external EEPROM with no help from any host computer, and still making the hacked wifi card "compatible" with an unmodified one.
To understand how this works, you need some basics about what happens inside your wifi card when voltage is applied to the ISL38xx :
- some power-on-reset circuitry initializes internal ISL38xx peripherals, enables its internal ARM946E core and branches it to address 0xe0000000, where lie 4 or 8 kilobytes (depending on the chip) of bootstrap ROM.
- the ROM reads the first 4 bytes of the I2C EEPROM of the card (not that of the Microstumbler board, which is at a different I2C address on the I2C bus). If these bytes match a signature, the EEPROM is assumed to have been programmed especially for the ISL38xx.
- If the EEPROM seems correctly programmed, the ROM reads 2 bytes of padding (hmm, in fact, we're not sure this is padding, but in all EEPROMs we've seen, those bytes were always zero), then 2 more bytes which form a 16-bit little endian integer, the "EEPROM firmware size".
- If EEPROM firmware size was zero (which is generally the case on all devices except 3887-based ones), the ROM does nothing and immediately enter its main idle loop, from which several commands can be run from the host to download firmware, debug,... but that's another story.
- Otherwise, the ROM reads the indicated number of bytes from the EEPROM, plus a 32-bit word which is the CRC32 of the data that has been just read.
- If that CRC is positive, the code just read from the EEPROM is executed on the ARM. This code may eventually call functions into the ROM which acts like the BIOS of a computer (the details of this mechanism have not been completely reverse engineered yet). On the 3887-based devices we've seen, the firmware area of the EEPROM is used, and makes USB transfers involving ROMcalls. I think those transfers are device enumeration, so that the USB IDs can be programmed in the EEPROM.
The software contained in the Microstumbler EEPROM should not interfere with normal firmware loading on devices with a PCI bus (this includes USB v1) ; indeed, with these, the PCI registers are used to stop the ARM and write to its memory, with no software intervention. However, on USB v2, we'll have to simulate the ROM host interface.
If you're interested in developing this, especially on reverse engineering the baseband processor (this will also benefit FreeMAC), just drop us a mail.