Unencrypt wallet.dat with known password for raw data scans - 10% bounty

[MrlostinBTC]

I am looking for a way to dump the data from my wallet.dat into raw form. I know the password. This is for a recovery attempt. Is there something that will do this "remove the password"? The wallet data corruption is very specific. I am looking for way to go through a unencrypted version of all the code.

So far I have dumped the wallet with Berkley flag R, gone though all the code and still did not find what I was looking for.

OpenSSL decrypt doesn't work and I suspect that is for android wallets. I have gotten data dumps but they are not readable.

Is there anything that will decrypt a wallet.dat and output a unencrypted version of the code?

Thank you in advance. I will also offer a bounty of 10%. However I do not know the value of the corrupted wallet.... It was originally from 2009-2010.....

This is my very old personal wallet.

I will not send it to you. Do not waste your time.

[achow101]

The encryption method used by Bitcoin Core does not come from OpenSSL or BerkeleyDB. It's in a format specific to Bitcoin Core itself, so you will need some custom software in order to get the unencrypted private keys. There is no way to remove encryption from a wallet with Bitcoin Core itself.  pywallet may be able to do what you want

[MrlostinBTC]

I really appreciate the reply. I assumed that. You would think by now it would have been created. I couldn't find anything other then using BTC core dumpwallet and import wallet to a newly created unencrypted BTC wallet. What's really interesting if I dump with -R berkley, and reload the cleaned up file into a new wallet a few 0420's show up in hex. Just not the ones I need. Pywallet is nice but also not picking anything up. Pywallet jackjack just gives me errors when trying to dump the file. The older version of pywallet works but doesn't give me any further keys then I have previously found. Libbitcoin tools comes in handy getting the key from the EC but other then that...

Pywallet jackjack --recover scan on a usb shows the expected keys no matter how I load it. If I scan it with a -R loaded wallet it shows a few more keys that do not decrypt but picks the obvious keys up. The problem is the keys were from a wallet before encryption and when the wallet was loaded/encrypted I think that data was quashed into the file without being properly converted.

I need to dump all this data into a raw file.

[BitMaxz]

Do you still have the original copy of the wallet.dat? If not, you just make your wallet.dat corrupted after you use BerkeleyDB to decrypt it or you just encrypted it again with that tool.


Why not try to install bitcoin core and then import the wallet.dat let's see if it still could read the wallet.dat file and then just dump it there on the console.

Can you share with us what error do you get from Pywallet with the latest one?

[MrlostinBTC]

pywalletJJ

--version pywallet.py 1.1

'ecdsa' package is not installed, pywallet won't be able to sign/verify messages
Segmentation fault (core dumped)

[PawGo]

Do you use Windows? Mac? Linux?

You need something like this:

Code:

sudo apt-get install python-setuptools

Code:

sudo easy_install pip

Code:

sudo pip install ecdsa

Anyway, take a look here:
https://bitcointalk.org/index.php?topic=34028.0
and of course here: https://github.com/jackjack-jj/pywallet

[PawGo]

1) Did you try Joric's version? https://github.com/joric/pywallet

2) I am not sure if I understand what do you need, but maybe this could help: https://keybase.pub/hcp/python/core_decrypter.py
It comes from this post https://bitcointalk.org/index.php?topic=5333765.msg57036972#msg57036972, I think you may want to contact the author.

3) Isn't it the case similar to yours? https://bitcointalk.org/index.php?topic=2637884.0

[BitMaxz]

~snip~

According to ETFbitcoin you could ignore it but you can get rid of that error by installing ecdsa like PawGo suggestion above.

If you are using Windows or OSX and not Linux then try the other suggestion from Jackjack here's the quoted part below

Signing/verifying messages requires the ecdsa package, but please do not install it yet to test missing dependencies warnings
It is installable with easyinstall(not sure for windows and osx):
 Linux Debian-based:
  apt-get install python-setuptools
  sudo easy_install ecdsa


 Windows:
  32bit http://pypi.python.org/pypi/setuptools#downloads to install setuptools
  64bit http://pypi.python.org/pypi/setuptools#windows to download, then run ez_setup.py
 
  Go to C:\Python27\Scripts
  Run easy_install.exe ecdsa

 OSX:
  http://pypi.python.org/pypi/setuptools#cygwin-mac-os-x-linux-other
  or found that too: http://stephenhucker.com/2008/04/08/python-easy-install-on-os-x-105-leopard/

[MrlostinBTC]

All have you have gave me renewed hope. I will try some of these and see what I can find.

Will report back soon. Thank you all!

[MrlostinBTC]

Yes, I was not worried about the ECDSA package missing. Not signing anything, just trying to recover. Thanks again!

[MrlostinBTC]

I have tried the wallet repair tool https://github.com/prof7bit/wallet-key-tool/releases. 4 months ago. As far as safe that is debatable. Anything in pre-compiled exe or jar format is suspicious. I do have a offline terminal setup for testing things such as this. I actually need to decrypt and dump the entire dat file in raw form. From what I am reading it may be possible but there is not a way to do it as of now.

Upadate.
Pywallet jackjack shows the same amount of keys expected. Could be a lost cause.

Need to dump raw.

Again thank you all for your input.

[PawGo]

Anything in pre-compiled exe or jar format is suspicious

<offtopic>

With a difference that jar is in fact a ZIP file with java classes and other resources like images etc. - and java class could be easy decompiled, so if you think you understand and may audit source code, this way is much easier than exe
Even online: http://www.javadecompilers.com/

[MrlostinBTC]

Just wanted to give a update. No BTC yet.

I used PawGo's link to marilyn4325 custom C++ code here. https://bitcointalk.org/index.php?topic=2637884.0

Prior Pywallet jack jack --recover scans on this suspect drive only showed encrypted keys from known empty wallets.

Running Ubuntu with the code from https://bitcointalk.org/index.php?topic=2637884.0 it found about 7 suspect wallets. This code is VERY good because it finds the header of the wallet file and dumps the 1 megabyte of raw data afterwards.

Using Berkley DB 5.3, I was able to command a dump of the suspect wallet files and then a subsequent loading into a new wallet file. Berkley is very good so far about ignoring random useless data from the dumped files. Make sure you check with the DB_dump and the DB dump -r command. Some wallets will not show keys without the -r flag. I know 4.8 would be better but I just ran them through Pywallet --recover afterwards so incompatibility isnt as much of a worry.

Using this low level scan provided from marilyn4325, It did indeed find many, many more wallets. Some unencrypted. Including my original one that I suspect may have had value. Dumping this wallet with Berkley DB_dump only shows a header, DB dump -r shows a actual unencrypted wallet with about 100 key pairs. Unedited 99 keys were originally found with pywallet, After some manual clean up of the DB_dump -r text file I now have 101. Hex data of the file shows 168 instances of the hex code 0201010420, but most will likely be duplicate key pairs.

Again thank all of you!
Just keep swimming.

[NotATether]

If the corruption is very specific that means that only certain sections of your wallet.dat are corrupted (by that I mean there's a section for private keys, one for addresses, one for metadata, and so on).

Only the private keys section (a database table to be exact) is encrypted. Also at the beginning of the file there is a wallet hash that your password is checked against. If that's the part that's corrupted then you can just ignore that  part since you already know the password, and directly decrypt the private keys section using the AES key and IV derived from the password.

If that decoding returns garbage for that table then you know the private keys section is also corrupt.

[MrlostinBTC]

I had a old BTC wallet I mined on during the non-encrypted era. This bitcoin wallet was loaded into a doge coin client and encrypted by a family member about 3 years later, Thus flushing the keypool if I am correct. I have access to about 6 possible hard drives that may have had a copy of the original unencrypted wallet. However there has been some data overwrite on some drives. Around 2013 I was messing around with Litecoin, Potcoin, Feathercoin, Dogecoin as well as Bitcoin. I knew of the corruption then, original wallet dating back to around 2010. It is a big mess.

If I dump the wallet that was encrypted/corrupted with a non-synced BTC core there is key birthdate timestamped data separation from BTC and Doge. As far as I understand if the keypool was flushed, that wallet will probably do me no good anyways. 101BTC keys, 102 Doge keys.

One hard drive has a Manufacture date of 2009, From this drive about 7 possible wallets were indeed found. Some have addresses with LTC, POT, BTC. So I know this is the drive. Really the only thing I can do is scan, dump keys and try them in the core to see if any have value. So far no luck. The un-encrypted BTC wallet I found may have been from the initial loading of the client before the corruption happened.

[MrlostinBTC]

Looking for 1 key from one of the first versions of the bitcoin client, uncompressed key obviously.

Recap,
I have a Litecoin wallet from about 2013 that a BTC 1 key original wallet.dat was loaded into and encrypted in a LTC client with known password.

Dumped that wallet with Berkley and the bottom of the keypool has about 100 pairs or 50 key value information. All of the top part front portion keypool data is the same except for the last one, as in 1 key value has a different keypool. The wallet contains the public and private key pairs in another part of the file with a known zero value possibly from the corruption, it is in compressed key format when dumped. This value reads correctly with the enc mkey when manually dumped as well.

If I dump the private key with this public key from BTC core I get a compressed private key, from that private key dumped with libbitcoin BX the EC look a little strange, middle of the key is "03abddbbbe9aa" a whole lot of a's ad b's this is just a sample here. Could be a coincidence.

Scanning file in hex it gets even more intriguing , There are 2 matching public key values in hex from the file, one has the normal starting byte 30 ending in a 2700 bytes like the rest. But the second value instead of a 2700 right after a encrypted key there is a 27A2AA52000000 value. Where the 2700 should be it starts with 27A2 right before the public key. The second value is preceded by a apparent encrypted key is exactly half the bytes of a normal encrypted key. ?.?.?

Half the key value?

My next thought. Is there a way to take a encrypted key with a known password and check it against every known public key with a balance? I have tried BTC-Recover and it claims to have some support. However it does not really support this old of a wallet. It looks as though it can be done with other versions of BIP, just not with Raw data in this format.

I apologize in advance if any of my posts seem rudimentary, I have indeed learned a great deal about some of this.

https://btcrecover.readthedocs.io/en/latest/Creating_and_Using_AddressDB/

[LoyceV]

Is there a way to take a encrypted key with a known password and check it against every known public key with a balance?

It's not entirely clear what you're looking for: if you have the password, the key isn't encrypted. I'm pretty sure I have all known public keys, but the public key is only know for addresses that have ever sent a transaction.

[NotATether]

Is there a way to take a encrypted key with a known password and check it against every known public key with a balance?

If you know the password, you don't have to do a brute-force scan. You can open the DB in "raw" mode (i.e. just as a stream of bytes), and extract the table which has the private/public keys if it is entirely uncorrupted.

Making a copy of the wallet.dat, you may be able to fill in the rest of the BDB data format to make it a database with just 1 table (I say "may" because I am talking in very abstract terms sine I'm not sure the exact specification of Berkeley  DB version 4), but don't try to extract the keys using libbitcoin. Because if the header is corrupted inside the file then it will probably just return garbage data like it did for you now.