search

ZerBea / hcxtools

A small set of tools to convert packets from capture files to hash files for use with Hashcat or John the Ripper.
MIT License
2.01k stars 392 forks source link

About using - o some questions #320

Closed LLH-l closed 1 year ago

LLH-l commented 1 year ago

@ZerBea Hello

Some questions about using hcxpcapngtool - o

e,g_1 5095.zip

791 Oct  1, 2015 21:00:24.793106000     1   2   de762b2eafd92f1c4365a09bba2c9c6f534baa4c79f0b357e2948d67aaace178    0.000000000 d8:00:4d:de:0e:8b   c8:3a:35:58:35:40
797 Oct  1, 2015 21:00:24.797696000     2   2   0f33866299db9db324c826479b8c473e39f2306a06ab6ab4aa5e52f1d0e5f1a9    0.004590000 c8:3a:35:58:35:40   d8:00:4d:de:0e:8b
798 Oct  1, 2015 21:00:24.811540000     3   3   de762b2eafd92f1c4365a09bba2c9c6f534baa4c79f0b357e2948d67aaace178    0.013844000 d8:00:4d:de:0e:8b   c8:3a:35:58:35:40
1217    Oct  1, 2015 21:00:25.712722000     1   4   de762b2eafd92f1c4365a09bba2c9c6f534baa4c79f0b357e2948d67aaace179    0.901182000 d8:00:4d:de:0e:8b   c8:3a:35:58:35:40
1221    Oct  1, 2015 21:00:25.716290000     2   4   56149eb314c34c3f61ff1ffc0035fcad1a9256dc923adc521d6e291b91bd8de8    0.003568000 c8:3a:35:58:35:40   d8:00:4d:de:0e:8b

When m1m3 NONCE same m1m2E2 equivalent m2m3E2

So, Should convert m2m3E2 Not convert m1m2E2

But it mistakenly chose to convert m1m2E2 In this case, it is impossible restore the authorized password !

e.g_2 2907.zip

710 Feb  1, 2016 02:58:15.035265000     1   1   02476e028f91745ee354238b1eac47e6d6ead37da46f91f536872ac2ccef98d1    0.000000000 00:26:b6:a5:28:a1   c4:a8:1d:8f:9f:b0
713 Feb  1, 2016 02:58:15.039873000     2   1   8c7d68cd80c5b0f5b6c4e103404f10ab317a9317f46958aef65cd65309664fe5    0.004608000 c4:a8:1d:8f:9f:b0   00:26:b6:a5:28:a1
1072    Feb  1, 2016 02:58:16.367041000     2   1   4915399d18006db2022fac6314b2c90a2a7a888e0127e388db036b52aa3986db    1.327168000 c4:a8:1d:8f:9f:b0   00:26:b6:a5:28:a1
1074    Feb  1, 2016 02:58:16.372673000     3   2   02476e028f91745ee354238b1eac47e6d6ead37da46f91f536872ac2ccef98d2    0.005632000 00:26:b6:a5:28:a1   c4:a8:1d:8f:9f:b0
1077    Feb  1, 2016 02:58:16.374721000     4   2   0000000000000000000000000000000000000000000000000000000000000000    0.002048000 c4:a8:1d:8f:9f:b0   00:26:b6:a5:28:a1

When m1m3 NONCE is different Priority should be given to selecting conversion authorization m2m3E2

If the m1m2E2 situation is converted, it will waste GPU time Ultimately, will result in failure recover the correct password

LLH-l commented 1 year ago

@ZerBea I checked many files, found many similar examples This is problem we need solve Although it may be very complex !

LLH-l commented 1 year ago

There is another question In this case, priority should be given to converting m1m2m4 ternary data packets It more reliable than only m1m2 data packets

2026    Jan 30, 2016 00:19:11.424986000     1   1   e1299b32f1795d984a37e11bb571a77ea5f527a9280d1f05e2e1182c549ed789    0.000000000 38:48:4c:ee:2a:3e   bc:f6:85:d2:a4:60
2028    Jan 30, 2016 00:19:11.428043000     2   1   3dcb11a11a18d0c40c446220ddfdefeb80a6f59bacdfcdf16f8bf8b7c5baa45b    0.003057000 bc:f6:85:d2:a4:60   38:48:4c:ee:2a:3e
2217    Jan 30, 2016 00:19:12.655898000     1   1   e1299b32f1795d984a37e11bb571a77ea5f527a9280d1f05e2e1182c549ed78a    1.221709000 38:48:4c:ee:2a:3e   bc:f6:85:d2:a4:60
2218    Jan 30, 2016 00:19:12.656922000     1   1   e1299b32f1795d984a37e11bb571a77ea5f527a9280d1f05e2e1182c549ed78a    0.001024000 38:48:4c:ee:2a:3e   bc:f6:85:d2:a4:60
2221    Jan 30, 2016 00:19:12.659994000     1   1   e1299b32f1795d984a37e11bb571a77ea5f527a9280d1f05e2e1182c549ed78a    0.003072000 38:48:4c:ee:2a:3e   bc:f6:85:d2:a4:60
2223    Jan 30, 2016 00:19:12.672537000     2   1   6d7228da46d536a86a81540b40bffa025fdafed7128dd72bb95e6a16af4c0b33    0.002543000 bc:f6:85:d2:a4:60   38:48:4c:ee:2a:3e
2224    Jan 30, 2016 00:19:12.674073000     2   1   6d7228da46d536a86a81540b40bffa025fdafed7128dd72bb95e6a16af4c0b33    0.001536000 bc:f6:85:d2:a4:60   38:48:4c:ee:2a:3e
2227    Jan 30, 2016 00:19:12.675265000     4   2   0000000000000000000000000000000000000000000000000000000000000000    0.008192000 bc:f6:85:d2:a4:60   38:48:4c:ee:2a:3e
ZerBea commented 1 year ago

I suppose we're talking about the automatic mode of hcxdumptool $ hcxdumptool -o test.22000 5095.cap

Criteria that a MESSAGEPAIR will be converted in this mode is the time gap between two EAPOL MESSAGES. Let's do some mathematics on 5095.cap:

$ tshark -r 5095.cap -Y "eapol" -T fields -e frame.number -e frame.time -e wlan_rsna_eapol.keydes.msgnr -e eapol.keydes.replay_counter -e wlan_rsna_eapol.keydes.nonce
791 Oct  1, 2015 15:00:24.793106000 CEST    1   2   de762b2eafd92f1c4365a09bba2c9c6f534baa4c79f0b357e2948d67aaace178
797 Oct  1, 2015 15:00:24.797696000 CEST    2   2   0f33866299db9db324c826479b8c473e39f2306a06ab6ab4aa5e52f1d0e5f1a9
798 Oct  1, 2015 15:00:24.811540000 CEST    3   3   de762b2eafd92f1c4365a09bba2c9c6f534baa4c79f0b357e2948d67aaace178
1217    Oct  1, 2015 15:00:25.712722000 CEST    1   4   de762b2eafd92f1c4365a09bba2c9c6f534baa4c79f0b357e2948d67aaace179
1221    Oct  1, 2015 15:00:25.716290000 CEST    2   4   56149eb314c34c3f61ff1ffc0035fcad1a9256dc923adc521d6e291b91bd8de8
M1M2    791/797     .797696000 - .793106000 =   4590000
M2M3    797/798     .811540000 - .797696000 =  13844000
M1M2    (1217/1221) .716299000 - .712722000 =   3577000

The lowest time gap is 3577000. This MESSAGEPAIR will be converted in automatic mode:

$ hcxpcapngtool 5095.cap -o test.22000
...
$ cat test.22000
WPA*02*e34a0e06ca45a7c3ee2537cc05d5fecb*c83a35583540*d8004dde0e8b*54656e64615f353833353430*de762b2eafd92f1c4365a09bba2c9c6f534baa4c79f0b357e2948d67aaace179*01030079fe010a0010000000000000000456149eb314c34c3f61ff1ffc0035fcad1a9256dc923adc521d6e291b91bd8de8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001add180050f20101000050f20401000050f20401000050f2020c00*a0

If you don't accept this behavior it is mandatory to run hcxdumptool with option --all and filter authorized MESSAGEPAIRs by hcxhashtool:

$ hcxpcapngtool 5095.cap -o test.22000
...
$ cat test.22000
WPA*02*e34a0e06ca45a7c3ee2537cc05d5fecb*c83a35583540*d8004dde0e8b*54656e64615f353833353430*de762b2eafd92f1c4365a09bba2c9c6f534baa4c79f0b357e2948d67aaace179*01030079fe010a0010000000000000000456149eb314c34c3f61ff1ffc0035fcad1a9256dc923adc521d6e291b91bd8de8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001add180050f20101000050f20401000050f20401000050f2020c00*a0
WPA*02*da4f97e9f14fbd9d06f92a9b79902691*c83a35583540*d8004dde0e8b*54656e64615f353833353430*de762b2eafd92f1c4365a09bba2c9c6f534baa4c79f0b357e2948d67aaace178*01030079fe010a001000000000000000020f33866299db9db324c826479b8c473e39f2306a06ab6ab4aa5e52f1d0e5f1a9000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001add180050f20101000050f20401000050f20401000050f2020c00*80
WPA*02*da4f97e9f14fbd9d06f92a9b79902691*c83a35583540*d8004dde0e8b*54656e64615f353833353430*de762b2eafd92f1c4365a09bba2c9c6f534baa4c79f0b357e2948d67aaace178*01030079fe010a001000000000000000020f33866299db9db324c826479b8c473e39f2306a06ab6ab4aa5e52f1d0e5f1a9000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001add180050f20101000050f20401000050f20401000050f2020c00*82
WPA*02*4a93be281c765cbcab19d341a2cf2323*c83a35583540*d8004dde0e8b*54656e64615f353833353430*0f33866299db9db324c826479b8c473e39f2306a06ab6ab4aa5e52f1d0e5f1a9*01030079fe01ca00100000000000000003de762b2eafd92f1c4365a09bba2c9c6f534baa4c79f0b357e2948d67aaace178000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001add180050f20101000050f20401000050f20401000050f2020c00*13

$ hcxhashtool -i test.22000 --authorized -o authorized.22000

OUI information file..........: /home/zerobeat/.hcxtools/oui.txt
OUI entries...................: 34205
total lines read..............: 4
valid hash lines..............: 4
EAPOL hash lines..............: 4
filter by status..............: authorized (M1M4, M2M3 or M3M4)
EAPOL written.................: 2

$ cat authorized.22000
WPA*02*da4f97e9f14fbd9d06f92a9b79902691*c83a35583540*d8004dde0e8b*54656e64615f353833353430*de762b2eafd92f1c4365a09bba2c9c6f534baa4c79f0b357e2948d67aaace178*01030079fe010a001000000000000000020f33866299db9db324c826479b8c473e39f2306a06ab6ab4aa5e52f1d0e5f1a9000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001add180050f20101000050f20401000050f20401000050f2020c00*82
WPA*02*4a93be281c765cbcab19d341a2cf2323*c83a35583540*d8004dde0e8b*54656e64615f353833353430*0f33866299db9db324c826479b8c473e39f2306a06ab6ab4aa5e52f1d0e5f1a9*01030079fe01ca00100000000000000003de762b2eafd92f1c4365a09bba2c9c6f534baa4c79f0b357e2948d67aaace178000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001add180050f20101000050f20401000050f20401000050f2020c00*13

I will not change the automatic mode, because: it is fast (e.g. on big dump files uploaded to https://wpa-sec.stanev.org) the chance to get a valid MESSAGEPAIR in case of packet loss is high

About m1m2m4: Neither hashcat nor JtR work on double MICs (MIC of M2 and MIC of M4), So there is absolutely no need to add an additional stage that convert a MESSAGETRIPPLE. And I guess none of the developers of hashcat and JtR will add this, because it will decrease the cracking speed (because the HMAC has to be calculated twice),

Just to mention that: The quality of the dump file is poor:

This dump file contains frames with out of sequence timestamps.
That is a bug of the capturing/cleaning tool.

Information: limited dump file format detected!
This file format is a very basic format to save captured network data.
It is recommended to use PCAP Next Generation dump file format (or pcapng for short) instead.
The PCAP Next Generation dump file format is an attempt to overcome the limitations
of the currently widely used (but very limited) libpcap (cap, pcap) format.
https://www.wireshark.org/docs/wsug_html_chunked/AppFiles.html#ChAppFilesCaptureFilesSection
https://github.com/pcapng/pcapng

Information: radiotap header is missing!
Radiotap is a de facto standard for 802.11 frame injection and
reception. The radiotap header format is a mechanism to supply
additional information about frames, from the driver to userspace
applications.
https://www.radiotap.org/

Warning: too many deauthentication/disassociation frames detected!
That can cause that an ACCESS POINT change channel, reset EAPOL TIMER,
renew ANONCE and set PMKID to zero.
This could prevent to calculate a valid EAPOL MESSAGE PAIR
or to get a valid PMKID.

Information: missing frames!
This dump file does not contain undirected proberequest frames.
An undirected proberequest may contain information about the PSK.
It always happens if the capture file was cleaned or
it could happen if filter options are used during capturing.
That makes it hard to recover the PSK.
ZerBea commented 1 year ago

Summary:

When m1m3 NONCE is different
Priority should be given to selecting conversion authorization m2m3E2

Definitely not in automatic mode because that need an additional stage that will slow down the entire conversion process. Use hcxpcapngtool --all and filter the MESSAGEPAIRs by hcxhashtool (--authorized). hcxpcapngtool designed to convert hashes (best, all). It is not designed to filter them. This is the task of hcxhastool.

If the m1m2E2 situation is converted, it will waste GPU time
Ultimately, will result in failure recover the correct password

Not for analysis purpose (e.g. get a password history, typos by user, weak points by system, detect an attack where the attacker types several passwords to get access to the NETWORK). Please notice, hcxtools are analysis tools - they are not designed to break the NETWORK of the old lady, living in the neighborhood.

If the m1m2E2 situation is converted, it will waste GPU time That is a problem caused by your workflow. Solution for this very special workflow on very poor quality dump files:

convert all MESSAGEPAIRs by hcxpcapngtool --all
filter whatever you want by hcxhashtool e.g. --authorized MESSAGEPAIRs
feed hashcat with this filtered hashes
I checked many files, found many similar examples
This is problem we need solve
Although it may be very complex !

This problem is solved by hcxpcapngtool/hcxhastool combination. Problem is your workflow.

LLH-l commented 1 year ago

Yes we are discussing automatic mode When using - o

89247   Jul 19, 2020 22:05:14.397322000     1   5   7ed660e02d7c3f6526fff75f755578de125dad44d8b11fc4ede257225a509b10    0.006147000 c8:14:51:07:39:25   f4:a5:9d:3a:46:b4
89261   Jul 19, 2020 22:05:14.410123000     1   5   7ed660e02d7c3f6526fff75f755578de125dad44d8b11fc4ede257225a509b10    0.012801000 c8:14:51:07:39:25   f4:a5:9d:3a:46:b4
89264   Jul 19, 2020 22:05:14.420353000     2   5   8c2834d6022124271a502df678cbc8df0a8a56e411c53e4b05962026a58e9a74    0.010230000 f4:a5:9d:3a:46:b4   c8:14:51:07:39:25
186360  Jul 19, 2020 22:28:51.409611000     1   3   9a8142736ff5413d7ae8fb636d8e318da593f092e365103b16d401a8c8b013c9    1416.989258000  c8:14:51:07:39:25   f4:a5:9d:3a:46:b4
186363  Jul 19, 2020 22:28:51.431098000     2   3   b31a03eb8b139c6423133c74dc2ed3cff35d1292f4669b8e015d3699024baa0e    0.021487000 f4:a5:9d:3a:46:b4   c8:14:51:07:39:25
186368  Jul 19, 2020 22:28:51.444929000     4   4   0000000000000000000000000000000000000000000000000000000000000000    0.013831000 f4:a5:9d:3a:46:b4   c8:14:51:07:39:25

e.g_3

If Packets 89261 and 89264 conversion were selected based on time priority Will face recovery failure

because ignored the more reliable m1m2m4 triple metadata package 186360-->186363-->186368 In fact, this data packet is more reliable than only m1m2 data packets

What I mean is, before preparing to convert m1m2E2, within the specified time interval, to detect whether there is still m3 or m4 message present.. If m3 or m4 exists, priority should be given, Thats why needs be changed

ZerBea commented 1 year ago

In fact, this data packet is more reliable than only m1m2 data packets Use --all and the PSK will be recovered.

We can't use that M4, because its SNONCE is zeroed. A not zeroed SNONCE is mandatory to make sure that it belongs to the same authentication sequence!

If you got a warning by hcxpcapngtool you should use --all, because the source is crappy. Heavy packet loss and an EAPOL M3 (authorization) is completely missing. The automatic can't handle this crappy dump files. And adding that to the automatic mode will have a huge speed impact.

ZerBea commented 1 year ago

In fact, this data packet is more reliable than only m1m2 data packets hcxpcapngtool doesn't know the PSK. If the time gap is greater than the other one, it will not convert it in automatic mode. You have the PSK, so it is easy for you to determine that this packet is more reliable. If you don't have the PSK, you can't determine it, too.

ZerBea commented 1 year ago

An example on a crappy dump file with heavy packet loss. We do not know the PSK at time of conversion

$ tshark -r example.pcap -Y "eapol" -T fields -e frame.number -e frame.time -e wlan_rsna_eapol.keydes.msgnr -e eapol.keydes.replay_counter -e wlan_rsna_eapol.keydes.mic -e wlan_rsna_eapol.keydes.nonce
2   Oct 24, 2023 10:17:09.729239000 CEST    1   4   00000000000000000000000000000000    eb82f8e7e920c83d3a4be0be73927591e1d384aa079d59eabd0e03ac3d0bd725
4   Oct 24, 2023 10:17:09.772278000 CEST    2   4   fe98d4dcfde1dc237f2b2f93d99eb766    99c87eaf0d8c97d12adcd5511725e4f07da69a98d492229748d42b834aec9b53
6   Oct 24, 2023 10:17:16.710595000 CEST    1   1   00000000000000000000000000000000    d0df2329a4399a7d993dd58a1dd1baf3075f42fb459cff26d138b108c2b0c9dc
8   Oct 24, 2023 10:17:16.761960000 CEST    2   1   fa0d6d1800cd49ff2475964f868e649f    2bf480cf09db23911976f135c8d21abee4f6b70553d15da22489160e0b510a86
10  Oct 24, 2023 10:17:16.766854000 CEST    4   2   8ae6822e43784059cb1860e02c68ac24    0000000000000000000000000000000000000000000000000000000000000000

Which MESSAGEPAIR is more reliable and should be converted by the automatic?

LLH-l commented 1 year ago

Which MESSAGEPAIR is more reliable and should be converted by the automatic?

Of course, choosing data packets with continuous m1m2m4 messages is more reliable

6   Oct 24, 2023 10:17:16.710595000 CEST    1   1   00000000000000000000000000000000    d0df2329a4399a7d993dd58a1dd1baf3075f42fb459cff26d138b108c2b0c9dc
8   Oct 24, 2023 10:17:16.761960000 CEST    2   1   fa0d6d1800cd49ff2475964f868e649f    2bf480cf09db23911976f135c8d21abee4f6b70553d15da22489160e0b510a86
10  Oct 24, 2023 10:17:16.766854000 CEST    4   2   8ae6822e43784059cb1860e02c68ac24    0000000000000000000000000000000000000000000000000000000000000000
ZerBea commented 1 year ago

Test environment:

TEST ACCESS POINT (WPA2 easy PSK) TEST CLIENT

TEST DUMP device (passive dumper) close to the border of the AP TRANSMIT range (so that we have a packet loss).

Now make up your own mind: example.pcap.zip

$ wget https://wpa-sec.stanev.org/dict/cracked.txt.gz
$ hcxpcapngtool -o example.22000 example.pcap
$ hashcat -m 22000 --potfile-disable -o example.txt example.22000 cracked.txt.gz

When hashcat finished, check which EAPOL MIC was taken to recover the PSK (compare MIC of hashcat out file with dump of tshark).

LLH-l commented 1 year ago

example.pcap.zip

Can be seen that 12345678 is not correct password Recovery is not the correct password, wasting GPU time (if not 12345678)

M1m2m4 is likely authorized password So, should convert m1m2m4 packet messages

6   Oct 24, 2023 10:17:16.710595000 CEST    1   1   00000000000000000000000000000000    d0df2329a4399a7d993dd58a1dd1baf3075f42fb459cff26d138b108c2b0c9dc
8   Oct 24, 2023 10:17:16.761960000 CEST    2   1   fa0d6d1800cd49ff2475964f868e649f    2bf480cf09db23911976f135c8d21abee4f6b70553d15da22489160e0b510a86
10  Oct 24, 2023 10:17:16.766854000 CEST    4   2   8ae6822e43784059cb1860e02c68ac24    0000000000000000000000000000000000000000000000000000000000000000
ZerBea commented 1 year ago

For sure, 12345678 is the correct password, because I added this to the configuration of the TEST AP. And my TEST CLIENT connected to the AP using this PSK and a stable connection was established.

The example dump file is really crappy and hcxpcapngtool throws several warnings.

At least we have three(!) authentication sequences: first

2   Oct 24, 2023 10:17:09.729239000 CEST    1   4   00000000000000000000000000000000    eb82f8e7e920c83d3a4be0be73927591e1d384aa079d59eabd0e03ac3d0bd725
4   Oct 24, 2023 10:17:09.772278000 CEST    2   4   fe98d4dcfde1dc237f2b2f93d99eb766    99c87eaf0d8c97d12adcd5511725e4f07da69a98d492229748d42b834aec9b53

second 6 Oct 24, 2023 10:17:16.710595000 CEST 1 1 00000000000000000000000000000000 d0df2329a4399a7d993dd58a1dd1baf3075f42fb459cff26d138b108c2b0c9dc

third

8   Oct 24, 2023 10:17:16.761960000 CEST    2   1   fa0d6d1800cd49ff2475964f868e649f    2bf480cf09db23911976f135c8d21abee4f6b70553d15da22489160e0b510a86
10  Oct 24, 2023 10:17:16.766854000 CEST    4   2   8ae6822e43784059cb1860e02c68ac24    0000000000000000000000000000000000000000000000000000000000000000

Due to missing frames (packet loss) there is only one authentication sequence (first) from which we can calculate a valid MESSAGE PAIR. On the second sequence we only have one M1 (M2 is missing). On the third sequence we only have one M2 and one M4 (m1 or M3 is missing),

If you use --all option you'll notice that hashcat got the PSK (12345678) only from the first MESSAGEPAIR.

Now the lesson learned: The automatic is fast and depending on the quality of the dump file you get a hit rate (valid MESSAGEPAIRs) of something between 50% and 100%. If the dump file is crappy, the automatic may fail and it is mandatory to convert all hashes.

Due to REUSE of PBKDF2, the speed impact is low.

$ hcxpcapngtool -o automatic.22000 example.pcap
$ time hashcat -m 22000 --nonce-error-corrections=0 --potfile-disable automatic.22000 cracked.txt.gz
fe98d4dcfde1dc237f2b2f93d99eb766:0896d798e19e:74da38f2038e:AP_7272:12345678

Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 22000 (WPA-PBKDF2-PMKID+EAPOL)
Hash.Target......: automatic.22000
Time.Started.....: Tue Oct 24 15:45:01 2023 (0 secs)
Time.Estimated...: Tue Oct 24 15:45:01 2023 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Base.......: File (cracked.txt.gz)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:  1365.4 kH/s (6.48ms) @ Accel:4 Loops:256 Thr:512 Vec:1
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Progress.........: 155648/517531 (30.08%)
Rejected.........: 0/155648 (0.00%)
Restore.Point....: 0/517531 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidate.Engine.: Device Generator
Candidates.#1....: 12345678 -> uyPGNyfU
Hardware.Mon.#1..: Temp: 52c Fan:  0% Util: 61% Core:2835MHz Mem:10802MHz Bus:16

Started: Tue Oct 24 15:45:00 2023
Stopped: Tue Oct 24 15:45:02 2023

real    0m1,463s
user    0m0,169s
sys 0m0,366s

versus

$ hcxpcapngtool  --all -o all.22000 example.pcap
fe98d4dcfde1dc237f2b2f93d99eb766:0896d798e19e:74da38f2038e:AP_7272:12345678
Approaching final keyspace - workload adjusted.           

Session..........: hashcat
Status...........: Exhausted
Hash.Mode........: 22000 (WPA-PBKDF2-PMKID+EAPOL)
Hash.Target......: all.22000
Time.Started.....: Tue Oct 24 15:47:59 2023 (1 sec)
Time.Estimated...: Tue Oct 24 15:48:00 2023 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Base.......: File (cracked.txt.gz)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:   660.5 kH/s (1.89ms) @ Accel:16 Loops:256 Thr:128 Vec:1
Recovered........: 1/2 (50.00%) Digests (total), 1/2 (50.00%) Digests (new)
Progress.........: 517531/517531 (100.00%)
Rejected.........: 1/517531 (0.00%)
Restore.Point....: 517531/517531 (100.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:1-3
Candidate.Engine.: Device Generator
Candidates.#1....: 52187171 -> 541700777
Hardware.Mon.#1..: Temp: 36c Fan:  0% Util: 10% Core:2850MHz Mem:10802MHz Bus:16

Started: Tue Oct 24 15:47:59 2023
Stopped: Tue Oct 24 15:48:01 2023

real    0m2,457s
user    0m0,580s
sys 0m0,413s

You may have noticed hashcat failed to recover the MESSGAEPAIR of the third AUTHENTICATION sequence due to missing frames.

I'll say that it is not a good idea to run hcxpcapngtool, hcxhashtool or hashcat with default options on crapy dump files. On every case, the automatic can't handle this at 100%. Regardless if we convert M1M2 or M1M2M4, the chance to fail is at 50% running this mode. If you want 100% it is mandatory to convert all possible hashes.

ZerBea commented 1 year ago

Maybe I haven't explained it in detail yet. README.md contain some suggestions about hardware, operating system and workflow. If you follow this recommendations (workflow: hcxdumptool -> hcxpcapngtool -> hcxhashtool/hceeiutool/hcxpsktool -> hashcat/JtR), everything is working like a charm. Even if this drivers are not recommended (but part stock Linux kernel) the entire process (request hash -> convert hash -> recover PSK) is really fast: https://github.com/ZerBea/hcxdumptool/issues/355#issuecomment-1777665874 https://github.com/ZerBea/hcxdumptool/issues/355#issuecomment-1777681880

I'm not going to customize this tools to make them work on:

And I don't add functions (in favor of other tools) that slow hcxdumtool/hcxtools down.

If you don't follow the recommendations you'll run into serious problems.

LLH-l commented 1 year ago

Ok, Not be discussed temporarily

ZerBea commented 1 year ago

I mistakenly thought that is clear.

Everything that is not inside the dump file (e.g. missing frames) is gone for ever(!) and absolutely nothing can bring it back. Even an epic password recovery machine (e.g. of 8 RTX4090) will mostly fail due to crappy data. That applies to the conversion tool (e.g. hcxpcapngtool), too.

The most important parts of such a penetration testing system (not the CPU, not the GPU):

In this case (and only in this case) you can expect good results, even on a small GPU, e,g, like mine:

$ nvidia-smi
Thu Oct 26 09:46:42 2023       
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.113.01             Driver Version: 535.113.01   CUDA Version: 12.2     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA GeForce GTX 1650        Off | 00000000:01:00.0 Off |                  N/A |
| N/A   27C    P8               1W /  30W |      5MiB /  4096MiB |      0%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+

+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
+---------------------------------------------------------------------------------------+

The philosophy should always be: capture everything (online) and filter later on what you want (offline)

ZerBea commented 1 year ago

A good example for this is here: https://github.com/ZerBea/hcxdumptool/issues/355#issuecomment-1777665874 Frames addressed to BROADCAST MAC are filtered out during capturing process and they are gone forever. Nothing can bring them back.

ZerBea commented 1 year ago

Adding more or less complex code to the conversion tool will only fight the symptoms (and make the entire process slow). But it will never fight the cause. That is the reason, why I do not add some of your requests to hcxpcapngtool.