Token processing question

[xabbix]

I have the following password candidate:

word1word2word3word4word5word6word7word8word9word10word11word12word13word14word15word16

Each actual word length is different and I have a few options for each numbered word (so word1 could be 5-6 different options) and one of the words could have some capitalization in place.

I'm looking for a token processor that can help me represent this in an easy way so that I could either feed it directly to hashcat, or create a word list to then feed it with mode 0.

To give a concise example (using only 4 words, to keep it simple), I'm currently using BTCRecover tokenlists, which works great but is extremely slow:

Code:

+ ^1^word1 ^1^Word1 ^1^wOrd1 ^1^word11 ^1^Word11 ^1^wOrd11
+ ^2^word2 ^2^Word2 ^2^wOrd2 ^2^word22 ^2^Word222 ^2^wordddd222 ^2^worD2
+ ^3^woRD3 ^3^word3 ^3^Word3 ^3^w0rd3 ^3^WORD3 ^3^word33 ^3^Word333
+ ^4^WORd44 ^4^word4 ^4^woRD44 ^4^wOrd4 ^4^WORD4 ^4^Word444 ^4^word4444

Is there any processor I can use that takes a similar input in a way that will allow me to set anchors for the positions, set multiple variations and feed back to hashcat?

Thanks in advance.

[penguinkeeper]

Assuming there's a possible wordlist of 2048 different words (BIP39) and 16 places for those words to go, that'd mean you had 2048 ^ 16 possible combinations, which is roughly equivalent to 96 sexdecillion possible combinations which would take an unbelievable amount of years to bruteforce through. It's mathematically impossible and there's a reason why Bitcoin uses this scheme as a recovery phrase

[xabbix]

Assuming there's a possible wordlist of 2048 different words (BIP39) and 16 places for those words to go, that'd mean you had 2048 ^ 16 possible combinations, which is roughly equivalent to 96 sexdecillion possible combinations which would take an unbelievable amount of years to bruteforce through. It's mathematically impossible and there's a reason why Bitcoin uses this scheme as a recovery phrase

Even though I'm using BTCRecover, there is no relation to BIP39 seed phrases. It's a normal password for a fast hash.

[penguinkeeper]

Fair enough, how many possible words could there be, per position?

[xabbix]

Fair enough, how many possible words could there be, per position?

There aren't many. Each position could have about 5-6 different words, each with a few variations related to capitilization. The question isn't about keyspace, but about a preprocessing tool that will allow me to generate a wordlist with relevant candidates.

I see that there's a combinator tool by hashcat, but it can only take up to 3 wordlists. Since the positions are known, maybe I could use BTCRecover's tokenlist to generate two 8 word lists and then use the combinator with two inputs, one for the first 8 words and the other for the other 8 words. That should work right?

[penguinkeeper]

Let's say 6 dict words, with 3 variations, that'd be 18 possible words per space, which would be 18^16, which is 121 quintillion, which is still way, way too high of a keyspace, even if you did have the tools

[xabbix]

Let's say 6 dict words, with 3 variations, that'd be 18 possible words per space, which would be 18^16, which is 121 quintillion, which is still way, way too high of a keyspace, even if you did have the tools

Again, I'm asking a general question about a preprocessing tool, not about the reality of running such an attack or its keyspace. It's actually a lot smaller since some words have less variations. Most words will have 5-6 variations in total, a few words will also have some capitilization variations on top of that. Thanks for the calculations.

[penguinkeeper]

Keyspace aside, I don't think any of the hashcat-util tools can handle that, but Linux's "paste" command can, with a command like:

Code:

paste file1 file2 file3 file4 

etc which can then be either piped into Hashcat through stdin, or outputted as a real file and run normally through Hashcat