Kismet and Wireless Stuff ... Extended development logs, up and coming features, and general wireless link-whorery.
Coming up on the second main release of Kismet-Newcore based code, I've realised that
plugins lacking a revision control (version matching plugin to binary) was a major
oversight and could lead to massive problems (plugins being compiled against an old
version of Kismet are very likely going to crash a newer version, if they even load).
Not wanting to break existing third-party plugins, a new revision api has been added.
If the function kis_revision_info(...) is present, a plugin is expected to return version
info from when it was compiled.
To allow for future expansion, the revision info struct contains a version field which,
when passed to the plugin, indicates what revision struct Kismet allocated, and when
returned, indicates what version the plugin can handle (ie, a future Kismet release may
include binary checksums or somesuch for versioning, and pass revision 2, but a plugin
which only checks against revision 1 would set this and return).
Almost every plugin will have the same kis_revision_info function:
void kis_revision_info(plugin_revision *prev) {
if (prev->version_api_revision >= 1) {
prev->version_api_revision = 1;
prev->major = string(VERSION_MAJOR);
prev->minor = string(VERSION_MINOR);
prev->tiny = string(VERSION_TINY);
}
}
Third-party plugins should update to include this function so that they can be
version-checked before loading. Plugins which don't include this will still be loaded,
but with warnings that they may be unreliable.
This revision API is only as granular as the Kismet release. Users tracking the SVN
development tree will have to rebuild plugins whenever something acts weird (or whenever a
svn update is done, to be safest). Some future plugin tracking mechanism might handle this,
but honestly it would be a big pain for users and for me so it'll probably stay at the
release-level control.
Recent SVN commits rework plugins to use a common Makefile so that they inherit the
compiler and path settings automatically (making building plugins much simpler).
Plugins have also been reworked to work on at least Linux and OSX (for the most part).
The compiler options have been tweaked for creating OSX shared objects, install options
fixed to work with non-linux install binaries, and notably the kismet-ptw plugin has
been reworked to use portable mutexes instead of pthread_tryjoin_np).
Third-party plugins should take their Makefiles from one of the existing plugins to
get maximum compatibility. Independently created makefiles are of course possible,
but I've done the hard work for you of making it cross-platform capable.
Initial plugin code is in Kismet SVN for using the AVR Raven USB stick to
capture 802.15.4 (base protocol for network layers like Zigbee) support.
What works:
* Capturing from the Raven (with channel hop, with standard and killerbee firmware)
* Multiple Raven support
* Reading from PCAP
* Writing to PCAP
* Basic 802.15.4 decoding
* Basic 802.15.4 device tracking
What isn't done:
* Zigbee layer data decoding
* Kismet UI
What should work but isn't really tested:
* Sending 802.15.4 data over the drone framework
Stream pipes suck. New IPC core using dgram unix sockets. Appears to work MUCH better so far.
Get it. Use it. Let me know if it dies.
On the list of things to do: Time channel change operation, introduce channelhop throttling.
So the N900 finally was announced, and a posting on the LKML wireless list by Kalle
indicates it actually uses a mac80211 kernel driver! Cheers!
If anyone has a contact at Nokia who can find a way for me to buy one of these, I'd
be extremely interested. (Anticipating the general mess of getting the N810, which
involved getting on a train to NYC and just buying one in person finally)
I'll be at Blackhat and Defcon, come to the MSF track and say "Hi" if you're there
New Spectools release to
go along with the new Kismet 2009-06-R1
release.
Spectools now supports the Wi-Spy 24i, the new low-cost Wi-Spy SA ($99).
New support for the Wi-Spy 24i SA from Metageek, plus a bunch of bugfixes for random
bad behavior that made it into older releases.
Sharkfest is here. If you're there too, come find me and say "Hi".
Talks are up at the sharkfest website
(Update: 2009-05-RC2 fixes a bug launching kismet_server, get that)
Kismet-Newcore has taken over as the main Kismet release after 5+ years
of development and is now available as trunk on svn
and as Kismet-2009-05-RC1 (release candidate 1).
What's new:
* New UI - Totally rewritten widget and layout-engine based UI with graphs, menus, variable-layouts, and an expandable design.
* New server code - Also totally rewritten, including new methods for tracking SSIDs to networks, improved and expanded logging, and simpler configuration
* Dynamic sources - Add and remove sources on the fly
* Auto-detection of source types and channels - Nearly all sources work out of the box with simply the interface (-c wlan0)
* Out-of-the-box support for Linux, OSX (using Airport cards), Windows (using CACE Airpcap cards), BSD (drivers permitting)
* Plugin architecture - Client and server plugins expand logging, alerts, protocol support, display options, etc
* Virtual network interface export - Tun/Tap on Linux allows for live packet exporting to any other pcap tool
* Plugin support for DECT phones, Spectools spectrum analyzers, and WEP cracking via Aircrack-PTW
What's next: Assuming no major problems are reported by anyone during
testing, touchups and improvements will go into 2009-xx-R1 as a full release
(probably 2009-06-R1 considering the timing) and then continued development
of new features and fleshing out missing features will continue on future
releases.
