[Data Recovery Problem] Recovering many Wallet.dat from repartitioned Hard drive

[Praxis]

1) I had a Linux system with many wallets ,bitcoin, litecoin, devcoin, etc.  and due to immense stupidity forgot to backup the hidden dot.folders ( .litecoin , .namecoin ... ) - where the wallets are - upon reinstalling a new OS

2) After deleting the partition and just before starting installing a new OS I cancelled this so the disk is still empty - no files were written over it ... this is why I have hope

3) I tried this tool: http://www.btcnn.com/2011/09/recovering-lost-due-to-format-bitcoin.html -

it did recover around 555 keys ... but it saves them all in one .dat - how can I ever import them unto many wallets?

4) I tried using PhotoRec to recover the .dat files using this : http://www.cyplo.net/2012/04/01/bitcoin-wallet-recovery-photorec/ - guide

this looks better since it saves many .dat files ... but some are 180 KB, some are 300 KB, some are 1 MB, some 600 MB (?)

I tried running *coin in a LiveCD environment and replacing wallet.dat with each of those files but it doesnt work.

---

I'm about to give up ... any ideas? I'll reward the person who can help

[1715406876]

1715406876

[1715406876]

1715406876

[1715406876]

1715406876

[1715406876]

1715406876

[jackjack]

Pywallet can read all the private keys it can find (doesn't care if in a .dat or not) on a partition and put them all in the same wallet.
If for whatever reason you don't want to use it, give a look at wxHexEditor. It might allow to search for patterns (prefix of private keys for example) and save the following bytes.

[Praxis]

Pywallet can read all the private keys it can find (doesn't care if in a .dat or not) on a partition and put them all in the same wallet.
If for whatever reason you don't want to use it, give a look at wxHexEditor. It might allow to search for patterns (prefix of private keys for example) and save the following bytes.

Thanks. Pywallet looks great, the problem is, I deleted the partition on which the files were. So I need a "raw scan" or "deep scan" or how should I put it.

It does work however if I apply Pywallet ON the recovered .dat (recovered with the makomk tool : https://bitcointalk.org/index.php?topic=25091.0 - it scans whole disk )

So I think now I KNOW it's possible, the problem is that makomk retrieved only keys that looked like bitcoin addr. starting with 1... it didnt retrieve the other wallets of the other alt-coins

[jackjack]

Pywallet can read all the private keys it can find (doesn't care if in a .dat or not) on a partition and put them all in the same wallet.
If for whatever reason you don't want to use it, give a look at wxHexEditor. It might allow to search for patterns (prefix of private keys for example) and save the following bytes.

Thanks. Pywallet looks great, the problem is, I deleted the partition on which the files were. So I need a "raw scan" or "deep scan" or how should I put it.

It does work however if I apply Pywallet ON the recovered .dat (recovered with the makomk tool : https://bitcointalk.org/index.php?topic=25091.0 - it scans whole disk )

So I think now I KNOW it's possible, the problem is that makomk retrieved only keys that looked like bitcoin addr. starting with 1... it didnt retrieve the other wallets of the other alt-coins

Pywallet does read raw disks, look in the help for the 4 commands starting with --recov. See http://pywallet.tk/ too, "Read a device to find deleted keys (CLI only)".
It definitely works on Linux, I tested it myself.

Also, as it looks for private keys, all your private keys are put in the recovered wallet. Bitcoin, Litecoin or whatever.

[Praxis]

Pywallet can read all the private keys it can find (doesn't care if in a .dat or not) on a partition and put them all in the same wallet.
If for whatever reason you don't want to use it, give a look at wxHexEditor. It might allow to search for patterns (prefix of private keys for example) and save the following bytes.

Thanks. Pywallet looks great, the problem is, I deleted the partition on which the files were. So I need a "raw scan" or "deep scan" or how should I put it.

It does work however if I apply Pywallet ON the recovered .dat (recovered with the makomk tool : https://bitcointalk.org/index.php?topic=25091.0 - it scans whole disk )

So I think now I KNOW it's possible, the problem is that makomk retrieved only keys that looked like bitcoin addr. starting with 1... it didnt retrieve the other wallets of the other alt-coins

Pywallet does read raw disks, look in the help for the 4 commands starting with --recov. See http://pywallet.tk/ too, "Read a device to find deleted keys (CLI only)".
It definitely works on Linux, I tested it myself.
 
Also, as it looks for private keys, all your private keys are put in the recovered wallet. Bitcoin, Litecoin or whatever.

This is amazing, thank you. Are you the creator of this tool? It's a life safer.
I'm doing the raw recovery now & it will take some time.
 Excuse the (probably) dumb question, but what is "Gio"?
Is it the same as gigabytes?  1 Gio = 1 GB ?

[Praxis]

It managed to import just a few keys (2 or 3) and then gave me this error:

Traceback (most recent call last):
  File "./pywallet.py", line 4438, in <module>
    importprivkey(db, sec, "recovered: %s"%sec, None, True)
  File "./pywallet.py", line 2291, in importprivkey
    crypted = 'salt' in json_db['mkey']
KeyError: 'mkey'
xubuntu@xubuntu:~$

[jackjack]

Pywallet can read all the private keys it can find (doesn't care if in a .dat or not) on a partition and put them all in the same wallet.
If for whatever reason you don't want to use it, give a look at wxHexEditor. It might allow to search for patterns (prefix of private keys for example) and save the following bytes.

Thanks. Pywallet looks great, the problem is, I deleted the partition on which the files were. So I need a "raw scan" or "deep scan" or how should I put it.

It does work however if I apply Pywallet ON the recovered .dat (recovered with the makomk tool : https://bitcointalk.org/index.php?topic=25091.0 - it scans whole disk )

So I think now I KNOW it's possible, the problem is that makomk retrieved only keys that looked like bitcoin addr. starting with 1... it didnt retrieve the other wallets of the other alt-coins

Pywallet does read raw disks, look in the help for the 4 commands starting with --recov. See http://pywallet.tk/ too, "Read a device to find deleted keys (CLI only)".
It definitely works on Linux, I tested it myself.
 
Also, as it looks for private keys, all your private keys are put in the recovered wallet. Bitcoin, Litecoin or whatever.

This is amazing, thank you. Are you the creator of this tool? It's a life safer.
I'm doing the raw recovery now & it will take some time.
 Excuse the (probably) dumb question, but what is "Gio"?
Is it the same as gigabytes?  1 Gio = 1 GB ?

I didn't create it, it's joric. His version "only" had wallet dumping and importing though.
I added the rest, including the recovery.

'o' means 'B'. Pywallet accepts both.
And the 'i' indicates that you're using a binary prefix. http://en.wikipedia.org/wiki/Binary_prefix
 (long story short, 1024**3 instead of 1000**3)
Both binary and SI prefixes are accepted.


As for the error, I'll look at that right now

[jackjack]

Ok I get it, wait a bit I'll push a fix soon

Done


Edit: Are your wallets encrypted? Because I just remembered they can't be recovered (the recovery feature is old and never draw much attention) but I can add this if you need it.

[Praxis]

Ok I get it, wait a bit I'll push a fix soon

Done


Edit: Are your wallets encrypted? Because I just remembered they can't be recovered (the recovery feature is old and never draw much attention) but I can add this if you need it.

You're the best.  

Yes, they were encrypted. Would it be possible to recover those?

[jackjack]

I'm glad it's appreciated!

It will be possible if there's a common pattern. I'm working on it now, I'll come back to report any info.
Also, maybe there's still a copy of your wallets before you encrypt them on the disk, so try anyway with the current version.

Edit: Wow, that's soooo slow! I'll try to make it faster once I'm done with encrypted wallets support

[jackjack]

Good news, I found the pattern.
How much time can you wait by the way? Could you wait for a few days?

[Praxis]

Good news, I found the pattern.
How much time can you wait by the way? Could you wait for a few days?

Awesome!! I'm so happy to hear.
Sure I will wait - the only alternative is loosing all the coins from all the wallets!
I can work on my PC anyway ... this Xubuntu USB Live OS is good enough for the time being.
I won't touch the drive of course.

[Praxis]

Also import finished, with your new pywallet:

Importing key  111/111:
Address (Bitcoin): 1BKGXf9pFg14XK38Sbj6w44dLE3jYABZdp

It seems though only addresses starting with "1" were found.
Not sure which wallet was that.

I had lots of Worldcoins for instance but no address starting with "W" was found. I wonder if it's because it was encrypted?

[jackjack]

All the addresses found will have the Bitcoin format. Keep in mind that this format in nearly never used in the wallet (only for labels) though.
AFAIK all the altcoins have the same wallet format than Bitcoin, so putting the recovered wallet in the altcoin dir and making a rescan should (must!) work.

Also, yes the current pywallet won't ever find any encrypted key so that's why.

By the way, everything's working now. I still have to make things clean, pretty and practical but it's definitely working with encrypted private keys. I'll push the update in around 24 hours.

[jackjack]

I don't have access to a Linux computer for the whole week-end... And Windows refuses to let me read raw disks correctly so you'll have to wait a bit more.

[jackjack]

Ok, use pywallet 2.1.0b1: http://pastebin.com/raw.php?i=zU2x7amw
The recovery now runs with encrypted+unencrypted on linux+windows

[Praxis]

Ok, use pywallet 2.1.0b1: http://pastebin.com/raw.php?i=zU2x7amw
The recovery now runs with encrypted+unencrypted on linux+windows

Wonderful! Going to try it now.

[Praxis]

I'm having some problems running it. I'm currently in a Linux LiveCD environment (running Manjaro which is a Arch-linux based distro, from an USB key). I tried to run the py with ./sudo pywallet.py after having chmod +x it, and it gives me this:

Code:

[manjaro@manjaro Code]$ ls
bsddb3-6.0.0/  pywallet.py*  pywallet.py~

[manjaro@manjaro Code]$ sudo ./pywallet.py
: No such file or directory

I thought it was a problem of me not having the bsddb that you write is a requirement, so I installed it, but it's still the same.
 

Code:

[manjaro@manjaro Code]$ python --version
Python 3.3.2

[manjaro@manjaro Code]$ python
Python 3.3.2 (default, May 21 2013, 15:40:45) 
[GCC 4.8.0 20130502 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.

>>> help('modules')

Please wait a moment while I gather a list of all available modules...

Within the list of modules, I see a long list, the relevant part is here:

Code:

[b]...[/b]
_bisect             base64              ipaddress           smtpd
_bz2                bdb                 itertools           smtplib
_codecs             binascii            json                sndhdr
_codecs_cn          binhex              keyword             socket
_codecs_hk          bisect              lib2to3             socketserver
_codecs_iso2022     [b]bsddb3 [/b]             linecache           spwd
[b]...[/b]

If I try to run it like this, I get the following error:

Code:

[manjaro@manjaro Code]$ sudo python pywallet.py
  File "pywallet.py", line 845
    _p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2FL
                                                                           ^
SyntaxError: invalid syntax

What do you think could be the issue? Should I load Ubuntu on the USB instead?

[jackjack]

Yeah sorry I'll put a specific error about that... You need python 2.*, pywallet can't run with python 3

[Praxis]

Yeah sorry I'll put a specific error about that... You need python 2.*, pywallet can't run with python 3

oh, thanks for the fast reply!! Got it! Let me retry with python2

[Praxis]

I just tried

Code:

sudo python2 ./pywallet.py

and it works!!

Going to run the recover now

This is quite the adventure. I'd never thought something like this could be fun, but it actually is in a strange way , even though real money is at stake ... !

Fingers crossed now

[Kouye]

Agreed, I had to install, had pywallet working - I didn't have python on my computer, and understand how to use it...
Was a lot of fun, even more since I managed to google for it from scratch, and finally succedeed.

Great tool, I agree with D&T it's a shame jackjack didn't receive more tips for it. Sending one (small tip, I'm pooooor!!!) now, in memory of this precious moment where it worked.

[Praxis]

Works now, it asks me for all the passphrases, I typed all the passes that I remember - I'm sure about the passes for the most important wallets - ... after all this, it gives me this:

Code:

Starting recovery.
Can't open /dev/sda, check the path or try as root
[root@manjaro Code]# 

Which is odd, since I am running this as root, and /dev/sda is the right path:

Code:

[root@manjaro Code]# fdisk -l

WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

Disk /dev/sda: 640.1 GB, 640135028736 bytes, 1250263728 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk label type: gpt


#         Start          End    Size  Type            Name
 1          162   1241514017    592G  unknown         
 2   1243977728   1250263023      3G  Linux swap      
 3   1250263074   1250263689    308K  unknown         

Is it because I run it with "python2 pywallet.py" instead of "./pywallet.py" - I think it shouldn't matter, I still ask

Otherwise I'll try a different Linux LiveCD. Sorry for so many questions. As Kouye has said you deserve fat tips for your work, when I get my hands on the lost coins I will donate a significant amount of my coins.

[jackjack]

Thanks for the kind words+tips guys

Praxis: Try with a specific partition, like /dev/sda1
I never tried the whole disk sda so I'm not sure it works

Is it because I run it with "python2 pywallet.py" instead of "./pywallet.py"

Nope
And changing the LiveCD shouldn't change anything

[Praxis]

Same error if I run with /dev/sda or /dev/sda1 or /dev/sdaX... "Can't open /dev/sda, check the path or try as root" ...

But with the old version of pywallet, I ran it on /dev/sda and it worked well. In fact, the old version works on /dev/sda or any other, /dev/sdax

I just tried again the old version :

Code:

[root@manjaro Documents]# python2 pywalletOld.py --recover --recov_device /dev/sda --recov_size 30Gio --recov_outputdir /home/manjaro/Documents/

0.00/32.21 Go
   ETA: 07:00:09

0.01/32.21 Go
   ETA: 01:04:14

0.02/32.21 Go
   ETA: 01:04:14

My partition table is currently a clusterfuck but it shouldn't be the reason, since with old pywallet I can scan /dev/sda directly. It's really strange, I can't understand.

[jackjack]

I'm using windows since yesterday so I think I made a windows fix that broke it...
Sorry for this, I'll give it a look a bit later

[scintill]

Have you tried guessing the old partition table with gpart?  Gparted has a nice UI frontend that will scan for partitions, then let you mount them.

If all that's happened is your partition table is gone, you have pretty good chances of finding your filesystems entirely intact, you just have to find where they are located on the disk.

[Praxis]

Have you tried guessing the old partition table with gpart?  Gparted has a nice UI frontend that will scan for partitions, then let you mount them.

If all that's happened is your partition table is gone, you have pretty good chances of finding your filesystems entirely intact, you just have to find where they are located on the disk.

Thanks for the ideas. Problem is, I made new partitions, not just deleted the old ones.haven-t done anything except making new partitions though. No idea how Gparted could restore my old partition table ...

the good news is that I feel I'm really close to recovering wallets with jackjack's pywallet after he made the changes to scan encrypted wallets

[trilightzone.org]

Have you tried guessing the old partition table with gpart?  Gparted has a nice UI frontend that will scan for partitions, then let you mount them.

If all that's happened is your partition table is gone, you have pretty good chances of finding your filesystems entirely intact, you just have to find where they are located on the disk.

Thanks for the ideas. Problem is, I made new partitions, not just deleted the old ones.haven-t done anything except making new partitions though. No idea how Gparted could restore my old partition table ...

the good news is that I feel I'm really close to recovering wallets with jackjack's pywallet after he made the changes to scan encrypted wallets

Maybe for the next time but if something like this happens it's important to first make a raw disk image and store it somewhere as a backup. Then work on the drive to get your data back. In case something goes wrong you at least have a raw backup image of the drive.

Hope with the good tools in this thread you'll get everything back or at least the important wallets !

[scintill]

Thanks for the ideas. Problem is, I made new partitions, not just deleted the old ones.haven-t done anything except making new partitions though. No idea how Gparted could restore my old partition table ...

the good news is that I feel I'm really close to recovering wallets with jackjack's pywallet after he made the changes to scan encrypted wallets

It depends, if by "make" new partitions that includes formatting them, then it does hurt your chances pretty badly.  Gparted scans the disk for filesystem signatures and can deduce the partitions' start and size from those.  If all you've done was delete the partition table and allocate space for new partitions, those signatures and all the rest of the data needed to store the old files would still be there.

Even if you formatted the new partitions, it might still be able to find something if the beginnings of the old and new partitions happened to be far enough apart, but it seems like a slim chance, and maybe you don't need to try it if you're making progress with pywallet.

[jackjack]

Pretty dumb I don't print the error when it crashes...
Done here 2.1.0b3: http://pastebin.com/raw.php?i=pXXh2bNF

You will still get the "path or try as root" error but the line just below will give some additional details

[Praxis]

Code:

Starting recovery.
Can't open /dev/sda, check the path or try as root
("'module' object has no attribute 'O_BINARY'",)

[jackjack]

2.1.0b4 should work: http://pastebin.com/raw.php?i=wmXTdQrf

[Praxis]

Works!! You're awesome! I run the proccess now

[jackjack]

Great
Good luck

[Praxis]

I think these might be some great news :

Code:

640.00 Go read
640.10 Go read
Found 46 possible wallets
Found 8414 possible encrypted keys
Found 5443 possible unencrypted keys

Possible wallet #1
with passphrase #1 

 [manjaro@manjaro ~]$ 

So, it works! Even for encrpyted wallets!

As far as I know pywallet is now the only program that can do this

Problem is, I can't find the output wallet.

This was my parameter in the command line:

Code:

--recov_outputdir /home/manjaro/Documents/

The folder exists and I ran it as root so there is write access.

But the file isn't there after it finished.

Sorry for nagging you so much  

[Praxis]

Looks as if it finds all keys/wallets, even the encrpyted ones, but then it should go into phase 2 - applying the passwords - but there it just quits the program, if I understand correctly.

[jackjack]

Looks as if it finds all keys/wallets, even the encrpyted ones, but then it should go into phase 2 - applying the passwords - but there it just quits the program, if I understand correctly.

That's exactly what I was about to ask you: did it stop just after "Possible wallet #1 with passphrase #1 "? Nothing printed after this?
If so, it definitely crashed
I'll try to see what could have happened and report here

[Praxis]

Looks as if it finds all keys/wallets, even the encrpyted ones, but then it should go into phase 2 - applying the passwords - but there it just quits the program, if I understand correctly.

That's exactly what I was about to ask you: did it stop just after "Possible wallet #1 with passphrase #1 "? Nothing printed after this?
If so, it definitely crashed
I'll try to see what could have happened and report here

Yes. If there's any other information I can give, let me know. Anything that could help.
Sadly my Python skills don't go a lot further than a hello world program.

[jackjack]

For now I really don't see what could make it crash
Also you'll have to scan all the drive again the next time you'll run the recovery I'm sorry for that...

Good news though, I just coded the creation of a partial file that keeps useful offsets before the crash, so you'll have to run the long disk reading only once more (you should do it now)
You don't have anything special to do: run the same command and pywallet will save 'pywallet_partial_recovery_timestamp.dat' in the outputdir before crashing
Next time you run a recovery, change

Code:

--recov_device=c:\

to

Code:

--recov_device=PartialRecoveryFile:c:\path\to\pywallet_partial_recovery_timestamp.dat

2.1.0b5
http://pastebin.com/raw.php?i=xi4ivsCH

[Praxis]

Yay, I have a pywallet_partial_recovery_timestamp.dat file now.

If I load it in, say, Worldcoin, it gives me an error.  I think I should run pywallet ON this file now to extract the crypted keys from it somehow? If I just put -recov_device as the file instead of /dev/sda like you said, it still crashes like before

[jackjack]

This file is not a wallet at all, it's just the list of the places where pywallet found keys.
Thus this avoid to read the disk again: pywallet just has to look around these places.

So you don't have to wait 3 hours each time you try the recovery

For now I didn't try any fix so it's normal it crashes like before. The goal was only to create this intermediate file.
Try this (using the partialrecoveryfile:, as you will always do from now on) and post all the output
2.1.0b6
http://pastebin.com/raw.php?i=UeavfR1a

[Praxis]

I ran it with the file, not /dev/sda, like you said:

Code:

Possible passphrase: 

Starting recovery.

Loaded 640.1 Go from /dev/sda

Found 46 possible wallets
Found 8414 possible encrypted keys
Found 5443 possible unencrypted keys

Possible wallet #1
    with passphrase #1  a
b
[manjaro@manjaro ~]$

[jackjack]

Odd
Do you have strange/UTF8 characters in your passphrase?

[Praxis]

Odd
Do you have strange/UTF8 characters in your passphrase?

only alphanumeric mixed with few symbols such as  ! , # , % , & , ...

but now that I think of it, when I encrypted the passwords, I was using a Slovenian keyboard / encoding, which is basically like American plus a few extra characters... and the keys are placed a bit differently

could that be the reason? (even though I did not use those special Slovenian characters in the passwords)

[jackjack]

I can't reproduce it
Try with random passphrases containing only alphanumeric characters
Does it crash too?

but now that I think of it, when I encrypted the passwords, I was using a Slovenian keyboard / encoding, which is basically like American plus a few extra characters... and the keys are placed a bit differently

could that be the reason? (even though I did not use those special Slovenian characters in the passwords)

Maybe but not likely if there is no Slovenian character in the passphrase
I'll try other things when I'm back home in a few hours

[Praxis]

Code:

[manjaro@manjaro Documents]$ sudo python2 ../Downloads/pywallet.py --recover --recov_device=PartialRecoveryFile:./pywallet_partial_recovery_1374430501.dat --recov_outputdir /home/manjaro/Documents/ --recov_size 640.1Gio
Enter the passphrase for the wallet that will contain all the recovered keys: asdf

Enter the possible passphrases used in your deleted wallets.

Possible passphrase: fdsa
Possible passphrase: 

Starting recovery.

Loaded 640.1 Go from /dev/sda

Found 46 possible wallets
Found 8414 possible encrypted keys
Found 5443 possible unencrypted keys

Possible wallet #1
    with passphrase #1  a
b
[manjaro@manjaro Documents]$ 

[jackjack]

Try this one and post the lines beginning with "crypter" and "skfp": http://pastebin.com/raw.php?i=0SMbAwat (with random passphrases too as it will print the passphrase you entered)

I'm sorry to make you try files so many times...

[Praxis]

It is I who am sorry for all these complications and deeply thankful for your help.

I attach a picture because I'm worried copy/paste wouldn't reproduce the strange characters it outputs:

[jackjack]

This seems desperately normal...
This one? http://pastebin.com/raw.php?i=PgXbLpdL

Ok I'll tell you what I'm doing, that would be less annoying for you. I found the function that crashes but I don't understand why it crashes without printing any error as it should. Also I don't even understand why it is crashing at all.
The last version prints something after each line within that function so that I'll know which one crashed.

Did you compile ssl yourself?

[Praxis]

Thank you for the information. I will try the other file now.

I did not compil SSL myself. I'm using a LiveCD of Manjaro which is a version of the rolling-release Arch distribution.

Here's verbose information output on SSL version:

Code:

[manjaro@manjaro Downloads]$ openssl version -a
OpenSSL 1.0.1e 11 Feb 2013
built on: Sun Feb 17 13:43:48 CET 2013
platform: linux-x86_64
options:  bn(64,64) md2(int) rc4(8x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) 
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/etc/ssl"
[manjaro@manjaro Downloads]$ 

[Praxis]

Different error this time - with the latest pastebin:

[jackjack]

Good idea posting the openssl version. I have 1.0.1c but I highly doubt this comes from that. I'll check though.

About the error, please delete these two lines and try again:
   line 769:   print strKeyData.encode('hex')
   line 772:   print chSalt.encode('hex')

[Praxis]

Code:

Possible wallet #1
    with passphrase #1  a
b
SKFP params: fdas �m�����* 58001 0
za
zc
zd
ze
[manjaro@manjaro Downloads]$ 

[jackjack]

I'm really starting to think this comes from openssl
http://pastebin.com/raw.php?i=1QyNB5Af

[Praxis]

Code:

Possible wallet #1
    with passphrase #1  a
b
SKFP params: ytrewq �m�����* 58001 0
za
zc
zd
ze
zf
zg
zh
zi

Perhaps I should just try another distribution that has another version of openssl?

[jackjack]

Yes, please try another distribution if you can
Don't forget to keep pywallet_partial_recovery_1374430501.
Do you have an exotic hardware?

[Praxis]

[manjaro@manjaro Documents]$ sudo hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
   Model Number:       WDC WD6401AALS-00L3B2                   
   Serial Number:      WD-WCASY4710125
   Firmware Revision:  01.03B01
   Transport:          Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5
Standards:
   Supported: 8 7 6 5
   Likely used: 8
Configuration:
   Logical      max   current
   cylinders   16383   16383
   heads      16   16
   sectors/track   63   63
   --
   CHS current addressable sectors:   16514064
   LBA    user addressable sectors:  268435455
   LBA48  user addressable sectors: 1250263728
   Logical/Physical Sector size:           512 bytes
   device size with M = 1024*1024:      610480 MBytes
   device size with M = 1000*1000:      640135 MBytes (640 GB)
   cache/buffer size  = unknown
Capabilities:
   LBA, IORDY(can be disabled)
   Queue depth: 32
   Standby timer values: spec'd by Standard, with device specific minimum
   R/W multiple sector transfer: Max = 16   Current = 1
   Recommended acoustic management value: 128, current value: 254
   DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
        Cycle time: min=120ns recommended=120ns
   PIO: pio0 pio1 pio2 pio3 pio4
        Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
   Enabled   Supported:
          SMART feature set
          Security Mode feature set
      *   Power Management feature set
      *   Write cache
      *   Look-ahead
      *   Host Protected Area feature set
      *   WRITE_BUFFER command
      *   READ_BUFFER command
      *   NOP cmd
      *   DOWNLOAD_MICROCODE
          Power-Up In Standby feature set
      *   SET_FEATURES required to spinup after power up
          SET_MAX security extension
          Automatic Acoustic Management feature set
      *   48-bit Address feature set
      *   Device Configuration Overlay feature set
      *   Mandatory FLUSH_CACHE
      *   FLUSH_CACHE_EXT
      *   SMART error logging
      *   SMART self-test
      *   General Purpose Logging feature set
      *   64-bit World wide name
      *   Segmented DOWNLOAD_MICROCODE
      *   Gen1 signaling speed (1.5Gb/s)
      *   Gen2 signaling speed (3.0Gb/s)
      *   Native Command Queueing (NCQ)
      *   Host-initiated interface power management
      *   Phy event counters
          DMA Setup Auto-Activate optimization
      *   Software settings preservation
      *   SMART Command Transport (SCT) feature set
      *   SCT Read/Write Long (AC1), obsolete
      *   SCT Write Same (AC2)
      *   SCT Error Recovery Control (AC3)
      *   SCT Features Control (AC4)
      *   SCT Data Tables (AC5)
          unknown 206[12] (vendor specific)
          unknown 206[13] (vendor specific)
Security:
   Master password revision code = 65534
      supported
   not   enabled
   not   locked
   not   frozen
   not   expired: security count
      supported: enhanced erase
   118min for SECURITY ERASE UNIT. 118min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 50014ee257f47641
   NAA      : 5
   IEEE OUI   : 0014ee
   Unique ID   : 257f47641
Checksum: correct

[Praxis]

Gonna try with a more standard/stable live distro.

[jackjack]

And your computer? Processor? Nothing special?

Gonna try with a more standard/stable live distro.

I hope it will help

[Praxis]

Nothing out of the ordinary. It's a DELL Inspiron 531 (desktop PC)

model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4000+

[jackjack]

Ok then my guess it definitely openssl

[Praxis]

Wow, seems to work now !!  

Code:

Private keys not decrypted: 5012
Trying all the remaining possibilities (645104) might take up to 1124 minutes.

It seems it already found many encrypted keys, but why does it go into this 18 hour process now? isn't it very likely it already found the right wallet(s) in the first step (where it tried the pass on the 42 possible wallets)? Or am I off the mark?

[jackjack]

First it tries to decrypt private keys only with the closer encryption parameters. Then if some private keys that are still not decrypted it will try all the remaining parameters (42 in your case).
I'll add a prompt to know if you want to stop after the first guesses.

I think too that it should be enough here. The other wallets may be altcoins you briefly tried.

[jackjack]

New and possibly last version: http://pastebin.com/raw.php?i=wuEZTqeL

You'll see things like this

Possible wallet: #1
   with passphrase #1
   with passphrase #2 ............
   with passphrase #3
   with passphrase #4

Possible wallet: #2
   with passphrase #1
   with passphrase #2
   with passphrase #3 ............
   with passphrase #4

Which shows you which passphrase unlocks which wallet

Then

Code:

Private keys not decrypted: %d
Trying all the remaining possibilities (%d) might take up to %d minutes.
Do you want to test them? (y/n): 

Just put 'n'

[Praxis]

Man, this last version works like a charm! I could run it with 6 passes and it created a recovered.dat! 

I just replaced the wallet.dat without downloading the blockchain first:

Code:

************************
EXCEPTION: 11DbException       
Db::open: Permission denied       
worldcoin in Runaway exception      

worldcoin-qt gives me this

I will try to replace the wallet.dat AFTER downloading the blockchain with a fresh wallet.dat

I tried running both with -rescan and -detachdb

[jackjack]

I'm glad it finally works!

"Permission denied" doesn't seem to be a problem from the wallet.
If it doesn't work please try with bitcoin-qt as worldcoin devs might have a different code (that I wouldn't plan to support in pywallet).

[Praxis]

I'm glad it finally works!

"Permission denied" doesn't seem to be a problem from the wallet.
If it doesn't work please try with bitcoin-qt as worldcoin devs might have a different code (that I wouldn't plan to support in pywallet).

Yeah, it say something like unable to load keypool or something like that now.
If the .dat is not "made" for other clients, perhaps I could try to import the keys one by one into the other clients or something.
I'll try to figure something out tomorrow.

Or maybe I should stop being lazy and learn Python so that I can contribute something 

[jackjack]

I know the keypool is empty, I may add keys if it avoids the error
Could you post it?

I really think all the wallets have the same format
Also, importing a key takes 0.5 second so it may take long
But yeah learning Python could be nice, even for you!

[Praxis]

I know the keypool is empty, I may add keys if it avoids the error
Could you post it?

I really think all the wallets have the same format
Also, importing a key takes 0.5 second so it may take long

So it means it should be possible, in theory, to recover even non-bitcoin wallets (alt-coins)?

I'm ashamed to admit but I don't understand what is a keypool or how to post it here.

I'm reading and Googling about these things now. I will try to educate myself.

Does the following apply - should I 'dump' my recovered wallet?

Code:

pywallet.py --passphrase="pass" --dumpwallet > dump.decrypted.txt


The dumpwallet command will dump the entire wallet (tx history, keypool order, labels, etc).  
For brevity you can print just the "keys" section (it includes the keys in the keypool).  
You don't need the "pool" section as it just contains the order of the keypool. 
 If you include a passphrase the keys will be decrypted. 
 If you do not include a passphrase the keys will be left in encrypted form.  
I use the encrypted option to print a disaster recovery (a backup for the backup) 
copy of all the company private keys which is stored off site in a fire rated safe.  
Yeah I am a little paranoid about backups but haven't lost a Satoshi yet.

I guess I'm still confused about how to get the coins even if I have the recovered wallet.

I'm trying to figure it out.

 

[jackjack]

I'm pretty sure that pywallet found your altcoin wallets.
Again, except maybe for some crazy ones. Try pywallet to dump a wallet from an altcoin, if it works, it's 99% sure the recovery would work

The keypool is a set of 100 (by default, but you can change it) "hidden" addresses. They are used for change (and generation if you are a miner).
By the way, you can add a pool address yourself. Using the pywallet WUI you can add a dummy address (private key = '000...001' for example) to a wallet and tell it to make it a pool address.

Yes, this would dump your recovered wallet. I misread, you asked if you should. Well it's as you wish... If you put that in the file, then keep in mind that there will be unencrypted private keys written on your hard drive.

If you have the recovered wallet, rename it 'wallet.dat' and put it in the bitcoin directory (~/.bitcoin) without forgetting to backup the current wallet.dat. Then

bitcoin-qt -rescan

[Praxis]

If you have the recovered wallet, rename it 'wallet.dat' and put it in the bitcoin directory (~/.bitcoin) without forgetting to backup the current wallet.dat. Then

bitcoin-qt -rescan

This worked. Since the wallets were not bitcoin wallets, even though Bitcoin recognizes the recovered wallet, it cannot detect or use the coins transferred to those addresses, normally, because they are alternative chains.

I'm pretty sure the structure of wallet.dat is same for all coins (what could be different, after all)? The changes within the coins is not related to the BerkeleyDB file.

What I'll try next is ... dump the keys from the recovered.dat and import them into an already-existing working Alt-coin wallet.

I think this should solve the problems. Looking for an elegant way to do this fast with Pywallet now.

[jackjack]

Great, now do the same thing with an altcoin client and it should work too

[Praxis]

Great, now do the same thing with an altcoin client and it should work too

Sorry for bringing this up again. you worked so hard to help me, I feel in your debt

After all this time I still haven't given up completely! Just took a long pause from this process.
I never could get the coins back. I still have the recovered .dat files ...
It just didn't load them into the *coin clients (if I replaced the wallet.dat)

Now I think it's simply because pywallet recovers only Bitcoin addresses
if I look into the recovered dat, all addresses start with "1" which is Bitcoin
Worldcoin addresses start with "W", for instance

[jackjack]

There is no addresses in the wallet files, there are only private and public keys (which do not contain '1' or 'W') so there is no difference between a Bitcoin wallet and a Litecoin one
I'm really interested in your recovered .dat files to see what could cause the problem
If you're OK with that, consider sending the bit/altcoins it contains to other addresses first

Maybe I'm wrong and I forget some settings that must contain an address, but even if it's the case your altcoin private keys must have been recovered