I’ve just complete work on a project I’ve had in mind for a while now, a warwalking case. As you can probably guess it involves fitting a war-drive rig (car excluded) inside a carryable case.
As I had one going spare I started off with a fairly standard CD carry case:
Bit of fun with a hacksaw and foam later and theres an alcove for my external Alfa wireless card:
The grooves cut into the central partition create secure compartment for my Acer AA1, both in transit and whilst running, (not sure about cooling ventilation yet, still a work in progress):
Finally, a groove in the edge of the case allows for external access for the omni antenna and GPS reciever. Complete kit below:
Now it’s complete I’m not sure whether this kit will actually get used though. It looks a bit suspicious and is now commonly referred to as ‘the bomb’. Not sure I’m looking forward to explaining to an armed response unit that I’ve got nothing more dangerous in the case than an up to date Metasploit install.
I’ve spent the day adding some additional functionality to my GPS mapping proof of concept (original here).
The second release, kismet2gmapstatic-0_2.py, changes the scripts output to wrap the Google maps API call in a self contained HTML page, and contains multiple map images to mitigate the URL length limit.
The third release, kismet2gmapstatic-0_3.py, builds on the HTML framework and includes additional information on each mapped access point: SSID, channel and available encryption options.This will likely be the final release of kismet2gmapstatic in this form, the code has grown organically without any real planning and as a result is a hideous mess, but as a PoC I feel it has served it’s purpose. I still have several ideas and additional functionality that I would like to implement, so watch this space for similar tools in the future.
Unsurprisingly given some of my previous posts, the initial use of the GPS device is to increase the power and data gathering ability of my war-driving rig for wireless security assessments. Therefore I was a little disappointed when I struggled to got the device working out of the box with gpsd, which is pretty much the de-fact0 standard in gps software.
After much hair-pulling, command-typing and Google-searching I found a series of articles and forum posts stating that the BU-353 works fine with gpsd-2.37 (sorry, can’t find links, but thanks to all those who put the information out there). A quick download and compile later and everything was good.
I don’t have prior experience with GPS devices for comparison, but I’ve got no regrets with the purchase. The accuracy seems very impressive, and the data logging ability when coupled with wireless sensors is equally so.
I’m still following my recent interest in wireless networks and devices. In the past month I gained a USB gps reciever (which I forgot to write about, may have a short review shortly). After adding gps capability to my wardrive setup I proceed to scan the local area, then hit a brick wall. There appears (could be my google-fu is failing me) a lack of available tools to meaningfully use the captured data.
After a lot of digging a stumbled upon this script, designed to parse the output from Kismet and generate a .kml file to import into Google Earth. Unfortunately, I’ve been unable to get this to work as Google Earth complains when opening the file. Could be a version issue so your mileage may vary, if anyone does get it working please let me know.
The PerryGeo code did however provide an excellent foundation to utilise the Kismet log file and generate different output. To this end I have released a basic proof of concept script that generates a static map via the Google Maps API. If you want to do anything similar, or want to extend or modify my image code I found the Google documentation to be invaluable.
To the tool itself, starting a disclaimer:
This tool should not be used for illegal or malicious purposes. It was created to visualise network locations and implemented encryption technologies, in an effort to enhance previous analysis of wireless network statistics.
For each discovered access point, the script places a marker on the map, colour coded to level of encryption: Open access points are green, WEP encrypted access points are yellow, whilst WPA encrypted APs are red.
The Google maps API appears to have a limit to the length of URL that it is able to support, as a result the script limits the plotted APs to the first 50 in a given Kismet xml log file. This should be sufficient for site surveys, but is less useful for mapping the results from a wardrive trip. I haven’t manage to locate any firm documentation on this limit, if anyone is able to shed any light or knows a workaround I’d appreciate a heads up.
Below is an example of the tools output (actually, it just outputs the URL, which in turn requests google create the image). The image is created from a subset of data collected during a drive around the Angel of the North.
This is still very early days for the tool (started coding 24hours ago) so any feedback, issues or feature requests would be appreciated. Download available here: kismet2gmapstatic-0_1b.py