Thursday, March 23, 2017

Scripting Against The Web Interface, Part 1

New Server Model

Recently I've seen several questions about connecting to the Kismet server with scripting tools - while possible with the stable/old Kismet, it's so much easier under the git-master code that I strongly recommend anyone developing something new that draws from Kismet look at runnign the git-master version instead.

The new Kismet code uses an embedded webserver (libmicrohttpd) to serve data as a collection of REST-like endpoints.

Object Data

Data is now stored in Kismet in introspectable (meaning they can be processed by the code automatically without having to know what they contain beforehand) dictionary-like (meaning they're usually structured as a collection of "key" = "value" records) objects.

The upshot of this is that they can be converted into interchange formats like JSON and exported as complete objects; Unlike the old Kismet protocol which was line-based and generally operated like a relational database:  Nested data had to be represented with multiple different server sentences, with a common key to correlate them.

By exporting complete objects, we are able to use a single request to represent an entire complex, nested entity.  By using introspectable objects, we're able to add new data to it without having to change the export code, which means plugins (and future Kismet code itself) can easily expand the data tracked for a device (or add whole new types of data), and by using a REST-like interface we can organize it simply and use common, standard protocols to access it.

Basic Interfaces

Currently Kismet data can be exported as JSON or binary Msgpack.  The format and field names on both should be identical - you can pick which you prefer by requesting a '.json' or a '.msgpack' field.  In the future, XML export may be possible, but JSON solves nearly all the problems XML would, and has simpler parsers in most languages.

Kismet also has a few special interfaces which export other data - notably the /system/tracked_fields.html interface which shows a HTML-formatted table of every named field Kismet knows about & their descriptions (great for looking up how a field is used without digging into the code), and the /phy/phy80211/handshake/[device]/[device]-handshake.pcap interface, which allows downloading a dynamically-created PCAP file.

Available Interfaces

All the currently available interfaces are defined in the webui_rest document:

which documents how to reach them, what they do, and what parameters they take.

There is a python class for handling interacting with Kismet and a collection of code doing interesting things with it at:

Part 2

Part 2 will focus on some of the specifics and provide some examples for doing interesting things, stay tuned!

A huge thanks to all who support Kismet on Patreon - if you'd like to help, you can become a patron here!

Monday, March 20, 2017

Discord (the good kind)

I've brought up a Discord server for chatting about Kismet related things: Kismet Discord

We're also on in #kismet for those who prefer IRC!

Tuesday, March 14, 2017

WPA Handshake Collection (Kismet git-master)

Another new feature in Kismet git-master:  WPA handshake collection!

Thanks to the new data format Kismet uses, it's possible to add additional complex fields to network records, trivially.  One of the fields we can add:  WPA packets!

This lets Kismet collect WPA handshakes and provide them as pcap files directly over the web ui.

Let's look for a network with captured handshakes

Kismet will highlight networks with a complete WPA handshake (or what appears to be a complete handshake) automatically.

For fun, you can also change the color of the highlighted network in the settings...

Look at the network details

The network details will show the handshake and offer a PCAP download if there is a complete handshake.  To be crackable, the handshake needs at least packets 1 and 2 or 2 and 3, and preferably all four packets of the handshake.  If you have insufficient packets, Kismet will warn you:

Internally this is stored as a bitset (where packet sequences 1, 2, 3, and 4 are bits 0, 1, 2, and 3 respectively) so scripts can easily check to see which handshake components a network has; rest_examples/ shows a quick use of this:

        if ((d['dot11.device.wpa_present_handshake'] & 0x06) == 0x06 or
                (d['dot11.device.wpa_present_handshake'] & 0x0C) == 0x0C):
            pkts = []
            for i in range(1, 5):
                if d['dot11.device.wpa_present_handshake'] & i:

Download the pcap

Download the pcap file.  You'll be prompted for your username and password you configured in kismet_httpd.conf - you did change the default password, right?

Take a look in Wireshark

You can open the pcap in Wireshark to take a look - you'll see that Kismet saves the handshake packets only, making a very small pcap file.  This is similar to trimming a much larger pcap file, only the packets required by Aircrack (or similar tools) are included.

Run Aircrack-NG

Or whatever tool you like; for Aircrack the syntax would be:

aircrack-ng -w wordlist -e UESC-N -b 0E-18-D6-9D-0D-AC 0E-18-D6-9D-0D-AC-handshake.pcap

Note that we provide the wordlist (-w), the ESSID (-e), and the BSSID (-b), and the PCAP we downloaded from Kismet.  You need all these parameters for Aircrack to detect the handshakes properly from the PCAP Kismet generates.

Let the magic happen 

Obviously this (also obviously doctored) screenshot took no time because we populated the wordlist with only one entry:  The known PSK for this network. 

Where to get it

This is in the Kismet git-master code, located at or at the Github mirror at if you want to live on the edge, and it will show up in the next major Kismet release including the web-ui and all the other new code.

Monday, March 13, 2017

Lots of new code in Kismet

Updates have been going to Twitter (@KismetWireless) but there's been a lack of content here:  Lets try to fix that!

Lots of new stuff:

  1. New object storage model.  
    Kismet now uses which is basically an introspectable dictionary structure to store all it's data internally.  Basically this means that instead of storing the data and then having to write custom output code for every type of interaction (logging, kismet client, etc), there is now a common data "blob" which can be turned into different things.
    This makes it tremendously simpler to add new features, new tracked elements, and non Wi-Fi data to Kismet.
    Even better, all the fields are documented on creation - every field in the hierarchy has a description and a human-readable name.
  2. Embedded webserver and web-ui.  Kismet now uses microhttpd to provide a built-in webserver capable of serving static (ie JS/HTML/etc content for the webui) and dynamic (REST-style endpoints with JSON data) content.
    The web-ui will be exposed to plugins so that they will be able to provide their own content to render custom data.
  3. Easily scriptable REST-style data.Instead of a custom TCP network protocol, Kismet now provides all the data via a REST-style web interface.
    This means scripts can pull data like network lists, packet rate, GPS location, battery status, everything Kismet knows, as standard JSON.

  4. Much simpler interface for non Wi-Fi dataThere is initial support already in Kismet now for some simple non-dot11 devices; wireless thermometers, weather stations, and other devices detected by the rtl433 tool for the RTLSDR, and Z-Wave home automation devices detected by KillerZee and a RFCat compatible tool, such as the Yardstick One.
    The new data structure allows new phy-handling code to plug into the existing device record and append new, arbitrary data structures, such as weather records, Z-Wave identifiers, etc
    Low-data-rate sources can even use the REST interface to submit data, which is how the RTL433 and KillerZee interfaces currently work.

More on the Web UI

The new web-ui allows much more data to be presented, as well as a huge amount of flexibility for displaying the information.  The web-ui is built on top of jquery and common open source jquery and js modules.

Using the seamless paging interface in jquery-datatables lets Kismet handle tens of thousands of devices with server-side sorting, filtering, and searching, while still being able to display reasonably on low-power devices, including mobile.

More coming

Development is going quickly on a number of new features & restoring currently broken functionality; coming soon will be the new packet capture framework, etc.  Keep an eye out for future posts with more info about new features.

What's broken

The new code is under heavy development so there's a number of things which don't currently work:  Text logging (text/netxml) and GPS logging (gpsxml) currently are disabled, filtering doesn't work, most plugins are unlikely to be happy or even compile, and various other subsystems have issues and quirks.

All of these are being addressed, of course.

Jumping in

If you want to jump in on the latest dev code, it's available from the git-master branch at either or