Hello, I´ve been messing with this in a couple of hours and hope that someone can give me an advice. I know how to decrypt this type of packet, because I have done it before but for now, it is impossible for some reason. I know the SSID and passphrase (WPA2) of the wireless network and I´ve captured the 4-way handshake of that device packets I want to decrypt. I´ve test to enter the WPA-PSK by generate it through Wiresharks PSK generator and entered WPA-PWD which is "passphrase:SSID". Nothing of this seems to work for me and I have no idea why. I´ve been following a tons of guides but can´t find any solutions. Do anyone have some ideas who can solve my problem? Version of Wireshark: 2.2.5 (v2.2.5-0-g440fd4d) Thanks in advance! asked 14 Mar '17, 02:57  vix1993 edited 14 Mar '17, 06:12  Christian_R showing 5 of 6 show 1 more comments |
One Answer:
I had a look at this issue a little closer today based on how @vix1993 is capturing packets. It's a little unusual to capture this way, but it is certainly doable. Test I setup a Dell with Intel 7260 wireless chipset and booted to Linux. At the same time, I set up my MAC to capture traffic, and configured a test SSID and I would capture two ways: with the MAC, which I know always works and then as this issue presents, with the secondary monitor mode interface on the same phy as the active adapter, with Wireshark/Linux pointed to this monitor mode interface. Initial Result I can replicate the findings described - it does not appear that we can decrypt when captured in this way. I proved this by ensuring the 4-way eapol frames are in both traces, then I moved both traces to a Windows box and opened both - this avoids any Wireshark issues based on version, e.g. the MAC works but Linux does not, etc. There are no findings here - all three versions (Linux/Mac/Win) had consistent results. Debugging Reviewing the eapol frames in detail, they look OK. One significant difference to the frames as a whole are the transmitted frames from the Intel client (that has the monitor interface attached) are missing a lot of information in the radiotap header - they must be sent prior to population of certain fields, and this makes sense: a signal strength measurement does not make sense at this point as it has not been actually transmitted. Same with the data rate, etc. So if the eapol frames are the same, why won't Wireshark decrypt? Findings In my case, I am using pings and the byte view led me to this. If you look at the picture below, you can see where the ICMP echo contents are visible in the raw data view, but the Info view seems to indicate encrypted. I think the answer is that the frames sent from the client are not encrypted at this point. They look encrypted from a cursory view, but I don't believe they are. If I do 'ignore protection bit with IV', they show as-is. When you have a trace like this, can you set this configuration and try again? I checked and indeed your trace comes alive with this filter after changing the setting: wlan.addr == 34:e6:ad:c8:d7:2d However, you probably leaked information that you did not want to so I will not post a picture. You may want to remove your trace for confidentiality reasons.
answered 14 Mar '17, 17:33  Bob Jones edited 15 Mar '17, 03:23 |
Could you share us the trace or at least the eapol packets
Alright. Here you can see the capture from Wireshark. I´ll saw right now that two of EAPOL packets were marked "Malformed Packet", do not know why. This 4-way handshake was a successfully.
@vix1993
Your "answers" have been converted to comments as that's how this site works. Please read the FAQ for more information.
The eapol frames do not show as an error in my Windows Wireshark. Can you confirm how you took the capture -
Are you on Linux? If so, did you add a monitor interface to the adapter, and you are using the same adapter to communicate and monitor traffic at the same time?
Is this a test SSID/Passphrase so you can share and we can try to decrypt?
Hi Bob and thanks for the response. Yeah I´m running Linux and yes I´ve added a monitor interface and communicate with the same adapter. No sorry, this is not a test.
Do you have the box "Assume packet have FCS" in Preferences -> Protocols -> IEE 802.11. Is it checked? Because I got that checked when I see "Malformed Packet".
Can you share us the succesful trace, too?