1 BTC reward

[ABCbits]

Sorry, but your guide is too vague even for me who've used BTCRecover few times. I never had to add or edit code while using BTCRecover. In addition, i didn't find date_variants text on any BTCRecover text/source code files.

Since you used it, then you should know that any .py file you run can be modified in any form you like and with the parameters you need...
If you want, I can take the time to put this element into the code and then run it.

Yes, it would be great if you write detailed guide. I doubt anyone (expect BTCRecover developer or experienced software developer) know which .py file should be modified and where should we put the code.

[aliveNFT]

Yes, it would be great if you write detailed guide. I doubt anyone (expect BTCRecover developer or experienced software developer) know which .py file should be modified and where should we put the code.

I just looked at everything and realized that I wrote nonsense... It's not that simple.
I take it back, I ran over you for no reason, sorry

I wonder if you can take and generate all possible dates through this script and feed a txt file to select a password for your wallet, can it help?

Code:

import datetime

def generate_date_variants(start_year=1950... For example):
    date_variants = []
    current_date = datetime.datetime.now()
    
    for year in range(start_year, current_date.year + 1):
        for month in range(1, 13):
            for day in range(1, 32):
                try:
                    date = datetime.datetime(year, month, day)
                    
                    date_variants.append(date.strftime('%Y-%m-%d'))
                    date_variants.append(date.strftime('%m-%d-%Y'))
                    date_variants.append(date.strftime('%d-%m-%Y'))
                    date_variants.append(date.strftime('%Y%m%d'))
                    date_variants.append(date.strftime('%m%d%Y'))
                    date_variants.append(date.strftime('%d%m%Y'))
                    date_variants.append(date.strftime('%Y/%m/%d'))
                    date_variants.append(date.strftime('%m/%d/%Y'))
                    date_variants.append(date.strftime('%d/%m/%Y'))
                
                except ValueError:
                    continue

    return date_variants

def save_passwords_to_file(filename):
    passwords = generate_date_variants()
    with open(filename, 'w') as file:
        for password in passwords:
            file.write(password + "\n")
    print(f"Passwords saved to {filename}")

save_passwords_to_file('generated_passwords.txt')

[LoyceV]

Yes, it would be great if you write detailed guide.

I would like to see this too. I've read about password recovery options for years, but never tried it myself (and I never had to try).
@aliveNFT or anyone else: Who's willing (and able) to write a detailed guide that can be followed and reproduced step by step? I like low-power systems, so I don't have a GPU I can use.
I can create a wallet.dat with password that can be used for testing by anyone. I'm thinking of a date in the last century, with 3 characters before or after it. Would this work as a basis for the guide?

Note: the guide should be ELI12-level. Let's assume the user who lost their password doesn't know much about computers.

[ABCbits]

Yes, it would be great if you write detailed guide. I doubt anyone (expect BTCRecover developer or experienced software developer) know which .py file should be modified and where should we put the code.

I just looked at everything and realized that I wrote nonsense... It's not that simple.
I take it back, I ran over you for no reason, sorry

I see. But at least you realize and acknowledge your mistake quickly.

I wonder if you can take and generate all possible dates through this script and feed a txt file to select a password for your wallet, can it help?

Code:

import datetime

def generate_date_variants(start_year=1950... For example):
    date_variants = []
    current_date = datetime.datetime.now()
    
    for year in range(start_year, current_date.year + 1):
        for month in range(1, 13):
            for day in range(1, 32):
                try:
                    date = datetime.datetime(year, month, day)
                    
                    date_variants.append(date.strftime('%Y-%m-%d'))
                    date_variants.append(date.strftime('%m-%d-%Y'))
                    date_variants.append(date.strftime('%d-%m-%Y'))
                    date_variants.append(date.strftime('%Y%m%d'))
                    date_variants.append(date.strftime('%m%d%Y'))
                    date_variants.append(date.strftime('%d%m%Y'))
                    date_variants.append(date.strftime('%Y/%m/%d'))
                    date_variants.append(date.strftime('%m/%d/%Y'))
                    date_variants.append(date.strftime('%d/%m/%Y'))
                
                except ValueError:
                    continue

    return date_variants

def save_passwords_to_file(filename):
    passwords = generate_date_variants()
    with open(filename, 'w') as file:
        for password in passwords:
            file.write(password + "\n")
    print(f"Passwords saved to {filename}")

save_passwords_to_file('generated_passwords.txt')

It's possible, BTCRecover have feature which accept password list file. See this documentation page, https://btcrecover.readthedocs.io/en/latest/passwordlist_file/. Although your code to generate the file could be improved since some months have less than 31 days.

[aliveNFT]

It's possible, BTCRecover have feature which accept password list file. See this documentation page, https://btcrecover.readthedocs.io/en/latest/passwordlist_file/. Although your code to generate the file could be improved since some months have less than 31 days.

yea.. mybad. I guess fixable in 1min:
_{import calendar} and modifying few strokes 

But I'm pretty sure now that this is a useless script.
Each time it will have to be rewritten to fit its own values..
Today we need a date in any format, tomorrow we need something else..

[mcdouglasx]

2016-05-05
05May2016

If the password is something like this, I don’t understand why it took you so long. You should create a personalized search according to your clues.

[nc50lc]

If the password is something like this, I don’t understand why it took you so long. You should create a personalized search according to your clues.

He's actively refusing to download the necessary tools or script to bruteforce his password.
Yet, he's willing to send the wallet file to member he deemed trustworthy who'll probably use the same tool they suggested.

To get the whole picture, OP has another thread last year where he mentioned the same wallet: /index.php?topic=5433957.0

[mcdouglasx]

If the password is something like this, I don’t understand why it took you so long. You should create a personalized search according to your clues.

He's actively refusing to download the necessary tools or script to bruteforce his password.
Yet, he's willing to send the wallet file to member he deemed trustworthy who'll probably use the same tool they suggested.

To get the whole picture, OP has another thread last year where he mentioned the same wallet: /index.php?topic=5433957.0

Without using brute force methods, it is difficult for him to achieve anything, assuming that he has set passwords that he guesses, without focusing on numbers, letters, symbols, case-sensitive...although sending the wallet.dat would be even more dangerous and contradictory.

[pooya87]

Basically, you can open up the wallet file with anything that can display hex (like Sublime Text), and then search for the following 4-byte pattern: 4300 0130.

I am not the most familiar with wallet.dat but it looks like the 0x43000130 should be considered a variable even if it appears similar for everyone. For example 0x30 (=48) is the length of the encrypted key, and 0x43 (=67) is the length of the total structure.
The actual fixed starting bytes that should be searched is 0x090001046d6b6579 with "6d6b6579" being hex format of "mkey" and "04" being its length.

[PowerGlove]

I am not the most familiar with wallet.dat but it looks like the 0x43000130 should be considered a variable even if it appears similar for everyone.

I mean, yeah, I get the direction you're thinking in. (Because I started by thinking in that same direction.)

The thing is, the DB-wise item value (my search pattern) and the item key (your search pattern) are not in the order you'd expect (they're reversed, as in, if you find the key-pattern then you have to jump backwards to find its corresponding value-pattern). It's a very subtle point, but by basing the search on the item value (which is what I chose to do), I'm avoiding having to dig deeper into Berkeley DB's source code to confirm on my own that there's an order-wise relationship between keys and values that will always be true).

I wrote my pattern in a peculiar way (4300 0130) because the pattern should always start on a 4-byte boundary (that is, typical-hex-view-wise, it will both always start on a 2-byte column, and never start on an odd column that might split the pattern across two lines). Also, if you're examining the wallet using something like Sublime Text's binary view, then the search pattern you enter (after Ctrl+F) is actually a text pattern (as in, if you change the spacing and search for 43 00 01 30, or 43000130, then you'll get no matches).

The 4-byte pattern that I settled on obviously isn't enough on its own to confirm a match: it's important to examine all of the uncolored parts in my previous post, and to check that they're the same, too (I skipped describing those parts, but I understand in detail what each of them do). With a fully-matched pattern, it's reliable enough for the purpose, I think. (That is, the whole procedure is basically saying: "On a 4-byte boundary, find the byte values 67, 0, 1, and 48, then make sure that there's a byte with the value 8 at a specific point after that, then make sure that there are four zero bytes at a specific point after that, and finally, make sure that the whole thing ends with a zero byte".)

[FP91G]

Buy this software and a mining farm.
https://www.thegrideon.com/bitcoin-password-recovery.html
If you have some password details, it will be easier to recover the password.

[Cricktor]

~~~

Looks like another closed-source software. So, why should anyone trust this? While it sounds good and isn't expensive, which is nice, I wouldn't feed any wallet.dat to it, unless the computer is permanently air-gapped and carefully wiped after such recovery software has done its thing.

I think there are enough reputed open-source tools to do the cracking, which have proven their effectivity and are used by a whole community of password-cracking folks.

I only looked very briefly at the description of the mentioned software. Frankly can't say much what are any highlights or why one should've a closer look at it.

As always, DYOR and be careful with unknown software. Better not use such software on online devices that are used for valuable stuff or hold your crypto wallets. Don't be careless and stupid!

[Coding Enthusiast]

Here is my implementation of it as part of The Finder Outer (you missed the AES IV by the way):
https://github.com/Coding-Enthusiast/FinderOuter/commit/5063a1ec3038523db3031ef5efe14bdb6c82c5a0

All that's left is to add the UI element and add an example for it.

[PowerGlove]

(you missed the AES IV by the way)

Hmm... I don't think so...

There's no IV in ECB mode. (I mean, I know the master key is encrypted in CBC mode, but, if you look carefully, you'll see that I'm not trying to decrypt the master key, I'm just doing trial-decryptions on the padding.)

Think of it like this: doing a CBC decryption backwards doesn't need the IV until the last step (which would be the first step when going forwards, but I'm not doing that).



Just to be sure that I haven't confused myself (it does happen from time to time), I've re-checked the example I left in that post:

(*) The 32-byte AES key that I derive from "MasterExploder" is: 75b8558ad738faeb4903164f3c486c24bd6df1f848561914a7ad754d4e8531e4.

(*) For the sake of completeness, the IV (which I don't need) that I derive from that same passphrase is: 914defc64e4b44fcf105534a50da0185.

(*) The encrypted padding is: 0032153d50cbf924a2ac1dc5f6279436.

(*) Performing an AES-256-ECB decryption (with the key from the first step) yields: 45e5f858c67596646cd010927d5c1c25.

(*) Finally, xoring that with the middle 16 bytes (55f5e848d66586747cc000826d4c0c35) of the 48-byte encrypted master key yields: 10101010101010101010101010101010.

That all checks out, yeah?

(I haven't examined your code, but probably you'll find that the IV-related parts of it can be omitted.)

[Coding Enthusiast]

(you missed the AES IV by the way)

Hmm... I don't think so...

You are absolutely right!

I tested it and IV is not needed. Even went through the dotnet source code and realized IV that I was setting wasn't even used. When this calls this the IV is set to null!
For some reason in my initial tests when I was first implementing this, the code only worked when I set the IV (I wasn't aware ECB mode doesn't use IV). Probably because I was changing more than one thing at a time... silly me...

[whanau]

Have you tried
8 years ago 06/05/2016 - 08:55:22. The date and time of the transaction?

That was UTC. You may be in a different timezone..