Didier Stevens

Tuesday 11 September 2018

WiFi Pineapple NANO: Persistent Recon DB

Filed under: WiFi — Didier Stevens @ 0:00

The WiFi Pineapple’s recon DB (recon.db) is volatile, because it is stored (by default) in the /tmp folder.

I store my recon.db on the SD card to make it persistent (survives a reboot).

First the SD card has to be formatted:

Then the “Scans Location” field can be changed from /tmp/ to /sd/:

recon.db is an SQLite database, that can be browsed with tools like sqlitebrowser:

Monday 10 September 2018

Firmware Upgrade: WiFi Pineapple NANO

Filed under: WiFi — Didier Stevens @ 0:00

This is mainly a reminder for myself, as I don’t often update my WiFi Pineapple NANO.

Updating the NANO performs a reset.

I connect my NANO via a USB cable to my laptop. The USB cable allows me to flip the NANO to access the reset button.

I login via HTTPS 172.16.42.1 port 1471

I connect the NANO to a WiFi access point:

Once connected, I can check for upgrades:

And then perform the upgrade:

This will take several minutes, after the upgrade is performed, this dialog will appear:

From here on, the NANO has to be setup again:

I press the reset button quickly to perform a setup with WiFi disabled.

And configure the NANO, just like for first use:

I select France for Radio Country Code, because Belgium is not an option:

At this point, the setup is not yet complete for me.

I store the recon.db on an sd card, so this has to be configured:

And I also install modules:

That I install on the SD card:

Once installed, some modules need dependencies to be installed too:

 

Monday 7 September 2015

Wireshark Wifi and Lua Training – Brucon 2015

Filed under: Didier Stevens Labs,Networking,WiFi — Didier Stevens @ 0:00

I teach a 2 day training “Wireshark Wifi and Lua Training” at Brucon. More details here.

Monday 2 February 2015

AirPcap Channel Hopping With Python

Filed under: Didier Stevens Labs,My Software,WiFi,Wireshark — Didier Stevens @ 0:00

I’m teaching a Wireshark WiFi and Lua 2-day class at Brucon Spring Training 2015. You get an AirPcap packet capture adapter when you attend this class.

I made a modification to my Python program to do channel hopping with the AirPcap adapter. Now you can specify a sequence of channels with option -c.

20150201-142106
apc-channel_v0_2.zip (https)
MD5: 52169F5CB679E6C0DF1F8D47DA38F779
SHA256: 59F4BEE229F5EF5B7AF27BAF6AA972DCDC9E6A6007E8E468AE7BC7C3F1CB89DD

Tuesday 19 June 2012

_nomap, _nomap, _nomap, …

Filed under: Entertainment,My Software,WiFi — Didier Stevens @ 20:50

About three years ago I released a Python program to send out WiFi beacon frames with an AirPCap adapter. During my last holiday, I took some time to add a new feature to apc-b.py: option nomap.

When you start apc-b.py with option nomap, it first listens for 60 seconds and records all ESSIDs in finds in beacon frames. Then it starts to broadcast beacon frames for these ESSIDs, but with string _nomap appended to each ESSID.

apc-b_v0_2_0.zip (https)
MD5: 849DE418A1F325B9DC133DBE2E7CC501
SHA256: C3F28DCEFE6FF747780E384E49BB4D373BC983518C592E1BB18E8455F78E7F95

Monday 1 June 2009

Quickpost: Sending WiFi Beacon Frames with an AirPcap Adapter

Filed under: My Software,Quickpost,WiFi — Didier Stevens @ 10:29

While preparing for my OSWP exam, I came across an unpublished Python program for the AirPcap adapter. I cleaned-it up a bit and here it is: apc-b

This program allows you to send out beacon frames, a very simple way to spoof WiFi access points.

This is the command to generate beacon frames on channel 6 for a couple of ESSIDs listed in file apc-b-2.txt:

20090601-120518

And here is Kismet on my N800 capturing these beacon frames:

kismet-n800


Quickpost info


Monday 12 January 2009

A Hardware Tip for Fuzzing Embedded Devices

Filed under: Hardware,WiFi — Didier Stevens @ 21:22

Phidgets are hardware interfaces that let your computer interact with the environment. In this first blogpost of a new series, I explain how to automatically power-cycle a crashed embedded device.

I’ve been playing with Phidgets over the holiday season. Phidgets are inexpensive hardware interfaces for your computer. You connect them via USB, thus extending your machine with digital inputs/outputs and analogue inputs.

There are several aspects I like about the API-software:

  • it’s available for Windows, Linux and Mac
  • the Linux version is open-source (in a next post, I’ll show it running on my nslu2)
  • there’s support for many programming languages, even Python
  • input changes can trigger events (avoids polling loops)

One problem with automated fuzzing of embedded devices (for example a WiFi AP) is that you’ve to power-cycle a device when it crashed. And that’s a problem when you let it run unattended (i.e. overnight). So it would be handy to have your fuzzer power-cycle the device each time it detects the device became unresponsive.

This Phidget Interface Kit with 4 relays lets you do this. Connect the power supply of the embedded device to the NC (Normally Closed) connector of the relay. This way, the un-powered relay will let the current flow through the power-supply and feed the embedded device. To power-cycle the device, activate the relay for a second or two. This will open the circuit and shutdown the embedded device.

Activating a relay for a second is very easy with the Phidgets sofware, here is a Python example for an Interface Kit:

    oInterfaceKit = Phidgets.Devices.InterfaceKit.InterfaceKit()
    oInterfaceKit.openPhidget()
    oInterfaceKit.waitForAttach(10000)

    oInterfaceKit.setOutputState(0, True)
    time.sleep(1)
    oInterfaceKit.setOutputState(0, False)

    oInterfaceKit.closePhidget()

setOutputState is the actual command used to control the relay on output 0. The other statements are necessary to setup the interface.

Before OSes took full control over the input and output ports, a popular solution was to connect a relay to a Centronics printer port and control the output of the port directly from your program. But nowadays, OSes like Windows take full control over the Centronics port (if your machine still has one…), making it much harder to control from user software.

Phidgets were used (but not hurt) for my TweetXmasTree:

20090112-220040

Sunday 23 November 2008

Quickpost: WiFi Availability

Filed under: Quickpost,WiFi — Didier Stevens @ 11:01

This new video shows how a WiFi camera can be jammed by another wireless device. I produced it for my last talk at the office, illustrating the concept of availability in secure systems.

A WiFi camera, operating on channel 1, is streaming video. When I switch on an analogue, wireless babycam, you see a strong signal appearing near channel 9 (watch the SPECTRAL VIEW of the Wi-Spy spectrum analyzer, e.g. the window in the upper-left corner). After some time, I switch the babycam to a channel near channel 1 of the WiFi camera. Now the transmission of the babycam jams the transmission of the WiFi camera, and we lose connectivity.

Powering off the babycam restores the WiFi connection.

YouTube, Vimeo and XviD hires.


Quickpost info


Monday 22 September 2008

Quickpost: WiFi Antenna With 360° Servo

Filed under: Hardware,Quickpost,WiFi — Didier Stevens @ 10:17

Last weekend, I’ve been playing with a RC servo to automate the recording of wsrradial plots. Metlstorm has presented a solution to do this with Lego Mindstorms, but I present a solution if you don’t want to use Lego components.

RC servos are easy to find, and you can find many servo controllers for PCs (a typical RC servo is controlled with a PWM signal). Though most RC servos though are limited to 180° rotations, there are 360° servos on the market.

Here is a picture of my 360° RC servo, togheter with a servo controller.

The servo in action:


Quickpost info


Tuesday 26 August 2008

wsrradial

Filed under: My Software,Puzzle,WiFi — Didier Stevens @ 0:06

My search for a radial WiFi plotting tool was unsuccessful, so a coded my own: wsrradial.py.

It’s easy to record activity in the 2.400–2.500 GHz ISM spectrum with a Wi-Spy adapter and a directional antenna. Here’s my 9 dBi Yagi antenna:

One low-tech way to quantify the electromagnetic radiation around you goes like this: point the Yagi antenna in one direction for 1 minute, then turn it 45° and repeat the procedure, until you’ve completed a full circle. Use wsrradial to generate radial plots of the recording made with Chanalyzer. It’s configured by default for 8 measurements (360° divided by 45°) of 1 minute each, but command-line options allow you to choose your own parameters.

The following radial plot shows the average amplitude for each sampled frequency. The frequency is set out on the radial axis (the lowest frequency is closest to the center, the highest is the most distant), the angular coordinate is just the orientation of the directional antenna. Amplitude is hue color-coded.

This was recorded a couple of meters away from an active access point operating at 2.432 GHz. You can clearly see that the access point is situated in the upper-left corner.

The second plot generated by wsrradial shows the maximum amplitude instead of the average amplitude. I believe this plot gives a better picture of nearby transmitters.

I tried to use matplotlib to generate the charts, but was only able to generate the same charts Chanalyzer produces. So I coded my own chart plotting routines with the Python Image Library. If you know how to use matplotlib to make radial spectrum plots, let me know.

FYI: my latest little puzzle showed an average amplitude plot of the same recording, but with an older version of my program featuring an easier to code color map.

Next Page »

Blog at WordPress.com.