Recovering 33 character private key from legacy blockchain.info wallet

[operator55]

Hi guys

I'm totally stuck trying to recover very old wallet from blockchain.info (likely V1). I've searched entire web using keywords coming from json file but no luck.
Perhaps some expert developer who is aware of security algos can advise me on this case.

- I got password to the wallet but no email access, therefore this file is all what i have.
- If "priv" field is encoded, i can try to decode it with the password - but i need to be aware of tech specification for this "priv" field.
- Wallet is from 2013.
- My note on the backup says "wallet for bitcoin-qt client", not sure if this is true. It doesnt look fit for bitcoin-qt at all.

Problem is that i cannot restore or extract the private key from this file.. it's very weird, i heard it's base58 + some custom implementation.
This is the wallet file and i have no total clue how to decode this. The private key is very weird, it's just 33 characters. Is it even valid?
The "addr" points to correct BTC address, therefore is fully valid.

Code:

{
	"guid" : "020XXXX-XXX-8fXX-bc6c-XXXXX17XX",
	"sharedKey" : "XXXXXX-69XX2-157f-XXX4-XXXXXX083",
	"options" :
	 {
		 "pbkdf2_iterations":10,
		"fee_policy":0,
		"html5_notifications":false,
		"logout_time":600000,
		"tx_display":0,
		"always_keep_local_backup":false,
		"transactions_per_page":30,
		"additional_seeds":[]
	},
	"keys" : 
	[
		{"addr":"1MHJxxxxxxxxxxxxxxYMwR","priv":"uNKxxxxxxxxxxxxxxxxxxxxxxxxxxxBfM"} (33 characters private key)
															
	]
}

{"addr":"1MHJxxxxxxxxxxxxxxYMwR", (34 characters valid address) "priv":"uNKxxxxxxxxxxxxxxxxxxxxxxxxxxxBfM"} (33 characters private key)

Is anyone aware what is "priv" key format for this wallet?

[1714292253]

1714292253

[1714292253]

1714292253

[1714292253]

1714292253

[1714292253]

1714292253

[nc50lc]

- My note on the backup says "wallet for bitcoin-qt client", not sure if this is true. It doesnt look fit for bitcoin-qt at all.

Yes, that looks like a wallet.aes.json file from blockchain.info.

This thread have the info of old and new private key types: [overview] Recover Bitcoin from any old storage format]
But there's nothing about a 33-character prv key.

Have you tried to drag-n-drop it to their import wallet page (https://login.blockchain.com/wallet/import-wallet)?
Said, it supports blockchain.info wallet files.

[operator55]

Yes, i have tried doing using blockchain import tool.

Doesn't recognise the file.

Although the last transaction i remember on the wallet is from 2013, it could have been created even earlier. (2011-2013)
Therefore some legacy privkey format could have been used.

- My note on the backup says "wallet for bitcoin-qt client", not sure if this is true. It doesnt look fit for bitcoin-qt at all.

Yes, that looks like a wallet.aes.json file from blockchain.info.

This thread have the info of old and new private key types: [overview] Recover Bitcoin from any old storage format]
But there's nothing about a 33-character prv key.

Have you tried to drag-n-drop it to their import wallet page (https://login.blockchain.com/wallet/import-wallet)?
Said, it supports blockchain.info wallet files.

[DannyHamilton]

It's been a long time since I've looked at a wallet.aes.json file, but 33 characters doesn't seem long enough to me.  Hopefully, I'm wrong.  Have you tried this yet?

https://github.com/blockchain/my-wallet-backup-decryption-tool

[keychainX]

Yes, i have tried doing using blockchain import tool.

Doesn't recognise the file.

Although the last transaction i remember on the wallet is from 2013, it could have been created even earlier. (2011-2013)

What file name did you use when dropping the file? I know blockchain can behave weird if you dont name the textfile exactly wallet.aes.json

/KX

[operator55]

Yes, i have tried doing using blockchain import tool.

Doesn't recognise the file.

Although the last transaction i remember on the wallet is from 2013, it could have been created even earlier. (2011-2013)

What file name did you use when dropping the file? I know blockchain can behave weird if you dont name the textfile exactly wallet.aes.json

/KX

I made multiple tries. wallet.aes.json and so on.
I also managed to access mine blockchain.info wallet just now and download it + decrypt it. The private keys matches. So the key that is problematic was somehow imported into blockchain.info and it was considered it valid at some point. Same private key is present in JSON unencrypted blob in 2020. Some sort of hint is, that the wallet was used around 2013.

It's been a long time since I've looked at a wallet.aes.json file, but 33 characters doesn't seem long enough to me.  Hopefully, I'm wrong.  Have you tried this yet?

https://github.com/blockchain/my-wallet-backup-decryption-tool

Yes i have tried it after downloading encrypted wallet from blockchain.info and using this tool, to see what blockchain.info stores in it's JSON blob.
Such test, completely overrules scenario where backup file was somehow modified/had its integrity violated. The exact same private is being returned by blockchain now in JSON, after downloading wallet using btcrecovery python tools in 2020. This results in exactly same weird 33 characters private key.


When interacting with BC.info user interface - the key shows up in "Imported Addresses" and while clicking on "Show private key" on blockchain.info it displays "Unsupported Private Key".

So TLDR: I managed to access blockchain wallet using web interface and their "GUID" login, but i cannot make any transactions or export private key - as it shows up as invalid/unsupported one. The 33 character private key from 2013 backup is the same as from 2020 backup.   Scenario where backup is corrupted is excluded i think. Therefore the key at some point was considered valid by blockchain if it end up being in wallet backup.

If someone manages to provide a good hint, i'll make sure you get paid.  

[pooya87]

When interacting with BC.info user interface - the key shows up in "Imported Addresses" and while clicking on "Show private key" on blockchain.info it displays "Unsupported Private Key".
The 33 character private key from 2013 backup is the same as from 2020 backup.

it may not even be a private key. just because the JSON file says "priv" in front of it doesn't make it so.
since it seems like this address is an imported one maybe you imported a bitcoin address and that key (uNKxxxxxxxxxxxxxxxxxxxxxxxxxxxBfM) is some data that corresponds with the address like its 20 byte hash160.

try decoding it with base58check (base-58 encoding with a checksum) and see if it is a valid encoding and what the result is.
don not post the result anywhere just tell us the length of the byte result, the first byte and the last.
if it is indeed a valid base-58 string with 4 byte checksum and gave you 21 bytes after decoding (1 byte may be the type) then you just have a hash not a private key. and you should be able to see the same 20 bytes if you perform the same decoding on your address (1MHJxxxxxxxxxxxxxxYMwR)

[operator55]

When interacting with BC.info user interface - the key shows up in "Imported Addresses" and while clicking on "Show private key" on blockchain.info it displays "Unsupported Private Key".
The 33 character private key from 2013 backup is the same as from 2020 backup.

try decoding it with base58check (base-58 encoding with a checksum) and see if it is a valid encoding and what the result is.

Thanks @pooya87, i will try it in next week when i have some more free time Finally a hint that makes some sense.

Not deseperate to recover but just very interested to see what is it and how it ended up in blockchain.info.

[travelvc]

Hey @operator55

I wrote some standalone code that can convert the old blockchain.info wallet (priv:) key base58 format, in to WIF.

You'll need Python 3. Here's the link to the Gist.

https://gist.github.com/Jun-Wang-2018/3105e29e0d61ecf88530c092199371a7#gistcomment-3522248

Hope you find it helpful.

[ymgve2]

I made a script that will dump your blockchain.info wallet data:

https://gist.github.com/ymgve/f66fb29f32380f79e68bbed997bac60f

I wonder if the "priv" key this script shows matches the one in your backup, or if it's longer.