3

Days ago I was dumping handshakes of my APs using airodump-ng. I would later use aircrack-ng to crack them using wordlists which would purposely contain the passphrases. However, I noticed that some handshakes of the same AP cracked while others didn't. I'd recapture the handshake again and again and test, however, not all of them cracked. So I started to inspect them using wireshark and I found no difference between a successfully cracked handshake and a failed one, they both contained:

the beacon

the M1

the M2

I once came across a post explaining that in order for a handshake to be healthy and enough for cracking it should contain:

the M2 (a must)

the M3 or the M1 (the M3 is preferred)

and possibly the beacon

So my question is what's the factor that makes a handshake suitable for cracking? Surely the eapol messages are a must but there must be something else judging. It is really inefficient and blind to capture a handshake, try to crack it, and assume the AP is secure just because the cracking failed, maybe the handshake wasn't healthy in the first place.

  • Try updating the version of aircrack-ng, they just released (10 days ago - April 15, 2018) version 1.2, not anymore an RC. Theoretically you got all what you need so maybe it was a bug? Have you tried using Hashcat, Kismet, or any other tool that's not aircrack-ng? – Azteca Apr 25 '18 at 17:54
  • I tried, the problem really doesn't change. Sometimes, the AP is far away and only one crippled handshake is captured. And sometimes this handshake doesn't crack although it should. I need to understand whether the handshake is valid for wasting time cracking and assuming its a secure AP. I tried analyzing as I described above with no help. – cablewelo2ma Apr 29 '18 at 15:40
  • I can provide you with the two handshakes to examine if this helps. – cablewelo2ma Apr 29 '18 at 15:42
  • files.fm/u/9afxqhzs#_ – cablewelo2ma Apr 29 '18 at 16:02
0

You need M2 and (M3 or M1), and they must belong to the same single set of a corresponding authentication (i.e., if the first authentication exchange fails, and there is a second, you won't be able to success using M2 from the first negotiation and M3 from the second).

The first thing to check is to load the capture log into Wireshark and verify that the value for the field Replay Counter be the same n (for M1 and M2) and n+1 (for M3 and M4).

Still, as Replay Counter will be frequently reset, you should also check that the interval between M2 and M3 is correct: I've seen about <0.1s working ok, but there is no fixed rule for this value; you should take a look at the rest of the packets and decide if the intervals are plausible, also considering larger values possibly valid because retransmitted packets.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.