Bitcoin Core won't take my passphrase

[CDNinATL]

So about 6 months ago I decided to encrypt my BTC wallet (good thing). Set the password and all that. Since then I upgraded from 0.9.0 core to the latest 9.2.1. Now my wallet won't accept my passphrase. I wasn't exactly sure on password so I extracted the hash from the wallet and ran John the Ripper in a Debian VM and verified the passphrase. The wallet itself is on my Windows 2012 server (not sure if that's relevant or not). Every time I try to reset the passphrase or send my coin to my Armory wallet (either will do), it just keeps telling me that the passprase is incorrect.

So far I've ran -upgradewallet, -rescan and -salvagewallet switches on it but none of them are letting me access my coin.

I guess next up will be the fixwallet.py inside of my linux vm and see if that makes any difference but I've never used it before. Any other suggestions would be awesome!!

[Foxpup]

I extracted the hash from the wallet

There is no hashed password stored in the wallet to extract. What exactly did you do?

[CDNinATL]

I extracted the hash from the wallet

There is no hashed password stored in the wallet to extract. What exactly did you do?

I ran bitcoin2john.py command that came with John the Ripper.

[Newar]

Can you install 0.9.0 on another system again and see if it works?

[CDNinATL]

Can you install 0.9.0 on another system again and see if it works?

I can. I'll give it a go on my main computer.

[btchris]

I extracted the hash from the wallet

There is no hashed password stored in the wallet to extract. What exactly did you do?

I ran bitcoin2john.py command that came with John the Ripper.

This means that JtR was able to decrypt the mkey (and verify that the padding bytes were correct, which makes it extremely likely that the password was correct). JtR doesn't try to actually decrypt any private keys to check them against the stored public keys.

If the first private key, or its associated public key, is corrupted, this will happen (although that seems unlikely to me...). If this is the case, `pywallet.py --recover` can help.

CDNinATL, can you let us know how this turns out? I'm personally interested...

Also, does your password contain any non-ASCII characters (any characters not list here: https://en.wikipedia.org/wiki/ASCII#ASCII_printable_code_chart)?

[CDNinATL]

I extracted the hash from the wallet

There is no hashed password stored in the wallet to extract. What exactly did you do?

I ran bitcoin2john.py command that came with John the Ripper.

This means that JtR was able to decrypt the mkey (and verify that the padding bytes were correct, which makes it extremely likely that the password was correct). JtR doesn't try to actually decrypt any private keys to check them against the stored public keys.

If the first private key, or its associated public key, is corrupted, this will happen (although that seems unlikely to me...). If this is the case, `pywallet.py --recover` can help.

CDNinATL, can you let us know how this turns out? I'm personally interested...

Also, does your password contain any non-ASCII characters (any characters not list here: https://en.wikipedia.org/wiki/ASCII#ASCII_printable_code_chart)?

No. Capital and lower case letters, numbers and the tilde key. I wasn't sure if the tilde was the issue but I was able to encrypt a blank wallet and then successfully change the password.

I'll try the pywallet thing later. Right now I'm up against washing machine and a bearing that doesn't want to be replaced!

[CDNinATL]

So I'm looking at the command pywallet.py --recover and it looks like it requires a size option be set. How do you what number to put in there? The rest of the command, seems easy enough.

[btchris]

So I'm looking at the command pywallet.py --recover and it looks like it requires a size option be set. How do you what number to put in there? The rest of the command, seems easy enough.

The size option is there mostly for hard drive scans. For a wallet, just choose a size that's larger than the wallet size.

You need to append a (strange) unit to the end of the size, so for example --recov_size=100Mo means 100 megaoctets.

(Be sure to take a backup of the wallet file before running pywallet on it, just in case)

[CDNinATL]

This is what I'm getting:

terry@CrackIt-WS:~$ sudo python pywallet.py --recover --recov_device /home/terry/wallet.dat --recov_size 2Mio --recov_outputdir /home/terry/fxd
Enter the passphrase for the wallet that will contain all the recovered keys: **********

Enter the possible passphrases used in your deleted wallets.
Don't forget that more passphrases = more time to test the possibilities.
Write one passphrase per line and end with an empty line.
Possible passphrase: **********
Possible passphrase:

Starting recovery.

Read 0.0 Go in 0.0 minutes

Found 1 possible wallets
Found 234 possible encrypted keys
Found 0 possible unencrypted keys

Possible wallet #1
    with passphrase #1 

Private keys not decrypted: 234
Trying all the remaining possibilities (234) might take up to 0 minutes.
Do you want to test them? (y/n): y

Private keys not decrypted: 234
Try another password, check the size of your partition or seek help
The wallet is encrypted and the passphrase is correct


Importing:


The new wallet /home/terry/fxd/recovered_wallet_1411437903.dat contains the 0 recovered key

To me it seems like it's accepting the password but the private keys won't take them. Or am I reading this wrong??

[btchris]

This is mysterious....

First, a little background (if you're interested, if not just skip to the questions):

Bitcoin Core makes two checks when validating your password.

A. Run the password through a key derivation function (PBKDF1-SHA512) to generate a derived_key.
B. Use the derived_key to decrypt (with AES256) the 48-byte long encrypted_mkey (from the wallet) into a decrypted_mkey.
C. Check (1): make sure the decrypted_mkey is exactly 32 bytes long plus 16 valid padding bytes at the end.
D. Use the decrypted_mkey to decrypt a single (arbitrary) encrypted_privkey (from the wallet) into a decrypted_privkey.
E. Mathematically derive from the decrypted_privkey a derived_pubkey.
F. Check (2): make sure the derived_pubkey is equal to the pubkey stored in the wallet file.

JtR doesn't bother with check (2) in the interest of speed. This should be OK, because the likelihood that check (1) passes, but check (2) fails should be extremely small (something like 1 in 2^128).

pywallet doesn't bother with check (1) (in other words, it always "accepts" the password at first), it simply truncates the decrypted_mkey to 32 bytes in length and ignores any padding (even when the padding is invalid). It only uses check(2) (running that check against every encrypted_privkey if you answer "y" to that question it asked).

If JtR thinks you have the right password, but pywallet and Bitcoin Core disagree... than I'm not sure what's going on.

So... questions...

Could you try btcrecover (another Python script)? (use "--passwordlist --wallet wallet.dat" for its options.) It should use the same single check as JtR.

Where did you get your JtR? If you compiled it from source, how recent is it (there were some recent Bitcoin-related updates to JtR)?

Do you have any wallet.dat backups (even if they're encrypted)?

[CDNinATL]

I'll give that python command a go at lunch time.

This was the command I used in Debian to get JtR:
git clone -b bleeding-jumbo git://github.com/magnumripper/JohnTheRipper JohnTheRipper

I have multiple copies of the wallet.dat. All are recent as I didn't want to mess with the original file other attempting to unlock it. What I don't have is an older version sitting around (wish I did).

[Newar]

I guess 0.9.0 didn't work either.

Can you dump your wallet with pywallet?

[CDNinATL]

I guess 0.9.0 didn't work either.

Can you dump your wallet with pywallet?

I still need to try that. I did do it but it may not be a proper test as the machine I put it on had it at one point. I do have a clean laptop I can put it but I haven't had a chance yet.

As for pywallet --dump, I can also try that a bit later.

[CDNinATL]

Ok...so I wasn't reading the output of JtR correctly. I purposely added a dummy password to the script I used to come up with the wordlist and that's when I realized I come close enough. So I'm back to that stage on trying to remember what I based my password on...grrrrrr

[btchris]

Ok...so I wasn't reading the output of JtR correctly. I purposely added a dummy password to the script I used to come up with the wordlist and that's when I realized I come close enough. So I'm back to that stage on trying to remember what I based my password on...grrrrrr

Well, although I'm kinda happy (sorry) that something weird and mysterious isn't going on, I'm unhappy that this could make things more difficult for you...

On the (small) plus side, you already have JtR compiled, so if you'd like to use it to search for your password, it's a great option.

btcrecover is faster if you have a discrete video card, in terms of guesses per second (and JtR is faster if you don't have one). I also think that btcrecover is the easier option if you already have a good idea of what your password is, but I'm just a teensy bit biased (I'm the author of btcrecover)....

If you do choose to try btcrecover, the tutorial and quick start is here: https://github.com/gurnec/btcrecover/blob/master/TUTORIAL.md#btcrecover-tutorial

Let me know if you have any questions.

[2112]

Windows 2012 server

the tilde key

You have a classic setup to get bitten by http://en.wikipedia.org/wiki/Dead_key issue. This is especially easy on Windows which keeps the keyboard layout state per thread/window. So many people are unaware that when the new window pops up the keyboard layout may have been temporarily changed for the duration of this new window being open. In all cases like this that I've personally assisted it was always caused by careless change in keyboard layout, keyboard driver, physical keyboard or the way the key presses are transmitted through the various "remote desktop" tools.

Like, are you positive that nobody in your household had recently started learning e.g. Spanish or stopped learning German?

[ForgottenPassword]

It's possible that your keyboard layout has changed from US to UK or US international. Try using one of these instead of the tilda:

`
¬
#
"
'

[sbrzol]

I have the same problem, is there any solution ?

Here are my two posts with my issue

First time i thought the problem is connected to Armory , but now i do not know
https://bitcointalk.org/index.php?topic=56424.msg9263763#msg9263763


https://bitcointalk.org/index.php?topic=34028.msg9271649#msg9271649    Re: Pywallet 2.2: manage your wallet [Update required]

[btchris]

I have the same problem, is there any solution ?

Here are my two posts with my issue

First time i thought the problem is connected to Armory , but now i do not know
https://bitcointalk.org/index.php?topic=56424.msg9263763#msg9263763


https://bitcointalk.org/index.php?topic=34028.msg9271649#msg9271649    Re: Pywallet 2.2: manage your wallet [Update required]

Responded to you in the pywallet thread over here.