Show Posts
|
Pages: [1]
|
There is actually very little information on the subject of licensing with pywallet, but from what I've seen, Joric created pywallet and then Jackjack made a fork of it, although apparently Joric's original license according to his repository on Google is BSD.
To be perfectly honest with you, I don't have much experience in open source development and this was actually my very first fork of an existing code ever. So, I don't really know what is the correct procedure here. Should I just assume the license is BSD and therefore mark my fork as BSD license as well on Github? On a relating note: I have been working more with my updated PyWallet. I found another corrupted wallet.dat file which could not be processed by any previous versions of PyWallet, so I made improvements to my fork and it is now able to handle that type of file corruption as well and recover data from it. Debug logging was also improved.
|
|
|
I didn't try it. But after reading the README, it seems your developer worked on it. Anyway, you may want to specify license of your pywallet. I stated this because it currently have no license[1].
I'm afraid I wasn't able to find the license information of PyWallet, so I didn't add any license to my fork either. I'd use the same license, but since I couldn't find this information, I didn't want to add anything. At a glance, it looks good. But on "Other Open Source Bitcoin Wallet Recovery Tools" section, do you mind adding BTCRecover forked by 3rdIteration[1]? It's fork of BTCRecover with more feature, documentation and optional paid support/request.
Very nice! I added this.
|
|
|
Long story short: I had problems using PyWallet because every time I ran it, it just crashed when trying to recover keys from a very corrupted legacy wallet.dat file. Since I happen to run a software development firm, I basically asked (read: paid) one of my developers to work on PyWallet to improve it. It escalated into a new PyWallet fork with Python 3 support and improved corrupted wallet recovery support. It's available at https://github.com/Great-Software-Company/pywalletAnd I also did this simple website for it: https://pywallet.org/I hope you like it! Thanks!
|
|
|
I tried to run Pywallet via pyenv but it always crashes with the previously mentioned error message. Since I wasn't sure whether this is some kind of Python version related issue, I also installed an older version of Ubuntu with Python 2.7 and tried it within that system as well, but no, Pywallet just always crashes. Since this approach seems the most promising (Pywallet does say that it can detect wallet and private keys from the recovery data that I show to it), I decided to try to pursue this path a bit further. I'm probably going to dox myself but the thing is that I run a software company and I got a Python developer. So I decided to use some of my own money and I assigned him to update Pywallet. He already completed the Python 3 support, but even with that implemented, the crash still happens during the recovery attempt. I'll have him try to improve the recovery feature of Pywallet in a way that in case of too corrupt data, it will recover anything it can without crashing. The worst case scenario is that I cannot recover my coins, but at least Pywallet gets updated, so at least there's that. I will release it all in Github, of course. I hope I will have an update about this project soon.
|
|
|
Since you've said " exact same output" in your previous reply above, Does it include this quoted error line: ? File "/usr/lib64/python3.13/ctypes/__init__.py", line 67, in create_string_buffer
Yes it does, I found that Python 3 reference to be a bit odd, too. But when I ran "python --version" before running pywallet, that does say "Python 2.7.18" I shall give this a read. Thank you!
|
|
|
I'm using pywallet from jackjack's Github. You are correct, I was using Python 3.x to run it. I have now installed Python 2.7 via pyenv, and re-ran it, and it produces the exact same output, I'm afraid. It seems to crash while trying to save the possible wallets.
|
|
|
I can't really tell you, I haven't had to deal with this in a long time. But I'd start by reading what's in that file (and don't post it of course).
I also ran the pywallet --recover directly with drive instead of the disk image input, and after it ran, it outputs: Read xxx Go in zzz minutes
Found 9 possible wallets Found 2820 possible encrypted keys Found 0 possible unencrypted keys
Possible wallet #1 with passphrase #1 Traceback (most recent call last): File "/home/username/recovery/pywallet/pywallet.py", line 4034, in <module> recoveredKeys=recov(device, passes, size, 10240, options.recov_outputdir) File "/home/username/recovery/pywallet/pywallet.py", line 1799, in recov res = crypter.SetKeyFromPassphrase(pp, mk.salt, mk.iterations, mk.method) File "/home/username/recovery/pywallet/pywallet.py", line 951, in SetKeyFromPassphrase strKeyData = ctypes.create_string_buffer (vKeyData) File "/usr/lib64/python3.13/ctypes/__init__.py", line 67, in create_string_buffer raise TypeError(init) TypeError: yyyy
This output seems to indicate that it does find something, but for some reason crashes at the very end. The json files that it outputs are 30+ KB in size, they contain things like mkey: [xxxx,zzzz], and ckey: [qqqq,yyyy] etc. Where the data itself seems to consist of 12 digit numbers. Something like this: ckey: [194857392812, 3948595949192, 384759284843] and so on. To me, the mkey sounds like it is a reference to the wallet's master key and ckey sounds like the encrypted private keys.
|
|
|
It probably has an option to use the image instead of partition, or maybe it just works ( Everything is a file): --recov_device /home/user/file.iso Alternatively, you could just use the partition on which you saved the image, but that may be much bigger than needed.I ran it with the --recov_device pointing to the path that contains the dd created disk image file. It ran and created a "pywallet_partial_recovery_xxxx.json" file. It didn't create a new wallet.dat file, as it said it would. Any tips what should I do now?
|
|
|
It probably has an option to use the image instead of partition, or maybe it just works ( Everything is a file): --recov_device /home/user/file.iso Alternatively, you could just use the partition on which you saved the image, but that may be much bigger than needed.At least there was no instant error message when trying to do that, so I now have pywallet with the recover option running, with --recov_device pointing to the image file from the dedicated Linux laptop that hopefully contains some private keys. The image file is about 1 TB in size, so this will take a moment to run. I will report back when it has completed. Thank you very much for your help so far.
|
|
|
The problem is, I didn't know you need to create a new backup of the wallet.dat any time you spend Bitcoin from it. I don't think that's entirely accurate. It was for the earliest version of Bitcoin-qt, but they quickly added a 100 key "pool": the wallet.dat would create 100 unused private keys, so your backup would still be valid for a while. But if you set or changed a password, those 100 keys would be replaced by new ones and a new backup was indeed required. Indeed, this is as much as I learned after I started to figure out what could be the reason why my balance was showing almost zero. And I have not made many transactions with the wallet to begin with. But nevertheless, Bitcoin-cli shows almost zero balance. I tried to do "bitcoin-cli -rpcwallet=legacy rescanblockchain 0" as well, to see if that would somehow fix the situation, but it didn't help. Running bitcoind on the original wallet.dat says: 2025-06-01T06:59:51Z [legacy] Wallet file version = 10500, last client version = 290000 2025-06-01T06:59:51Z [legacy] Legacy Wallet Keys: 0 plaintext, 206 encrypted, 0 w/ metadata, 206 total.
EDIT: I have not changed the password of the wallet since originally creating it. I have not tried that. Does the pywallet's --recov_device parameter accept a path to the disk image, or do I do something with the disk image first, such as mount it?
|
|
|
I used Bitcoin Core to create a wallet.dat in probably around 2014 (pre-HD, that is). I bought some Bitcoin from an exchange in a few different times and stored those in that wallet. The wallet is encrypted. I have the wallet.dat and I have its passphrase.
The problem is, I didn't know you need to create a new backup of the wallet.dat any time you spend Bitcoin from it. I had ass-u-med, you only need to backup it, after you receive more coins to it.
I had my Bitcoin Core and my wallet on a dedicated Linux laptop that I updated to a new Linux distribution, at which time I lost the currently in use copy of wallet.dat, I only have the original copies of it.
After I realized my mistake (i.e. copying the original wallet.dat to a new computer and using Bitcoin Core again, and the wallet showing almost zero balance), I used a live Linux USB to create a disk image of the laptop's drive using the dd command. I have used different file recovery tools, such as PhotoRec to recover files from that disk image.
I have a couple of recovered files that look like they could be the lost, updated version of the wallet.dat.
The restored wallet files are about 1 MB in size, while the original wallet.dat copy is about 115 KB in size. I have used a binary file comparison tool to see how the files look, and the recovered 1 MB wallets have identical content for the first 115 KB bytes, and after that, new content. The new content doesn't look like random mess, but it looks similar to the other content of the original wallet file.
I have tried to use bitcoin-cli (of Bitcoin Core 28.1) to load up the recovered wallet, and I have tried the Bitcoin Core's "bitcoin-wallet salvage" method as well. Neither have been able to load the restored wallet, so clearly there is some corruption there.
I have tried to use pywallet to dump the private keys from the restored wallet but that fails as well. I'm using Linux (Fedora 42).
I'm offering a bounty of $200 to anyone who helps me to recover the coins. If the recovery happens with help of multiple people, they all will receive the bounty.
|
|
|
|