the pipe (|) aka stdin mode only works with -a 0 in hashcat.
That means that you would need to use something like this:
to chain 4 rule files to end up adding 4 times ?d.
The right part can only use rules in -a 0 mode.
You could use something like this:
or similar to end up adding 4 times the digits (1+3, 2+2, 3+1 all make 4), but the cracking part (right part) should (in general !) do also a lot of work and therefore use rules for acceleration. There is a little "exception" here, because the itunes hashing algorithm is using a so-called "slow hash" (this is the term used in hashcat internally, or we say that it is using this approach: attack outside kernel) and therefore the (password candidate generation)/acceleration part matters much less if we compare this to fast hashes such as MD5, SHA1, NTLM etc... But still, you shouldn't give hashcat too little work to do... it should have maximum acceleration and utilization of the resources.
An alternative could be to use -S (also test with rules or -a 6 alternatively).
The main problem here is also that you are trying to crack a very slow hash with very bad hardware (mac mini without any cooling system i.e. blowers/coolers/fan, or alternatively a very slow virtualized system with bad GPUs i.e. poor tesla). This doesn't mean that you could brute-force a hash easily with modern RTX 2080 Ti or similar. it's just the algorithm that is designed to be very slow and should be attacked more cleverly e.g. dedicated dict + dedicated rules instead of a "brute force" attack. Oftentimes a better approach is the key to success and avoids wasting time and resources, this also holds especially when it comes to hash cracking.
That means that you would need to use something like this:
Code:
-r rules/hybrid/append_d.rule -r rules/hybrid/append_d.rule -r rules/hybrid/append_d.rule -r rules/hybrid/append_d.ruleto chain 4 rule files to end up adding 4 times ?d.
The right part can only use rules in -a 0 mode.
You could use something like this:
Code:
./hashcat64.bin --stdout -r rules/hybrid/append_d.rule wordlist.txt | ./hashcat64.bin -m 14800 -r rules/hybrid/append_d.rule -r rules/hybrid/append_d.rule -r rules/hybrid/append_d.rule hash.txtor similar to end up adding 4 times the digits (1+3, 2+2, 3+1 all make 4), but the cracking part (right part) should (in general !) do also a lot of work and therefore use rules for acceleration. There is a little "exception" here, because the itunes hashing algorithm is using a so-called "slow hash" (this is the term used in hashcat internally, or we say that it is using this approach: attack outside kernel) and therefore the (password candidate generation)/acceleration part matters much less if we compare this to fast hashes such as MD5, SHA1, NTLM etc... But still, you shouldn't give hashcat too little work to do... it should have maximum acceleration and utilization of the resources.
An alternative could be to use -S (also test with rules or -a 6 alternatively).
The main problem here is also that you are trying to crack a very slow hash with very bad hardware (mac mini without any cooling system i.e. blowers/coolers/fan, or alternatively a very slow virtualized system with bad GPUs i.e. poor tesla). This doesn't mean that you could brute-force a hash easily with modern RTX 2080 Ti or similar. it's just the algorithm that is designed to be very slow and should be attacked more cleverly e.g. dedicated dict + dedicated rules instead of a "brute force" attack. Oftentimes a better approach is the key to success and avoids wasting time and resources, this also holds especially when it comes to hash cracking.