Topic: 1 BTC reward (Read 852 times)

Hi,

I got an idea. In your case, I would take a look at how your dad was writing down the dates, so maybe he used "/';-_" or some of these placeholders regularly. Or you could try to write the DATE as a word there are many options like "November fourth, two thousand and twenty-two" or "The fourth of November, twenty twenty-two."

However, I wish you the best!!

I don't understand why you created this post. What exactly was the point of it? Are you asking for something or not.

Not the best choice .. i have it and it blows... ill give it to him just because.

Pass-ware which would be a better util ..   

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..

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...

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.)

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.

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!

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.

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".)

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.

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.

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

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.

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..

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


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.

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.

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?

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.

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.