Why Combinator is not making all possible combinations?
#1
Hi,

I made three wordlists: 12345 (885 lines/words), qaz (16 lines), wsx (16 lines).

First I combine qaz with wsx  (result: qazwsx)

Combining 12345 with qazwsx   is giving me wordlist with  226560  lines (correct)


Also using combinator3  combining 12345 with qaz and with wsx  is giving me wordlist with  226560  lines (correct)


But when I first combine 12345 with qaz  (result 12345qaz   (14160 lines, correct))

And then combine 12345qaz with wsx  I got wordlist with only 226048 lines  (512 lines missing).


Can someone explain me why I'm getting two different results (they should be exactly the same)

I've  attached the three base wordlist.


Attached Files
.txt   12345.txt (Size: 6.65 KB / Downloads: 2)
.txt   qaz.txt (Size: 64 bytes / Downloads: 1)
.txt   wsx.txt (Size: 64 bytes / Downloads: 1)
.txt   missing lines.txt (Size: 18.5 KB / Downloads: 1)
Reply
#2
Is there any restriction in single password length? I noticed that Combiner is dropping passwords when they are longer than 36 signs.
Reply
#3
(06-11-2017, 05:45 PM)Flx Wrote: Is there any restriction in single password length? I noticed that Combiner is dropping passwords when they are longer than 36 signs.

I searched around and couldn't find the reference, but the combinator attack will only accept words of a limited character length and I remember reading that if the output is greater than 64 characters, it wouldn't work.  Could have something to do with it.  I'm in the middle of setting it up myself to get it going, will reply back if I find the info again
Reply
#4
(06-11-2017, 05:45 PM)Flx Wrote: Is there any restriction in single password length? I noticed that Combiner is dropping passwords when they are longer than 36 signs.

Found it from this page: https://hashcat.net/wiki/doku.php?id=hashcat_utils

Limitations

Some programs from hashcat-utils have a minimum and maximum allowed word-length range (like in “len” example).
E.g. see splitlen.c:
#define LEN_MIN 1
#define LEN_MAX 64

You can change them and then recompile the hashcat-utils. However we usually do not need plain words of greater length in password cracking.

---------------------------------------------------------------------------------------------
So, somewhere in the code is a way to extend the length of input or output.  Idk how though; sorry, i'm new Smile
Reply
#5
(06-11-2017, 05:45 PM)Flx Wrote: Is there any restriction in single password length? I noticed that Combiner is dropping passwords when they are longer than 36 signs.

found this also: https://hashcat.net/wiki/doku.php?id=fre...ese_hashes

What is the maximum supported password length?

There's no easy or general answer. Thing is, it depends on many factors.
First let's try to answer why is there such a limitation at all? The answer to this one is more simple: Because of performance! We're not talking here about a few percent. It can make a difference between 0% - 300% so we have to be very careful when we decide to support longer passwords. For example when we dropped the limitation of 16 characters in oclHashcat-plus v0.15 it had the following effect on fast-hashes:
  • Zero-based optimizations: Many algorithms can be optimized based on the fact that zero values in arithmetic or logic operations do not change the input value. With a password limit of less than 16 characters, it was guaranteed that values for positions 16-63 were zero, allowing us to omit dozens of operations from each step. These optimizations can no longer be used. See Passwords13 presentation: http://hashcat.net/p13/js-ocohaaaa.pdf
  • Register pressure: If a password is 15 characters or less, we only need four 32-bit registers to hold it. But as we increase the length, more registers are required. This can slow down the entire process if more registers are required than accessible, as the compiler has to swap out data to global memory. Supporting passwords longer than 15 characters increases register pressure.
  • Wordlist caching: hashcat handles wordlist data in a very unique way. The words are not simply pushed to GPU from start to finish; they are first sorted by length. This is done because many algorithms can be further optimized when all of the input data is the same length. This required a lot of host memory. Depending on the number of GPUs we have and the specified -n value, oclHashcat-plus easily allocated 16GB of host memory or more. This buffer would have been increased 4x since we wanted to increase from a maximum length of 16 to a maximum length of 64. In other words, our host system would request 64GB of RAM!
  • Branching: Many (nearly all) hash algorithm support any password length as input. To do this, the password is split into blocks of a specific size, for example 64 byte for MD5. The hash computes the first 64 byte and then uses the resulting digest as initialization value for the next 64 byte, and so on… To be able to do this, it has to branch (means using if() statement) and GPU's hate branching
[size=undefined]
Now what are the real maximum password lengths? This is something that we change from time to time. For each hash-type you can say the following: Whenever we find an optimization that allows us to increase the support, we will do it. Generally speaking, the new maximum length is 55 characters, but there are exceptions:
[/size]
  • Limitation from the hash itself:
    • 1500: 8
    • 3000: 7
    • 9710: 5
    • 9810: 5
    • 10410: 5
  • For slow hashes:
    • 400: 40
    • 500: 16
    • 1600: 16
    • 1800: 16
    • 2100: 16
    • 5200: 24
    • 5300: 16
    • 5800: 16
    • 6300: 16
    • 7400: 16
    • 7900: 48
    • 8500: 8
    • 8600: 16
    • 10300: 40
    • 10500: 40
    • 10700: 16
    • 11300: 40
  • For fast hashes, the important factor is the attack mode:
    • attack-mode 0, the maximum length is 31
    • attack-mode 1, the maximum size of the words of both dictionaries is 31
    • attack-mode 6 and 7, the maximum size of the words of the dictionary is 31
[size=undefined]
Just to make this clear: We can crack passwords up to length 55, but in case we're doing a combinator attack, the words from both dictionaries can not be longer than 31 characters. But if the word from the left dictionary has the length 24 and the word from the right dictionary is 28, it will be cracked, because together they have length 52.
Also note that algorithms based on unicode, from plaintext view, only support a maximum of 27. This is because unicode uses two bytes per character, making it 27 * 2 = 54.
[/size]
Reply