This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

802.11 decryption not working properly

0

Hi all, I am working on some pentests in my home network using WPA2 and I am trying to sniff the traffic between the clients and the AP. Capturing data works like a charm with Wireshark, but WPA2 decryption seems not to work at all. Here is what I've done so far:

First of all, I sniffed some traffic I generated. To be more specific, Wireshark was running on one computer with wireless card in monitor mode (A), while I used another computer (B) to authenticate into the home network and after it received config from DHCP, I accessed the router's web UI.

My goal: In short, expected result of my work is to see some HTML code decoded from captured data.

Distance between devices A and B was less than a meter, while the AP was approx. 10 meters away, so I guess there was no communication left unheard. Since Wireshark sniffed a number of beacons and probes from my network and occasionally from some neighbors' networks too, I also guess the monitor mode works correctly.

Having traffic recorded as described I found the 4-way handshake packets. Wireshark recognizes them correctly and describes them as "Key (msg 1/4)", "Key (msg 2/4)", "Key (msg 3/4)" and "Key (msg 4/4)".

The problem: Although I have decryption enabled and WPA-PSK key set in IEEE 802.11 configuration, decryption doesn't work and I only see "802.11 Data" packets between computer B and the AP.

I tried to play with "Assume packets have FCS" and "Ignore the protection bit" settings, but I got only notices that all the packets are malformed. In another combination of these only first two key messages from 4-way handshake were recognized and in yet another combination all the "Data" packets were recognized as LLC (Logical-Link Control). I also tried different ways to enter the PSK into configuration (plaintext, percent-escaped characters, with and without SSID), but with no luck.

Is there anything I do obviously wrong? Thanks in advance for any help or hint.

Jirka

asked 01 Sep '12, 02:25

Jiri's gravatar image

Jiri
1111
accept rate: 0%

I just tried decryption of the sample capture from the "How To Decrypt 802.11" wiki page with wpa-pwd:Induction:Coherer using Wireshark 1.8.0 and SVN 44728 on Windows 7 64-bit and in both cases decryption was successful.

Which version of Wireshark are you using? Does the example work for you?

(01 Sep '12, 07:26) cmaynard ♦♦

Hi Chris, thanks for the comment. This is from my Wireshark's about box:

Compiled (64-bit) with GTK+ 2.24.6, with GLib 2.29.92, with libpcap 1.1.1, with libz 1.2.3.4, with POSIX capabilities (Linux), without libpcre, with SMI 0.4.8, with c-ares 1.7.4, with Lua 5.1, without Python, with GnuTLS 2.10.5, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Jul 27 2011 11:52:20), without AirPcap.

Running on Linux 3.0.0-16-generic, with libpcap version 1.1.1, with libz 1.2.3.4, GnuTLS 2.10.5, Gcrypt 1.5.0.

Built using gcc 4.6.1.

(02 Sep '12, 04:24) Jiri

About the example, the decryption works with it, I forgot to mention that in original question, sorry about that.

I see few differences between example and my captured data. Datagrams in the example have "Radiotap" headers, while my capture shows "Prism capture header" headers (Ethernet plus Prism is the only option Wireshark gives me when the interface is in monitor mode).

Also, among captured data I can see "Prism" protocol datagrams with info like this: "71 2.067751 Prism 42 Device: @+G", Message 0xffffffff, Length -664731649[Malformed Packet]".

Could that be of any importance?

(02 Sep '12, 04:36) Jiri

I think someone will need to take a look at an actual capture file in order to figure out what's going on here. The easiest way would probably be for you to open a bug report and attach a capture file to it.

(By the way, you didn't actually indicate which version of Wireshark you were running.)

(02 Sep '12, 07:00) cmaynard ♦♦