(04-28-2021, 07:06 PM)philsmd Wrote: Thanks for testing kiara.

yeah that thing you noticed with using the hash directly within the command line is not really a bug... hashcat never sees the full hash since every $xyz string is interpreted as a variable by your shell/bash etc.
just test it like this:

Code:

echo "---$THIS_IS_A_SHELL_VARIABLE---"

This is actually true for every hash format that has a "$" in it... and therefore for many hash modes that hashcat supports... you can work around it by escaping it (or using different types of quotes like the single quote ') or using a hash file (of course the whole mechanism about what is interpreted as a variable by your shell/cmd or not and how to escape it, depends a lot on the shell and operating system itself, so read the shell's manual, if you really have to do it e.g. echo "\$VAR" ).

For me your testing seems to indicate that everything is working fine, including the extractor... and the speed seems to very good and what we would expect with a little bit more advanced -m 10900 like algo with 1000 iterations).

I've also analyzed the decrypted wallet (plain text) and the length seems to be varying a little bit. the main JSON keys that changed are:

Code:

"sequence":1,
"fee":200000,
"defaultDirectory":""

of course this makes the ciphertext (and plaintext) longer, if some of these keys/values are different or missing, but the hash module and kernel actually accepts all of these lengths/strings.


I don't think the PC could now help a lot for finalizing/improving this new hash module/addition. If anything, it could maybe help your friend somehow to discover or remember the password, but in my opinion it's not important to do anything special with this PC to make this module better etc.

I've also thought a little bit about what we could optimize further, but the only thing that came to my mind is this little test/change that could or could not make a little speed difference (attached file, run within shell).

I was also thinking about using an entropy check right away instead of the TAG, but for me the tag / checksum turned out to be faster (compared to adding some additional code for an entropy/randomness check with the hc_get_entropy () function or similar, the other problem is that we would need to assume/have a fixed minimum data length and check the plaintext for randomness and therefore the plaintext shouldn't be too small... for truecrypt/veracrypt we use at least 512 bytes which aren't available here). An advantage of the entropy check would be that we wouldn't need to rely on the short 8 byte tag. But since it seems to be slower, it's not really a valid/good alternative.

Hopefully the most important wallet here, the one of your friend, is also working (extraction and accepted by hashcat).
Good luck cracking. thx