Strange program error?

[deloxd]

Hi Gurnec,

I have some problem with btcrecover. I forgot my wallet password to multibit [ ver: 0.5.18] After installation, start program and finally in 4 days i see password found 'some password'. (7 letter and digit] Cool! But after put password to program i see "could no decrypt" echhh ;/

I will describe how I do it:

1. First i extract key from 'multibit key backup '

   I use: ./extract-multibit-privkey.py --and here file

2. After when i have key export I use:

./btcrecover.py --typos 5 --typos-capslock --typos-case --tokenlist tokens.txt --data-extract Starting btcrecover 0.17.8 on Python 2.7.10 64-bit, 16-bit unicodes, 64-bit ints Please enter the data from the extract script I put my key and after Wallet difficulty: 3 MD5 iterations Using 8 worker threads 1 of 2 [#####################---------------------] 0:00:00, ETA: 0:00:00 Password found: 'password'

After all this I tried it use option --wallet and put file of my wallet and finally password no working.

Some solution?

I did one more thing!

I created new wallet in multibit and use with previously found password. Then i compared my old password key and new one an and one thing is interesting. In new and old 10 first charcters are the same. Maybe this help in some solution?

[gurnec]

First off, I should apologize for not having this documented sooner, but please read the warning here which I just added. I also just updated btcrecover so that it generates a warning when using MultiBit Classic data-extracts so that in the future others will not waste their time with them....

In short, MultiBit Classic data-extracts can sometimes report that an invalid password is correct.

After all this I tried it use option --wallet and put file of my wallet and finally password no working.

You mean that you re-tried the entire token file & options except with the --wallet option? This is what you should trust. When using a --wallet option (and not --data-extract), the "false positive" bug is no longer an issue. If it ended with "Password search exhausted" then your password wasn't found (regardless of what it said with --data-extract). I'm sorry if you wasted your time with the --data-extract option, hopefully it won't happen again....

In new and old 10 first charcters are the same.

The first 10 characters of every MultiBit Classic .key file is always the same. It's also how btcrecover can automatically recognize the file.

If you're working with MultiBit Classic and short passwords, you're probably better off using John the Ripper. For straight brute-forcing with "fast" wallets (those with little key stretching like MultiBit Classic), John the Ripper is much faster.

I have a write-up of how to get John the Ripper up and running on OS X here. Getting it running on Linux should be similar (except that getting the OpenSSL headers is easier). When it comes to running john in the last step, you probably don't want the --wordlist option if you're brute-forcing, but instead take a look into the --mask option here.

[deloxd]

Thank's for you response!

I have one more question. When i try use password decrypt "key backup file" from my wallet with

enssl enc -d -p -aes-256-cbc -a -in /Users/daniel/some.key -out /Users/daniel/somefile.txt -pass pass:somepassword I see "bad decrypt" but when i open export file i see 16 characters, they look like a piece of a private key. Is this a mistake "false positivies" like you mentioned?

Greetings from Poland :)

[gurnec]

Yup, this is exactly the problem!

When you decrypt something with the wrong key, the result is completely random, that's just how good encryption algorithms like AES work. It may not look completely random though—this is the infinite monkey theorem. Just by pure chance, in about 1 out of every 300,000,000,000 decryptions, the first 16 bytes will happen to look like a valid private key.

The extract script only extracts enough information to decrypt the first 16 bytes (any more than that and you might put the decrypted key as risk of theft), so when this random occurrence happens, btcrecover wrongly assumes it's found the correct password.

When you use btcrecover with a full .key file, it can check past just the first 16 bytes which eliminates (for all practical purposes) these false positives.

Also, in case you were wondering, the current version of John the Ripper has also fixed this false positive issue.

Also greetings from the U.S. 😃

[Mat008]

Hello, I'm lost... I'm having the "Provided AES key is wrong" issue in Multibit version 0.5.16 on a MacBook Pro running OS X El Capitan 10.11.6. My bitcoins are locked because of a bug (if I understood well?) I've read a lot on the topic but I did not really understand if there is really a way to solve the problem. Where should I start please? Thank you very much for any support...