Feasible method of cracking long, randomised passwords?

[CracktainCrunch]

So I understand that brute forcing anything longer than 8 or 9 characters, especially when special characters and upper and lower cases are involved, is not feasible.
But what about other methods? Like taking already cracked passwords that were randomly generated and jumble them up or something like that? I have seen rockyou.txt contains a few of those. Would that make sense? Or are there better, more efficient methods? And if so, is someone willing to take me through the process?
I am talking RAR3 btw. My GPU hashes at 44KH/s when brute forcing and about 20 when using a dictionary attack which I find very odd. Shouldn't a dictionary attack be faster than brute force?

[philsmd]

mask attack: the candidates are directly generated/used on GPU, within the GPU kernel code
attack involving dictionaries (-a 0, -a 1, -a 6, -a 7): disk I/O bottleneck AND passwords need to be "send"/transfered from host RAM ("CPU") to device VRAM ("GPU") (PCIe "bottleneck")

there is an exception with slow hashes that only have init/loop/comp kernel functions: for some attacks the password candidates are not directly generated and used on-the-fly within the same GPU kernel code, because of the "slow hashing algorithm bottleneck" (no need and no performance difference, because of cost factor/iterations etc)

there are ways to speed things up: -w 3, -O (if applicable) and a good amount of rules in -a 0 attack (rule-based-attacks, see https://hashcat.net/wiki/doku.php?id=rule_based_attack)

[undeath]

Like taking already cracked passwords that were randomly generated and jumble them up or something like that?

That's what rule-based attacks do (see philsmd's post above) and those are the recommended kind of attacks for every attack where a full brute-force is infeasible (which applies to almost all attacks).

My GPU hashes at 44KH/s when brute forcing and about 20 when using a dictionary attack which I find very odd. Shouldn't a dictionary attack be faster than brute force?

You are mixing things up in a weird way here. The amount of hashes per second vs the about of total candidates (and thus full attack ETA). Even with a (much) slower hash rate your dictionary attack will likely complete much faster than a brute-force attack of a meaningful password length. That said, philsmd has already provided some hints how you can make your dictionary attack a bit faster. However, while in many cases it's possible to get close to the mask attack hash rate, it will usually end up with a slightly slower rate.

[CracktainCrunch]

Like taking already cracked passwords that were randomly generated and jumble them up or something like that?

That's what rule-based attacks do (see philsmd's post above) and those are the recommended kind of attacks for every attack where a full brute-force is infeasible (which applies to almost all attacks).

My GPU hashes at 44KH/s when brute forcing and about 20 when using a dictionary attack which I find very odd. Shouldn't a dictionary attack be faster than brute force?

You are mixing things up in a weird way here. The amount of hashes per second vs the about of total candidates (and thus full attack ETA). Even with a (much) slower hash rate your dictionary attack will likely complete much faster than a brute-force attack of a meaningful password length. That said, philsmd has already provided some hints how you can make your dictionary attack a bit faster. However, while in many cases it's possible to get close to the mask attack hash rate, it will usually end up with a slightly slower rate.

Would it make sense to generate passwords with say min 10 max 15 characters containing all possible combinations into a wordlist and then test them against the RAR3 hash? Does that make sense speedwise or would it be just a waste of time because it would take too long to generate all those passwords/test them? It would essentially be a brute force attack but with pre-generated passwords that one would use in a dict attack I guess.

[philsmd]

if you have some specific idea, you could also develop/program your own password generator (for instance a python script or whatever) and pass the candidates to hashcat like this:

Code:

python generate_password_candidates_combine_and_filter.py | hashcat -m 12500 -a 0 -w 3 -r rules/best64.rule hash.txt

of course the python script must be coded by you first and include all the "policies" and filters that you need. The rules are somehow required to achieve max. speed if the python script is quite slow and the hash type is fast. You could also think of using very special / dedicated rules e.g. rules that do not change the length etc (the rule file best64.rule does contain all sort of rules and might - in your specific case - also generate some "invalid" password candidates).

[undeath]

It would essentially be a brute force attack but with pre-generated passwords that one would use in a dict attack I guess.

I'm not sure what brought this idea. You want the worst of both worlds? The way too large keyspace of a brute-force attack paired with the slightly slower speed of a dictionary attack? If you want to do a brute-force you should use the mask attack. But if your passwords exceeds 7 or 8 characters (leave alone 10 do 15) this pretty much is infeasible. You need clever attacks like dict+rules.

[CracktainCrunch]

It would essentially be a brute force attack but with pre-generated passwords that one would use in a dict attack I guess.

I'm not sure what brought this idea. You want the worst of both worlds? The way too large keyspace of a brute-force attack paired with the slightly slower speed of a dictionary attack? If you want to do a brute-force you should use the mask attack. But if your passwords exceeds 7 or 8 characters (leave alone 10 do 15) this pretty much is infeasible. You need clever attacks like dict+rules.

There seems to be a misunderstanding I guess. I am new to all of this so I am not sure if I expressed myself correctly.
Since I don't know the password and have not the slightest idea how it was generated - it's an encrypted archive that I downloaded from usenet but don't remember which board provided the NZB and they all have passwords like "QTSQfy9VVpHaRdcDY%" - I am assuming it is between 10 and 15 characters long consisting of lower, upper case letters, numbers and special signs like %. I understand that anything larger than 8 characters is infeasible to use brute force on, even with a mask. So I wondered if it would help to shorten the time by generating a bunch of random passwords that are 10 to 15 characters in length containing lower, upper case letters, numbers and special signs since hashcat wouldn't have to do that on the fly, copy them into a wordlist and use that wordlist to attack the archive.
That is just an idea, I have no clue if it makes sense speed wise. That's why I decided to ask?

[CracktainCrunch]

if you have some specific idea, you could also develop/program your own password generator (for instance a python script or whatever) and pass the candidates to hashcat like this:

Code:

python generate_password_candidates_combine_and_filter.py | hashcat -m 12500 -a 0 -w 3 -r rules/best64.rule hash.txt

of course the python script must be coded by you first and include all the "policies" and filters that you need. The rules are somehow required to achieve max. speed if the python script is quite slow and the hash type is fast. You could also think of using very special / dedicated rules e.g. rules that do not change the length etc (the rule file best64.rule does contain all sort of rules and might - in your specific case - also generate some "invalid" password candidates).

Not really a specific idea since the password most likely is something like "QTSQfy9VVpHaRdcD%". I downloaded the archive from a usenet board but don't remember which one.
My idea was to generate a bunch of passwords like this and use them in a wordlist to attack the archive. I have no clue if that even makes sense speed wise so I decided to ask first before starting a project only to find out that I have wasted my time reading up on python and program my own password generator and so on.
But your help is very much appreciated. I have no clue about how to use rules. Will have to read up on it.

[philsmd]

no, mask attack would be MUCH, MUCH faster if you just try "random passwords". every operation involving the disk would slow it down tremendously as already explained above when we compared -a 3 with -a 0/1/6/7

but this depends a lot also on the hashing algorithm. we distinguish fast and slow hash types in general, one that can be considered raw or non-iterated and salted hashes versus hashes which have a lot of iterations or a high cost factor

-m 12500 = RAR3-hp for instance has 262144 (0x40000) iterations, so it's technically already considered a slow hash type

[CracktainCrunch]

no, mask attack would be MUCH, MUCH faster if you just try "random passwords". every operation involving the disk would slow it down tremendously as already explained above when we compared -a 3 with -a 0/1/6/7

but this depends a lot also on the hashing algorithm. we distinguish fast and slow hash types in general, one that can be considered raw or non-iterated and salted hashes versus hashes which have a lot of iterations or a high cost factor

-m 12500 = RAR3-hp for instance has 262144 (0x40000) iterations, so it's technically already considered a slow hash type

I remember reading about the difficulties of cracking encrypted RAR archives because it is such a slow algorithm. I'm guessing the exception you mentioned earlier doesn't apply to RAR algorithms? So -a 0 + rules aka jumbling up already cracked passwords would be the way to go as I suspected in the first place?
If so, can you give a few general tips regarding which rules would be useful to me? Or point me in the right direction what kind of rules to read up on for my case?