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

wifi decryption not working ( with EAPOL packets and SSID and Key)

0

Hello,

I have a wireless capture and I see that the EAPOL exchange is been captured and I have also provided the SSID and key under the 802.11 preferences. I have captured and successfully decrypted wifi traffic before with the same settings. The only difference this time is thatthe Acesspoint is my samsung cellphone mobile hotspot. I have configured the AP to use a specific channel and I have see the traffic flowing in the Wireshark but still unable to decrypt it despite a sucesfull handshake and access to the SSID and key. i am right now only have one client connected.

Any pointers will be really helpful.

asked 06 Jun '16, 04:45

airhack's gravatar image

airhack
6112
accept rate: 0%

A couple of maybe obvious pointers, but since you don't provide any trace, there is nothing I can really do to test it:

  1. Reload the trace after the psk info is entered
  2. Be sure you have all four of the eapol keys (labelled 1 through 4)

We also don't know what traffic you have to decrypt. It needs to be of type Data or QoS Data. It's common when capturing 802.11n or ac traffic to not get many of the data frames due to difficulties with modulation differences between Tx/Rx and capture device. Since there is no trace to review, I can't check for any of this.

(06 Jun '16, 05:24) Bob Jones

I have uploaded the capture at the below location https://drive.google.com/open?id=0ByOYyC-nQZluWnpsS1hNZkwtNnc

To answer your questions, yes all the 4 EAPOl packets are captured and I have reloaded the trace multiple times. I have initiated some web browsing and other stuffs to generate data so there is surely data flowing through.

To add one more point. I am using the Alpha USB adapter which works on b/g range. I assume that the hotspot works in mixed mode since the alpha card is able to see the traffic just not decrypt it. Any pointers ?

(06 Jun '16, 09:59) airhack
1

If you use a display filter wlan.ta == ec:1f:72:9c:d0:bb or wlan.ra == ec:1f:72:9c:d0:bb, you'll see only frames sent by your Samsung device acting as an AP, and frames unicast to it by other devices. And among these, there are just a few Data or QoS Data frames.

As you haven't published the passphrase, you'll have to have a look at frames 463, 499, 504, 517 yourself. The first two on the list are broadcast frames from the other Samsung device, so I'd assume them to be ARP request and deciphered as such if you provide the right passphrase to Wireshark.

If you extend the display filter to (wlan.ta == ec:1f:72:9c:d0:bb or wlan.ra == ec:1f:72:9c:d0:bb) and wlan.fc.type_subtype == 0x0028, you should see only this type of frames, and these should be deciphered.

If they are not, please change your passphrase on the AP and the test client to a stupid one you would never think of using normally, so that knowledge of it is useless for anyone, take a new capture including the EAPOL exchange and some web traffic, and then change the passphrase back to the one you use normally. Then publish that new capture together with the temporary passphrase, as it would really indicate something weird about the deciphering.

(06 Jun '16, 10:26) sindy

Did you ever manage to get this solved ? I have the same issue with the Alpha AWUS036NH adapater (802.11-b/g/n). On several AP's the Alpha is able to capture session data (random http/https browsing) between Station and AP after 4 way handshake is captured. On other AP's (Asus RT-AC66u) the 4 way handshake is captured but none of the data packets following the handshake is captured, so can not be decrypted.

(11 Jan '17, 12:08) --JayJay--

@JayJay - Following on from your aircrack-ng forum question:

If you start a new question, we can work through the capability differences between the different products. We will need some sample traces (with some beacons and probes/associations for devices) and some other information related to your hardware. We should be able to determine what settings are preventing the proper capture of various wireless frames with Wireshark.

This is a very common issue.

(11 Jan '17, 12:42) Bob Jones

One Answer:

0

I revisited the decryption keys under the 802.11 preferences option and found out the the AccessPoint incorrectly spelled out instead of AndroidAP it was AndriodAP (keep searching for the diff):D. Thanks Bob on your quick turnaround on my questions, with the correct decryption keys Wireshark is decrypting the packets properly.

A couple of more questions: Is the QoS data frame same as the Data frame, which contains the actual payload ? What is the correct filter to use to only filter the capture to a specific network/SID, should wlan.bssid == "ID" work ? I guess so.

Thanks Again!!

answered 06 Jun '16, 15:24

airhack's gravatar image

airhack
6112
accept rate: 0%

1

Is the QoS data frame same as the Data frame, which contains the actual payload ?

Yes, they serve the same purpose. The QoS Data frame has QoS information attached in the header and you are likely to see these with 802.11n or higher rates and/or when using WMM.

What is the correct filter to use to only filter the capture to a specific network/SID, should wlan.bssid == "ID" work ?

This is a display filter and is how I would do it. Some shortcuts I use, so I don't type the whole bssid all the time:

wlan.bssid[4:2] == <last two="" octets="">

--> example wlan.bssid[4:2] == 45:67

If you want to run a capture filter, i.e. only capture from your bssid, the syntax is different and you need the tcpdump syntax. However, wireless traces are more difficult - not all frames between a client and an AP have the bssid field, so you have to be creative in your filtering to capture everything. For example, ACKs do not have a bssid field, nor do broadcast probe requests from a client.

(07 Jun '16, 03:05) Bob Jones

Thanks for the display filter.

What could possibly reason where all the 4 EAPOL packets are not captured. I am currently capturing traffic from a device and I constantly see only the (message 1 of 4) and (message 3 of 4) been captured. Message 2 and 4 are not captured. Any thoughts ?

(12 Jun '16, 16:22) airhack

There are a number of reasons why this could be, and it happens often.

  1. Probability of packet loss is much higher in the WiFi world relative to wired networks. Everything else being equal, if I really need to capture packets on WiFi for decryption, then I will capture on at least two different capture configurations. For instance, OmniPeek on a Win PC and then Linux with an adapter in monitor mode at the same time. Or Windows with AirPcap and a lightweight AP set to monitor mode. Other examples exist.
  2. Issues with modulation compatibility - be sure those frames are sent with a modulation/rate that your sniffer can decode. This is a common issue for these type of questions on this forum. Things like frequency band, channel width, guard interval, MCS Index, etc., all play into this. Be sure they are compatible. If you just want to 'play' with decryption, then adjusting the AP to match what you can capture might be OK. In production, it probably isn't so you will need to upgrade your capture capability.
  3. Location matters. What you sniff is what your sniffer can see in the RF environment, so it is relative. If you are next to the AP, you will see roughly what the AP sees. If you are next to the client, you will see roughly what the client sees. if you are somewhere else, you might see something else. Pay attention to RSSI values and such to be sure you can capture the correct data. Signal can be too strong too, so don't be too close.

I really can't help deduce what might be your specific issue since no real data is provided.

(12 Jun '16, 17:49) Bob Jones

Packet loss is what I suspected too, the device I am testing a a client VPN device that can connect via wifi. I guess modulation compatibility would be the most likely reason. Will play with the device and AP settings. Thanks!!

(13 Jun '16, 12:07) airhack