zenkei18
Newbie
Offline
Activity: 5
Merit: 0
|
|
February 07, 2021, 10:19:33 PM |
|
Support of Python 3 is started Basic things seems to be working but you'll likely find bugs
Also the recovery looks broken, I fixed a small part and I'll fix the rest during next weeks
Sounds like it is coming along nicely... if you get a "stable-ish" release... let me know and I'll do some basic testing on it Great, I'll let you know! What is broken in recover? I used recently and got a dump fail
Is there a legacy version that is stable that can be reverted to?
What is broken always has been broken Today's fix is about compressed keys not being recovered for example Recent wallets, like the ones using BIP32 seem to be recoverable at least partially but I don't know exactly what works or not In case I break more things than I fix though, you can try that 'legacy' version here: https://github.com/jackjack-jj/pywallet/tree/b52c955f8c93a75745166ebf281448016e1f22e2What do you mean by dump fail? Nevermind, my recover was giving me segmentation fault core dumped error, but I fixed by installing pycrypto.
|
|
|
|
SheriffBass
Member
Offline
Activity: 77
Merit: 11
|
|
February 07, 2021, 10:49:19 PM |
|
Will this search through All types of folders and files? being compressed, zip, and BKF backup files too?
|
|
|
|
HCP
Legendary
Offline
Activity: 2086
Merit: 4363
<insert witty quote here>
|
|
February 08, 2021, 01:23:59 AM |
|
Will this search through All types of folders and files? being compressed, zip, and BKF backup files too?
No... any form of compression will modify the actual structure of the underlying data... it has to, otherwise the data can't get "smaller". This will mean that the script will be unable to detect the wallets by inspecting the bytes for the indicators of a wallet file. It's the same reason why you can't use the "hex string search" method on zip files etc... the data will have changed, and you can't really know how it will have changed... so the "standard" markers you're looking for won't be found... The only way to do it would be to uncompress the files and then inspect the extracted files... which could be problematic if the archives are encrypted/password protected... and you don't have the password.
|
|
|
|
zenkei18
Newbie
Offline
Activity: 5
Merit: 0
|
|
February 08, 2021, 02:20:30 AM |
|
If I used pywallet 2.2 what can I do with the partial wallet or how can I use the mkey values to try to brute force the password if I don't know the passphrase? T
|
|
|
|
SheriffBass
Member
Offline
Activity: 77
Merit: 11
|
|
February 08, 2021, 03:32:24 PM |
|
Will this search through All types of folders and files? being compressed, zip, and BKF backup files too?
No... any form of compression will modify the actual structure of the underlying data... it has to, otherwise the data can't get "smaller". This will mean that the script will be unable to detect the wallets by inspecting the bytes for the indicators of a wallet file. It's the same reason why you can't use the "hex string search" method on zip files etc... the data will have changed, and you can't really know how it will have changed... so the "standard" markers you're looking for won't be found... The only way to do it would be to uncompress the files and then inspect the extracted files... which could be problematic if the archives are encrypted/password protected... and you don't have the password. OH crap !!! No wonder I can't find any wallets will have a long way to find good quality programs to decompress and decipher/make backup files readable to PYwallet then. I was using windows search looking for .dat files on a 500 GB drive yesterday and it said it needs 1.4TB disk space do u know off any software that decompress many large backup files as: .pbd, .bkf… to a drive, I found one but it creates a tree and I have to go through every file separately to choose one file and restore
|
|
|
|
NotATether
Legendary
Offline
Activity: 1806
Merit: 7476
Top Crypto Casino
|
|
February 08, 2021, 03:46:27 PM |
|
do u know off any software that decompress many large backup files as: .pbd, .bkf… to a drive, I found one but it creates a tree and I have to go through every file separately to choose one file and restore .pbd files are EaseUS backups and .bkf are Windows Backup files. Both of these are proprietary programs and so the file formats for them are unknown. Which means only the vendor can make a decompress program for their own format. If you have these kind of files then you should restore them with their respective program to a blank hard disk, one by one, and look for your wallet file there. I don't think these files are even compressed anyway, they are packages inside an "archive file format". The situation is different if you are looking for decompressing/extracting programs for generic archive files such as .zip, .tar.gz and .7z. These file formats are well-known and so there exist many programs for unzipping them such as 7-zip and WinRAR (trialware).
|
|
|
|
Pi07r
Newbie
Offline
Activity: 2
Merit: 0
|
|
February 12, 2021, 09:26:15 PM |
|
Hi,
I have corrupted my syscoin wallet while I was trying to make masternode. I didn't made any backup, yes that was irresponsibly.
This is the instruction which I was following:
1. Open your wallet (MAKE SURE IT IS THE 4.1.3 LATEST VERSION). 2. Go to the “Settings” menu and choose “Options”. In the Main tab enable the “Show Masternodes Tab” option and press “OK”. 3. Go to Syscoin Core root directory (location of wallet.dat) and open masternode.conf file with any basic text editor. This file may already contain # as the first item in the lines. These lines are comments and can be left in the file (to open masternode.conf file on MacOS click on the file, then select the “Open file with” option and choose “TextEdit” application there).
And here I made very big mistake. I opened wallet.dat file instead of masternode.con (don't know how).
I was trying to recover priv key using pywallet, but either my skills are not enough or the wallet is so damaged that is not possible to recover the priv key. As a pywallet result I received hundreds of keys, but any of them was the private one.
Do you know how I can try to solve this case? Or maybe is here some one who can help?
Thank you in advance Piotr
|
|
|
|
zenkei18
Newbie
Offline
Activity: 5
Merit: 0
|
|
February 14, 2021, 11:24:09 PM |
|
Sorry to bother again. I dont know the password to the mkey and encrypted keys and when I am running the recover function it won't place those keys into the wallet.dat file which is needed to run brute forcing algorithms on. Is there a way to make a wallet.dat that includes all the partial wallet recovery file data too?
|
|
|
|
HCP
Legendary
Offline
Activity: 2086
Merit: 4363
<insert witty quote here>
|
|
February 15, 2021, 02:04:14 AM |
|
And here I made very big mistake. I opened wallet.dat file instead of masternode.con (don't know how).
Simply opening the file in a text editor should not cause any modifications to the file... it should have been OK if you simply closed the file again. If you changed anything and then pressed "save", then it would have corrupted the wallet file. What exactly did you do after accidentally opening the wallet.dat file?
|
|
|
|
zenkei18
Newbie
Offline
Activity: 5
Merit: 0
|
|
February 19, 2021, 03:49:35 PM |
|
For an encrypted private ckey in wallet.dat, Is the public key portion encrypted as well?
E.g. is it impossible to find the address and balance with this info alone?
|
|
|
|
HCP
Legendary
Offline
Activity: 2086
Merit: 4363
<insert witty quote here>
|
|
February 27, 2021, 02:34:59 AM |
|
You should still be able to locate the address (open the wallet.dat in a text editor and search for: name )... I don't know about the balance though. You'd probably need to look that up on a block explorer rather than relying on any information stored in the wallet.dat file (as it could be years out of date!)
Also, the public keys should not be encrypted... as they're necessary for the wallet to be able to see transaction history/balance etc... and also for watching only wallets. It's why you don't need to enter the wallet password in Bitcoin Core until you want to sign a transaction/message or dump the private keys etc... it is using unencrypted public key data to show the transaction history etc.
|
|
|
|
morbius55
|
|
April 10, 2021, 11:19:30 PM |
|
Pywallet is very old and the wallet.dat file format has changed since Pywallet was last updated (2014). It looks like the script does not handle some of the new data fields that are now included in the wallet.dat file. It should theoretically be possible to modify the script to either handle or ignore the unknown fields. If you just want to dump the file and don't care about making a "valid" wallet.dat... you can edit the pywallet.py file: Change Line #2111 from: d.update(parse_BlockLocator(vds))
to: #d.update(parse_BlockLocator(vds))
Then on Line #2502, change: json_db['bestblock'] = d['hashes'][0][::-1].encode('hex_codec') to: print("ignored") #json_db['bestblock'] = d['hashes'][0][::-1].encode('hex_codec')
The script will still spit out a whole heap of garbage like this: Wallet data not recognized: {'__type__': 'keymeta', '__value__': "\n\x00\x00\x00\xa9\xd2\x85Z\x00\x00\x00\x00\x0bm/0'/0'/28'\x0c[\xfd\xe5\xabu\xfe\xf6\x13\xfb\x98p$F\xa6\xc2\xf1\\\xba\x04", '__key__': '\x07keymeta!\x03\xe3k\x94[F\xb4HO5f<b\x84\x88\x9fx\xb5Y~\xba\x01&e}\xcd\xbft\x90k\xdf\xbf\x07'} but you should get to see all the key stuff printed out: "keys": [ { "addr": "1PLXWsEWa3wrZTGo52FDjGiTP85LBbKRpg", "compressed": true, "hexsec": ".... removed ....", "private": "308ffffffffffffffffffffffffffffffffffffffffffffffffffffff73311b4fb36b7bffffffff ffffffffffffffffffffffffffffffffffffffffffffff48ce3d0101022100fffffffffffffffff ffffffffffffffffffffffffffffffffffffffefffffc2f30060fffffffffffffffffffffffffff fffffffffffffffffffffffffff6f81798022100fffffffffffffffffffffffffffffffebaaedce ffffffffffffffffffffffffffffffffffffffffffffffffffffff002067ddfffffffffffffffff fffffffffffffffffffffffffffffffffffff1298b98e", "pubkey": "02067dd94367c87da0d59c5f3b1c400239f846073b2b83b87bc15bc3201298b98e", "reserve": 1, "sec": ".... removed ....", "secret": ".... removed ...." }
The important one will be "sec"... that will be the WIF private key and should start with "5", "L" or "K" I have reason to believe that a wallet.dat i found that is from from 2015 could contain the private key i am after. It seems that my brother in law has got his information mixed up. I opened this particular file up with a file viewer 4 and i could read the address i'm after within it. Do you think i could have any luck with either your code alterations or the newer version of pywallet. Cheers. I didn't have any luck when i ran pywallet on the whole hard drive which contains this wallet file.
|
|
|
|
HCP
Legendary
Offline
Activity: 2086
Merit: 4363
<insert witty quote here>
|
|
April 11, 2021, 10:21:23 AM |
|
You can try those code alterations... or use my version here: https://github.com/HardCorePawn/pywalletIt essentially has the mods as shown by the commits here: https://github.com/jackjack-jj/pywallet/compare/master...HardCorePawn:masterBut before messing around with PyWallet... have you just tried installing Bitcoin Core and opening a copy of the wallet.dat from 2015 that has the address you're after in it? It would be much much simpler to use dumpprivkey from within Bitcoin Core (it doesn't even need to be synced or connected to the network) and get the private key that way than trying to use PyWallet. And of course, regardless of whether you are using Bitcoin Core or Pywallet, you'll still need to know what the wallet passphrase is to be able to access the private key.
|
|
|
|
morbius55
|
|
April 11, 2021, 04:49:06 PM |
|
You can try those code alterations... or use my version here: https://github.com/HardCorePawn/pywalletIt essentially has the mods as shown by the commits here: https://github.com/jackjack-jj/pywallet/compare/master...HardCorePawn:masterBut before messing around with PyWallet... have you just tried installing Bitcoin Core and opening a copy of the wallet.dat from 2015 that has the address you're after in it? It would be much much simpler to use dumpprivkey from within Bitcoin Core (it doesn't even need to be synced or connected to the network) and get the private key that way than trying to use PyWallet. And of course, regardless of whether you are using Bitcoin Core or Pywallet, you'll still need to know what the wallet passphrase is to be able to access the private key. JackJack mentions that pywallet didn't recover compressed keys. Could that be why i'm not able to recover anything from this wallet? Does the old pywallet have trouble recovering and dumping newer wallets. Does a wallet from 2015 fall into this category? Cheers.
|
|
|
|
HCP
Legendary
Offline
Activity: 2086
Merit: 4363
<insert witty quote here>
|
|
April 11, 2021, 09:42:41 PM |
|
JackJack mentions that pywallet didn't recover compressed keys. Could that be why i'm not able to recover anything from this wallet? Does the old pywallet have trouble recovering and dumping newer wallets. Does a wallet from 2015 fall into this category? Cheers.
Not sure about "recovering"... but it certainly dumps "compressed" keys... the thing you have to remember, is that the private key itself is not "compressed" or "uncompressed"... It is the public key (and the subsequent hash160 "address") that is "compressed" or "uncompressed". The private key is always a 256bit number. I think the "new" fields were added when HD wallet support was introduced which was in v0.13... which was released in August 2016... so a wallet created in 2015 should be the old "non HD" wallet type. However, if it was subsequently opened in a newer version of Bitcoin Core, the wallet file was likely "upgraded" (not to HD, but to the new format) which may have added in the fields that cause issues with PyWallet. This is why I recommend making copies of the original 2015 wallet.dat file and working on the copies. Again, have you simply tried opening one of the copies of the wallet.dat in Bitcoin Core and using either dumpwallet or dumpprivekey from inside Bitcoin Core? It would be much much easier than trying to deal with PyWallet and it won't matter if the wallet file is old version or new version.
|
|
|
|
morbius55
|
|
April 11, 2021, 09:49:19 PM |
|
The comment he made about compressed key recovery is in the first comment of this page.
|
|
|
|
morbius55
|
|
April 12, 2021, 07:48:11 PM |
|
JackJack mentions that pywallet didn't recover compressed keys. Could that be why i'm not able to recover anything from this wallet? Does the old pywallet have trouble recovering and dumping newer wallets. Does a wallet from 2015 fall into this category? Cheers.
Not sure about "recovering"... but it certainly dumps "compressed" keys... the thing you have to remember, is that the private key itself is not "compressed" or "uncompressed"... It is the public key (and the subsequent hash160 "address") that is "compressed" or "uncompressed". The private key is always a 256bit number. I think the "new" fields were added when HD wallet support was introduced which was in v0.13... which was released in August 2016... so a wallet created in 2015 should be the old "non HD" wallet type. However, if it was subsequently opened in a newer version of Bitcoin Core, the wallet file was likely "upgraded" (not to HD, but to the new format) which may have added in the fields that cause issues with PyWallet. This is why I recommend making copies of the original 2015 wallet.dat file and working on the copies. Again, have you simply tried opening one of the copies of the wallet.dat in Bitcoin Core and using either dumpwallet or dumpprivekey from inside Bitcoin Core? It would be much much easier than trying to deal with PyWallet and it won't matter if the wallet file is old version or new version. The wallet seemed to load okay into the latest Bitcoin Core but I don't see the address. Here is a wallet dump of it, i'm not sure if I loaded the wallet into core correctly as it seems more complicated than older versions. Why are all the addresses in the newer format? I have obviously deleted most of the private key info. https://imgur.com/a/vQ5cpCn
|
|
|
|
HCP
Legendary
Offline
Activity: 2086
Merit: 4363
<insert witty quote here>
|
|
April 13, 2021, 04:41:11 AM |
|
Bitcoin Core will likely have upgraded the wallet to the new wallet version and then refilled the keypool to have 1000 keys. By default the new versions of Bitcoin Core generate bech32 addresses. You can still get it to generate legacy or nested segwit address, but the default is native segwit (bech32) addresses.
Also, have you tried: dumpprivkey ADDRESS_YOU_WANT_THE_KEY_FOR
How did you load the wallet? All you should need to do is shutdown Bitcoin Core... copy the wallet file into the Bitcoin Core data directory and then restart Bitcoin Core. If you didn't rename the old wallet file to "wallet.dat", then once Bitcoin Core has started up, use "File -> Open Wallet ..." menu command and then select the wallet file.
If you did rename it to wallet.dat, then Bitcoin Core should have opened it up by default.
|
|
|
|
morbius55
|
|
April 14, 2021, 08:54:44 PM |
|
Is there a way of not entering a passphrase for the recovered wallet but still entering the correct passphrase for the actual recovery, ie leaving the recovered wallet decrypted?
|
|
|
|
HCP
Legendary
Offline
Activity: 2086
Merit: 4363
<insert witty quote here>
|
|
April 15, 2021, 07:44:03 AM |
|
If you mean for using the recovery feature of PyWallet, then the answer is no... you have to provide a passphrase for the script and it creates encrypted wallets.
|
|
|
|
|