Quote from: bitcoiner2001 on December 07, 2022, 07:53:35 PM

I know that the password is 9-10 characters long, contains "r", "u", "@" and "." and I know that the password is an email. Is this even worth decrypting? Or it is impossible to get the password just based on this information?

Any help is appreciated. Thanks!

If it's true, it should be already brute forced since there aren't that many possible permutation.

Code:

XXXX@X.ru
XXX@XX.ru
XX@XXX.ru
X@XXXX.ru

XXXXX@X.ru
XXXX@XX.ru
XXX@XXX.ru
XX@XXXX.ru
X@XXXXX.ru

Naively assuming X only use lowercase, uppercase and number (total 62 character).

Code:

62^5 * 4 + 62^6 * 5 = 287665709248 (about 2.87E10) permutation

Nvidia 1660 Ti with BTCRecover have performance 6.75 kp/s (6750 keys/second), so it could be brute forced within 1.35 years. With multiple and faster GPU, it could be reduced to less than a month.

Code:

287665709248 / 6750 = 42617142.11 seconds

Quote from: NeuroticFish on December 07, 2022, 08:10:08 PM

This being said, I'll leave it to the others give you more technical details, since I don't have experience actually decoding / brute forcing wallets (I consider that a waste of time and resources).

Past explanation by one of Bitcoin Core contributor should be sufficient.

Quote from: achow101 on April 12, 2019, 02:10:03 AM

The wallet file isn't fake per se, nor are the transactions it shows. What's fake about it is that it doesn't contain the private keys it claims it does.

Quote from: yangxin325 on April 12, 2019, 12:44:33 AM

The method of identification is to look at the corresponding version of the wallet code, check the data consistency, time, field, type, structure, It looks very complicated.

It actually is not that complicated. You don't need to check any data consistency, time, etc. You don't need to check any of the things you mentioned. You also don't really need to look at the wallet code because the data that they are manipulating doesn't change frequently, if ever. In fact, the specific database fields that are being modified will likely never change in order to maintain backwards compatibility with older wallet versions.

What the authors have done here is simply add fields which represent encrypted keys. These fields contain the pubkey and the encrypted private key which will typically just look like random data (because that's the point of encryption). What the authors have done is just create a field that contains the pubkey and random data (or in this case, a string) as the private key.

It is impossible for anyone (technical or not, professional or not) to identify that the wallet is "fake" by simply looking at it (besides the fact that common sense tells you its a scam). If done correctly, the supposed encrypted key will be garbage data and its veracity cannot be determined without knowing the decryption key. Of course, if it's just zeroes or some other obvious non-random data, then it can be easily determined. You can inspect the data of a wallet.dat file using BDB 4.6's db_dump tool.