Trouble decryping WPA2 WLAN traffic in Wireshark

asked 2018-11-23 11:34:41 +0000

Masato
1 ●1 ●1 ●1

I have trouble decryping WPA2 WLAN traffic in Wireshark.

I've done research and followed all advises I could possibly find and still cannot decrypt it. There are of course plenty of variables, but I strongly believe I covered all of them, and yet I'm still missing out something.

Basically, all I can view is Probs, Beacons, Null function (No data) and QoS Null function (No data). I connect to the network with my phone and start randomly browsing and can clearly see my traffic is going in Wireshark, but it only Null function (No data) packets.

I've made sure I added [password]:[ssid] to 802.11 and enabled decryption. Always have long streams and full EAPOLs when capturing the traffic and tried on three different wifi cards (Alfa, TP-link & Intel). I have most up to Kali distribution and latest Wireshark version, and tried on someone else pcaps and Wireshark decrypted it successfully.

The only thing I can think of causing this is the driver.

Please help.

edit retag flag offensive close merge delete

add a comment

answered 2018-11-23 13:19:25 +0000

Bob Jones
1481 ●2 ●171 ●22 Boston, MA

It sounds as if your issue is not decryption, but rather not collecting data traffic, that can be decrypted.

You need to have a capture capability envelope at least as big, or bigger, than the traffic you want to collect. There are many factors to this: band, channel, spatial streams, encoding, and others...

There are lots of questions and answers here on this topic, some are below (there are more). To start, I would reduce the performance of the AP system to something like a or b/g only, i.e. no 802.11n or 802.11ac. See if you then get the data frames you are looking for. Then go from there - the actual process of associating/authenticating will give clues as to the modulation settings that will be used between a device and the AP and you can use this information to specify a new capture system to meet your specific needs. There is no example trace provided so we can't point out where that information exists in your case.

https://ask.wireshark.org/question/1631/cant-decrypt-wpa-psk-wpawpa2-even-with-passphrase-and-eapol-handshake

https://ask.wireshark.org/question/1538/no-http-protocols-in-scan-results/#1542

edit flag offensive delete link

Comments

You need to have a capture capability envelope at least as big, or bigger, than the traffic you want to collect. There are many factors to this: band, channel, spatial streams, encoding, and others..

Please explain that.

I have no access to the router thus cannot follow your advice.

Masato ( 2018-11-23 13:59:17 +0000 )edit

You won't have any success trying to capture 802.11ac traffic with an 802.11n adapter; it's not physically possible. This goes for all of the standards: 802.11 a/b/g/n/ac. But it doesn't stop there - there are number of spatial streams (if you try to capture with a device that supports 1, but your test device supports 2, it won't work...). There are other catches as well - LDPC or not, channel width (20-40-80MHz), etc.

The trick is to understand the capabilities of what you want to capture, and then select your capture system. What frequently happens is one tries to capture traffic with whatever they have, say an old laptop with Linux, from their brand new AP and smartphone, both of which are near state of the art in regards to WiFi capability. But the poor old laptop, loaded with Linux... is ...(more)

Bob Jones ( 2018-11-23 20:37:22 +0000 )edit

Bob Jones, that is the most safisticated answer I've ever had on this subject, thank you very much. Although, that doesn't clear my problem, that is very good start in understanding wifi traffic capturing and its difficulties, and I'm willing to investigate further.

I understand this will be a complex task, but is there any info in those packets can be dag out that I'm capturing will indicate on more details of where to start. I mean brute forcing the ideas and just trying thing at a time is too inefficient.

Currently, I have tried 3 different wifi adapters running them on Kali.

Masato ( 2018-11-27 08:22:31 +0000 )edit

Yes, you can get information that you need. Look in the following frames on wifi:

Probe Request
Probe Response
Association Request
Association Response
Beacons

These are all low datarate frames, so should be relatively easy to pick up.

These will have information elements like HT and/or VHT: these will tell what each device supports as far as 802.11n or ac and maximum MCS index (see www,mcsindex.com); number of spatial streams; bandwidth (20-40-80, etc), LDPC or not, SGI or not. Assume that comms will flow between them at the highest set of common capabilities.

This is what you have to match to collect your traffic. Now look at your capture adapter chipset; either

lspci 
lsusb

(depending if PCI or USB based) and look up the chipset. Google helps, and then once you get the chipset, look up on wikidev website for information and some capability information. As ...(more)

Bob Jones ( 2018-11-27 11:14:28 +0000 )edit

To summarize, especially, considering what you've described in the previous post, the simple solution will be just trying out different wifi adapters, considering there are not so many chipsets can run promiscuous mode supported by linux kernel, this should be quick & easy.

Playing with kernel headers probably last thing you want to do especially if you are in the field and trying to capture live stream.

Masato ( 2018-11-27 14:09:48 +0000 )edit

see more comments

Trouble decryping WPA2 WLAN traffic in Wireshark

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Trouble decryping WPA2 WLAN traffic in Wireshark edit

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Trouble decryping WPA2 WLAN traffic in Wireshark