+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Misc (https://hashcat.net/forum/forum-15.html)
+--- Forum: User Contributions (https://hashcat.net/forum/forum-25.html)
+--- Thread: New hccapx format explained (/thread-6273.html)
RE: New hccapx format explained - c4p0ne - 02-08-2017
When converting from .pcap is the converter considering ALL available handshakes (including invalid), or only valid handshakes for output to .hccapx ?
RE: New hccapx format explained - rico - 02-08-2017
Did atom not already answer that earlier in this thread?! https://hashcat.net/forum/thread-6273-post-33445.html#pid33445
RE: New hccapx format explained - c4p0ne - 02-08-2017
(02-08-2017, 06:45 PM)rico Wrote: Did atom not already answer that earlier in this thread?! https://hashcat.net/forum/thread-6273-post-33445.html#pid33445
Yeah, it was unclear the first time I skimmed it, but after review, I think I understand what's being said.
RE: New hccapx format explained - rico - 02-08-2017
I, too, read it a couple of times and then nodded knowingly...
RE: New hccapx format explained - atom - 02-08-2017
Also note that this feature is kind of unique in the WPA/WPA2 cracking world. There's no other cracker (both commercial and non-commercial) that combines the packets in such a way that they produce at least one crackable handshake out of many. They can tell you to have a working handshake but they can not guarantee it (because of the deauth attack collisions). Hashcat can not know the correct one, too, but by simply combining all possible variants it can guarantee to have at least one valid.
The idea for combining the packets requires to had a different idea before. That is hashcats new feature that can crack N handshakes of the same ESSID for the price of one (see here: https://hashcat.net/forum/thread-6150.html ). Without this feature a cracker can not combine all the packets because it would create too many handshakes and if it produces 28 combinations the speed would be 28 times slower, so you wouldn't even think about it.
This is one of the success stories you often have in the IT security world. You find a bug to something but you can not exploit it. But then you find another bug and you can not exploit it either. But if you combine them, you can exploit it.
RE: New hccapx format explained - c4p0ne - 02-08-2017
Incidentally, I think the latest version of Passcape's software (v4.x) has implemented the "many for price of one" feature into their commercial product...
RE: New hccapx format explained - atom - 02-09-2017
Hehe, I guess in that case it will not take long to update it again, allowing it for combining of packets
RE: New hccapx format explained - c4p0ne - 02-09-2017
It would be nice to see cap2hccapx be able to handle very large (>1GB) .pcap files. I am getting the message "too many ESSID's" on occasion.
RE: New hccapx format explained - philsmd - 02-09-2017
if you see that error, just increase the DB_ESSID_MAX value to whatever value you feel comfortable. The risk of doing this is that it might use much more RAM. So you should do it at your own risk.
We felt that a reasonable upper limit might work in most of the cases (1000 different networks should work in most of the cases). Of course, if you use a .cap file generated while wardriving/warflying, the limit needed must be (a little bit?
) higher.
RE: New hccapx format explained - c4p0ne - 02-09-2017
Worked.... But for some reason (and this is with the pre-compiled binary, too, not just the one I built) I get 0 handshakes written with 100% of my captures. A good portion of those captures get properly converted by the online version of hccapx though. (??)