Author Archives: birukun

War Pi 2.0 – Pi3

This post will be dedicated to installing and configuring a Raspberry Pi 3 Model B as a War Pi device.  It will use much of the War Pi 2.0 instructions and adds in some of the updates that were made to the build after the original post. Please refer to the post Using War Pi 2.0 for general usage after completing the build.
(Updated to remove multiple WiFi sources for Pi3 – looking into functionality issues with that configuration. Pi2 works well with multiple adapters)

Requirements

  • Raspberry Pi 3 Model B (also known as Pi 3)
  • 2016-11-25-raspbian-jessie-lite installed to microSD (>8GB preferred)
    https://www.raspberrypi.org/downloads/raspbian/
  • SSH access to the freshly installed OS
  • Internet access for Pi to download updates
  • 1 x USB GPS (GlobalSat BU353S4)
  • USB Wireless adapter, capable of promiscuous mode (1 x TP-Link WN-722N 802.11 b/g/n
    or 1 x Alfa AWUS051NH v2 802.11 a/b/g/n)
  • Battery power source (2A or better preferred)

Setup

Prior to downloading and installing Kismet, there are some dependencies that have to be met.

Run raspi-config to expand the filesystem to to use all the space on the microSD card.  Refer to the Raspberry Pi documentation for further details. You can also take an opportunity to set a static IP address.

First, determine what IP address you want to use.  I selected one that is outside my DHCP range on my home network, and one I was confident would not conflict with other static addresses.
# sudo vi /etc/dhcpcd.conf           <-  make sure to type the exact file name

Add the following lines to the bottom of the file. (using your own IP addressing scheme):

interface eth0

static ip_address=192.168.0.98/24
static routers=192.168.0.1
static domain_name_servers=192.168.0.1

Save the file and reboot.  You should now be able to SSH into the static IP address every time you are connected via Ethernet.

Update the environment before adding the additional packages.
# sudo apt-get update
# sudo apt-get upgrade

Now install the following packages that are dependencies for Kismet:
# sudo apt-get install gpsd
# sudo apt-get install libncurses5 libncurses5-dev
# sudo apt-get install libnl1 libnl-dev
# sudo apt-get install libpcap-dev libpcap0.8 libpcap0.8-dev

The following command will download the most recent Wireshark IEEE OUI file for Kismet to correlate detected MACs to manufacturers.  This step is optional.
#  wget -O manuf “https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob_plain;f=manuf;hb=HEAD”
# sudo cp manuf /etc/.

Download and Extract Kismet

The version used for this build was Kismet 2016-07-R1.
# wget https://www.kismetwireless.net/code/kismet-2016-07-R1.tar.xz

Note: If you get an SSL error using wget, add  ‘–no-check-certificate’ to ignore certificate checking.

Once downloaded, extract the files, then navigate into the new directory that was created.
# sudo tar –xf kismet-2016-07-R1.tar.xz
# cd kismet-2016-07-R1/

Compile and Install Kismet

Kismet follows the standard build process, first you run the configuration script.  You may receive some warnings, but if all dependencies are met, then proceed to compile.  Compiling takes some time, and you will see warnings, mostly about unused variables. No need for concern unless Kismet does not work later, then you can go back and review the warnings, and check in at the Kismet forums or IRC to see if anyone else has a similar issue.
# sudo ./configure
# sudo make dep
# sudo make
# sudo make install

Configure Kismet

Kismet must be configured to store logs, use the correct wireless adapter(s), and use GPS.  Configuration is done in the kismet.conf file that is in /usr/local/etc. (NOT /etc)

# sudo vi /usr/local/etc/kismet.conf
(or use the editor of your choice)

The following are the parameters I modified, all other fields were left to default.

Configure Logging

logprefix=/home/pi/kismet
writeinterval=120 

Now that we have set the logging to /home/pi/kismet, we need to create that directory.
# sudo mkdir /home/pi/kismet
# sudo chmod 777 /home/pi/kismet

Configure Interfaces

Confirm the ‘ncsource’ parameter is set as follows:   (wlan0 is used by the Pi3 internal WiFi)

ncsource=wlan1

Configure GPSD

GPSD must be configured to address the GPS device, and to automatically start up when booting. Connect the USB GPS.  Confirm that the system recognizes it.
# dmesg | grep ttyUSB0

This command should display something like: “usb 1-1.5: pl2303 converter now attached to ttyUSB0”  This confirms the serial driver for the USB GPS is in place.

Edit the GPSD startup file in /etc/default.
# cd /etc/default
# sudo vi gpsd

The following are the parameters I modified, all other fields were left to default:

START_DAEMON="true"
DEVICES="/dev/ttyUSB0"

NOTE: if your GPS is connected to a different device name, substitute it as needed. The following command must be run every time the /etc/default/gpsd file is modified or updated.
# sudo dpkg-reconfigure gpsd

Configure GPS to SetTime

The War Pi 2.0 was not getting system time from the network when it is running in standalone mode.  As a result, the log files were getting written with old dates and time. To fix this, I used a script from a fellow wardriver (JD) and made a tweak or two.  The script is in a file I created called GPSTimeUpdate.
# sudo vi GPSTimeUpdate

#!/bin/bash
#extracts time from GPS
GPSLINE=`gpspipe -w | head -10 | grep TPV | head -1`
#pull date and time from valid TPV line
GPSDATE=`echo $GPSLINE | sed -r 's/.*"time":"([^"]*).*/\1/'`
#set system time to GPS time
date -s "$GPSDATE"

This script is then modified as an executable, and copied into the /usr/bin directory.
# sudo chmod +x GPSTimeUpdate
# sudo cp GPSTimeUpdate /usr/bin/.

To execute the command on startup, I added it to the /etc/rc.local file. This startup file is the last to execute on startup, for all run levels.
# sudo vi /etc/rc.local

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
printf "My IP address is %s\n" "$_IP"
fi

/usr/bin/GPSTimeUpdate

exit 0

Configure Kismet Startup

Similar to GPSD, we are going to configure Kismet to start automatically on bootup.  Unlike GPSD, there is no pre-existing file to configure so we will build one from scratch, called ‘kismet’. This will also allow us to issue stop and start commands like other services.  We are also building in a 30 second startup delay to allow time for the GPS and wireless adapter to start.
# cd /etc/init.d
# sudo vi kismet

#!/bin/sh
### BEGIN INIT INFO
# Provides:              kismet
# Required-Start:     $all
# Required-Stop:     $local_fs $remote_fs $syslog $network
# Default-Start:         3 4 5
# Default-Stop:         0 1 6
# Short-Description:     Start kismet at boot time
# Description:         Starts kismet at boot time
### END INIT INFO

case "$1" in
start)
echo "Starting kismet"
/bin/sleep 30
/usr/local/bin/kismet_server --daemonize
;;
stop)
echo "Stopping kismet"
killall kismet_server
;;
*)
echo "Usage: /etc/init.d/kismet start|stop"
exit 1
;;
esac

exit 0

Once the script has been saved, make it executable.
# sudo chmod +x kismet

Activate the script to start at the appropriate runlevels.
# sudo update-rc.d kismet defaults

Now you can stop and start the Kismet at will.  This is useful after a capture session to shut down the kismet server gracefully.

To stop kismet after booting:
# sudo /etc/init.d/kismet stop

To start again, issue the start command.
# sudo /etc/init.d/kismet start

Start Wardriving

Everything should be set up to automatically start collecting data. Shut down the War Pi (if it is not already off), connect your WiFi adapter(s) and GPS, and then add power.

If something is not going right, verify all the steps here were completed without any errors.  Leave a comment if you find errors, or have a better way to do things.

 

War Pi 2.0 – Pi2 Update

A few updates:
– ran some power tests
– got the GPS time hack straightened out (Thanks JD!)
– configured Kismet to use 2 adapters, and split the channels for faster acquisition
– set up wired ethernet to use static IP so you can access directly from your network/laptop
– running on Pi3 (will add separate post)

Power Testing

Power was tested using a PortPilot between the battery source and the War Pi 2.0.  It was used in the 2 basic configurations, and power peaked around 1.1A on startup, and then settled in to the below:

Power draw with the GPS and TP-Link adapter was around 700mA.
Power draw with the GPS and dual band Alfa card was around 1.1A.

As you can see, the Alfa card uses a bit more power, and so I have purchased a TP-Link T2UH dual band adapter to try out.

I also purchased a thin 4000mAh battery on sale for $7.  I should have bought the whole bin full of them.  With the War Pi 2.0 using the TP-Link adapter, I managed to get 4 hours of runtime.  They worked really well for short engagements.

Another user reported getting >12 hours on a 10,000 mAh supply with about 50% to spare.

GPS Time Hack

The War Pi 2.0 was not getting system time from the network when it is running in standalone mode.  As a result, the log files were getting written with old dates and time. To fix this, I used a script from a fellow wardriver (JD) and made a tweak or two.  The script is in a file I created called GPSTimeUpdate.
# sudo vi GPSTimeUpdate

#!/bin/bash
#extracts time from GPS
GPSLINE=`gpspipe -w | head -10 | grep TPV | head -1`
#pull date and time from valid TPV line
GPSDATE=`echo $GPSLINE | sed -r 's/.*"time":"([^"]*).*/\1/'`
#set system time to GPS time
date -s "$GPSDATE"

This script is then modified as an executable, and copied into the /usr/bin directory.
# sudo chmod +x GPSTimeUpdate
# sudo cp GPSTimeUpdate /usr/bin/.

To execute the command on startup, I added it to the /etc/rc.local file. This startup file is the last to execute on startup, for all run levels.
# sudo vi /etc/rc.local

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
printf "My IP address is %s\n" "$_IP"
fi

/usr/bin/GPSTimeUpdate

exit 0

Using Multiple Adapters

In order to cover more channels quicker, I added another TP-Link adapter to my War Pi 2.0.  Kismet comes preconfigured to spend a little more time on channels 1,6, and 11 as those are the most popular.  I decided that with 2 adapters, I will split the channels in half, all with equal time.  The only exception would be channel 6 – both adapters will hit channel 6.

To enable a 2nd adapter in Kismet and configure the channel hopping, you need to edit the kismet.conf file in /usr/local/etc/.
# sudo vi /usr/local/etc/kismet.conf

Find and modify the sources list as shown:

ncsource=wlan0:channellist=first
ncsource=wlan1:channellist=second

Scroll down further until you find the channel list section. DO NOT MODIFY THE DEFAULTS.  We are going to add our own channel lists, labeled ‘first’ and second’.

# added to split channels between 2 adapters
channellist=first:1,2,3,4,5,6
channellist=second:6,7,8,9,10,11

These channels are for 802.11bgn as the adapters only support that.  Save the file, restart, and be ready to process more data.  🙂

Static IP (eth0)

One of the challenges with accessing the War Pi while out and about, or even at home has been figuring out which IP address to SSH into.  With a few more quick changes, we can set a static IP address that can match your addressing scheme on your home network, or even better – use a straight Ethernet cable from your War Pi to your laptop.  This gives you the freedom to shutdown the War Pi gracefully, and avoids file corruption from removing power.  Most modern Ethernet devices support this use without a crossover cable.  No more lugging around a switch!

First, determine what IP address you want to use.  I selected one that is outside my DHCP range on my home network, and one I was confident would not conflict with other static addresses.
# sudo vi /etc/dhcpcd.conf           <-  make sure to type the exact file name

Add the following lines to the bottom of the file (using your own IP addressing scheme):

interface eth0

static ip_address=192.168.0.98/24
static routers=192.168.0.1
static domain_name_servers=192.168.0.1

Save the file and reboot.  You should now be able to SSH into the static IP address every time you are connected via Ethernet.  On my Windows laptop, I added an ‘alternate’ IPv4 configuration.  This gives me the flexibility to use DHCP on the wired interface, and also address my War Pi when *directly* connected with Ethernet.

Stay tuned as a build using the Raspberry Pi3 will be forthcoming, in War Pi 2.1.

Using War Pi 2.0

Now that you have a working rig built, it is time to put it to use.

It is up to you on how you want to go wardriving.  I prefer biking over walking or driving, so I am sharing my biking experience.  The first step was setting up my rig.  I decided that my camelback was a good candidate, and the equipment I selected was not too heavy so it worked out without having to modify it or create some elaborate platform.

IMG_20160402_153604121
Continue reading

War Pi 2.0 – Pi2 (Start Here)

As a long-time Kismet user, but new to Raspberry Pi, I was interested to see if anyone else had run Kismet on a Raspberry Pi.  I discovered a paper written for SANS about using Kismet on a Raspberry Pi Model B, and set out to use those instructions to build my own, only for the Pi 2 Model B.  The Pi 2 Model B is an update to the original Model B platform that brings a lot more processing power to the table.  Using only 50mA more power than a 1st generation Model B, the Pi 2 Model B uses a quad core processor at 900Mhz complemented by 1GB of RAM.  The original Model B utilized a single core processor with 512MB RAM.  This makes the Pi 2 Model B a much more capable device, and should be able to handle the improvements and new features being made to the Kismet package.

I was pleasantly surprised to discover that the Kismet package was being updated – the original paper covered the installation of version 2013-03-R1b.  This paper covers the building and installation of kismet-2016-01-R1.

Original War Pi paper:
https://www.sans.org/reading-room/whitepapers/incident/war-pi-34435
War Pi, written by Scott Christie, scottochristie@gmail.com

What follows is meant to augment the original paper, and document only what is necessary to get the casual user up and running.  The user is responsible for any additional research into setting up the Pi 2 Model B with installation of the OS. Continue reading

How your Internet Service Provider sets you up for failure

The cable company just installed your Internet service.  Life is good – you can stream video like you always wanted.  That is, until you notice a few days later the computer seems slower and the lights on the little black box connected between the wall and your computer has furiously blinking lights.  Eventually your computer takes forever to start up, and everything comes to a crawl…..

What the heck happened?

Internet Service providers like your cable company and telephone company often install a MODEM at your house for Internet access.  A MODEM is a simple device, it simply provides a path for data to go to and from the Internet.  In order to be on the Internet, your computer has to have an address, not unlike a house.  Here is the catch – instead of someone needing to physically drive by, on the Information Superhighway anyone is able to ‘drive by’ your address.  Not only that, but they walk right up to the front door and jiggle the handle to see if it is locked.  And they try to find an open window. When they find a window open, they climb in, set up their shop, and before you know it they are selling porn out of your living room. Continue reading