Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

About using - o some questions #320

Closed
LLH-l opened this issue Oct 24, 2023 · 17 comments
Closed

About using - o some questions #320

LLH-l opened this issue Oct 24, 2023 · 17 comments

Comments

@LLH-l
Copy link

LLH-l commented Oct 24, 2023

@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
Copy link
Author

LLH-l commented Oct 24, 2023

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

@LLH-l
Copy link
Author

LLH-l commented Oct 24, 2023

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
Copy link
Owner

ZerBea commented Oct 24, 2023

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 ZerBea closed this as completed Oct 24, 2023
@ZerBea
Copy link
Owner

ZerBea commented Oct 24, 2023

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
Copy link
Author

LLH-l commented Oct 24, 2023

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
Copy link
Owner

ZerBea commented Oct 24, 2023

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
Copy link
Owner

ZerBea commented Oct 24, 2023

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
Copy link
Owner

ZerBea commented Oct 24, 2023

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
Copy link
Author

LLH-l commented Oct 24, 2023

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
Copy link
Owner

ZerBea commented Oct 24, 2023

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
Copy link
Author

LLH-l commented Oct 24, 2023

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
Copy link
Owner

ZerBea commented Oct 24, 2023

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
Copy link
Owner

ZerBea commented Oct 25, 2023

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:
ZerBea/hcxdumptool#355 (comment)
ZerBea/hcxdumptool#355 (comment)

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

  • proprietary operating systems
  • other distributions (mostly not well configured by default)
  • other tools than hashcat, JtR, tshark, WireShark, tcpdump
  • third party drivers (not part of the stock Linux kernel)

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
Copy link
Author

LLH-l commented Oct 26, 2023

Ok, Not be discussed temporarily

@ZerBea
Copy link
Owner

ZerBea commented Oct 26, 2023

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):

  • high gain antenna
  • high gain device
  • dump tool that capture everything and request missing frames

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
Copy link
Owner

ZerBea commented Oct 26, 2023

A good example for this is here:
ZerBea/hcxdumptool#355 (comment)
Frames addressed to BROADCAST MAC are filtered out during capturing process and they are gone forever.
Nothing can bring them back.

@ZerBea
Copy link
Owner

ZerBea commented Oct 26, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants