I'm trying to decrypt some DHCP packets with WPA-2. Using my key, I was able to see the side sending the DHCP Discover and Request (decryption is working), but I am unable to decrypt the packets sending the DHCP Offer and Ack. I have toggled all of the various settings but these packets just show up as encrypted data. The difference is, the packets I CAN decrypt have a transmitter address AND a Receiver address (destination is broadcast). So they are clearly part of the session. The packets I CAN'T decrypt have a transmitter address BUT both destination and receiver addresses are broadcast. Is there some way to force Wireshark to treat these packets as being in the same session that I am decrypting? I just found this unanswered question is a duplicate. Question still stands. http://ask.wireshark.org/questions/19141/not-decrypting-both-sides-of-the-dhcp-handshake asked 17 Jul '13, 11:36  mtd19 edited 18 Jul '13, 17:21 showing 5 of 8 show 3 more comments |
One Answer:
Ok, that is indeed stange - because by pure luck pick I was able to find traces that match exactly your problem definition BUT those broadcast packets (in your terms) were "from A to broadcast/broadcast" which resulted out of a capture issue. That's why I asked you to double-check. Could you upload the trace file or just the DHCP process related frames along with the 802.11 Layer 2 ACKs? I don't need them to decrypt but maybe there is a way to figure comparing those to my traces here answered 17 Jul '13, 15:58  Landi Akismet thinks I'm spamming...trying again (1) is DHCP Discover (3) I THINK is DHCP Offer (won't decrypt) (4,13,29) DHCP Request (15, 31) I THINK DCHP Ack (won't decrypt) (32,34) ARP Packets decrypt just fine (18 Jul '13, 14:37) mtd19 31 can't be a request since it's coming from the station. 32 isn't a DHCP ACK but purely a wireless layer 2 ACK for 31 --> so the only (also timely possible) valid process I could estimate would be Discover(29), Offer(31), Request(32), DHCP ACK(34). Which of those do and don't decrpyt? (18 Jul '13, 14:54) Landi Poor formatting, retrying (1) is DHCP Discover (3) I THINK is DHCP Offer (won't decrypt) (4,13,29) DHCP Request (15, 31) I THINK DCHP Ack (won't decrypt) (32,34) ARP Packets decrypt just fine (18 Jul '13, 16:20) mtd19 Sorry for misinterpreting your previous message - made sense already but where I'm located it's quite in the middle of the night ;) I'm honest with I'm not sure about what's happening there - but from what I see I'd sucpect a few things: - WPA does exchange keys for broadcast packets during eapol handshake --> seeing multiple DHCP sessions (by timing) indicated multiple encryption handshakes - maybe (!!) there is an issue due to packet loss during the capture making wireshark unable to decrypt the frames sent by/over the AP due to missing GMT/GTK deriving from handshake What makes me most sceptical is that given the delta times you seem to have scattered multiple DHCP attempts which bring me to the conclusion that there might be some issue with packet loss while capturing. (18 Jul '13, 16:37) Landi I'm actually investigating a DHCP issue where I'm seeing these multiple requests 2 seconds apart. So that is expected. I'm reasonably certain this is not a packet loss issue, but I could be wrong The DHCP transaction ID's are the same so I don't think that is the issue. I'm uploading the packets with the M1-4 so you can decrypt them to see this issue better yourself. /file/i40BXOVu/DHCP_packets_issue_with_4-way_.html The WPA-psk is F77E5D0BEFD85A7B0EBBE278ED81013B054D702D0BF6A4545B176840D9C82A0C (18 Jul '13, 17:02) mtd19 Thank you for providing the trace file.
The 2 seconds between requests with the same transaction ID indicate packet loss - let's analyse on base of wireless ACKs (46bytes only one mac in it) and the timings. I set a time reference on frame 16 just to see how long the process takes in regard to the DHCP Discover starting it off: 16: DHCP Discover 17: ACK to 16 18: (suspected) DHCP Offer 19: DHCP Request 20: ACK to 19 and then it gets silent :) what is weird is that I don't see ACKs for many frames from the AP e.g. frame 18 - this pattern is going to repeat then 2 seconds later: 23: DHCP Re-Request <-- fits to why there was no DHCP ACK before 24: ACK to 23 25: (sucpected) DHCP ACK and again no wireless ACK but also no wireless retransmission, so there is s.th. strange. Wireless ACKs in 26+ are way too late to match then 2 seconds later: 32: DHCP Re-Request <-- would again support the last one didn't make it 33: ACK to 32 34: (sucpected) DHCP ACK and this time it worked because we have the ARPs ~ 400ms later but again no (wireless) ACK to the DHCP Application acknowledge. So I'd guess either they were not captured or the station didn't send any ACK but then there should have been wireless retransmits within few hundred ms at max. To me it doesn't look like a network issue but maybe some weird problem inside the station where the packet gets lost between wireless NIC and DHCP client but that's a complete guess based on the few facts there are given the trace files. I hope that helped a little - sorry if there were no news to you (18 Jul '13, 23:21) Landi showing 5 of 6 show 1 more comments |
I can see your problem inside one very old trace I found and observe the same behaviour. Could it be possible for you the check if you have the same issue using WPA/TKIP security? In my case TKIP decryption perfectly works for all 4 DHCP packets.
If you second this maybe there really is an issue within CCMP decryption there
I can't change the security type, this is a WiFi Direct application that uses WPS, not an AP that I can just configure.
Are you sure the Offer and ACK are inside the trace? In various traces with your problem description I see encrypted data packets but none match the estimated size and mac addresses they should have.
I too have the non-decryptable packets but the transmitter address matches the station and not the AP / DHCP server, so those can't be Offer and/or ACK or the capture setup broke sth. here
I see something like this: DHCP DISCOVER (from A to broadcast/B is receiver) encrypted data (from B to broadcast/broadcast) DHCP REQUEST (from A to broadcast/B is receiver) encrypted data (from B to broadcast/broadcast)
I have Microsoft NetMon on one machine and I used that to match timestamps of the encrypted data packets. It seems like I do have those packets, but Wireshark does not decrypt them.
Apparently you can't post links at all? Can you access this URL at 4shared? /file/GmZD7tah/DHCP_packets_issue.html
That is 4shared dot com and then the URI above (these SPAM filters are really annoying)
Just downloading - btw: you can easily provide traces at http://cloudshark.org/ without having to register or do anything else. There they are also visible inside a web based - yet limited - wireshark WebUI
I converted a few things to make it easier to follow up --> see answer section