|
Thanks @HCP, another thing to cross off. Cheers.
|
|
|
|
After doing some code archaeology, I am pretty sure that wkey records were never actually used. I am unable to find any point in time where wkey were even able to be written to disk. So it's really odd that you have a wallet file that contains wkeys.
In any case, wkey is supposed to be a private key with some extra metadata. There should be a 4 byte version number, followed by the private key, followed by an 8 byte creation time, followed by an 8 byte expiration time.
It's probably not an old Qt wallet file then. Maybe it's an old exchange wallet? This is a screenshot of part of the wallet file. Thanks for the info. https://imgur.com/a/gOm4fh8 |
|
|
|
|
During my hex editor hard drive search I have stumbled on a wallet file that has wkeys and other keys that are named differently to more modern wallet files. I don't know if wkeys are private keys or not, or whether I need to look at other things in the file. It may come to nothing but I still need to check it out, but I need to understand what I'm looking at. Thanks.
|
|
|
|
|
Does anyone know what version of Bitcoin Core was the last to use wkeys and how did the wallet.dat differ from later versions. Thanks.
|
|
|
|
Thanks so much for doing this HCP, it gives me another avenue to pursue (probably the last). I don't have much spare time at the moment to try it out and it's very time consuming for me, being the computer thicko that I am  . I might need some pointers if you don't mind, once I have a go at it. Thanks again, nice work. |
|
|
|
|
Did you run pywallet as administrator? Also I wouldn't count on recovery software to be the best option. I would run pywallet on the whole hard drive rather than on a file you recovered via recuva or whatever software. Make sure you include the passphrase when you run pywallet, if the wallet was encrypted. If It finds any private keys you can then use them with Electrum, I don't think you can just use a wallet recovered by pywallet straight into Bitcoin Core. Obviously it will be safer to try this on your cloned version of the hard drive. Good luck.
|
|
|
|
|
How hard would it be for jackjack or someone to create a standalone tool to decrypt private keys, if the correct hex strings and passphrase were inputted? Not that I'm implying he should, as he seems to be a very busy person. But If you can search out the required info with a hex editor, it would be a very flexible tool for fragmented wallet files.
|
|
|
|
I tried using 2 versions of Bitcoin Core (0.21.1 and 0.8.6) to read the wallet.dat and was given the warning "wallet.dat corrupt, salvage failed".
If you see error message when you open Bitcoin Core normally, you can external Bitcoin Core tools to salvage your wallet properly. Check this thread, Salvagewallet in latest Bitcoin core. My next step is to recover the HDD using GetDataBack instead of Recuva, and then reattempt what I have done so far.
I strongly suggest you to make RAW copy of your HDD using tools such as http://www.hddguru.com/software/HDD-Raw-Copy-Tool/. After doing that, you can use the software to scan the RAW copy instead. If you're searching text with a hex editor then you need to type key!. The exclamation mark is important, but is not used for the master key (mkey). You might not get a hit on the word name as that doesn't always appear in a wallet.dat. It is another term for address. If the wallet was encrypted by using a passphrase, then the private keys should be searched by the term ckey! if using a hex editor. |
|
|
|
|
Is the latest update useable and stable? Python 3 supported? Thanks.
|
|
|
|
When you create a recovered wallet... you have to specify a passphrase that the "recovered wallet.dat" is going to use... you then specify the "possible" passphrases it should try when recovering keys/data etc...
The script attempts to decrypt any encrypted keys found using the "possible" passphrases... and then puts them into the recovered wallet.dat, encrypted with a master key derived from the "recovered wallet.dat" passphrase (NOT the passphrase of the original wallet)
Thought so. I presume that while dumping private keys it wouldn't be impossible to show any decrypted master keys also. It would be a handy feature for any other ckeys that may share the same master key but were not gathered into the recovery. |
|
|
|
|
When a recovered wallet is dumped with pywallet, is the master key near the end the encrypted version and if so, is it a result of the passphrase given for the recovered wallet? It would be great if the original decrypted master key, or master keys were listed, as I presume that possibly more than one original lot of wallet keys are gathered into the one recovered wallet. This would be handy for trying fragmented wallets where other ckeys were not gathered and processed.
|
|
|
|
|
I think bitaddress handles base 64 to wif as well. As has been said, use the offline version with a computer that is offline.
|
|
|
|
I don't think you will be able to use that site, as there are some other background things happening that I don't think that website supports, but assuming you can decrypt the master key, then it should theoretically be possible to then decrypt individual private keys. As for decrypting the master key, I found this project which claims to be able to extract the encrypted master key, salt, IV etc from a wallet.dat: https://github.com/brichard19/core-decryptThere is also an OpenCL based project included (and a precompiled .exe  ) that claims to be able to test the master key decryption using a password dictionary. The idea being that you can identify what the wallet passphrase is... it doesn't decrypt individual keys, and it doesn't show the decrypted master key etc. It just seems to test the "encrypted master key" decryption using passwords you pass in. If this information regarding wallet.dat encryption is still valid: https://en.bitcoin.it/wiki/Wallet_encryptionThen it looks like you would need to start playing with your wallet passphrase, SHA512 and OpenSSL "EVP_BytesToKey" functionality (along with the extracted IV, Salt, iteration count etc as extracted by the python script) to derive the "key" needed to decrypt the "encrypted master key"... and then once you have the "unencrypted master key", you should be able to decrypt the individual private keys. The passphrase is no problem as I already know it. I wonder if the salt and iteration are viewable within the wallet file? How do these various scripts find them? |
|
|
|
|
So you don't have the password for the email account?
|
|
|
|
|
I think it all hinges on being able to authenticate the email when they send it to you. If you have no access to that email account then you might struggle and need to reach out to them and push things further. It sounds like you have everything needed apart from that. Good luck.
|
|
|
|
|
I've searched the 0201010420 trailing bytes and checked hundreds of private keys manually but with no success as yet. I could see they were bitcoin core keys with the data and text surrounding them. I suspect that the private key I need is encrypted and there are hundreds of those as well, plus mkeys. I noticed that each ckey marker 000104636b65 79 is followed at a point later by the trailing byte of 30 as discovered and shown in HCP's example. I'm thinking that maybe the bytes following 30 is the encrypted key and the public key is between 79 and 30 maybe?
|
|
|
|
|
What would be the minimum data required to decrypt a private key? Would it be ckey! and mkey, what about salt, is that part of the mkey? All depends on having the correct passphrase of course. My corrupt wallets have been either fragmented with groups of ckeys that have been separated from the mkey, or other data in the wallet has been corrupted causing the wallet to be unusable with normal methods. I'm pretty sure that the hex values of the mkey and ckeys can be found quite easily by using Winhex or similar. If possible, it would be fantastic to have a tool for manually inputting the keys and passphrase that doesn't get tied up with other corrupt data in the wallet.dat.
|
|
|
|
weird... then is the highlighted text that has been partially redacted the Bitcoin Address? Because it doesn't look like that address is used in that transaction at all??!? But like I said, it is very difficult to interpret what is going on when you're only providing heavily edited data  In any case, you're just looking at a debug.log from an early version of BitcoinQT (aka Bitcoin Core)... You likely won't discover anything of great value by analysing this.  Cheers. |
|
|
|
|
Could anyone tell me how to do this if it's possible. Windows and using core version 8.6
|
|
|
|
|
Show Posts
