Hashcat + wlangenpmkocl how to convert back to plaintext ?
#1
Hi everyone !

So I'm testing hashcat on my network, first I tried with a dictionary with 1 word on mode 2500, this was successful.

Next up I used wlangenpmkocl (-a mode) to make a pmk dictionnary with again the same word, mode 2501 this time as 2500 fails (obviously).

It cracks successfully again, but this time the potfile returns the key instead of plaintext.

How do we convert the key back to plaintext ?

(added truncated to hide part of the key)

type hashcat.potfile
e02ede2909ac91cd095ce1fc469f6990a6d[truncated]8c8edda73b4be62f365c53*497448757274735768656e4950:

Thank you very much for the support and the incredible work put into this program.

EDIT: Stumbled on this:
https://miloserdov.org/?p=5167

It answers all the questions except one, what happens if you use rules ? What then ?

Thanks

EDIT2: Ugh the answer is to brute force it with the same rules isn't it ? GAAAHHHH IT'S JUST A GIANT CIRCLE
cat PMK-FILE | cut -d ':' -f 1 | hashcat -m 2501 -w 4 -a 0 HASHFIRE -r RULEFILE

So for any other noobs hopelessly lost I think this is the answer.
Reply
#2
Hash mode 2501, 16801 and 22001 are designed to verify an existing Plain Master Key PMK. That can be a PMK from a rainbow table, e.g. calculated by wlangenpmkocl.
Workflow:
calculate PMK list
$ wlangenpmkocl -e network-essid -i passwordlist -A combi.list
The combi.list contain PMK and PSK

Now get the PMKs and feed hascat with them:
$ cut -c -64 > pmk.list

run ahshcat to find the PMK
$ hashcat -m 2501 hash.hccapx pmk.list

if the PMK is verified by hashcat, grep for it in the combi.list
$ cat combi.list | grep e02ede2909ac91cd095ce1fc469f6990a6d
and you will see the matching PSK.

BTW1:
Due to the length of the PMK it is impossible to run a mask or a rule to find a new one.

BTW2:
Hash mode 250x and 1680x are deprecated. You should use hash mode 2200x instead.
Reply
#3
(02-21-2021, 02:08 AM)ZerBea Wrote: Hash mode 2501, 16801 and 22001 are designed to verify an existing Plain Master Key PMK. That can be a PMK from a rainbow table, e.g. calculated by wlangenpmkocl.
Workflow:
calculate PMK list
$ wlangenpmkocl -e network-essid -i passwordlist -A combi.list
The combi.list contain PMK and PSK

Now get the PMKs and feed hascat with them:
$ cut -c -64 > pmk.list

run ahshcat to find the PMK
$ hashcat -m 2501 hash.hccapx pmk.list

if the PMK is verified by hashcat,  grep for it in the combi.list
$ cat combi.list | grep e02ede2909ac91cd095ce1fc469f6990a6d
and you will see the matching PSK.

BTW1:
Due to the length of the PMK it is impossible to run a mask or a rule to find a new one.

BTW2:
Hash mode 250x and 1680x are deprecated. You should use hash mode 2200x instead.

Hello !

Thanks for answering

I made a batchfile testing ALL hash modes on my test network with plan text, the only that worked was 2500, with the PMK the only one that worked was 2501.

The 22000s don't work for me. Am I misunderstanding something ? I thought the -m was the type of hash you're dealing with ?

Also what's wrong with adding the -r RULE with hashcat ? Technically that'll brute it no ? Or you're saying time-wise it isn't worth it ?

EDIT: Allow me to explain my philosophy.
I'm assuming I don't know the password. Masks take too long but technically more guaranteed I guess if you had a datacenter at your disposal they would be feasible or if you had a lot of clues to the password. Dictionary I find it's unlikely will contain the password. But using a rule like say NSA_dive rule I find would HOPEFULLY make it more likely. However it takes much more time. That's where the PMK comes in. I was hoping to run advanced rules on the PMK to kind of cheat instead of using masking because I can search PMKs much faster. Crunching ?x?x?x?x?x?x?x?x? or whatever though is like a pentabyte so that's not feasible either (in case you were going to suggest appending). Also I have 3 rigs for the job:

Laptop1: general purpose, Vegas10,6gbRAM,8CPU,The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali)
Laptop2: workhorse, shittygfx,4CPU,6gbRAM This makes the PMKs all day, takes a day to make a PMK from a 3GB wordlist,The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali)
Gaming rig: 32gbram,12CPU,GTX680. I use this to hashcat the hashes,windows

my password (I've changed the digits obviously but the positions are the same) a1yqfu1746
So not knowing anything about this pass, what would be the correct philosphy to adopt ? Or do I have the right mindset, just not the processing power *sad face*

Btw if anybody wants the handshake to experiment it's no problem, this is perfectly legal and it's my router promise (I can prove this obviously as I have the real password).

FYI, to me 'too long' is anything that exceeds 3-5 days
Reply
#4
Running hash mode -m 22000 you must convert the capture file to a 22000 format hash file.
Than run hashcat -m 22000 hashfile.22000 wordlist. You should use latest version of hashcat.

Also what's wrong with adding the -r RULE with hashcat?
For sure, you can use masks or add rules to hashcat - but it doesn't make sense for hash modes like 2501, 16801, 22001.

I recommend to read basic information about PBKDF2:
https://en.wikipedia.org/wiki/Pbkdf2
https://github.com/s3inlc/hashtopolis/is...-749482259
If you have a PMK only, it is impossible to recover the PSK from it.

I think, you haven't understand to procces of calculating keys on WPA:
Please read this, too:
https://www.ins1gn1a.com/understanding-w...-cracking/

Here we go again:
The PMK is always 256-bit (32 byte) at length and calculated via PMK = PBKDF2(HMAC-SHA1, preshared_password, salt=access_point_name, rounds=4096) (where PBKDF2 is password based key-derivation function 2, which in this case involves 4096 rounds of HMAC-SHA1).
It is impossible to to run a mask or rule to calculate a PMK within a human life time!
We are not talking about 3-5 days. We are talking about > 1000 years
Reply
#5
How do we convert the key back to plaintext ?
I haven't answered this question, so shame on me.
If you mean with "key" a PMK, and if If you have a PMK and an ESSID, you can calculate the PSK via hash mode -m 12000
It is explained here:
https://github.com/s3inlc/hashtopolis/is...-749519078
Please notice:
This is also PBKDF2 and as slow as hash mode 2500, 16800 and 22000.
Reply
#6
(02-21-2021, 10:54 AM)ZerBea Wrote: How do we convert the key back to plaintext ?
I haven't answered this question, so shame on me.
If you mean with "key" a PMK, and if If you have a PMK and an ESSID, you can calculate the PSK via hash mode -m 12000
It is explained here:
https://github.com/s3inlc/hashtopolis/is...-749519078
Please notice:
This is also PBKDF2 and as slow as hash mode 2500, 16800 and 22000.

Nono are you kidding me you've given me so much info thank you !

You've answered the question in many different ways in fact. My original idea was just to open both PMKs in notepadd++ run the compare addon and find the line. But grepping / cat cutting is much efficient/smart.

You are correct though, I'm being a script kiddie at the moment. I clearly do not yet understand how encryption, hashing and the WPAs work. I read the links but need to re-read and experiment in my lab. Perhaps I should login to my network, fire kismet and observe the traffic. I remember once upon a time doing tech support I used to learn so much by simple TCPdumps.

It's coming back to me.. Just slowly.

I guess what I was hoping is that the wpa key would resemble a dictionnary word rather than something like x9abcd9999 as a password.

I'm too new to make statements like this but from the books I'm reading and such t seems like the most effective method of infiltration is actually impersonation and not cracking.

I mean if all I could is compare a dictionnary to the hash why would I want to make a PMK then ?

It'll take me about 24hrs to construct a PMK from a 3GB wordlist. If I run it straight as a wordlist instead of converting HASHCAT's eta is about maybe 2 days or say 3 even. I understand that technically it can save you a day or two, but on the other hand there's so many mistakes you can make. A 48 hr tradeoff or whatever doesn't sound like a big gain there must be something else.

Either I'm not understanding the true purpose of rainbow tables or I'm far too ambitious for this low level of processing power. Hmmm.

I've stumbled on people across the net talking about how they've recovered PART of a password sometimes. Is this an actual possibility ? Because that would make masking much more feasible you can start guessing a little bit.

Going to read https://www.ins1gn1a.com/understanding-w...-cracking/ now. Thanks

EDIT:
"The MIC is calculated using HMAC_MD5, which takes its input from the KCK Key within the PTK. Unfortunately I wasn't able to come up with some Python code to compute the MIC, even after reviewing aircrack-ng and Cowpatty source code (my C skills are severely lacking). Expand on the above and let me know if anyone has an idea!"

Hmmm I know this is cheating but you guys know about https://gpuhash.me right ? There's a 'check service' option where you can dump your handshake and it'll show you the MICs. Is that what he's saying he's missing here or did I misunderstand ? Because if that's the case I think this would be quite helpful for everyone.
Reply
#7
(02-21-2021, 10:54 AM)ZerBea Wrote: How do we convert the key back to plaintext ?
I haven't answered this question, so shame on me.
If you mean with "key" a PMK, and if If you have a PMK and an ESSID, you can calculate the PSK via hash mode -m 12000
It is explained here:
https://github.com/s3inlc/hashtopolis/is...-749519078
Please notice:
This is also PBKDF2 and as slow as hash mode 2500, 16800 and 22000.

Here's the problem though (and correct me if I'm wrong). Let's be honest the likeliness of a PSK being in the wordlist is practically nill. I don't understand how these guys in their talks say things like rockyou=76% success right. Maybe like 15 years ago... Masking takes too long. Hybrid would take even longer.

There has to be a smarter approach around this. Again like I said before I'm beginningto realize impersonation is the way to go, but I just can't let go of this. I hate unsolved puzzles, I need to get to the bottom of this. I mean like 30 years ago you had people doing this with like 286s how did they fare it ? The limitations they would face are proportional to the ones we face today in my opinion.

fyi I do understand what you're doing that procedure is in the milos.org link I posted. It's just that technique still brings us back to 'oh well I can just run the dictionnary plain and if the key shows up well fine if it takes a few extra days so be it'. I was thinking by going PMK it would allow us to run advanced rulesets THEN the dictionnary can be very powerful, especially this one. (I have a 80GB one but I'm still benchmarking the 4GB one, seems like that's gonna take 90hrs to PMK, then like 5 minutes to run through hashcat)

EDIT: Ok some progress here..

hashcat -a 6 -m 2501 -w 4 "ANALYZE ME\ithurts.hccapx" dict\ithurts.pmk masks\rockyou-1-60.hcmask

Forgot about the hybrid attacks. I know the -m 2501 is making you wince, we'll take care of that last don't worry.
This is POC though there's 1 password in the pmk and it's the actual. Let's see what happens tonight with the live exercise. I'll keep us posted Wink
Reply
#8
It would be much appreciated if you share your experience with us.

Hash mode 2501 (16801, 22001) doesn't make me wince.
I really love this "verification" modes and that is exactly the reason, why I explained the purpose of them to Atom and asked him to add this modes (apart from this, it was also the reason for me to code hcxdumptool and hcxtools).
That include hash mode 22000 to get full benefit of reuse of PBKDF2 over PMKID end EAPOL.
https://github.com/hashcat/hashcat/issues/1816

This are my experiences (PMK verification) on hash mode 2200x:
Code:
$ hashcat -m 22001 -w4 --nonce-error-corrections=0 hash.22000 pmk.list -o found
hashcat (v6.1.1-120-g15bf8b730) starting...

CUDA API (CUDA 11.2)
====================
* Device #1: GeForce GTX 1080 Ti, 10859/11175 MB, 28MCU

OpenCL API (OpenCL 1.2 CUDA 11.2.136) - Platform #1 [NVIDIA Corporation]
========================================================================
* Device #2: GeForce GTX 1080 Ti, skipped

Minimum password length supported by kernel: 64
Maximum password length supported by kernel: 64

Hashes: 699380 digests; 699380 unique digests, 221559 unique salts
Bitmaps: 17 bits, 131072 entries, 0x0001ffff mask, 524288 bytes, 5/13 rotates
Rules: 1

Applicable optimizers applied:
* Zero-Byte
* Slow-Hash-SIMD-LOOP

Watchdog: Temperature abort trigger set to 90c

Host memory required for this attack: 491 MB

Dictionary cache built:
* Filename..: pmk.list
* Passwords.: 299836
* Bytes.....: 19489282
* Keyspace..: 299836
* Runtime...: 1 sec

Session..........: hashcat
Status...........: Exhausted
Hash.Name........: WPA-PMK-PMKID+EAPOL
Hash.Target......: hash.22000
Time.Started.....: Mon Feb 22 10:52:46 2021 (34 mins, 16 secs)
Time.Estimated...: Mon Feb 22 11:27:02 2021 (0 secs)
Guess.Base.......: File (pmk.list)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 43622.5 kH/s (0.00ms) @ Accel:64 Loops:1024 Thr:1024 Vec:1
Recovered........: 686597/699380 (98.17%) Digests, 213641/221559 (96.43%) Salts
Remaining........: 12783 (1.83%) Digests, 7918 (3.57%) Salts
Recovered/Time...: CUR:21229,N/A,N/A AVG:20035,1202122,28850930 (Min,Hour,Day)
Progress.........: 66431364324/66431364324 (100.00%)
Rejected.........: 221559/66431364324 (0.00%)
Restore.Point....: 299836/299836 (100.00%)
Restore.Sub.#1...: Salt:221558 Amplifier:0-1 Iteration:0-1
Candidates.#1....: 0000000000000000000000000000000000000000000000000000000000000000 -> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Hardware.Mon.#1..: Temp: 74c Fan: 59% Util: 76% Core:1847MHz Mem:5005MHz Bus:16

Started: Mon Feb 22 10:52:34 2021
Stopped: Mon Feb 22 11:27:03 2021

Please notice:
This is only a demonstration.
To save time, I used --nonce-error-corrections=0 (NC).
Due to packet loss during capturing (some of the capturing tools are not able to detect this), a few of the hashes require a higher NC to recover the PSK. Unfortunately this will increase task time, too. For a demonstration it is not worth it.

BTW:
I don't use the ancient modes 250x and 1680x any longer since Atom added 2200x to hashcat.
Reply
#9
(02-22-2021, 12:29 PM)ZerBea Wrote: It would be much appreciated if you share your experience with us.

Hash mode 2501 (16801, 22001) doesn't make me wince.
I really love this "verification" modes and that is exactly the reason, why I explained the purpose of them to Atom and asked him to add this modes (apart from this, it was also the reason for me to code hcxdumptool and hcxtools).
That include hash mode 22000 to get full benefit of reuse of PBKDF2 over PMKID end EAPOL.
https://github.com/hashcat/hashcat/issues/1816

This are my experiences (PMK verification) on hash mode 2200x:
Code:
$ hashcat -m 22001 -w4 --nonce-error-corrections=0 hash.22000 pmk.list -o found
hashcat (v6.1.1-120-g15bf8b730) starting...

CUDA API (CUDA 11.2)
====================
* Device #1: GeForce GTX 1080 Ti, 10859/11175 MB, 28MCU

OpenCL API (OpenCL 1.2 CUDA 11.2.136) - Platform #1 [NVIDIA Corporation]
========================================================================
* Device #2: GeForce GTX 1080 Ti, skipped

Minimum password length supported by kernel: 64
Maximum password length supported by kernel: 64

Hashes: 699380 digests; 699380 unique digests, 221559 unique salts
Bitmaps: 17 bits, 131072 entries, 0x0001ffff mask, 524288 bytes, 5/13 rotates
Rules: 1

Applicable optimizers applied:
* Zero-Byte
* Slow-Hash-SIMD-LOOP

Watchdog: Temperature abort trigger set to 90c

Host memory required for this attack: 491 MB

Dictionary cache built:
* Filename..: pmk.list
* Passwords.: 299836
* Bytes.....: 19489282
* Keyspace..: 299836
* Runtime...: 1 sec

Session..........: hashcat
Status...........: Exhausted
Hash.Name........: WPA-PMK-PMKID+EAPOL
Hash.Target......: hash.22000
Time.Started.....: Mon Feb 22 10:52:46 2021 (34 mins, 16 secs)
Time.Estimated...: Mon Feb 22 11:27:02 2021 (0 secs)
Guess.Base.......: File (pmk.list)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 43622.5 kH/s (0.00ms) @ Accel:64 Loops:1024 Thr:1024 Vec:1
Recovered........: 686597/699380 (98.17%) Digests, 213641/221559 (96.43%) Salts
Remaining........: 12783 (1.83%) Digests, 7918 (3.57%) Salts
Recovered/Time...: CUR:21229,N/A,N/A AVG:20035,1202122,28850930 (Min,Hour,Day)
Progress.........: 66431364324/66431364324 (100.00%)
Rejected.........: 221559/66431364324 (0.00%)
Restore.Point....: 299836/299836 (100.00%)
Restore.Sub.#1...: Salt:221558 Amplifier:0-1 Iteration:0-1
Candidates.#1....: 0000000000000000000000000000000000000000000000000000000000000000 -> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Hardware.Mon.#1..: Temp: 74c Fan: 59% Util: 76% Core:1847MHz Mem:5005MHz Bus:16

Started: Mon Feb 22 10:52:34 2021
Stopped: Mon Feb 22 11:27:03 2021

Please notice:
This is only a demonstration.
To save time, I used --nonce-error-corrections=0 (NC).
Due to packet loss during capturing (some of the capturing tools are not able to detect this), a few of the hashes require a higher NC to recover the PSK. Unfortunately this will increase task time, too. For a demonstration it is not worth it.

BTW:
I don't use the ancient modes 250x and 1680x any longer since Atom added 2200x to hashcat.

oh don't you worry I have a full treatise in preparation Smile I'm actually enjoying t his very much. Once all this is laid out the ultimate objective is to see if it's possible to guess part of the password.

btw I was saying mode 2501 makes you wince hehe the 22ks I know you like. What do I have to do just convert the hccapx to 22000 mode or something ?
(and if I'm using a PMK it's 22001 I'm assuming ?)

So yeah I've been reading the information you've posted and it's a little hard to understand so I need to ask, is it possible to extract PART of a password ?

What would happen if I took a hash, and only removed say the first 2 characters, and tried to brute force that ? I know I'm not wording it properly yet but you get what I'm trying to say. Maybe the whole problem here is trying to guess the entire password at once.

Meanwhile the PMK is at 80 million out of 90 so in a couple hours it'll be ready for testing we'll see what happens

EDIT: Forgot to mention, I have this little superstition that the needle is always at the bottom of the haystack so to speak. Is there a way to search backwards wit hthe masks and dictionnaries ? Dicts I suppose I can just reverse the order and pipe it or whatever but what about the masks ? Without rules preferably sounds needlessly tedious for this specific task unless I'm off base of course.
Reply
#10
For sure a mask on a PMK will work, in case you hav 90% of the PMK.
Example:
$ wlangenpmk -e hashcat_net -p hashcat1

essid (networkname)....: hashcat_net
password...............: hashcat1
plainmasterkey (SHA1)..: 9cff1131859ffd9255a3bd412db53d3a576c41910cff9bf8165176b3fd6fdbf0

If you run hashcat with this mask
9cff1131859ffd9255a3bd412db53d3a576c41910cff9bf8165176b3fd6fdb?h?h
it will verify the PMK.
Please note my wording: I didn't write it cracked the network or it recovered the PSK.

Now take a look at the result of PMKDF2 if you change a character within the ESSID
$ wlangenpmk -e hashcat-net -p hashcat1

essid (networkname)....: hashcat-net
password...............: hashcat1
plainmasterkey (SHA1)..: da4976c8e0e045d3f3e48e3213953cde92f6ac2e0b75b5dde88d4177e924251a

No chance to run this simple mask to verify the PMK.

Now we change a character of the PSK:
$ wlangenpmk -e hashcat_net -p hashcat2

essid (networkname)....: hashcat_net
password...............: hashcat2
plainmasterkey (SHA1)..: 332f14d711b5be5b5b8dcce42c36a0b452502cab0d7db1b5a4ef7ac9d7ec90b3

our simple mask will fail, too.

In every case you must do "slow" PBKDF2:
ESSID + PSK -> PMK
ESSID + PMK -> PSK

And if you discover a new PMK, ESSID + PMK -> PSK is mandatory.


hash mode comparison table:
2500 -> 22000
2501 -> 22001
16800 -> 22000
16801 -> 22001

2500 & 16800 -> 22000 reuse of PBKDF2
2501 & 16801 -> 22001

Mostly I don't use masks, rules or big wordlists found in www.
hcxdumptool/hcxtools and hashcat (or JtR) is more than enough for me.

I recommend not to convert hccapx to 22000, because you don't know nothing about the quality of the hccxcap file.
It is much better to recapture and to convert them directly to 22000.

Which tools do you use for capturing and converting?
Reply