hashcat Forum

Hello, I try to convert my wallet.aes.json to base64 via a btcrecover script in order to pick up a second password, but I get an error that I enter the wrong password, I encounter this problem a second time, the password is specified exactly, the hashcut finds password from this wallet. What could be the problem? Why can't the script convert the wallet so that I can put it on brute -m 18800?

https://i.ibb.co/Pms7vn1/image.png

are you sure that this wallet uses a second password at all ? Did you try to validate and find out the details and that the password works with another tool (or the blockchain web page) ?

From your previous posts https://hashcat.net/forum/thread-8207-po...l#pid44031 (these posts are actually, again, against the forum rules since you are posting hashes which is of course forbidden, see https://hashcat.net/forum/announcement-2.html) I can see that you have a lot of problems with your setup or cracking the hashes, maybe it's related again and it's a problem of your installation/system/setup.

Furthermore, "convert to base64" isn't really what is going on here, for base64 encoding you do not need any passwords. base64 is just a type of representation of (raw) bytes, nothing more. The important step is not the conversion to base64, but the decryption of the data instead (using a password based key derivation function).

I think "brute" is also not a good term and strategy here. you should try to crack the hashes with dictionary attacks (-a 0) combined with rules (-r rule_file.txt) instead. brute-force is a bad strategy, mask attack would be much better, but again the best thing to try first is dictionary-based attacks (except if the passwords are known to be really random and you have no clue what the pattern is... but then again it could be infeasible if the password is very long and random).
18800 as far as I know uses at least 10000 sha256 rounds, so it's not really the fastest algo to "just brute" it.

I would also recommend trying to crack the examples from https://hashcat.net/wiki/example_hashes and/or creating new wallets with known password and testing with those, just to make sure that everything is working okay.

Thanks to Proxerboss I was able to troubleshoot this problem (he has send me an empty encrypted wallet with 2nd password that fails for him to accept the password with btcrecover).

I've now analyzed the wallet and came very quickly to the conclusion that btcrecover doesn't validate the decrypted data correctly, It allows only a very specific regex, which we already found out isn't working correctly.

The problem is similar to this one we had discovered in hashcat:
https://github.com/hashcat/hashcat/issues/1937
and first fixed here: https://github.com/hashcat/hashcat/commi...4ee0620076

basically, the check for {"guid" is not always good enough, because decrypted wallets could start with other patterns too (see https://github.com/hashcat/hashcat/issue...-469038973 , for instance with {"tx_notes":{},...}).

the problem of btcrecover is located here: https://github.com/gurnec/btcrecover/blo...sh.py#L153

and this is only for the 2nd password extraction of current versions, there might be other lines of code in the btcrecover software that also need to be more flexible and therefore fixed.

Could somebody please report this to the btcrecover guys on github (https://github.com/gurnec/btcrecover/issues/ ... if it's not already a known issue update: I got some spare minutes and have now searched for a similar issue on the btcrecover github and found this https://github.com/gurnec/btcrecover/issues/203, so I guess it's already a known issue and not fixed yet. In general, it seems that this project is quite inactive ), explain this problem and maybe also link to this post.

Thank you very much

BTW: it's needless to say, but if it's still unclear ... this is not a hashcat problem, but btcrecover doesn't accept the password because the validation fails because it only tries to match {"guid", but guid could be anywhere in the wallet file not always after the opening curly brackets. We addressed a similar problem in the hashcat kernel (decrypted data validation) already, thanks to the help of an user who reported this (see above hashcat github issue).