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
Topic: [Data Recovery Problem] Recovering many Wallet.dat from repartitioned Hard drive (Read 7906 times)
November 25, 2013, 11:48:36 AM
November 25, 2013, 11:17:17 AM
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
July 25, 2013, 10:59:20 AM
Great, now do the same thing with an altcoin client and it should work too
July 25, 2013, 10:49:05 AM
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
Quote
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.
July 23, 2013, 01:48:05 PM
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
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.
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
Quote
bitcoin-qt -rescan
July 23, 2013, 01:27:04 PM
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
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.
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.
July 23, 2013, 03:05:00 AM
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!
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!
July 22, 2013, 09:17:15 PM
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).
"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
July 22, 2013, 03:39:42 PM
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).
"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).
July 22, 2013, 03:20:21 PM
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:
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
I just replaced the wallet.dat without downloading the blockchain first:
Code:
************************
EXCEPTION: 11DbException
Db::open: Permission denied
worldcoin in Runaway exception
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
July 22, 2013, 03:30:57 AM
New and possibly last version: http://pastebin.com/raw.php?i=wuEZTqeL
You'll see things like this
Then
You'll see things like this
Quote
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 walletwith 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
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' Trying all the remaining possibilities (%d) might take up to %d minutes.
Do you want to test them? (y/n):
July 22, 2013, 01:45:23 AM
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.
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.
July 21, 2013, 06:15:26 PM
Wow, seems to work now !! 
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?
Code:
Private keys not decrypted: 5012
Trying all the remaining possibilities (645104) might take up to 1124 minutes.
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?
July 21, 2013, 04:35:18 PM
Ok then my guess it definitely openssl
July 21, 2013, 04:33:35 PM
Nothing out of the ordinary. It's a DELL Inspiron 531 (desktop PC)
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
July 21, 2013, 04:29:43 PM
And your computer? Processor? Nothing special?
Gonna try with a more standard/stable live distro.
I hope it will help July 21, 2013, 04:28:28 PM
Gonna try with a more standard/stable live distro.
July 21, 2013, 04:27:24 PM
Quote
[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
/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
July 21, 2013, 04:06:22 PM
Yes, please try another distribution if you can
Don't forget to keep pywallet_partial_recovery_1374430501.
Do you have an exotic hardware?
Don't forget to keep pywallet_partial_recovery_1374430501.
Do you have an exotic hardware?
July 21, 2013, 04:04:57 PM
Code:
Possible wallet #1
with passphrase #1 a
b
SKFP params: ytrewq �m�����* 58001 0
za
zc
zd
ze
zf
zg
zh
zi
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?
Jump to: