Maybe I'm too trusting, but I always try to give people (that I don't know) the benefit of the doubt, and try to read their posts in the best possible light before jumping to conclusions...
In case OP really
is just a super skittish person that's genuinely looking for help, I spent a little time on this, and came up with the following:
Like other people have pointed out, it's safe to share just the "mkey" value from an encrypted wallet file. The thing is, OP doesn't want to download or run anything, which makes it really tough to guide them. So, I created a test wallet using the closest version (0.12.1) of Bitcoin that I could find (closest to the date that the
address posted
here was funded, that is), and then went through the source code for both that and Berkeley DB, to try to figure out exactly how things were laid out back then.
I came up with a really tidy/short Python script to pull out the relevant data (the encrypted key, the salt, and the iteration count). It's so short, in fact, that the sequence can actually be performed manually.
Basically, you can open up the wallet file with anything that can display hex (like Sublime Text), and then search for the following 4-byte pattern:
4300 0130. Then, you copy those four bytes along with the 66 bytes that follow it. Using the test wallet I created, for me that comes out like this (spaces removed):
43000130ac71182a748152bb788fb9deb11f2f5a55f5e848d66586747cc000826d4c0c350032153d50cbf924a2ac1dc5f6279436089ca0271b64c0e66f00000000c6fe040000The blue part is the 48-byte encrypted master key (it's 48 bytes because 16 bytes of padding are appended to the 32-byte key before it's encrypted). The green part is the 8-byte salt (needed for the key derivation function to work). The orange part is the 4-byte (little-endian) iteration count (also needed for the key derivation function). If the uncolored parts differ from the above, then you're probably not at the correct offset and should skip to the next match (or, your file was created by a build of Bitcoin that differs in some way from the one that I'm basing all of this on).
The
first 16 bytes of the encrypted master key aren't necessary to brute-force the passphrase (just the last half of the encrypted key, and the encrypted padding will suffice), so those bytes can be zeroed before sharing, like this (ignore the bolding and the underlining for now):
430001300000000000000000000000000000000055f5e848d66586747cc000826d4c0c350032153d50cbf924a2ac1dc5f6279436089ca0271b64c0e66f00000000c6fe040000If OP shares the above bytes from their own file, then people (me included) can try to help them find the correct passphrase without them actually risking anything at all.
That procedure works as follows:
(1) Take a candidate passphrase, and after appending the salt to it, hash it (with SHA-512) a certain number of times (the iteration count, which is 327366 in the above extract).
(2) Take the first 32 bytes of the 64-byte iterated-hashing result and then use that as the key to attempt decryption (with AES-256) of the last 16 bytes of the 48-byte encrypted master key (the bolded part).
(3) Take the 16 potentially-decrypted bytes from the previous step and then do a bitwise exclusive-or on them with the 16
underlined bytes.
(4) If the result is 16 bytes all with the value 16 (10 in hex), then you've probably (with the odds astronomically in your favor) found the correct passphrase.
(If anyone tries to implement the above procedure, then before throwing joules at a search for OP's passphrase, I suggest shaking the bugs out of your implementation by first testing it against my example extract: the passphrase for that is "
MasterExploder".)
