WPA Bruteforce test

Just a side note, i’ll be getting to the crackers i wrote later on – but been testing WPA update since couple of days now on WPA Handshakes and the cracker is a success.


This is a single core task – but have a Distributed Task for GridMan in place already.
The cracker goes through all WPA handshakes that i have sniffed and tries to crack them with a wordlist or a bruteforce generator.


Above a dump from a modified version of a handshake stripper, i take the airmon dump file and strip all WPA Handshakes that were found for a crack-all-at-once approach.

Ok, let’s find out what’s sitting there and let me tell you that i hate Linux support for WiFi – it’s just a mess if you need to do things quick, but as i’m left now with a Raspberry PI on the balcony that has Kali installed, there’s no other option around.

Couple of command line entries and we’re in.



Now that we know we’re in, let’s checkout the AP.

Zrzut ekranu 2016-08-06 o 22.58.04

Aha! A login form, i can bet the owner didn’t even change admin password.
admin/admin is the default setting for WR340g.

Zrzut ekranu 2016-08-06 o 22.59.05


Fuzzing continues

Just made a simple fuzzing strategy that shoots random characters on arguments for binary. I am testing this on my MacOSX – and it seems like it works ūüėČ
Zrzut ekranu 2016-08-05 o 23.36.23

The tool itself is dirty coded yet, however fuzzing Rez with argv0 gave

SIGSEGV 11 Invalid memory segment access (ANSI)




Recently i turned my attention to security, but this time i took a peak into what’s called Fuzzing.

Long story short, fuzzing is mainly brute force vulnerability detection and has a lot of categories. Take a look here. What caught my attention is fuzz testing Web applications and local binaries (mainly black box /grey box fuzzing).

I am total noob in this area, never tried it and never seen a fuzzer doing a good job – however interested in this area i have a low power distributed approach idea somewhere behind.

Just started to read a great book on the topic check it out.

As always, there are some basics that i’ll be focusing on at the start.

  1. Fuzzing arguments passed to suid binary, you just randomly generate a set of characters and put them into binary arguments to discover eventual input handling issues.
  2. Fuzzing WEB applications, this is a bigger topic however here i would like to focus mainly on SQL injection discovery, directory traversal, and POST/GET argument fuzzing.

The whole fuzzing area is wide but i have decided to pick up two pretty major destinations to see if i come up with something interesting. Ideally i would like to be able to write a vulnerable binary, fuzz it and get back with some results. Finally i am thinking of getting this stuff distributed, as it is known fuzzing can take some time Рit would be good to pack it all up with GridMan.

So let’s treat this as an intro, i will be posting in Security/Fuzzing area some updates as i go through the learning curve.

Fingers x.

ESP8266 – WIDS – “Spooky”

Okay this is both #ESP8266 and #Security.

When i first got my hands on the ESP8266 i was curious how much can be done with the chip in terms of security. Knowing that the chip can go ‘monitor’ mode it was clear to me that first thing i’ll code would be the Wireless Intrusion Detection thing running on a 5v low power chip. At that time i ordered something what is called #NODEMCU and the fun started.


The chip itself is capable of running a callback on ever packet it receives with a function:

static void ICACHE_FLASH_ATTR handle_pkt(uint8_t* buf, uint16_t len)

There is actually an official “Sniffer” PDF document by Espressif, google it for more details.

So the way Spooky works is simple. It captures packets within BSSID that is your local home Access Point. When a packet is received, it scans through 802.11 to find the source and destination. If Source or Destination is not listed on the ‘trusted mac’s’ list then it adds this traffic to a list that is then sent out to your Gmail account every hour.

So long story short, Spooky monitors for a non-trusted traffic (that has to be defined by user) and reports it when found via E-Mail, see below for example.

A Spooky generated e-mail notifying of unknown traffic (this is an unknown device authenticating on my AP)



And a simple configuration page with trusted devices added


static void ICACHE_FLASH_ATTR handle_pkt(uint8_t* buf, uint16_t len)

So how is this all programmed?
Firstly all is coded in C with Arduino IDE – it’s just great we can code chips with C. It was my first adventure with chip programming and i was very happy i didn’t have to lear myself some ASM or other script-kiddie language around.

The code itself is very easy, ESP8266 has a file system (SPIFF) so the configuration is loaded/stored directly from that file. I could easily skip writing/reading from EEPROM thanks to this.

All these Web server things are built in and available as ready to use classes so i will not go into details with that.

The Sniffer Callback function has to be very quickly executed or WatchDog will restart the chip, so there is no room and space and time for a lot of work to do. Knowing that i am only doing quick 802.11 inspection to find out RSSI, BSSID, Source, Destination and packet type in accordance to the below 802.11 header


First i find out the packet type by defining them as below:
Zrzut ekranu 2016-08-04 o 10.58.11

Then i¬†filter out all Beacon and Probe request type of frames as they fly around and Spooky will identify them as unknown traffic. So i’m looking only after DATA and MANAGEMENT type frames that are Directed towards user selected Access Point BSSID. This is how i get only the interesting packets out of the chaos around.

Next i read out Source / Destination by looking into ToDS FromDS fields Рthese are swapped around in regards to the frame type, so be careful how you read them. An example below:

Zrzut ekranu 2016-08-04 o 10.57.11

Then we get the RSSI of the packet, this is easily taken from ESPRESSIF RxControl header within 802.11.

At this moment Spooky knows:
– What is the Packet type
– What BSSID is packet traveling within
– What source is this packet coming from
– What destination is this packet going to

Now having all above and list of trusted MAC addresses, it is easy for Spooky to identify wether a traffic directed within a defined BSSID is trusted or non trusted.
Anything coming from/to a MAC address that is not on the trusted list and having BSSID as defined by user is considered untrusted – and Spooky will email you the details.
All the rest is trusted so Spooky will ignore the traffic.

So the idea of using Spooky is quite simple:
Whenever you get an untrusted traffic notification from Spooky – you either block the MAC address on your Router (if you can’t identify it) or add it to Spooky Trusted MAC’s list (if you know the MAC).

Thanks to this you keep your AP safe and you are notified of unknown events. The word Notified is important because you don’t have to check your AP logs (who does it anyway?) ¬†for intruders and you can respond to events immediately. And yes i know routers can be configured to block untrusted MACs, but i never used that option.

Spooky went into release and some of the users even made a small TicTac version of it.


I expect to make some 3d printed cube for spooky in free time. If you are interested in the code i will be posting it shortly.