Topic: Bitcoin private key/wallet.dat data recovery tool! (Read 69021 times)
up
Hi,
Will it recover litecoin wallet.dat as well? I made a huge mistake and lost all my coins. Will appreciate if you can help with it.
Will it recover litecoin wallet.dat as well? I made a huge mistake and lost all my coins. Will appreciate if you can help with it.
Interested as well, whats needed for other wallets
edit: just checked the source, a bit lost here, could someone point out which parts need changes for this to work for e.g. litecoin?
i guess this tool checks constants that are in the btc curve (secp256k1?) and picks the right bits around it?
Pls enlighten me
Edit: Updated to create a new wallet.dat with the recovered keys.
Edit 2: New v0.2 release, new instructions. Note that this still can't recover encrypted wallets!
Edit 3: v0.3 release to support the compressed public keys created by recent Bitcoin versions. Still can't recover encrypted wallets.
For some reason, people keep reformatting their drive or deleting their wallet.dat without taking proper backups. As casascius helpfully points out - and this is something I'd already suspected - it may be possible to recover the crucial wallet.dat private keys and the bitcoins secured with them by scanning the disk for certain markers, so long as you're lucky and the data you need isn't too fragmented and hasn't already been overwritten.
To that end, I've written a little experimental utility that tries to search for and validate those keys. It's not even close to being able to recover all keys that are recoverable - though it should work in a decent proportion of cases -and importing those keys back into a new wallet is left as an exercise for the user to figure out for now, but it might be useful to some people.
Instructions:
Run the program on your drive:
For 99% of users, this will be:
Hopefully it should find and print out a bunch of public keys and corresponding private keys, at least 100 of them, together with a file recovered-wallet.dat. Copy the recovered-wallet.dat to a USB drive and load it up in the Bitcoin client as usual (not forgetting to start it with -rescan) - with a bit of luck you should have access to your money again. I suggest not doing anything with the computer you lost the bitcoins on until you're 100% sure the recovery was successful - load up recovered-wallet.data on a different PC if at all possible.
WARNING: The recovered wallet does not contain a pool of spare keys to send change to (the old ones should get recovered but aren't marked as such). It also doesn't include any names for addresses, so the address you can copy-and-paste in the client is a NEW address created when you first started bitcoin using your recovered wallet, and any change from transactions also goes to a NEW address - none of these addresses are in the original recovered wallet. After first running Bitcoin with the recovered wallet, you MUST exit it and take backup copies of the wallet.dat in your .bitcoin directory to several locations BEFORE making or receiving any transactions - then be sure to use this version and NOT THE ORIGINAL recovered-wallet.dat from this point on. If you're using bitcoind rather than the GUI, you must also call "bitcoind getnewaddress" before shutting down and copying the wallet.dat. Also, be extremely careful about backing up your wallet on a regular basis after using this tool - Bitcoin's handling of the keypool is quirky and this may trigger bugs in it. (Added 9th July, amended 19th Sept.)
Disclaimer: This code comes with no warranty, not even an implied warranty of fitness for its intended purpose. I don't guarantee that it won't make things worse, or that the recovered keys are correct, and obviously I can't guarantee that it'll manage to recover the keys you need. Oh, and it may not be able to recover older wallets at all.
Edit 2: New v0.2 release, new instructions. Note that this still can't recover encrypted wallets!
Edit 3: v0.3 release to support the compressed public keys created by recent Bitcoin versions. Still can't recover encrypted wallets.
For some reason, people keep reformatting their drive or deleting their wallet.dat without taking proper backups. As casascius helpfully points out - and this is something I'd already suspected - it may be possible to recover the crucial wallet.dat private keys and the bitcoins secured with them by scanning the disk for certain markers, so long as you're lucky and the data you need isn't too fragmented and hasn't already been overwritten.
To that end, I've written a little experimental utility that tries to search for and validate those keys. It's not even close to being able to recover all keys that are recoverable - though it should work in a decent proportion of cases -
Instructions:
- Stop using your computer until you've recovered your data, in case something overwrites it. Shut down the PC as soon as possible.
- Obtain a suitable 32-bit Linux LiveCD, like the System Rescue CD, and boot your computer from it. You'll need working internet access (or some other way to download http://makomk.com/~aidan/wallet-recover and transfer it over)
- Open a terminal.
- Run these commands to download the utility and unpack it (2MB download - it contains largish crypto and database libraries):
Code:
wget http://www.makomk.com/~aidan/wallet-recover-0.3-linux.tar.gz
tar xzf wallet-recover-0.3-linux.tar.gz
Code:
sudo ./wallet-recover-0.3-linux/bin/32/wallet-recoverrecovered-wallet.dat
Code:
sudo ./wallet-recover-0.3-linux/bin/32/wallet-recover /dev/sda recovered-wallet.dat
WARNING: The recovered wallet does not contain a pool of spare keys to send change to (the old ones should get recovered but aren't marked as such). It also doesn't include any names for addresses, so the address you can copy-and-paste in the client is a NEW address created when you first started bitcoin using your recovered wallet, and any change from transactions also goes to a NEW address - none of these addresses are in the original recovered wallet. After first running Bitcoin with the recovered wallet, you MUST exit it and take backup copies of the wallet.dat in your .bitcoin directory to several locations BEFORE making or receiving any transactions - then be sure to use this version and NOT THE ORIGINAL recovered-wallet.dat from this point on. If you're using bitcoind rather than the GUI, you must also call "bitcoind getnewaddress" before shutting down and copying the wallet.dat. Also, be extremely careful about backing up your wallet on a regular basis after using this tool - Bitcoin's handling of the keypool is quirky and this may trigger bugs in it. (Added 9th July, amended 19th Sept.)
Disclaimer: This code comes with no warranty, not even an implied warranty of fitness for its intended purpose. I don't guarantee that it won't make things worse, or that the recovered keys are correct, and obviously I can't guarantee that it'll manage to recover the keys you need. Oh, and it may not be able to recover older wallets at all.
Hi,
Will it recover litecoin wallet.dat as well? I made a huge mistake and lost all my coins. Will appreciate if you can help with it.
Is this useable with windows? and is there a computer novices guide to getting it running?.
i used it
it works really well
my hdd was virus attacked now my wallet.dat is recovered
great job
it works really well
my hdd was virus attacked now my wallet.dat is recovered
great job
Hey, thanks a lot for posting this. I will keep it in mind.
Will be checking it out this weekend.
The suspense is killing me
Thank you for your contribution, this is a very helpful tool. I have a friend that past away in 2013 supposedly his mom said his laptop has a bunch of BTC on it. Will be checking it out this weekend.
So I wrote my own simple "privkey finder":
Code:
#include
main() {
int c, i;
// privkeys are preceeded by: 3081 d302 0101 0420 and are 32 bytes long:
while ((c = getchar()) != EOF)
if (c == 0x81 &&
getchar() == 0xd3 && getchar() == 0x02 && getchar() == 0x01 &&
getchar() == 0x01 && getchar() == 0x04 && getchar() == 0x20) {
for (i = 0; i < 32; i++)
printf("%02x", getchar());
printf("\n");
}
}
main() {
int c, i;
// privkeys are preceeded by: 3081 d302 0101 0420 and are 32 bytes long:
while ((c = getchar()) != EOF)
if (c == 0x81 &&
getchar() == 0xd3 && getchar() == 0x02 && getchar() == 0x01 &&
getchar() == 0x01 && getchar() == 0x04 && getchar() == 0x20) {
for (i = 0; i < 32; i++)
printf("%02x", getchar());
printf("\n");
}
}
Hi dooglus, where did you get the 3081 d302 0101 0420 sequence from? Did you reverse engineer that yourself, or see it elsewhere? I don't think that sequences covers all keys, because I found several in my wallet which had different leading bytes. I've modified your code to extract keys more aggressively - using a smaller sequence - and also backtrack if the conditional fails:
Code:
#include
int main() {
int c, i;
/* assume that the 32 bytes following the sequence 0420 are a private key */
while ((c = getchar()) != EOF) {
if (c == 0x04) {
if ((c = getchar()) == 0x20) {
for (i = 0; i < 32; i++)
printf("%02x", getchar());
printf("\n");
fflush(stdout);
} else {
ungetc(c, stdin); /* push back in case it's 0x04 */
}
}
}
}
int main() {
int c, i;
/* assume that the 32 bytes following the sequence 0420 are a private key */
while ((c = getchar()) != EOF) {
if (c == 0x04) {
if ((c = getchar()) == 0x20) {
for (i = 0; i < 32; i++)
printf("%02x", getchar());
printf("\n");
fflush(stdout);
} else {
ungetc(c, stdin); /* push back in case it's 0x04 */
}
}
}
}
The downside of the reduced lead sequence is that the program will cause a lot more false positives, particularly if you use it to scan an entire raw device, rather than (say) a corrupt wallet.dat file. I fed it an old 40GB Windows XP backup image, and it output nearly 600,000 potential keys, so it's really only practical for extracting keys from a known wallet file.
Hope this helps someone, anyway.
I just created the code to insert random private key into wallet.dat and bitcoin core says wallet.dat is corrupt. I just got my answer.
Code:
printf("found: ");
for (i = 0; i < 32; i++)
{
printf("%02x", fgetc(file));
fputc(rnd(),file2);
}
for (i = 0; i < 32; i++)
{
printf("%02x", fgetc(file));
fputc(rnd(),file2);
}
I think you would have better luck if you did a fgetc() with each of those fputc() calls. That way you are effectively overwriting the old privkey with a new random one rather than inserting new bytes into the file which will corrupt it.
Edit: oh, you are already doing that.
So I'm not sure what went wrong. I'll take another look.Edit2: wallet.dat stores the public keys as well as the private keys and complains if they don't match. That's why you're getting the error you're getting.
From walletdb.cpp:
Code:
// Old wallets store keys as "key" [pubkey] => [privkey]
// ... which was slow for wallets with lots of keys, because the public key is re-derived from the private key
// using EC operations as a checksum.
// Newer wallets store keys as "key"[pubkey] => [privkey][hash(pubkey,privkey)], which is much faster while
// remaining backwards-compatible.
// ... which was slow for wallets with lots of keys, because the public key is re-derived from the private key
// using EC operations as a checksum.
// Newer wallets store keys as "key"[pubkey] => [privkey][hash(pubkey,privkey)], which is much faster while
// remaining backwards-compatible.
I just created the code to insert random private key into wallet.dat and bitcoin core says wallet.dat is corrupt. I just got my answer.
Code:
#include
#include
#include
void rnd_init( void )
{
srand((unsigned)time(NULL));
}
int rnd( void )
{
int tmp;
tmp = rand();
return (tmp&0xff);
}
main()
{
int c, i=0;
FILE* file = fopen("wallet.dat","r");
FILE* file2 = fopen("new.dat","w");
rnd_init();
if ( file != NULL )
{
printf("wallet.dat opened\n");
while ( (c = fgetc(file)) != EOF )
{
fputc(c,file2);
if ( c == 0x020 && i == 6 )
{
printf("found: ");
for (i = 0; i < 32; i++)
{
printf("%02x", fgetc(file));
fputc(rnd(),file2);
}
printf("\n");
i = 7;
}
else if ( c == 0x04 && i == 5 )
{
i = 6;
}
else if ( c == 0x01 && i == 4 )
{
i = 5;
}
else if ( c == 0x01 && i == 3 )
{
i = 4;
}
else if ( c == 0x02 && i == 2 )
{
i = 3;
}
else if ( c == 0xd3 && i == 1 )
{
i = 2;
}
else if ( c == 0x81 && i == 0 )
{
i = 1;
}
else
{
i = 0;
}
}
fclose(file);
fclose(file2);
}
// privkeys are preceeded by: 3081 d302 0101 0420 and are 32 bytes long:
//while ((c = getchar()) != EOF)
//if (c == 0x81 &&
// getchar() == 0xd3 && getchar() == 0x02 && getchar() == 0x01 &&
// getchar() == 0x01 && getchar() == 0x04 && getchar() == 0x20) {
// for (i = 0; i < 32; i++)
// printf("%02x", getchar());
// printf("\n");
//}
}
#include
#include
void rnd_init( void )
{
srand((unsigned)time(NULL));
}
int rnd( void )
{
int tmp;
tmp = rand();
return (tmp&0xff);
}
main()
{
int c, i=0;
FILE* file = fopen("wallet.dat","r");
FILE* file2 = fopen("new.dat","w");
rnd_init();
if ( file != NULL )
{
printf("wallet.dat opened\n");
while ( (c = fgetc(file)) != EOF )
{
fputc(c,file2);
if ( c == 0x020 && i == 6 )
{
printf("found: ");
for (i = 0; i < 32; i++)
{
printf("%02x", fgetc(file));
fputc(rnd(),file2);
}
printf("\n");
i = 7;
}
else if ( c == 0x04 && i == 5 )
{
i = 6;
}
else if ( c == 0x01 && i == 4 )
{
i = 5;
}
else if ( c == 0x01 && i == 3 )
{
i = 4;
}
else if ( c == 0x02 && i == 2 )
{
i = 3;
}
else if ( c == 0xd3 && i == 1 )
{
i = 2;
}
else if ( c == 0x81 && i == 0 )
{
i = 1;
}
else
{
i = 0;
}
}
fclose(file);
fclose(file2);
}
// privkeys are preceeded by: 3081 d302 0101 0420 and are 32 bytes long:
//while ((c = getchar()) != EOF)
//if (c == 0x81 &&
// getchar() == 0xd3 && getchar() == 0x02 && getchar() == 0x01 &&
// getchar() == 0x01 && getchar() == 0x04 && getchar() == 0x20) {
// for (i = 0; i < 32; i++)
// printf("%02x", getchar());
// printf("\n");
//}
}
I guess I should have said a new/different private key. I didn't know if it would work.
What do you mean, "inject 32 different bytes into each"? Good to know that the script runs on any system.
I compiled it on windows using Cygwin and ran it just on a wallet.dat file. Worked great.
I'm going to modify the code and inject 32 different bytes into each, is there any problem with this?
I'm going to modify the code and inject 32 different bytes into each, is there any problem with this?
I think the code that dooglus posted just a few posts back should run on windows, assuming you know how to run a compiler on that system (I don't).
What do you mean, "inject 32 different bytes into each"? Good to know that the script runs on any system.
I compiled it on windows using Cygwin and ran it just on a wallet.dat file. Worked great.
I'm going to modify the code and inject 32 different bytes into each, is there any problem with this?
I'm going to modify the code and inject 32 different bytes into each, is there any problem with this?
I think the code that dooglus posted just a few posts back should run on windows, assuming you know how to run a compiler on that system (I don't).
What do you mean, "inject 32 different bytes into each"? Good to know that the script runs on any system.
I compiled it on windows using Cygwin and ran it just on a wallet.dat file. Worked great.
I'm going to modify the code and inject 32 different bytes into each, is there any problem with this?
I'm going to modify the code and inject 32 different bytes into each, is there any problem with this?
I think the code that dooglus posted just a few posts back should run on windows, assuming you know how to run a compiler on that system (I don't).
The ideal solution would be USB -> USB using a Linux live CD, with either no hard drive plugged in, or by running "swapoff" to make sure no virtual memory is in use at the time of the copy.
I think the code that dooglus posted just a few posts back should run on windows, assuming you know how to run a compiler on that system (I don't).
This is actually a good tool to use, but kinda hard to use for a newbie
Yeah a detailed video would handy to be honest. I got stuck in the beginning already..
wget http://www.makomk.com/~aidan/wallet-recover-0.3-linux.tar.gz
Do i need a linux server for this or can i do this with windows also?
Isn't the answer to your question rather obvious from the name of the file ?
This is actually a good tool to use, but kinda hard to use for a newbie
Yeah a detailed video would handy to be honest. I got stuck in the beginning already..
wget http://www.makomk.com/~aidan/wallet-recover-0.3-linux.tar.gz
Do i need a linux server for this or can i do this with windows also?
So after doing a scan with System Rescue CD, it find 226 keys. How do I transfer them to a usb? After Googling the issue, I cant seem to find a way to mount a usb in System Rescue so I can move files to it. Can anyone help me? Also plan on donating if I am able to get my wallet back. Thank you.
What is a System Rescue CD? It sounds like you've got some proprietary software there and maybe you have to read the manual. If you just need help mounting a USB drive on a linux system, I can help you with that.
So after doing a scan with System Rescue CD, it find 226 keys. How do I transfer them to a usb? After Googling the issue, I cant seem to find a way to mount a usb in System Rescue so I can move files to it. Can anyone help me? Also plan on donating if I am able to get my wallet back. Thank you.
You might be surprised to learn this, but your code is equivalent to mine.
Interesting, you are right, I thought left-to-right evaluation for && operator is not guaranteed.
Solution may be to introduce another variable to buffer first next getchar() value, and then in case of missed match take the value of c from that buffer instead of getchar() in the while loop condition statement.
I expect reading characters one by one is introducing lots of overhead, and it would be better to do some kind of buffering. Or maybe stdio.h handles that for me. There's also ungetc():
ungetc() pushes c back to stream, cast to unsigned char,
where it is available for subsequent read operations.
Pushed-back characters will be returned in reverse order;
only one pushback is guaranteed.
which could be all I need to avoid missing keys.
My main aim in sharing this was to show a very simple way of scanning a device for private keys that recently worked for me. It took maybe 5 hours to scan my whole (full-disk encrypted) 1 TB root partition.
This is actually a good tool to use, but kinda hard to use for a newbie
You might be surprised to learn this, but your code is equivalent to mine.
Interesting, you are right, I thought left-to-right evaluation for && operator is not guaranteed.
Solution may be to introduce another variable to buffer first next getchar() value, and then in case of missed match take the value of c from that buffer instead of getchar() in the while loop condition statement.
IMHO your code should use nested If's instead of ANDs, that way not finding expected byte should reset search to the beginning, without ever encountering false positives or missing something:
You might be surprised to learn this, but your code is equivalent to mine.
Both
Code:
if (a() && b()) ...
and
Code:
if (a()) if (b()) ...
don't call b() if a() returns a falsy value.
For example:
Code:
#include
main() {
if (printf("hello\n") == 1234 &&
printf("world\n"))
printf("omfg\n");
}
main() {
if (printf("hello\n") == 1234 &&
printf("world\n"))
printf("omfg\n");
}
Then...
Code:
$ gcc if-shortcut.c
$ ./a.out
hello
$
$ ./a.out
hello
$
Edit: see http://stackoverflow.com/a/628538/1253362 for confirmation of this.
IMHO your code should use nested If's instead of ANDs, that way not finding expected byte should reset search to the beginning, without ever encountering false positives or missing something:
You might be surprised to learn this, but your code is equivalent to mine.
Both
Code:
if (a() && b()) ...
and
Code:
if (a()) if (b()) ...
don't call b() if a() returns a falsy value.
For example:
Code:
#include
main() {
if (printf("hello\n") == 1234 &&
printf("world\n"))
printf("omfg\n");
}
main() {
if (printf("hello\n") == 1234 &&
printf("world\n"))
printf("omfg\n");
}
Then...
Code:
$ gcc if-shortcut.c
$ ./a.out
hello
$
$ ./a.out
hello
$
Code:
#include
main() {
int c, i;
// privkeys are preceeded by: 3081 d302 0101 0420 and are 32 bytes long:
while ((c = getchar()) != EOF)
if (c == 0x81 &&
getchar() == 0xd3 && getchar() == 0x02 && getchar() == 0x01 &&
getchar() == 0x01 && getchar() == 0x04 && getchar() == 0x20) {
for (i = 0; i < 32; i++)
printf("%02x", getchar());
printf("\n");
}
}
main() {
int c, i;
// privkeys are preceeded by: 3081 d302 0101 0420 and are 32 bytes long:
while ((c = getchar()) != EOF)
if (c == 0x81 &&
getchar() == 0xd3 && getchar() == 0x02 && getchar() == 0x01 &&
getchar() == 0x01 && getchar() == 0x04 && getchar() == 0x20) {
for (i = 0; i < 32; i++)
printf("%02x", getchar());
printf("\n");
}
}
Simple and useful program, dooglus, thanks for sharing it. One follow up question, I can see how you're just checing for each byte and then printing if you find them. But the code you pasted just checks for 7 bytes. There should be a check for 0x30 before the 0x81, right? Or what am I missing?
Suppose the disk image contains: "2930 3081 d302 0101 0420 privkey". Checking for 0x30 would cause my simple program to miss that privkey completely, since it never backtracks. I figured it was better to maybe get some false positives than to miss some private keys.
In tests, my code encountered bytes like these, and so missed the privkey:
0081 d302 0101 0420 3081 d302 0101 0420 privkey
It output:
3081 d302 0101 0420 privke
since the 7 bytes before the real 8 byte prefix triggered the matching code.
I'm guessing that's quite an uncommon situation.
Oh I see what you mean. I guess you could make it more robust if you, say, recurse when you find 0x30 so that you check all potential 8 byte windows. Anyway, thanks again.
Code:
#include
main() {
int c, i;
// privkeys are preceeded by: 3081 d302 0101 0420 and are 32 bytes long:
while ((c = getchar()) != EOF)
if (c == 0x81 &&
getchar() == 0xd3 && getchar() == 0x02 && getchar() == 0x01 &&
getchar() == 0x01 && getchar() == 0x04 && getchar() == 0x20) {
for (i = 0; i < 32; i++)
printf("%02x", getchar());
printf("\n");
}
}
Simple and useful program, dooglus, thanks for sharing it. One follow up question, I can see how you're just checing for each byte and then printing if you find them. But the code you pasted just checks for 7 bytes. There should be a check for 0x30 before the 0x81, right? Or what am I missing?
Suppose the disk image contains: "2930 3081 d302 0101 0420 privkey". Checking for 0x30 would cause my simple program to miss that privkey completely, since it never backtracks. I figured it was better to maybe get some false positives than to miss some private keys.
In tests, my code encountered bytes like these, and so missed the privkey:
0081 d302 0101 0420 3081 d302 0101 0420 privkey
It output:
3081 d302 0101 0420 privke
since the 7 bytes before the real 8 byte prefix triggered the matching code.
I'm guessing that's quite an uncommon situation.
IMHO your code should use nested If's instead of ANDs, that way not finding expected byte should reset search to the beginning, without ever encountering false positives or missing something:
Code:
#include
main() {
int c, i;
// privkeys are preceeded by: 3081 d302 0101 0420 and are 32 bytes long:
while ((c = getchar()) != EOF)
if (c == 0x30)
if (getchar() == 0x81)
if (getchar() == 0xd3)
if (getchar() == 0x02)
if (getchar() == 0x01)
if (getchar() == 0x01)
if (getchar() == 0x04)
if (getchar() == 0x20) {
for (i = 0; i < 32; i++)
printf("%02x", getchar());
printf("\n");
}
}
Code:
#include
main() {
int c, i;
// privkeys are preceeded by: 3081 d302 0101 0420 and are 32 bytes long:
while ((c = getchar()) != EOF)
if (c == 0x81 &&
getchar() == 0xd3 && getchar() == 0x02 && getchar() == 0x01 &&
getchar() == 0x01 && getchar() == 0x04 && getchar() == 0x20) {
for (i = 0; i < 32; i++)
printf("%02x", getchar());
printf("\n");
}
}
Simple and useful program, dooglus, thanks for sharing it. One follow up question, I can see how you're just checing for each byte and then printing if you find them. But the code you pasted just checks for 7 bytes. There should be a check for 0x30 before the 0x81, right? Or what am I missing?
Suppose the disk image contains: "2930 3081 d302 0101 0420 privkey". Checking for 0x30 would cause my simple program to miss that privkey completely, since it never backtracks. I figured it was better to maybe get some false positives than to miss some private keys.
In tests, my code encountered bytes like these, and so missed the privkey:
0081 d302 0101 0420 3081 d302 0101 0420 privkey
It output:
3081 d302 0101 0420 privke
since the 7 bytes before the real 8 byte prefix triggered the matching code.
I'm guessing that's quite an uncommon situation.
Can this be used on other wallets other than bitcoin if so would be good as I have lost a few wallets in the past on one drive that I have not used in ages and has had deleted partitions and all sorts go wrong on it. is their any windows version to t his tool or just Linux?
My code should work on any wallet and any OS with a C compiler. You may need to change the 8 bytes it looks for. Make a new wallet, load it up in a hex editor, look for the 8 bytes which precede each private key.
I thank you so much for sharing this as well, light enough to use on my arm based node.
Code:
#include
main() {
int c, i;
// privkeys are preceeded by: 3081 d302 0101 0420 and are 32 bytes long:
while ((c = getchar()) != EOF)
if (c == 0x81 &&
getchar() == 0xd3 && getchar() == 0x02 && getchar() == 0x01 &&
getchar() == 0x01 && getchar() == 0x04 && getchar() == 0x20) {
for (i = 0; i < 32; i++)
printf("%02x", getchar());
printf("\n");
}
}
Simple and useful program, dooglus, thanks for sharing it. One follow up question, I can see how you're just checing for each byte and then printing if you find them. But the code you pasted just checks for 7 bytes. There should be a check for 0x30 before the 0x81, right? Or what am I missing?
Can this be used on other wallets other than bitcoin if so would be good as I have lost a few wallets in the past on one drive that I have not used in ages and has had deleted partitions and all sorts go wrong on it. is their any windows version to t his tool or just Linux?
My code should work on any wallet and any OS with a C compiler. You may need to change the 8 bytes it looks for. Make a new wallet, load it up in a hex editor, look for the 8 bytes which precede each private key.
Can this be used on other wallets other than bitcoin if so would be good as I have lost a few wallets in the past on one drive that I have not used in ages and has had deleted partitions and all sorts go wrong on it. is their any windows version to t his tool or just Linux?
So this morning I noticed there was an outgoing transaction in my wallet that hadn't confirmed for a week. I decided I would try to send it again with a bigger fee. So I did a 'dumpprivkey' on the address that funded the unconfirmed transaction, made a new wallet, did an 'importprivkey' to import the address into the new wallet, then re-sent the transaction. There was only a single output on the address, so it used the same one again, effectively double-spending it.
Once the transaction confirmed, which it did quickly, I switched back to my main wallet, and deleted the temporary new wallet, since I was done with it. Right?
I rescanned the old wallet, using the -zapwallettxes argument to delete the old conflicting transaction, and it came up showing that I had made two spends recently, not the one that I expected. Then I remembered: the change from the new spend is only in the new temporary wallet that I just deleted.
Oops.
I looked for 'undelete' programs, but didn't find anything that looked useful. I found this thread, but the git repository seems to have died. So I wrote my own simple "privkey finder":
It's much simpler than the tool this thread is about, but it did the trick. It found the deleted private keys and I was able to get my coins back.
So I figured I'd share it.
I built and ran it like this:
I was somewhat surprised to find that the private key for the change address was on the drive 5 times. It was a new wallet that I created just to double-spend that single output, then deleted. And somehow the key found itself written to disk 5 times.
Once the transaction confirmed, which it did quickly, I switched back to my main wallet, and deleted the temporary new wallet, since I was done with it. Right?
I rescanned the old wallet, using the -zapwallettxes argument to delete the old conflicting transaction, and it came up showing that I had made two spends recently, not the one that I expected. Then I remembered: the change from the new spend is only in the new temporary wallet that I just deleted.
Oops.
I looked for 'undelete' programs, but didn't find anything that looked useful. I found this thread, but the git repository seems to have died. So I wrote my own simple "privkey finder":
Code:
#include
main() {
int c, i;
// privkeys are preceeded by: 3081 d302 0101 0420 and are 32 bytes long:
while ((c = getchar()) != EOF)
if (c == 0x81 &&
getchar() == 0xd3 && getchar() == 0x02 && getchar() == 0x01 &&
getchar() == 0x01 && getchar() == 0x04 && getchar() == 0x20) {
for (i = 0; i < 32; i++)
printf("%02x", getchar());
printf("\n");
}
}
It's much simpler than the tool this thread is about, but it did the trick. It found the deleted private keys and I was able to get my coins back.
So I figured I'd share it.
I built and ran it like this:
Code:
$ gcc -O4 -o pkgrep pkgrep.c
$ df ~/.bitcoin
Filesystem Size Used Avail Use% Mounted on
/dev/dm-1 901G 497G 359G 59% /
$ su
Password:
# ./pkgrep < /dev/dm-1
I was somewhat surprised to find that the private key for the change address was on the drive 5 times. It was a new wallet that I created just to double-spend that single output, then deleted. And somehow the key found itself written to disk 5 times.
Data Recovery is a wonderful and multifunctional recovery tool to retrieve your lost videos, photos, music, documents, emails, etc. from your computer's hard drive. Besides, it can also recover data from USB drives, external hard drives, mobile phones, digital cameras, iPods, MP3/MP4 players and other storage devices.
Some steps on how to recover the lost data with Data Recovery:
1. Select types of lost data. All the common file formats are generally classified into six different categories. Only choose the specific types of the files you need to retrieve will accelerate the scan speed.
2. Choose a location to start searching data. This option is suitable for the situation of a data loss caused by deleting or losing a partition, and re-partition.
3. Scan your computer or device. The process bar displays how long the scan will take.
4. Preview and recover the files. When the preview or search finishes, select the target files and press Recover button to save data again on your device.
Want to get back your lost data right now? IfCoupons.com offers you Discounts and Coupons for Data Recovery from different brands and companies. Come and get one!
Some steps on how to recover the lost data with Data Recovery:
1. Select types of lost data. All the common file formats are generally classified into six different categories. Only choose the specific types of the files you need to retrieve will accelerate the scan speed.
2. Choose a location to start searching data. This option is suitable for the situation of a data loss caused by deleting or losing a partition, and re-partition.
3. Scan your computer or device. The process bar displays how long the scan will take.
4. Preview and recover the files. When the preview or search finishes, select the target files and press Recover button to save data again on your device.
Want to get back your lost data right now? IfCoupons.com offers you Discounts and Coupons for Data Recovery from different brands and companies. Come and get one!
hero member
Activity: 560
Merit: 509
I prefer Zakir over Muhammed when mentioning me!
I have lost all private keys of blockchain.info wallet,
Can anyone recover it, I have nearly 50,000 btc in it.
I tried many ways but I couldn't. Help me out
Can anyone recover it, I have nearly 50,000 btc in it.
I tried many ways but I couldn't. Help me out
I think this is a spam just to increase activity. Please don't spam, you will get banned from the forum.
Blockchain.info is an online wallet. So what do you mean by that question? What are the ways you tried?
~~MZ~~
I have lost all private keys of blockchain.info wallet,
Can anyone recover it, I have nearly 50,000 btc in it.
I tried many ways but I couldn't. Help me out
Can anyone recover it, I have nearly 50,000 btc in it.
I tried many ways but I couldn't. Help me out
u are life saver to many people!
You may need an additional library
Also I don't want to hijack the thread but OP haven't logged for more than a year
Have you tried pywallet? I only requires python2.7
lol, I hadn't noticed how old the thread was Also I don't want to hijack the thread but OP haven't logged for more than a year
Have you tried pywallet? I only requires python2.7
Thanks for the tip 
Hello,
I'm trying to build your very useful tool form source as a member of the forum stated that they had more success when it was built on their machine.
I downloaded a .tar.gz snapshot of the master branch and ran make in the same directory as the akefile but got:
Please could you give me some directions if possible? I don't build software very often
Thanks
I'm trying to build your very useful tool form source as a member of the forum stated that they had more success when it was built on their machine.
I downloaded a .tar.gz snapshot of the master branch and ran make in the same directory as the akefile but got:
Code:
g++ -I/usr/include/db4.8 -I/usr/include/cryptopp -ggdb -Wall -O2 -o wallet-recover main.cpp -lcryptopp -ldb-4.8
main.cpp:29:0: warning: "_GNU_SOURCE" redefined [enabled by default]
#define _GNU_SOURCE
^:0:0: note: this is the location of the previous definition
main.cpp:39:16: fatal error: db.h: No such file or directory
#include
^
compilation terminated.
make: *** [wallet-recover] Error 1
Please could you give me some directions if possible? I don't build software very often
Thanks
You may need an additional library
Also I don't want to hijack the thread but OP haven't logged for more than a year
Have you tried pywallet? I only requires python2.7
Hello,
I'm trying to build your very useful tool form source as a member of the forum stated that they had more success when it was built on their machine.
I downloaded a .tar.gz snapshot of the master branch and ran make in the same directory as the akefile but got:
Please could you give me some directions if possible? I don't build software very often
Thanks
I'm trying to build your very useful tool form source as a member of the forum stated that they had more success when it was built on their machine.
I downloaded a .tar.gz snapshot of the master branch and ran make in the same directory as the akefile but got:
Code:
g++ -I/usr/include/db4.8 -I/usr/include/cryptopp -ggdb -Wall -O2 -o wallet-recover main.cpp -lcryptopp -ldb-4.8
main.cpp:29:0: warning: "_GNU_SOURCE" redefined [enabled by default]
#define _GNU_SOURCE
^:0:0: note: this is the location of the previous definition
main.cpp:39:16: fatal error: db.h: No such file or directory
#include
^
compilation terminated.
make: *** [wallet-recover] Error 1
Please could you give me some directions if possible? I don't build software very often
Thanks
What if you scan a drive with several wallets (litecoin, bitcoin, quarkcoin), are all the keys imported into one 'wallet.dat' file which will work with all three clients or will the have to be separated somehow??
@makomk, Thanks for the tool and please post a donation address
@makomk, Thanks for the tool and please post a donation address
Hi makomk,
I want to thank you for your Bitcoin private key/wallet.dat data recovery tool.
I recover my Gridcoins with the tool.
I want to send you btc,but I can't find the address.
Thanks again.
I want to thank you for your Bitcoin private key/wallet.dat data recovery tool.
I recover my Gridcoins with the tool.
I want to send you btc,but I can't find the address.
Thanks again.
I was able to get a recovered wallet but it was still giving me a corrupt wallet error so I ran it with the salvagewallet=1 conf file in the appdata folder and it worked!
Hi, I tried using the tool and it worked at first. I got this error after the first few minutes
Device read: Input/output error
Could someone please help? thanks
Device read: Input/output error
Could someone please help? thanks
Could this tool of yours be used to recover any accidently deleted files? I accidently removed the alphacoin folder with close 100k alphacoins in it 
will this prgram work for a litecoin wallet instead of a bitcoin wallet?
Today I tried it, version, which you can download at 1st post didn't worked, but I dowloaded source codes from GIT and that version worked for me.
I had corrupted wallet file so any python script could not open it as long probably header was damaged so it was not valid database file...
I used file instead device as long I didn't needed find wallet at raw (deleted) drive.
Code:
./wallet-recover damagedWallet.dat newWallet.dat
after move newWallet to .litecoin and rebuild tree I've got this
http://petrkr.net/a/ltcrepaired.jpeg
All "mined" transactions appears with date and time when I ran recovery tool. I can't tell if send of them will work as I still don't have synced network, but I hope so.
will this prgram work for a litecoin wallet instead of a bitcoin wallet?
This tool ignores whatever filesystem there is. It just reads it raw. It reads it as if the whole disk is just one big file. You don't need the disk to be mountable.
You can use System Rescue CD, it comes with all the tools you'll need.
Feel free to email me or PM me; i can help you through.
You can use System Rescue CD, it comes with all the tools you'll need.
Feel free to email me or PM me; i can help you through.
Thank you for the suggestions.
I was able to set it up to make it start but:
a) The key scan is taking very long. After an hour or so the program stops with 'io error: impossible to read' or something like that.
Of course the hd is crashed, so there might be some damaged clusters. Is there any way to make the program continue anyway instead of stopping?
b) The program seem to find a large number of keys. On the first scan it found 302 keys after 2 hours of work (but there was a power cut, so I could not even see the result file...). On successive scans around 100 keys. On the terminal screen I see a new line for each new key with a private key output. Is this useful in any way?
c) The file recovered-wallet.dat is written at each new key or only at the end?
I ask as I was not able to have a full run (due to the power cut and the reading errors in the next runs), but in two cases I saved the file recovered-wallet.dat. This does not seem to be populated at all. Certainly looking at it with an hex editor I cannot see any sign of the 100 keys the program tells me being recovered. Maybe they were not written yet?
Any suggestion how to make use of the terminal dump with all those private keys to attempt seeing if any of those is the lost wallet key I am after?
I tried this, but it isn't working for me.
I downloaded SystemRescueCd ---> http://www.sysresccd.org/SystemRescueCd
I booted from a DVD and went straight to the GUI, had terminal open, typed in exactly what is written in the OP and I get an error in terminal.
After I type the part with "sudo ....."
Terminal responds with:
zsh: correct 'sudo' to '_sudo' [nyae]?
If I press y: _arguments:comparguments:312:can only be called from completion function
If I press n: zsh: command not found : sudo
I have 4 hard-drives and 1 SSD. I disconnected all of them and connected the 1 hard-drive that I need to run the recovery tool on (this HDD is not bootable). It's not connected to the number 1 SATA port on the mobo. Does this therefore affect the part of the code with: '/dev/sda'? Or what's going on?
I downloaded SystemRescueCd ---> http://www.sysresccd.org/SystemRescueCd
I booted from a DVD and went straight to the GUI, had terminal open, typed in exactly what is written in the OP and I get an error in terminal.
After I type the part with "sudo ....."
Terminal responds with:
zsh: correct 'sudo' to '_sudo' [nyae]?
If I press y: _arguments:comparguments:312:can only be called from completion function
If I press n: zsh: command not found : sudo
I have 4 hard-drives and 1 SSD. I disconnected all of them and connected the 1 hard-drive that I need to run the recovery tool on (this HDD is not bootable). It's not connected to the number 1 SATA port on the mobo. Does this therefore affect the part of the code with: '/dev/sda'? Or what's going on?
I can help you here, as I had the exact same problem.
It is a problem due to how gentoo (the base of SystemRescueCd) works.
You solve it doing this.
Instead of typing sudo ./wallet-recover-0.3-linux/bin/32/wallet-recover /dev/sda recovered-wallet.dat
in the terminal window you type first:
su
(so you get the superuser priviledges)
and then simply:
./wallet-recover-0.3-linux/bin/32/wallet-recover /dev/sda recovered-wallet.dat
It will then work.
Also, careful if you work with external devices your drive to scan will NOT be sda.
with the crashed hard disk connected via usb in my case was sdc
You can see a list of all your drives via the system menu - partition names
I have a slightly different scenario and would need help.
A mate's pc crashed (it was on Windows 7), the file system (NTFS) is half corrupt, so the HDD itself won't boot or be recognised by other PC. I extracted the HDD and connected to a working PC with a USB-SATA cable.
With a data recovery tool I reconstructed the file system and tried to recover the critical wallet.dat file. I can get the entire dir out but wallet.dat seem corrupt (the file opened in an HEX file shows all zeros, seem totally empty).
How would I run this tool to scan the crashed HDD in search of these key traces?
By putting a linux distro on a CD/flash drive, then boot it and run the tool.A mate's pc crashed (it was on Windows 7), the file system (NTFS) is half corrupt, so the HDD itself won't boot or be recognised by other PC. I extracted the HDD and connected to a working PC with a USB-SATA cable.
With a data recovery tool I reconstructed the file system and tried to recover the critical wallet.dat file. I can get the entire dir out but wallet.dat seem corrupt (the file opened in an HEX file shows all zeros, seem totally empty).
How would I run this tool to scan the crashed HDD in search of these key traces?
The hard disk crashed is now an extranl drive of a working PC with Windows XP.
It is NOT recognised by the OS, so probably alsso linux will not be able to see it properly.
Only data recovery tools (like ZAR which I used) can reconstruct the File system on the crashed hdd by reading data in fragments and recovering them. I was wondering if this wallet recovery tool can do something similar or needs a drive mapping (which cannot be done due to the crash) to start with...
Also: can anyone recommend any small linux distribution which can fit on a USB drive and work with this tool?
I don't have a cd reader on that PC.
You can use System Rescue CD, it comes with all the tools you'll need.
Feel free to email me or PM me; i can help you through.
I have a slightly different scenario and would need help.
A mate's pc crashed (it was on Windows 7), the file system (NTFS) is half corrupt, so the HDD itself won't boot or be recognised by other PC. I extracted the HDD and connected to a working PC with a USB-SATA cable.
With a data recovery tool I reconstructed the file system and tried to recover the critical wallet.dat file. I can get the entire dir out but wallet.dat seem corrupt (the file opened in an HEX file shows all zeros, seem totally empty).
How would I run this tool to scan the crashed HDD in search of these key traces?
By putting a linux distro on a CD/flash drive, then boot it and run the tool.A mate's pc crashed (it was on Windows 7), the file system (NTFS) is half corrupt, so the HDD itself won't boot or be recognised by other PC. I extracted the HDD and connected to a working PC with a USB-SATA cable.
With a data recovery tool I reconstructed the file system and tried to recover the critical wallet.dat file. I can get the entire dir out but wallet.dat seem corrupt (the file opened in an HEX file shows all zeros, seem totally empty).
How would I run this tool to scan the crashed HDD in search of these key traces?
The hard disk crashed is now an extranl drive of a working PC with Windows XP.
It is NOT recognised by the OS, so probably alsso linux will not be able to see it properly.
Only data recovery tools (like ZAR which I used) can reconstruct the File system on the crashed hdd by reading data in fragments and recovering them. I was wondering if this wallet recovery tool can do something similar or needs a drive mapping (which cannot be done due to the crash) to start with...
Also: can anyone recommend any small linux distribution which can fit on a USB drive and work with this tool?
I don't have a cd reader on that PC.
I have a slightly different scenario and would need help.
A mate's pc crashed (it was on Windows 7), the file system (NTFS) is half corrupt, so the HDD itself won't boot or be recognised by other PC. I extracted the HDD and connected to a working PC with a USB-SATA cable.
With a data recovery tool I reconstructed the file system and tried to recover the critical wallet.dat file. I can get the entire dir out but wallet.dat seem corrupt (the file opened in an HEX file shows all zeros, seem totally empty).
How would I run this tool to scan the crashed HDD in search of these key traces?
By putting a linux distro on a CD/flash drive, then boot it and run the tool. A mate's pc crashed (it was on Windows 7), the file system (NTFS) is half corrupt, so the HDD itself won't boot or be recognised by other PC. I extracted the HDD and connected to a working PC with a USB-SATA cable.
With a data recovery tool I reconstructed the file system and tried to recover the critical wallet.dat file. I can get the entire dir out but wallet.dat seem corrupt (the file opened in an HEX file shows all zeros, seem totally empty).
How would I run this tool to scan the crashed HDD in search of these key traces?
I have a slightly different scenario and would need help.
A mate's pc crashed (it was on Windows 7), the file system (NTFS) is half corrupt, so the HDD itself won't boot or be recognised by other PC. I extracted the HDD and connected to a working PC with a USB-SATA cable.
With a data recovery tool I reconstructed the file system and tried to recover the critical wallet.dat file. I can get the entire dir out but wallet.dat seem corrupt (the file opened in an HEX file shows all zeros, seem totally empty).
How would I run this tool to scan the crashed HDD in search of these key traces?
A mate's pc crashed (it was on Windows 7), the file system (NTFS) is half corrupt, so the HDD itself won't boot or be recognised by other PC. I extracted the HDD and connected to a working PC with a USB-SATA cable.
With a data recovery tool I reconstructed the file system and tried to recover the critical wallet.dat file. I can get the entire dir out but wallet.dat seem corrupt (the file opened in an HEX file shows all zeros, seem totally empty).
How would I run this tool to scan the crashed HDD in search of these key traces?
Bump here.
So any news on recovering encrypted wallets?
So any news on recovering encrypted wallets?
Would it be possible to retrieve other *coins? namecoin, devcoin, litecoin etc. wallets?
I was trying to recover my corrupted bitcoin wallet with your recovery tool, I used a Ubuntu 13.04 install CD, I managed to extract 101 key pairs, and I can find the recovered-wallet.dat file, however I couldn't move the file to anywhere, it says "Error opening file: Permission denied", I've got root by type in "su" command in teminal but still no help. I'm not familiar with Linux system so could you please help me with this issue? Thanks
Yes, this is a Linux version. You'll want to stop using the OS that's on the drive with the corrupted wallet as soon as possible to reduce the odds of lost data being over-written and destroyed. The easiest way to do that is with a Linux live CD, so don't hold your breath for a Windows version, I doubt it's really worth the time. (Although the program would probably compile and run under cygwin or mingw just fine.)
You should be able to erase the block chain files or copy the wallet to a fresh install to see if it's really the wallet that's damaged. I recommend using a different machine if possible just in case.
You should be able to erase the block chain files or copy the wallet to a fresh install to see if it's really the wallet that's damaged. I recommend using a different machine if possible just in case.
Would love more info and a Windows version here...
Hi makomk,
Is this a linux version?
I have a corruption with Litecoin but dont know if there's even a problem with the wallet...
Just have the error:
"A fatal error occured. Litecoin can no longer continue safely and will quit.
EXCEPTION: 11DbException
Db::open: Invalid argument
litecoin in Runaway exception "
Can I try loading the wallet in a fresh install of the client does anybody know?
Cheers
Is this a linux version?
I have a corruption with Litecoin but dont know if there's even a problem with the wallet...
Just have the error:
"A fatal error occured. Litecoin can no longer continue safely and will quit.
EXCEPTION: 11DbException
Db::open: Invalid argument
litecoin in Runaway exception "
Can I try loading the wallet in a fresh install of the client does anybody know?
Cheers
I tried this, but it isn't working for me.
I downloaded SystemRescueCd ---> http://www.sysresccd.org/SystemRescueCd
I booted from a DVD and went straight to the GUI, had terminal open, typed in exactly what is written in the OP and I get an error in terminal.
After I type the part with "sudo ....."
Terminal responds with:
zsh: correct 'sudo' to '_sudo' [nyae]?
If I press y: _arguments:comparguments:312:can only be called from completion function
If I press n: zsh: command not found : sudo
I have 4 hard-drives and 1 SSD. I disconnected all of them and connected the 1 hard-drive that I need to run the recovery tool on (this HDD is not bootable). It's not connected to the number 1 SATA port on the mobo. Does this therefore affect the part of the code with: '/dev/sda'? Or what's going on?
I downloaded SystemRescueCd ---> http://www.sysresccd.org/SystemRescueCd
I booted from a DVD and went straight to the GUI, had terminal open, typed in exactly what is written in the OP and I get an error in terminal.
After I type the part with "sudo ....."
Terminal responds with:
zsh: correct 'sudo' to '_sudo' [nyae]?
If I press y: _arguments:comparguments:312:can only be called from completion function
If I press n: zsh: command not found : sudo
I have 4 hard-drives and 1 SSD. I disconnected all of them and connected the 1 hard-drive that I need to run the recovery tool on (this HDD is not bootable). It's not connected to the number 1 SATA port on the mobo. Does this therefore affect the part of the code with: '/dev/sda'? Or what's going on?
Hello! any chance to get this tool working with crypted wallets?
Edit: Updated to create a new wallet.dat with the recovered keys.
Edit 2: New v0.2 release, new instructions. Note that this still can't recover encrypted wallets!
Edit 3: v0.3 release to support the compressed public keys created by recent Bitcoin versions. Still can't recover encrypted wallets.
Edit 2: New v0.2 release, new instructions. Note that this still can't recover encrypted wallets!
Edit 3: v0.3 release to support the compressed public keys created by recent Bitcoin versions. Still can't recover encrypted wallets.
Sorry for doing a necro, but this is a great little bit of code! Sucks the private keys directly out of a drive, does not care about file system, OS's or anything! I just had to sub to it.
I have already put it onto my Recovery USB and tested several different scenarios. Any ideas on how/when you are going to implement support for encrypted wallets? I think that encrypted wallets is the last thing left and then this will be the ultimate key recovery tool.
Thanks
Does it matter what file system is on the HDD that we are attempting to recover from?
Not particularly, so long as it's not encrypted or compressed. Some filesystems may give a better chance of success than others though. 
Does it matter what file system is on the HDD that we are attempting to recover from?
Finally got around to adding the compressed public key support required to recover wallets created by Bitcoin 0.6 and up.
windows version?
Afraid not, sorry.
windows version?
I haven't looked at the details of how your code works, so I can't be sure, but there is a possibility that you could save yourself some maintenance effort on it if you put it together as a magicrescue recipe... Magicrescue scans block devices looking for particular sigils to recover certain kinds of files, and then calls arbitrary scripts to extract them. I don't know if it would make anything easier or not, but it might be worth a look.
Edit: Also, This seems donation-worthy, but I'm not seeing an address listed...
Edit: Also, This seems donation-worthy, but I'm not seeing an address listed...
Finally got around to rolling a new v0.2 release of this:
- The binaries are now compiled with gitian-builder, which means it now comes with both 32-bit and 64-bit binaries
- How the binary release is packaged has changed; it now comes as a tarball rather than a bare archive. The instructions have been updated to match.
- Internal changes to make the code more portable and hopefully increase the chances of successful recovery slightly. No Windows release yet though.
- May be able to recover wallet private keys from some versions of BitcoinJ, though it's rather hacky and they've changed their wallet format at least once
I don't know how to even get a copy of the wallet.dat off of the phone, I've left it untouched for two months taking up phone space.
I think the "easiest" solution is to install adb and use adb pull to copy it off. In fact, a quick google turns up these instructions. I'm not sure if this is the right Bitcoin app, but if it is then it appears it may have files with plain-text Base58 copies of the private keys you can copy off - that'd save a lot of hassle! Presumably you'd have to change the command to:Code:
adb pull /data/data/de.schildbach.wallet/files/key-backup-base58
I don't know how to even get a copy of the wallet.dat off of the phone, I've left it untouched for two months taking up phone space.
Would a bounty help to encourage your efforts?
Dunno. The main obstacle is that Java is involved. In particular, the wallet file uses Java's own serialization support which seems to be both poorly-documented and a pain to deal with.If you've got or can obtain a (non-corrupt) copy of the .wallet file from the phone in question, then it looks like bitcoinj already has a tool for opening it and printing the private keys, and that's probably the easiest option:
Code:
java -classpath bitcoinj-0.2.jar:bitcoinj-0.2-sources.jar:../lib/* com.google.bitcoin.examples.DumpWallet pingservice-prodnet.wallet
Wallet containing 0.00 BTC in:
0 unspent transactions
0 spent transactions
0 pending transactions
0 inactive transactions
0 dead transactions
Keys:
addr:1H6s7S2GS6DHDvZgQN5ufxMYj76bMMpHxh pub:044bec72bf6c0be93ffefb154ffce6622317527c8d0f78cd3c5b47f5c15af7f5750b2e1ccde5a827c83e89ef67ca1262bfa5427b732332c41104cc7483e756a0d6 priv:00fd6e40862973730e97be5b6ab08ef8ca02a3575f8c95858dcec51d88058a0839
Any possibility that this recovery tool can be used to scan an Android phone for the keys of an android client that no longer will properly update?
Not currently, no. It is/was on my TODO list to add this feature to it, but I haven't got around to it yet. (A lot of users of the Android client have been running into difficulties.) The Android client - and bitcoinj-based clients in general - store private keys in a more compact format than the official Bitcoin client does.Would a bounty help to encourage your efforts?
Any possibility that this recovery tool can be used to scan an Android phone for the keys of an android client that no longer will properly update?
Not currently, no. It is/was on my TODO list to add this feature to it, but I haven't got around to it yet. (A lot of users of the Android client have been running into difficulties.) The Android client - and bitcoinj-based clients in general - store private keys in a more compact format than the official Bitcoin client does.
Any possibility that this recovery tool can be used to scan an Android phone for the keys of an android client that no longer will properly update?
Wow, good one.
Any chance of a windows build ?
Any chance of a windows build ?
debian squeeze amd64 users will need this:
aptitude install ia32-libs
That's useful to know. Probably makes sense too... the canned instructions were mainly aimed at users running from random 32-bit LiveCDs. aptitude install ia32-libs
i got my btc back, thanks again for speeding the process along makomk :-)
Was glad to hear it helped someone - and thank you for the donation, by the way!
debian squeeze amd64 users will need this:
aptitude install ia32-libs
i got my btc back, thanks again for speeding the process along makomk :-)
aptitude install ia32-libs
i got my btc back, thanks again for speeding the process along makomk :-)
Source code?
Yep, follow the second link - it's in a git repository here (because I've set up so many of those by now I can almost do it in my sleep). A bit messy, but the code should be reasonably straighforward.Ah, your prose did not make it clear that that was a source code repository. Sorry.
Source code?
Yep, follow the second link - it's in a git repository here (because I've set up so many of those by now I can almost do it in my sleep). A bit messy, but the code should be reasonably straighforward.
Source code?
Excellent that this is out there as a resource now.
If I ever need to use it I'll definitely send some coin your way!
If I ever need to use it I'll definitely send some coin your way!
sorry to bug you with an off topic question but when i transfer a wallet.dat from a usb stick to a cdrom or to another usb stick on same computer, are there any traces of it left on hard drive?
Unless you know how the system works, you should assume that the answer is yes. Windows caches files on the disk before burning it to CD. When copying from USB -> USB you'd expect nothing to be written to the hard drive, but it goes through RAM and anything in there could potentially end up in your paging file and therefore written to disk.The ideal solution would be USB -> USB using a Linux live CD, with either no hard drive plugged in, or by running "swapoff" to make sure no virtual memory is in use at the time of the copy.
sorry to bug you with an off topic question but when i transfer a wallet.dat from a usb stick to a cdrom or to another usb stick on same computer, are there any traces of it left on hard drive?
That tool's a lot easier to use, but relies on you having a filesystem and enough of wallet.dat left intact for BerkleyDB to be able to open it.
Quote
i created a new wallet using Live CD Ubuntu, tx'd some btc to it, but then didn't save it properly. would there be any traces left on my computer?
Not a chance, sorry. Live CDs deliberately don't save anything to your computer unless you specifically tell them to - it's why I suggest using one for this, because that way you don't risk overwriting any more of the data you're trying to recover - so there's just nothing there to be recovered.
http://forum.bitcoin.org/index.php?topic=11331.0
how does your tool differ from above?
i created a new wallet using Live CD Ubuntu, tx'd some btc to it, but then didn't save it properly. would there be any traces left on my computer?
how does your tool differ from above?
i created a new wallet using Live CD Ubuntu, tx'd some btc to it, but then didn't save it properly. would there be any traces left on my computer?
Edit: Updated to create a new wallet.dat with the recovered keys.
Edit 2: New v0.2 release, new instructions. Note that this still can't recover encrypted wallets!
Edit 3: v0.3 release to support the compressed public keys created by recent Bitcoin versions. Still can't recover encrypted wallets.
For some reason, people keep reformatting their drive or deleting their wallet.dat without taking proper backups. As casascius helpfully points out - and this is something I'd already suspected - it may be possible to recover the crucial wallet.dat private keys and the bitcoins secured with them by scanning the disk for certain markers, so long as you're lucky and the data you need isn't too fragmented and hasn't already been overwritten.
To that end, I've written a little experimental utility that tries to search for and validate those keys. It's not even close to being able to recover all keys that are recoverable - though it should work in a decent proportion of cases -and importing those keys back into a new wallet is left as an exercise for the user to figure out for now, but it might be useful to some people.
Instructions:
Run the program on your drive:
For 99% of users, this will be:
Hopefully it should find and print out a bunch of public keys and corresponding private keys, at least 100 of them, together with a file recovered-wallet.dat. Copy the recovered-wallet.dat to a USB drive and load it up in the Bitcoin client as usual (not forgetting to start it with -rescan) - with a bit of luck you should have access to your money again. I suggest not doing anything with the computer you lost the bitcoins on until you're 100% sure the recovery was successful - load up recovered-wallet.data on a different PC if at all possible.
WARNING: The recovered wallet does not contain a pool of spare keys to send change to (the old ones should get recovered but aren't marked as such). It also doesn't include any names for addresses, so the address you can copy-and-paste in the client is a NEW address created when you first started bitcoin using your recovered wallet, and any change from transactions also goes to a NEW address - none of these addresses are in the original recovered wallet. After first running Bitcoin with the recovered wallet, you MUST exit it and take backup copies of the wallet.dat in your .bitcoin directory to several locations BEFORE making or receiving any transactions - then be sure to use this version and NOT THE ORIGINAL recovered-wallet.dat from this point on. If you're using bitcoind rather than the GUI, you must also call "bitcoind getnewaddress" before shutting down and copying the wallet.dat. Also, be extremely careful about backing up your wallet on a regular basis after using this tool - Bitcoin's handling of the keypool is quirky and this may trigger bugs in it. (Added 9th July, amended 19th Sept.)
Disclaimer: This code comes with no warranty, not even an implied warranty of fitness for its intended purpose. I don't guarantee that it won't make things worse, or that the recovered keys are correct, and obviously I can't guarantee that it'll manage to recover the keys you need. Oh, and it may not be able to recover older wallets at all.
Edit 2: New v0.2 release, new instructions. Note that this still can't recover encrypted wallets!
Edit 3: v0.3 release to support the compressed public keys created by recent Bitcoin versions. Still can't recover encrypted wallets.
For some reason, people keep reformatting their drive or deleting their wallet.dat without taking proper backups. As casascius helpfully points out - and this is something I'd already suspected - it may be possible to recover the crucial wallet.dat private keys and the bitcoins secured with them by scanning the disk for certain markers, so long as you're lucky and the data you need isn't too fragmented and hasn't already been overwritten.
To that end, I've written a little experimental utility that tries to search for and validate those keys. It's not even close to being able to recover all keys that are recoverable - though it should work in a decent proportion of cases -
Instructions:
- Stop using your computer until you've recovered your data, in case something overwrites it. Shut down the PC as soon as possible.
- Obtain a suitable 32-bit Linux LiveCD, like the System Rescue CD, and boot your computer from it. You'll need working internet access (or some other way to download http://makomk.com/~aidan/wallet-recover and transfer it over)
- Open a terminal.
- Run these commands to download the utility and unpack it (2MB download - it contains largish crypto and database libraries):
Code:
wget http://www.makomk.com/~aidan/wallet-recover-0.3-linux.tar.gz
tar xzf wallet-recover-0.3-linux.tar.gz
Code:
sudo ./wallet-recover-0.3-linux/bin/32/wallet-recoverrecovered-wallet.dat
Code:
sudo ./wallet-recover-0.3-linux/bin/32/wallet-recover /dev/sda recovered-wallet.dat
WARNING: The recovered wallet does not contain a pool of spare keys to send change to (the old ones should get recovered but aren't marked as such). It also doesn't include any names for addresses, so the address you can copy-and-paste in the client is a NEW address created when you first started bitcoin using your recovered wallet, and any change from transactions also goes to a NEW address - none of these addresses are in the original recovered wallet. After first running Bitcoin with the recovered wallet, you MUST exit it and take backup copies of the wallet.dat in your .bitcoin directory to several locations BEFORE making or receiving any transactions - then be sure to use this version and NOT THE ORIGINAL recovered-wallet.dat from this point on. If you're using bitcoind rather than the GUI, you must also call "bitcoind getnewaddress" before shutting down and copying the wallet.dat. Also, be extremely careful about backing up your wallet on a regular basis after using this tool - Bitcoin's handling of the keypool is quirky and this may trigger bugs in it. (Added 9th July, amended 19th Sept.)
Disclaimer: This code comes with no warranty, not even an implied warranty of fitness for its intended purpose. I don't guarantee that it won't make things worse, or that the recovered keys are correct, and obviously I can't guarantee that it'll manage to recover the keys you need. Oh, and it may not be able to recover older wallets at all.
Jump to: