how fix error in m15700 with hashlist

[svobodnui11]

I found an error in hashcat and maskprocessor of all versions, if I run brute force in hashcat and put several hashes of the 15700 algorithm, it stops on the first line and does not iterate further, I tried to generate all possible options in maskprocessor, but it cuts the values in the output *262144*1*8** for some reason removes $ethereum$s
Why do you need so many hashes, you ask? the answer is simple in the UTC file, several characters have been changed, namely 6 pieces in known places, the goal is to make all the hash options and run them using 3 known passwords, I made the file with hashes in a different way and the size is 3GB, tell me how you can solve this problem, because on others hashcat and maskprocessor algorithms work perfectly


1 / https://hashcat.net/wiki/doku.php?id=example_hashes give -m15700 (hash) take the test hash from here - hashcat
2 / hashcat64.exe -D1 -m15700 UTC.txt -a0 password.txt
if you put the hash in line 2 and below, brute force will not find it, but will stop at the first line

[Chick3nman]

First, update your hashcat to the newest version as you appear to be running an older one.

Second, i've just tested and hashcat correctly finds the example hash regardless of what line in the hash file it is on, even with 10 other scrypt hashes above it.

Third, you are trying to load 3GB worth of extremely high setting SCRYPT HASHES?? Do you understand how insane that is? If you can even get that many to load, it will take an incredible amount of time to run a list like that, even through just 3 candidates. This does not sound like the correct approach to whatever your problem is but I do not have enough information to give you better guidance from your post.

Edit: Regarding this part "I tried to generate all possible options in maskprocessor, but it cuts the values in the output *262144*1*8** for some reason removes $ethereum$s"

This sounds like you are just not escaping the characters correctly in your command.

[svobodnui11]

use on Windows and The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) Linux and have one problem
you misunderstood me, i have used all versions of hashcat as well as the most recent, now the test is done on 6.1.1
It's hard for me to explain, check this with yourself

hashcat.exe -D1 -m15700 hash.txt -a0 password.txt

hash.txt - only 3 hash from HASHCAT site the main thing here is that there are no repetitions, otherwise the hashkat will remove duplicates and find the correct one, do everything like mine is different-

$ethereum$s*262144*1*8*3436383737333838313035343736303637353530323430373235343034363130*8b58d9d15f579faba1cd13dd372faeb51718e7f70735de96f0bcb2ef4fb90270*8de566b919e6825a65746e266226316c1add8d8c3d15f54640902437bcffc8c0
$ethereum$s*262144*1*8*3436383737333838313035343736303637353530323430373235343034363130*8b58d9d15f579faba1cd13dd372faeb51718e7f70735de96f0bcb2ef4fb90277*8de566b919e6825a65746e266226316c1add8d8c3d15f54640902437bcffc8c9
$ethereum$s*262144*1*8*3436383737333838313035343736303637353530323430373235343034363130*8b58d9d15f579faba1cd13dd372faeb51718e7f70735de96f0bcb2ef4fb90278*8de566b919e6825a65746e266226316c1add8d8c3d15f54640902437bcffc8c3

password.txt
hashcat
hashcat1
hashcat12

when finish fle hashcat.potfile have zero

but if you do the same, for example, with the bitcoin algorithm or md5, then everything is fine, only with 15700 I have a problem

[svobodnui11]

symbols were replaced in a hash in a known place, for protection, I always do this, but I did not expect that I would get such a problem when iterating
if someone receives the key, he will not be able to use it, although it will be determined by the wallets correctly, I do not see better secure storage

[Chick3nman]

The reason that specific test is failing is because the portions of the hash and salt that hashcat uses to compare are exactly the same in those hashes so they are thrown away. Changing only the last bits of the enc/mac like that wont actually change how hashcat does its calculations, so in theory all those hashes are considered the same until the last two steps where the enc is decrypted and the MAC is checked on the decrypted data. When the MAC fails on the decrypted data or the decryption fails the candidate is thrown away. This is not a bug exactly, i believe it's related to an optimization applied to almost all of our kernels/algorithms. In the case of this kernel specifically, and how incredibly slow it is already, we could possibly store/check the entire string and not lose speed but that may take a bit to do.

Further, corrupting your own hashes like that seems really odd to do on purpose. It doesn't offer you any extra security as the hash format is NOT to be used as a format for backups/security regardless. In some wallets/modes for ethereum it doesn't even store enough information to use the wallet again afterwards, it only stores enough information to find the password. You can't use the information in the hash format to rebuild the wallet fully. This is not true for presale wallets, but the other variants it can be.

[svobodnui11]

then it's too late, now the task is to check all the hashes, otherwise I will lose my wallet, maybe there is a way out of the situation or other software will you prompt for such checks of each hash with the correct password?
but if I do this with other algorithms, then the hashcat will check all the hashes, this only applies to the Ethereum algorithm