How to see when over the 15 char limit?

[Kgx Pnqvhm]

oclHashcat-plus has the password-length maximum of 15 characters, but if gone over, where do we see the unused attempts in the status screens?

In other words, how does oclHashcat-plus tell us we've gone over the 15 chars?

(Background info: I'm trying to divide the work between the CPU and GPU hashcats, so need to run 15 chars and below on the GPU program, and above 15 on the CPU version.)

[M@LIK]

Code:

Rejected.....: 59269488/133906311 (44.26%)

[Kgx Pnqvhm]

Code:

Rejected.....: 59269488/133906311 (44.26%)

I posted this question after testing a wordlist of 21 character rules with a rule that added 5 characters, that showed 0 rejected.

So I figured that "Rejected" means by the algorithm, not the program. (I used DCCs.)

And when I run a bunch of dictionaries via a command file (Windows), I don't even see the status screens, until the last one.

The "Scanning dictionary" section didn't complain, which would be that part that is seen with running many dictionaries in a row.

[M@LIK]

It does relate to algorithm somehow.
For example, when using -m2500 (WPA) it will reject passes < 8 chars due to WPA's limitation.

The "BOOM!" here is that plus-0.09 apparently has a bug with rejection container, see below:

Code:

01.txt has 5k of 16-in-length digits.

0.08 00000000000000000000000000000000 01.txt
Rejected.....: 5000/5000 (100.00%)

0.09 00000000000000000000000000000000 01.txt
Rejected.....: 0/5000 (0.00%)

0.10b8 00000000000000000000000000000000 01.txt
Rejected.....: 0/5000 (0.00%)

[M@LIK]

And when I run a bunch of dictionaries via a command file (Windows), I don't even see the status screens, until the last one.

The "Scanning dictionary" section didn't complain, which would be that part that is seen with running many dictionaries in a row.

Yes, you would have to press 's' to view the status.
If a dictionary is finished withOUT any 's' press, you won't see any status about that dict.

[atom]

Its a nice discussion since it is something that user should not but do not face very often, so i never explained it before. It is something in the very deep of oclHashcat-plus.

There are two types of algorithms. Slow ones and fast ones. The slow ones are: 400, 500, 1600, 1800, 2100, 2500 and 3200. All others are fast algorithms.

Fast algorithms have an in-kernel rule engine. On there, if a rule leads to a situation that the password candidate is longer that 15 chars, it is -not- rejected and the test being done is unpredictable.

Slow algorithm have in in-host rule engine. On there, if a rule leads to a situation that the password candidate is longer than 15 chars, it -is- simply rejected.

This should explain your discussion.

[Kgx Pnqvhm]

(Note that the splitlen utility stops at 15 chars, as a reminder, but we may have other programs that do more.)

E.g., if I use a wordlist of 221 char words, the program start of showing the dictionary loading:

Scanning dictionary ..\hashcat\dicts\CainWordlist\Length-21.txt: 1932 bytes (100.00%), 84 words, 277
Scanned dictionary ..\hashcat\dicts\CainWordlist\Length-21.txt: 1932 bytes, 84 words, 27720000 keysp
ace, starting attack...

And with running a rule that adds 5 characters, yielding 26 character trials, it shows:

Rejected.....: 0/110880000 (0.00%)

This is in: cudaHashcat-plus v0.09 by atom starting...

[Kgx Pnqvhm]

Fast algorithms have an in-kernel rule engine. On there, if a rule leads to a situation that the password candidate is longer that 15 chars, it is -not- rejected and the test being done is unpredictable.

Shouldn't this be changed to warn that something not expected has happened?

Since I know my dictionaries and rules, I can inspect a run, and "know" that some should be run in the CPU hashcat, but I'm also having my Windows command (aka batch) files do some logging, so I can run a set of rules overnight, to have a record of what dictionaries and rules were run against which hash files.

Could the status screen show that the questionable state has happened, or something in he dictionary parsing/loading stage give a warning?

[atom]

It could but it would slow down the cracking performance a lot (80% or more). So I decided to just let it run into this situation. No worries, nothing gets damaged this way. With the next rule all states are back to normal.