SnoopPi: A Raspberry Pi based Wifi Packet Capture Workhorse. ( Part 1/n for SnoopPi)

Prologue: Its been two months since the the HackChip died. Still no signs of the replacement being shipped..Anyway wait we shall. In the mean time back to Packet Bass Fishing (i.e.:packet capturing)

The family:

The elder one: DropPi.

So the DropPi was originally a companion to the HackChip , its purpose was to be left after you leave the site. Its a RaspberryPi Zero W with my favorite usb dongle the Alfa AWUS036NEH. I call it the cockroach. #TrevorForget
It used to run the stable kismet package but I have since upgraded to the bleeding edge new core Kismet. (not for the faint of heart , but if you feel adventurous definitely worth exploring. Just use a different miniSD card so you can always go back) Given it has only one interface (the Alfa dongle) that supports monitor mode, the DropPi will have to channel hop to cover the 2.4Ghz range. Which technically is not a problem cause well its not meant to be a capture all. Rather than saving the data locally it passed the captured data to a remote Kismet server via the wlan0 (onboard wifi chip) connected to a network. This is pretty simple to achieve. Instead of running a full-blown kismet instance you would just use the kismet_cap_linux_wifi tool.

$ /usr/local/bin/kismet_capture_tools/kismet_cap_linux_wifi \
 — connect 192.168.1.2:3501 — source=wlan1:name=remoteDropPi

This allows the DropPi to connect to a remote Kismet server and pass on the data. (the remote server has to be accessible) If you have read the original DropPi post, this isn’t an issue for the DropPi cause it already has an openVpn client that connects to a remote server.

The Big Dog: H.I.T.B

I have written a previous post of on the H.I.T.B wifi platform so I will keep it simple here. One change I have made is setup an AP on the onboard wlan0 which is Broadcom chip that doesn’t support monitor mode but does support AP mode. The main reason being I wanted the ability for kismet remote captures to be able to connect to the H.I.T.B and feed data to it. By setting up an AP , the remotes can connect as a client and feed data back, allowing the H.I.T.B to get ever more coverage of a specific site. (this is more for demo purposes than anything else, cause the H.I.T.B already has 26 interfaces I don’t think there is much it will miss, but I can also easily imagine a scenario where you are trying to figure out the wifi situation in a large area)

The new kid on the block: SnoopPi

So what the SnoopPi? Well lets see, DropPi= very mobile , can runs on a mobile battery but limited coverage, H.I.T.B= Not very mobile, but massive coverage and decent computing power. So DropPi has 1 interface, H.I.T.B has 26. Its like having a easy to go around town small car and a in-case-shit-happens Humvee in the garage. The problem is that this family is lacking a workhorse. The one that gets shit done. A SUV for packet capturing. Thats where the SnoopPi comes in. The SnoopPi has 3 interfaces, 2 Alfa AWUS036NEH and 1 AWUS052NH. Well why? The idea is simple, if you want you can run all three of them on the 2.4ghz spectrum and use the channel bleed over to capture most packets. But you can also have them hop to cover both the 2.4ghz and 5ghz spectrum. The AWUS052NH is a dual band so this works in our favor. So depending on the situation you can switch up how to look around the wifi landscape, and by using a mobile battery like the OmniCharge the SnoopPi can easily be deployed in a mobile way. Technically the powered usb hub is a 12v hub so you should be able to power it off a cigarette outlet in a car.

SnoopPi the setup: The basic setup is pretty simple.

Hardware:
1. Raspberry Pi 3
2. 7 Inch TFT (I used the waveshare 7 inch, will explain why later)
3. Alfa AWUS036NEH x 2
4. Alfa AWUS052NH x 1
5. Aukey USB 3.0 Hub. CB-H19 ( 4 port + 3 power only ports)
6. Bluetooth keyboard x 1
7. 1 hard case.
8. Optional: OmniCharge Mobile Battery.

The setup is pretty much the same as “Hey whats your wifi? Form holder.” As a matter of fact using a usb power port has become my favorite way to power a RaspberryPi while avoiding multiple cables running wild. The image below shows the setup.

You gotz da power?

The black lines are data lines (i.e.:regular usb connections) The red lines are power-only connections.

Now the key to making this whole rig somewhat mobile is the OmniCharge Mobile Battery. I got one when they were doing a crowdfunding on Indigogo and have been using it for a while. Despite’s its size its a 10000mah battery, but the upside is it has a regular AC port. Technically it for using it with a laptop, which one could argue the SnoopPi is , so we good.

Here is the reason why I went with the WaveShare 7 inch display, you can power this display with a 5v usb connection. The manual says you can use the on-board usb of the Raspberry Pi too, but the Alfa cards are power hungry devices and I wanted to avoid any stress on the Raspberry Pi, besides the usb-hub I chose already has enough power-only ports. Also because have no plans to run a full desktop , I didn’t connect 2 mini USB cables , 1 for power and 1 for touch input, I just used 1 for power.

The orange Alfa Awus AWUS052NH is one power hungry monster, so I used one of the power ports on the usb hub to feed the extra power it needs using the y-cable that came with it. Plug the thicker cable (data connection) to a regular usb port and the thinner smaller connection to a power-only port.

Stuff I learned . (some of it “again”, trust me its not just you , we all forget shit and go over to StackOverflow or Google to check”)

1. Paring a bluetooth keyboard.
Turns out this is somewhat cumbersome on the Raspberry Pi. The pairing process is pretty simple:

i). Install the necessary stuff (apt-get install bluetooth, bluez ..etc etc)
ii). Run the bluetoothctl tool and find and pair the keyboard.

$sudo bluetoothctl
$[bluetoothctl] agent on
 $[bluetoothctl] default-agent
 $[bluetoothctl] scan on

(wait for keyboard to show up , keyboard has to be in paring mode. If you can’t figure out which one is which use a laptop with a desktop manager and try to pair it, most bluetooth managers will show you the bluetooth address of the device)

$[bluetoothctl] pair [Bluetooth Address of keyboard]
 $[bluetoothctl] trust [Bluetooth Address of keyboard]
 $[bluetoothctl] connect [Bluetooth Address of keyboard]

iii). Now you would imagine that this connection would stick. Wrong…you need to add the following line to your /etc/rc.local

echo “connect [Bluetooth Address of keyboard] \nquit” | bluetoothctl

After a reboot just give it a couple of seconds for the keyboard to connect, or turn off your keyboard and turn it back on. Hit enter a couple of times and the keyboard should be connected to the RaspberryPi

2. Avoid wpa_supplicant to use the usb adaptors to connect to an wifi-AP. Since the main purpose of the external usb adapters are to use them in monitor mode , I didn’t want them to connect to an AP. Because this will cause issues with kismet. The easiest way I found out was to modify the dhcpd library. The file you want to edit is:
/lib/dhcpcd/dhcpcd-hooks/10-wpa-supplicant

in the code there is a chunk of code :

if [ “$ifwireless” = “1” ] && \
 type wpa_supplicant >/dev/null 2>&1 && \
 type wpa_cli >/dev/null 2>&1
then

modify this to :

if [ “$ifwireless” = “1” ] && [ “$ifwireless” != “wlan1”] && [ “$ifwireless” != “wlan2”] && [ “$ifwireless” != “wlan3”] \
 type wpa_supplicant >/dev/null 2>&1 && \
 type wpa_cli >/dev/null 2>&1
then

Now make sure that you are telling the right wlan[Number] , wlan0 should be the on-board, but I have found out cases where this isn’t true. If you are not sure , just use airmon-ng to figure out which interfaces are the external. (I’m sure there is an unix-guru way of doing this, but airmon-ng is sooo much simpler)

Which kismet ?
So the new core bleeding edge kismet master on GitHub is very cool, thats what I run on the H.I.T.B (yea its not the fully fledged software it aims to be , but I’m a hacker I like new “stuff” and tinkering, and I ain’t afraid to try)

However for SnoopPi I decided to go with the Stable version (i.e.: apt-get install kismet) . There is some unique nostalgic feeling that the older kismet gives me, makes me feel hackerish I guess. It also is nice for me to be able to compare the two versions side by side.

So there you have it , SnoopPi the new addition to the Packet-Bass-Fishing arsenal.

Epilogue: TP-Link for a long time was a favorite of mine. Not anymore , the newer stuff is just too fineky , weird to use for “us.” Sad to see a great company go “legit” and loosing its appeal. The whole v.1 vs v.2 of the TL-WN722N is just sad and frustrating. (if you don't know, only the v.1 of TL-WN722N can be put into monitor mode) and I have a couple of them and even v.1 is unstable to be of real use. They have a pretty design, but I’ll stick to my Alfa cockroaches. #trevorForget.