12x GPU Monster For SALE by HashKiller Owner

NOTE: Why not use our List Manager to crack your lists? Its easy and enables better management.

NOTE: When cracking WPA/WPA2 passwords, make sure you check gpuhash.me first incase it's already been processed.

Home - Wireless Cracking - Warning about problem in the new cap2hccapx converter


23 Results - Page 1 of 1 -
1
Author Message
Avatar
Gort

Status: Trusted
Joined: Mon, 16 Jan 2017
Posts: 183
Team:
Reputation: 170 Reputation
Offline
Fri, 10 Feb 2017 @ 11:48:34

I have just found a very subtle bug in the cap2hccapx converter, which
generates invalid handshake results in the output hccapx file.

The problem arises in the code used to check the timing relationship
between the handshake messages. The logic of these checks is not correct.

The window used for the checks is 2s, which seems far too large to me.
I would have expected something closer to 200ms between related EAPOL
frames.

Anyway, just going with the 2s window for now, the Time of Arrival (ToA)
between handshake message 1 (M1) and handshake message 2 (M2) is
checked with this logic:

IF (ToA of M1 + 2) < ToA of M2) THEN skip handshake ELSE process handshake
(Notice that this is deliberately inverted logic. If the expression is TRUE,
the handshaked is skipped, if the expression is FALSE it gets processed)

The intent of the code was to allow something like

+100 M1
+101 M2
+102
+103

but discard something like

+100 M1
+101
+102
+103 M2

However, it all goes horribly wrong if there is something like this in the
capture:

+100 M2
+101
+102
+103 M1

Now, (ToA of M1 + 2) < ToA of M2) is FALSE and the handshakes gets
erroneously processed as valid and a bogus unauthenticated handshake
goes into the hccapx output.

What is missing is an initial check to ensure that (ToA M1 < ToA M2),
before doing the test with the 2s window. Alternatively, ToA M1
could simply be subtracted from ToA M2 and a check made to see if
there is a postive result less than the window.

The same problem arises with the timing comparison between M2 and M3,
but that one generates a bogus authenticated handshake.

As Hashcat is presumably going to try to compute the MIC from
every candidate handshake in the hccapx, these bogus ones may not
always be a problem, but I can easily imagine a capture with an
assortment of EAPOL frames that will generate nothing but bogus
handshakes.

I have patched my local copy of cap2hccapx.c to add the extra logic
checks and it has eliminated the two bogus handhakes I was seeing
from the capture file I am currently testing with.

Still think that the timing window of 2s is too big for EAPOL,
but that is another issue....


BTC: 12QTTgtbSHqxseW2Hnt5qzrngvBRXgTEj4

Avatar
Gort

Status: Trusted
Joined: Mon, 16 Jan 2017
Posts: 183
Team:
Reputation: 170 Reputation
Offline
Fri, 10 Feb 2017 @ 13:49:57

Tried to post this information onto the Hashcat forum, but cannot get past their spam
filter to register without compromising my location, so given up trying to notify them!

If anyone can at least get them to look at this thread, it might be possible to
get a fix implemented.



BTC: 12QTTgtbSHqxseW2Hnt5qzrngvBRXgTEj4

Avatar
hashcat

Status: n/a
Joined: Sat, 16 Aug 2014
Posts: 1
Team: hashcat
Reputation: 0 Reputation
Offline
Fri, 10 Feb 2017 @ 15:11:57

Thanks for the report, I've pushed the fixes to GitHub repository and updated the beta on https://hashcat.net/beta/

About the eapol TTL, we're unable to find any official reference or suggestions. You say you'd expect 200ms, but why?

Please use the github issue for discussion or for sending in bugs, not the forums. We're just lucky that someone send us the link.


Avatar
gpuhash_me

Status: Trusted
Joined: Sun, 08 Nov 2015
Posts: 855
Team: gpuhash team
Reputation: 1602 Reputation
Online
Fri, 10 Feb 2017 @ 15:55:30

Introducing hccapx format wasn't good idea IMO.
They could have the same result just merging two or more hccap files with same ESSID but with different nonces and MIC fields so you will crack several type 2500 hashes with 1 salt only.
We are processing captures this way and quite happy with it.


Head of cheap publicity department
Support, discounts, free offers for HK members
BTC: 1GPUHASHckzcL2fDXyGSc2WNqpFjJZbFaN

Avatar
blandyuk
Admin / Owner
Status: Trusted
Joined: Tue, 05 Jul 2011
Posts: 3219
Team: HashKiller
Reputation: 7731 Reputation
Online
Fri, 10 Feb 2017 @ 16:24:40

I disagree! The cap2hccapx binary exports all possible handshakes for the specific SSID at no cost of speed. I do not think the other methods of exporting the hccap data does this affectively and most certainly, not easily.

I have used the hccapx format already and its much better. I find it more reliable.


Please read the forum rules | Please read the paid section rules
I accept private hash lists, with forum donations only.
BTC: 1JZGVq58m4RS1QQS8JE5xndzDFy2BvGU6y
GPU Power: 9x GTX 1070 + 6x GTX 1080

Avatar
Gort

Status: Trusted
Joined: Mon, 16 Jan 2017
Posts: 183
Team:
Reputation: 170 Reputation
Offline
Fri, 10 Feb 2017 @ 16:36:35

hashcat said:

Thanks for the report, I've pushed the fixes to GitHub repository and updated the beta on https://hashcat.net/beta/

About the eapol TTL, we're unable to find any official reference or suggestions. You say you'd expect 200ms, but why?

Your fix looks good to me.

For the 200ms, if you have no references, I could equally ask why you chose 2s

If you look in 802.11, the Authenticator timeout is defined as 100ms, so the AP is going
to start retransmitting M1 after 100ms if it has not seen M2 from the STA. So, I could
make an argument that the window between EAPOL for reliably sniffing handshakes
is more like 100ms.

A lot can happen in 2s, especially if the AP is being hammered with deauthentications
which trigger it to keep restarting Security Associations. I think having a window of
2s is not a good choice, unless you have a specific justification for it.

Edit: If you want an exact reference, check IEEE Std 802.11-2012, section 11.6.6.6


BTC: 12QTTgtbSHqxseW2Hnt5qzrngvBRXgTEj4

Avatar
Gort

Status: Trusted
Joined: Mon, 16 Jan 2017
Posts: 183
Team:
Reputation: 170 Reputation
Offline
Fri, 10 Feb 2017 @ 17:31:33

gpuhash_me said:

Introducing hccapx format wasn't good idea IMO.
They could have the same result just merging two or more hccap files with same ESSID but with different nonces and MIC fields so you will crack several type 2500 hashes with 1 salt only.
We are processing captures this way and quite happy with it.

The hccapx format is going to be big improvement for most. Not sure what you are doing to
have a problem with it?

The expensive operation is deriving the PMK for a SSID/passphrase pair. Once Hashcat
has the PMK it can verify multiple candidate handshakes at the essentially zero overhead
of running one HMAC-SHA1 for each. If any of the handshake candidates gets a matching
MIC, the job is done (even in the presence of bad handshakes)


BTC: 12QTTgtbSHqxseW2Hnt5qzrngvBRXgTEj4

Avatar
gpuhash_me

Status: Trusted
Joined: Sun, 08 Nov 2015
Posts: 855
Team: gpuhash team
Reputation: 1602 Reputation
Online
Fri, 10 Feb 2017 @ 17:42:09

blandyuk said:

I disagree! The cap2hccapx binary exports all possible handshakes for the specific SSID at no cost of speed. I do not think the other methods of exporting the hccap data does this affectively and most certainly, not easily.

I have used the hccapx format already and its much better. I find it more reliable.

No doubt exporting possible nonce/MIC pairs for given ESSID is great idea.
But why we need new file format?
Just check hccapx binary specs, it holds the same amount of data as hccap except of authenticated flag (just 1 bit) which could be stored anywhere in unused 4 bytes of hccap (FIY at offset 0x20 hccap have 4 spare bytes because long time ago they decided ESSID string could be 36 bytes long - WRONG!) and it would be backward compatible with previous versions of hashcat.


https://hashcat.net/wiki/lib/exe/fetch.php?media=hccapx_specs.jpg

https://hashcat.net/wiki/lib/exe/fetch.php?cache=&media=hccap_specs.png


Head of cheap publicity department
Support, discounts, free offers for HK members
BTC: 1GPUHASHckzcL2fDXyGSc2WNqpFjJZbFaN

Avatar
Gort

Status: Trusted
Joined: Mon, 16 Jan 2017
Posts: 183
Team:
Reputation: 170 Reputation
Offline
Fri, 10 Feb 2017 @ 17:58:37

gpuhash_me said:


No doubt exporting possible nonce/MIC pairs for given ESSID is great idea.
But why we need new file format?
Just check hccapx binary specs, it holds the same amount of data as hccap except of authenticated flag (just 1 bit) which could be stored anywhere in unused 4 bytes of hccap (FIY at offset 0x20 hccap have 4 spare bytes because long time ago they decided ESSID string could be 36 bytes long - WRONG!) and it would be backward compatible with previous versions of hashcat.

Well, I agree that the lack of backward compatibility is a problem. I am stuck with hardware
running under Linux that currently has no good drivers for the latest Hashcat, so I have to
use an earlier open source version. I have been creating my own converter from hccapx
to a single hccap. This is why I was concerned about these bad handshakes getting created
from that EAPOL TTL bug. As it stands, I still have to choose one hccapx structure to put
into my hccap and I am favoring the last authenticated one, as it is furthest from the
deauthentication noise.

I have considered backporting the hccapx support into the hashcat version I am using,
but that is more work that I need right now. A private converter from hccapx to hccap
seems the easiest fix for the short term.


BTC: 12QTTgtbSHqxseW2Hnt5qzrngvBRXgTEj4

Avatar
Gort

Status: Trusted
Joined: Mon, 16 Jan 2017
Posts: 183
Team:
Reputation: 170 Reputation
Offline
Fri, 10 Feb 2017 @ 19:11:24

Double post deleted.
See next in thread.


BTC: 12QTTgtbSHqxseW2Hnt5qzrngvBRXgTEj4

Avatar
Gort

Status: Trusted
Joined: Mon, 16 Jan 2017
Posts: 183
Team:
Reputation: 170 Reputation
Offline
Fri, 10 Feb 2017 @ 19:11:59

Gort said:


Edit: If you want an exact reference, check IEEE Std 802.11-2012, section 11.6.6.6

Anyone interested, you can download your own copy of 802.11 at

http://standards.ieee.org/getieee802/download/802.11-2012.pdf

Select User Type: Academic/Student (or whatever)

No confirmation loop on the email address, so you can put a random in there if
you don't want any spam back (I am sure the IEEE spam is very good quality)


BTC: 12QTTgtbSHqxseW2Hnt5qzrngvBRXgTEj4

Avatar
gpuhash_me

Status: Trusted
Joined: Sun, 08 Nov 2015
Posts: 855
Team: gpuhash team
Reputation: 1602 Reputation
Online
Sun, 12 Feb 2017 @ 11:21:22

While testing new hccapx format we noticed very strange hashcat behaviour.
Our testbed setup: fresh git cloned hashcat, one radeon HD 7850 and three synthetic handshakes with the same essid, bssid, stmac fields but different nonces and mic fields (all three handshakes have known 8 digits passwords and authenticated flag cleared hence we simulating three different handshakes of the same AP-station).
You can download these handshakes below.
When we ran test1.hccapx-test3.hccapx one by one with ?d?d?d?d?d?d?d?d mask all 3 passwords were found.
But with combined test_all.hccapx hashcat finds first password, then its hashing speed indicator suddenly grows up to ~12MH/s (one HD 7850 and WPA hash type, hmmm) and it finishes all 8 digits keyspace in less than 30 seconds.
No additional passwords were found as well.
Gort could you please try the similar test?


Head of cheap publicity department
Support, discounts, free offers for HK members
BTC: 1GPUHASHckzcL2fDXyGSc2WNqpFjJZbFaN

Attachments: Login to view attachments.
Avatar
blandyuk
Admin / Owner
Status: Trusted
Joined: Tue, 05 Jul 2011
Posts: 3219
Team: HashKiller
Reputation: 7731 Reputation
Online
Sun, 12 Feb 2017 @ 12:24:15

This is because of the new way hashcat deals with multiple handshakes. As part of the cap2hccapx process, it exports ALL the handshakes, not just one like the old hccap does. This is to ensure that hashcat is more likely to have a valid handshake to crack and it does not affect the speed assuming we have just one SSID for however many handshakes.

This has caused the speeds to show as mentioned above. It's basically [speed] * [hand-shakes].


Please read the forum rules | Please read the paid section rules
I accept private hash lists, with forum donations only.
BTC: 1JZGVq58m4RS1QQS8JE5xndzDFy2BvGU6y
GPU Power: 9x GTX 1070 + 6x GTX 1080

Avatar
Gort

Status: Trusted
Joined: Mon, 16 Jan 2017
Posts: 183
Team:
Reputation: 170 Reputation
Offline
Sun, 12 Feb 2017 @ 12:54:44

gpuhash_me said:

When we ran test1.hccapx-test3.hccapx one by one with ?d?d?d?d?d?d?d?d mask all 3 passwords were found.
But with combined test_all.hccapx hashcat finds first password, then its hashing speed indicator suddenly grows up to ~12MH/s (one HD 7850 and WPA hash type, hmmm) and it finishes all 8 digits keyspace in less than 30 seconds.
No additional passwords were found as well.
Gort could you please try the similar test?

I cracked each of your hccapx separately, so that I could understand
exactly what you are trying to do here.

test1.hccapx 04020310
test2.hccapx 14010591
test3.hccapx 37777772

Then, you have concatenated these three hccapx into a single
test_all.hccapx and tried to crack that?

This is not a valid test from my understanding. When Hashcat
is given a hccapx file with multiple hccapx structure, its
only aim is to get one matching MIC for the set of candidate
handshakes in the hccapx file.

The assumption is that all hccapx structures in the hccapx file
relate to the same PMK, or passphrase/SSID combination.

I do not think it is possible to crack multiple passphrases for
the same SSID in a single hccapx file.


BTC: 12QTTgtbSHqxseW2Hnt5qzrngvBRXgTEj4

Avatar
gpuhash_me

Status: Trusted
Joined: Sun, 08 Nov 2015
Posts: 855
Team: gpuhash team
Reputation: 1602 Reputation
Online
Sun, 12 Feb 2017 @ 13:13:19

blandyuk said:

This is because of the new way hashcat deals with multiple handshakes. As part of the cap2hccapx process, it exports ALL the handshakes, not just one like the old hccap does. This is to ensure that hashcat is more likely to have a valid handshake to crack and it does not affect the speed assuming we have just one SSID for however many handshakes.

This has caused the speeds to show as mentioned above. It's basically [speed] * [hand-shakes].

We have physical WPA speed 85 kH/s with our test setup and just 3 handshakes, so 12 MH/s is wrong figure anyway. Also searching 8 digits with our speed should finish in ~20 minutes, not in 30 seconds.


Head of cheap publicity department
Support, discounts, free offers for HK members
BTC: 1GPUHASHckzcL2fDXyGSc2WNqpFjJZbFaN

Avatar
gpuhash_me

Status: Trusted
Joined: Sun, 08 Nov 2015
Posts: 855
Team: gpuhash team
Reputation: 1602 Reputation
Online
Sun, 12 Feb 2017 @ 13:26:47

Gort said:


This is not a valid test from my understanding. When Hashcat
is given a hccapx file with multiple hccapx structure, its
only aim is to get one matching MIC for the set of candidate
handshakes in the hccapx file.

MIC depends on PMK, both nonces, bssid and stmic fields. While bssid and stmic usually constants within one capture, nonces change between handshake sessions, so MIC fields will be completely different between handshakes too.
Selecting just one MIC you select just one handshake while you can try all possible at no cost.
For example if you have two unauthenticated handshakes with the same ESSID value you can't be sure they will both have the same password. Generally speaking they can have different passwords (one true and one false for example) and you can find them both at no cost.


Head of cheap publicity department
Support, discounts, free offers for HK members
BTC: 1GPUHASHckzcL2fDXyGSc2WNqpFjJZbFaN

Avatar
Gort

Status: Trusted
Joined: Mon, 16 Jan 2017
Posts: 183
Team:
Reputation: 170 Reputation
Offline
Sun, 12 Feb 2017 @ 13:59:26

gpuhash_me said:


MIC depends on PMK, both nonces, bssid and stmic fields. While bssid and stmic usually constants within one capture, nonces change between handshake sessions, so MIC fields will be completely different between handshakes too.
Selecting just one MIC you select just one handshake while you can try all possible at no cost.
For example if you have two unauthenticated handshakes with the same ESSID value you can't be sure they will both have the same password. Generally speaking they can have different passwords (one true and one false for example) and you can find them both at no cost.

I still cannot see how you can verify two passphrases at no cost?

Each passphrase results in a different PMK, so you have to do an
expensive PMK derivation for each one.

Have you confirmed this understanding with the Hashcat team?


BTC: 12QTTgtbSHqxseW2Hnt5qzrngvBRXgTEj4

Avatar
gpuhash_me

Status: Trusted
Joined: Sun, 08 Nov 2015
Posts: 855
Team: gpuhash team
Reputation: 1602 Reputation
Online
Sun, 12 Feb 2017 @ 14:12:49

Gort said:


I still cannot see how you can verify two passphrases at no cost?

Each passphrase results in a different PMK, so you have to do an
expensive PMK derivation for each one.

You have two unauthenticated handshakes with the same ESSID (salt) but with different nonces/MIC.
For every given password you calculate PMK as PBKDF2 (password, ESSID) <- this operation is expensive, 4096 hmac_sha1 loops
Then using this PMK value you calculate PTK and MIC for every given nonce/MIC pair and compare MIC <- these operations much easier, four hmac_sha1 to calc PTK and hmac_sha1 or hmac_md5 to calc MIC

Please correct me if I wrong.

Gort said:


Have you confirmed this understanding with the Hashcat team?

I'm afraid hashcat team have very basic understanding how WPA auth works. We already pulled similar patch a year ago. Hope we could prepare new one.

Anyway it looks like the new hccapx is not ready for production yet.


Head of cheap publicity department
Support, discounts, free offers for HK members
BTC: 1GPUHASHckzcL2fDXyGSc2WNqpFjJZbFaN

Avatar
Gort

Status: Trusted
Joined: Mon, 16 Jan 2017
Posts: 183
Team:
Reputation: 170 Reputation
Offline
Sun, 12 Feb 2017 @ 14:38:21

gpuhash_me said:


You have two unauthenticated handshakes with the same ESSID (salt) but with different nonces/MIC.
For every given password you calculate PMK as PBKDF2 (password, ESSID) <- this operation is expensive, 4096 hmac_sha1 loops
Then using this PMK value you calculate PTK and MIC for every given nonce/MIC pair and compare MIC <- these operations much easier, four hmac_sha1 to calc PTK and hmac_sha1 or hmac_md5 to calc MIC

Please correct me if I wrong.

Yes, I agree this is exactly what you can do, but only for a single passphrase
has been pushed through PBKDF2 to get the PMK. This is also exactly what
Hashcat does with the multiple handshake in the hccapx from my understanding.

Also correct that the overhead in checking multiple MICs against on PMK is
very low. I would need to double check the four HMAC-SHA1. I think you
might be able to do it in less, because the MIC verification key is early in
the PTK and you don't need to create all of PTK block?

But, I thought earlier you were saying that two unauthenticated handshakes
could have different passphrases and you expected to discover both of those
passphrases from a single hccapx at no extra cost?

I probably misunderstood what you were saying there?


BTC: 12QTTgtbSHqxseW2Hnt5qzrngvBRXgTEj4

Avatar
gpuhash_me

Status: Trusted
Joined: Sun, 08 Nov 2015
Posts: 855
Team: gpuhash team
Reputation: 1602 Reputation
Online
Sun, 12 Feb 2017 @ 18:59:41

Gort said:

But, I thought earlier you were saying that two unauthenticated handshakes
could have different passphrases and you expected to discover both of those
passphrases from a single hccapx at no extra cost?

Two unauthenticated handshakes with different passwords is quite common thing. Imagine one capturing handshakes and trying to connect to AP with simple password like '12345678' at the same time.
He will capture several handshakes with different passwords.
If handshake containing true password was caught unauthenticated you can't distinguish which handshake should be cracked.
But once you calculated PMK you can try all handshakes then with the same ESSID with low overhead. That is why rainbow tables were used long time ago to crack WPA with common ESSIDs.

By the way we use the same approach in our proof-of-work system. We inject synthetic handshakes with false passwords into hccap chain then check whether our workers find all these passwords.
This approach gives us proof that worker really processed task unit and also early reports hardware problems which can lead to skipping true passwords.


Head of cheap publicity department
Support, discounts, free offers for HK members
BTC: 1GPUHASHckzcL2fDXyGSc2WNqpFjJZbFaN

Avatar
Gort

Status: Trusted
Joined: Mon, 16 Jan 2017
Posts: 183
Team:
Reputation: 170 Reputation
Offline
Sun, 12 Feb 2017 @ 20:13:27

gpuhash_me said:


But once you calculated PMK you can try all handshakes then with the same ESSID with low overhead. That is why rainbow tables were used long time ago to crack WPA with common ESSIDs.

I am still struggling to understand this part.

I remember in the past when people would run an entire dictionary through
against a common SSID and produce a database of PMK for the SSID. That was
when you might find several networks called dlink for example.

So, you expend time creating the PMK database for dlink in the hope that you
find another network in the future with the SSID of dlink and then you can do
a super fast crack against your database of PMK for one specific precomputed
dictionary.

But now, SSIDs are all pretty much unique, because they have parts of MAC
address or some other pseudo-random string appended to them.

If you have computed a PMK from a passphrase for one of these essentially
unique SSIDs and it is unique enough that you cannot have already created
a PMK database for the SSID, all you can do is run an OK/NOTOK test for a
single passphrase against the MIC of each unauthenticated handshake.

But, isn't that what Hashcat does with them anyway?

Or, are you saying Hashcat will terminate with a crack on the first MIC it
matches from the hccapx and that MIC could be from an unauthenicated
handshake with some spurious passphrase and the true passphrase of
the AP is missed completely?

But how could Hashcat ever solve this problem? It would have to
continue running, trying more and more PMK from different passphrases
until it had cracked every single unauthenticated handshake? Even then, it
could never be sure to have the true AP passphrase, because all of
the unauthenticated handshakes could be bogus?

I am wondering if I will ever understand your logic on this issue?

Not expecting you to share any proprietary secret magic that you
do to crack things quicker than the competition, but if you can clarify
any further, I would be really interested to understand what I am
missing here.



BTC: 12QTTgtbSHqxseW2Hnt5qzrngvBRXgTEj4

Avatar
gpuhash_me

Status: Trusted
Joined: Sun, 08 Nov 2015
Posts: 855
Team: gpuhash team
Reputation: 1602 Reputation
Online
Sun, 12 Feb 2017 @ 21:04:36

Gort said:

But how could Hashcat ever solve this problem? It would have to
continue running, trying more and more PMK from different passphrases
until it had cracked every single unauthenticated handshake? Even then, it
could never be sure to have the true AP passphrase, because all of
the unauthenticated handshakes could be bogus?

I am wondering if I will ever understand your logic on this issue?

Hashcat should continue searching for every unauthenticated handshake or stop when it finds authenticated handshake password.
That is why they added authenticated flag to hccapx.

You are right, for unatuhenticated handshakes we can't be sure we found true password or all found passwords are false. But you will surprised how many unauthenticated handshakes we see in the wild, more than 50%.
So we should find all possible passwords, in any words try all possible MICs.

I basically found why hashcat shows so strange behaviour with mixed hccapx salts, it is due to wrong salt skipping logic.
But I need more testing now before pushing pull request.


Head of cheap publicity department
Support, discounts, free offers for HK members
BTC: 1GPUHASHckzcL2fDXyGSc2WNqpFjJZbFaN

Avatar
Gort

Status: Trusted
Joined: Mon, 16 Jan 2017
Posts: 183
Team:
Reputation: 170 Reputation
Offline
Mon, 13 Feb 2017 @ 11:24:42

gpuhash_me said:


You are right, for unatuhenticated handshakes we can't be sure we found true password or all found passwords are false. But you will surprised how many unauthenticated handshakes we see in the wild, more than 50%.
So we should find all possible passwords, in any words try all possible MICs.

I think we are looking at this from totally different standpoints.

For me, WPA is just an amusing hobby, I am not trying to run a cracking service.

So, I treat any unauthenticated handshake as a fail. I am simply not interested in
them at all. I will just try to capture again until I get an authenticated one.

Specifically cracking unauthenticated clients is a corner case that is rarely
even worth my time to look at.

Now, you probably get all sorts of randoms submitting handshakes and you have
no idea what they have done to get them, or what their motivations are.

Maybe, they are so desperate to get a handshake, they have set up their own
client with some dumb passphrase of 12345678 and they submit that to you
not really understanding how WPA works?

Anyway, if I was running a cracking service (again, which I am not!), I would
probably welcome hccapx, because it just gives me more information about
what I am dealing with.

Take an example you get a hccapx of EEBrightBox-XXXXXX being submitted
and it only contains unauthenticated handshakes. With the right dictionaries,
this would be an easy job for default passphrase.

With an authenticated handshake, you probably have very good chance of
success, but with only unauthenticated, the chances are less.

For a business model, I would be inclined to charge someone more to run
unauthenticated handshakes in this case, because I am more likely to waste
my own resource on it.

YMMV


BTC: 12QTTgtbSHqxseW2Hnt5qzrngvBRXgTEj4


23 Results - Page 1 of 1 -
1

We have a total of 201707 messages in 24862 topics.
We have a total of 22156 registered users.
Our newest registered member is sajixvii.