cgsecurity.org

I just tried to see if photorec was able to recover Bitcoin-Qt wallets.

So I loop-mounted a small 100Mb block file, ext4 formatted it, and I copied a wallet file from Bitcoin-Qt 0.8.5 (70Kb) on it. I then umounted the loop file and used photorec to see if it could restore something from it.

With all file options enabled, it couldn't restore anything.

With these custom additional file signatures, it restored two corrupted .dat files (8Kb & 16Mb)
http://blog.cyplo.net/2012/04/01/bitcoi ... -photorec/

So I wondered if there was something you could do about it. I can probably offer myself to test various scenarios. FWIW, Since 0.8.0, Bitcoin-Qt uses LevelDB and not Berkeley DB.

Thanks a lot for testdisk & photorec, you have no idea how it saved life of a few people.

Bitcoin-qt wallet is still using Berkeley DB https://bitcointalk.org/index.php?topic=145184
"Berkeley DB is now only used for the wallet.dat file (public and private wallet keys and transactions
relevant to you)."
You can use in photorec.sig the following signature for Berkeley DB Btree, version 9, in little-endian (native format on x86 and x86_64) Note that recovered file may/will be larger than the original one as end of file isn't detected.

I just tried with the suggested new signature (all other signatures disabled) and I get a similar result. Even though the filesystem is not corrupted / erased and the file on the partition isn't corrupted either, photorec restores two corrupted files. I can't dump anything from these files using pywallet and bitcoind -salvagewallet fail to restore a wallet from these files.

When you have done the test, was the file deleted or have you choose Whole instead Free to scan the whole partition ?

The file wasn't deleted and I choosed Whole.

Using vbindiff, you may be able to identify if junk data have been inserted in the file or at the end of the file

OK, so strangely, vbindiff crashes (core dumped) when I compare the first file (8Kb). It works correctly until I get to "0000 1FF0". No difference is visible between the two files up to that point. When I compare the second file (70Kb), there is a few differences between "0000 0000" and "0000 0060". Between "0000 0060" and "0000 0FF0", the file is filled with "00". And after "0000 0FF0", everything mismatch.

8k is 0x2000, so it looks like the first file is ok but too big.

cgrenier wrote:8k is 0x2000, so it looks like the first file is ok but too big.

Perhaps you meant to say "not big enough"? The restaured file is 8k when the original file to be restaured was 70k.