BIP-38 / scrypt question

[sigkill]

Hello - I posted a suggestion / feature request on the github site earlier, but it may be more appropriate to post here.

I've been playing with a BIP-38 bruteforce utility that appears to work by using libwallycore, and somehow takes the public address (in lower case hex) and the BIP38 encrypted private address, along with a password list (loads only one file at a time, but is REALLY fast.)

https://github.com/agurodriguez/brute_fo...config.hpp

I was able to generate a test private key, encrypt to BIP-38, and then feed a bunch of generic passwords, using the maskprocessor as a generator along with PACK to make a fairly huge password list.

It was able to decrypt the private key that I used, with the settings of N=14, r=8, p=8, however it has not been able to decrypt another paperwallet that I have had for some time, even though I know the password, privatekey and public address values.

I am curious if this is actually functional, or if the N,r,p settings might be different in some way for the other wallet that I did not generate? (Would that even matter?)

Anyhow, the other thing is I would like to request support for this in hashcat - if it is possible to use the public address, and encrypted private key to decrypt the private key - everything I've read on here would suggest otherwise, but I thought it would be worth the ask.

If inappropriate I can remove my post on github as well, but I posted here: https://github.com/hashcat/hashcat/issues/2978

If I wanted to use the public address and the encrypted private key as variables with hashcat, would there be any settings with scrypt that might enable these two things to validate the decryption passphrase, and the decrypted private key?

[monyanus]

Interesting, are you sure the paper-wallet uses the same derivation? E.g. what is the address type, what does the address of the paper wallet start with?

If I look at your code, I think you derive a legacy wallet type, meaning one address directly derived from the public key, which is indeed fast.
Your paper wallet probably uses a more elaborate derivation using BIP44 and possibly segwit (address starting with bc1).
The challenge is to build in these derivation shema's and address types, then let the user chose at which dept they want to search. I would love to see this in hashcat, but this is non-trivial to implement.

For example a BIP4 wallet has a different derivation process to derive a tree of privatrkeys-publickeys-address from a master key and generating new child keys by hashing the master key with an index:
http://aaronjaramillo.org/bip-44-hierarc...ic-wallets

Additionally there are other derivation types, BIP49, BIP84, BIP141
See iancolman tool for deriving privatekey-publickey-address pairs:
https://iancoleman.io/bip39/

I have some code that allows testing and derivation for any type of derivation paths, even custom, but it is build in Python and it is not very fast.

[sigkill]

The paper wallet has a 6P address. My test wallet also has a 6P too. I believe it was BIP-38 encrypted, but with a non-standard password other than the present dictionary lists that have been used in more recent wallets.

It's quite fast, but I haven't been able to decrypt my test wallet, even though I emailed the developer that made the utility, I have yet to hear back on how he converted the example wallet public address hex string.

When I attempt to convert it into an address string from hex I am not able to produce a good bitcoin address, which is where the knowledge gap is at the moment.

It is indeed way faster than the present methods using btcrecover, I'm not sure how one would implement a similar method in hashcat, but it would be worth it, if the results and method can be verified, tested and reproduced.

It seems thousands of times faster than Python. (Using the libwally backend)

Interesting, are you sure the paper-wallet uses the same derivation? E.g. what is the address type, what does the address of the paper wallet start with?

If I look at your code, I think you derive a legacy wallet type, meaning one address directly derived from the public key, which is indeed fast.
Your paper wallet probably uses a more elaborate derivation using BIP44 and possibly segwit (address starting with bc1).
The challenge is to build in these derivation shema's and address types, then let the user chose at which dept they want to search. I would love to see this in hashcat, but this is non-trivial to implement.

For example a BIP4 wallet has a different derivation process to derive a tree of privatrkeys-publickeys-address from a master key and generating new child keys by hashing the master key with an index:
http://aaronjaramillo.org/bip-44-hierarc...ic-wallets

Additionally there are other derivation types, BIP49, BIP84, BIP141
See iancolman tool for deriving privatekey-publickey-address pairs:
https://iancoleman.io/bip39/

I have some code that allows testing and derivation for any type of derivation paths, even custom, but it is build in Python and it is not very fast.