[Request] Cap2John about hcxtools

[ZerBea]

I'm trying to streamline an "automated" mobile cracking box and could really use a binary to convert directly to John format.

hcxpcaptool does it for JtR jumbo:
-j : output john WPAPSK-PMK file (john wpapsk-opencl)
-J : output raw john WPAPSK-PMK file (john wpapsk-opencl)

$ hcxpcaptool -j john.hash test.cap
start reading from test.cap

summary:
file name..............: freeon-clean.cap
file type..............: pcap 2.4
network type...........: DLT_IEEE802_11 (105)
endianess..............: little endian
read errors............: flawless
packets inside.........: 3
skipped packets........: 0
packets with FCS.......: 0
warning................: zero value timestamps detected
beacons................: 1
EAPOL packets..........: 2
best handshakes........: 1 (ap-less: 0)

1 handshake(s) written to john.hash
Please do not wonder about the size of the hash output, because hcxpcaptool is doing the nonce-error-corrections for JtR.

Would also be extremely nice to have an option to output directly to STDOUT.
Right know, JtR doesn't hexify non ASCII characters. Directing this to a terminal output will destroy the hash.

[RealEnder]

Does mdxfind support wpa-psk?

[roycewilliams]

Not currently. There is no official online MDXfind documentation that lists its usage, but I have a snippet here that lists the formats:

https://www.techsolvency.com/pub/bin/mdxfind/algorithms.txt

[ZerBea]

Thanks for the link to mdxfind.
According to this, we can use the following algorithms in combination with hcxtools:
PBKDF2-SHA256 (wpa-pmk)
NTLM
and some of the MD5s

[roycewilliams]

To be clear, the official distribution point of mdxfind is

https://hashes.org/mdxfind.php

I have a mirror of it with some additional information that you would otherwise have to download and run mdxfind to discover. But it's just interim/convenience documentation - not the real thing. :)

[ZerBea]

If I understand it right (mdxfind), we need a function, which grep a hash from the cap file and write it to stdout so that mdxfind can analyze the hash.

[winxp5421]

Alright, So here is the entire story.

MDXfind does not support WPA2-PSK currently but, does support all of the elements we need to crack WPA2-PSK so implementation of WPA-2PSK will be easy..ish. Long story short, after talking with waffle and another MDXfind dev. WPA2-PSK will be supported soonish.

MDXfind supports reading hashes from a file as well as STDIN, however, due to the way HDXfind parses hashes we cannot use the HCCAPX format without major changes. So, the JTR format would be preferred as it can be read by MDXfind without serious modification on the input side of things. Seen as MDXfind works on ARM processors out of the box I would like to stay off of disk as much as possible. (SD cards are not exactly high performance) So if we can find a way to output directly to STDOUT we gain 2 advantages. 1. we stay off disk 2. MDXfind starts cracking the hash right after its converted/captured.

Now, I understand that cracking performance on most arm chips will be slow but, the idea here is to have a mobile capture and cracking box that just guesses a few hundred popular PSK's and outputs cracks to a small screen.

Anything we can do to speed up the process of captureing and converting to JTR and passing the output to MDXfind would be awesome. ( maybe directly pushing from wlandump > MDXfind )

[ZerBea]

I don't think that I'm able to add this feature to hcxdumptool. The attack engine has priority 1, because this engine must be extreme fast. That was the (main) reason for me to drop libpcap and the beautiful status output (like wlandump-ng does). But it's no problem to add this to hcxpcaptool (here we have time; I hope so. @RealEnder: Do you remember -O (raw handshakes) - running over days).
OSX, LINUX, Android are running counter measures and the effort required to run counter counter measures is immense.

wlandump-ng is outdated, because the tool is no longer able to attack hardened clients.
wlancap2hcx is outdated, too. Sooner or later I will remove both.

The new procedure is:
hcxdumptool -> hcxpcaptool -> filtertools (like wlanhcx2ssid) -> cracker (online/offline) -> database (online/offline)

Please take a look at this picture:
#40 (comment)
and keep in mind:
hcxdumptool is able to retrieve many, many handshakes in a short time (depending on clients in range). A cracker, running on the same machine isn't able to handle this.

[winxp5421]

"The new procedure is:" ok, good to know thanks.

Alright, so I will need to modify my plan a little and use multiple units.
One machine for attack/capture and push output to another "cracker" machine.

Now I'm thinking 4G would be an interesting incorporation.

capture > convert > push to a remote machine over 4G and send output back.

Anyways, at some point modifying hcxpcaptool would be a big help but, certainly not something high priority.

[RealEnder]

Guys, still in doubt about mdxfind: if I understood correctly, this is something like help_crack for wpa-sec, but not only for contributions, but also for query of hashes.org. This is really useful, but the tool is closed source (why!?), don't have docs and this makes it hard to integrate.
Looking at original issue, how cap2john resulting format can be put through mdxfind?
Sorry if I'm missing something obvious about the whole thing...

[winxp5421]

Ah, no you have MDXfind all wrong. MDXfind is an entirely separate entity from Hashes.org. Hashes.org just hosts the binaries etc. MDXfind is an actual cracking tool similar to Hashcat or JTR. I did a talk about MDXfind a couple years ago https://youtu.be/34JTUAJYjXQ?t=1599 (~26min in)
MDXfind does not support anything useful for us to use currently but, it's in the works.

MDXfind will be opensource soon. The creator just ended some legal Intelectual Property Issues with previous employers which did not allow him to release the source. The source is currently being updated and "prettified" before release.

I understand that MDXfind has little to no help docs which is the entire reason why I did a talk on it. Hopefully, once the source is released we can push out proper documentation.

[RealEnder]

@winxp5421 thanks for explanation, now it makes sense :)

[ZerBea]

I'm ver often asked to add some functions to hcxdumptool. So please let me say some words about "on-the-fly" cracking and/or new functions.
If deauthentication/disassociation isn't disabled, hcxdumptool use a BEACON as trigger to start an attack. Normally an AP will transmit his BEACON every 100ms (depends on his config and could be less or more).
hcxdumptool use a ringbuffer in which every new AP is stored. Once we received a BEACON we search for the AP in the ringbuffer. If we have 50 APs (and some times we have much more) on that frequency, we must(!) do this every 2ms!
And we must do the same for all clients in range. Here we use also a ringbuffer to determine if we allready got a handshake. So, lets say we have 10 clients on that frequency, then we must search this ringbuffer on every proberequest, authenticationrequest, associationrequest and reassociationrequest of a client. Well, if some clients have more than 1 default AP in their wpa-supplicant configs (and many clients have 10 or more inside), you can imagine how often we must run through this buffers.
And at all, we must be faster than both AP and client. If one of them received an ACK from the other one, we loose!

[ZerBea]

This issue is still open, because we need some improvements on hcxtools and Jtr and hashcat (aircrack-ng is invited to participate, if they want it). Since this issue was opened, I have often thought about some improvements. After several tests, I opened this issue here:
WPAx: proposal for a new hash line format (successor of hccapx) #1816
hashcat/hashcat#1816
One world of hash cracking, we are all in the same boat. So only one issue/discussion there, instead of three different ones (hashcat, JtR, hcxtools).
So, if you have some good/better ideas, please join #1816 on git.

[ZerBea]

W're now on hash format hc22000.