Topic: 1 BTC reward (Read 690 times)

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.

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.

Are there any other methods besides brute-force in general? In my opinion, this is the safest and best option.

git clone https://github.com/3rdIteration/btcrecover.git

install requirements

go offline
set everything correctly


and forget about it for a while...
at least need to start somewhere.
total gonna be ~243,252 variants

edited: from 1950 - 2024

You're asking someone who's not willing to run the brute-force he's been suggested for years, to prove he can extract mkey, salt and iteration from Bitcoin Core. It's not going to happen.

What is fee? The 1BTC you offer? I'm not going to bid any real coins as I'm not interested in an auction for this. Or what do you expect as a bid?


This is what I'm willing to offer and my terms if both sides agree (I'm still hesitant because I don't see a safe solution for me):
I'm willing to execute some exhaustive searches for date formats (search space first attempt 1900-2024 full years, every day will be tried) on mkey hash.

To prove that pffffffff is able to propery extract mkey, salt and iteration count, as described by PowerGlove, I will send him an empty encrypted Bitcoin Core wallet.dat for which I know the wallet encryption password. I will first check that my toolset is working and I'm able to crack the encryption password of this test model wallet.dat. My offer is only valid if my toolset is working. If I mess up in the first place, there's no offer for obvious reasons.

pffffffff can post the hex sequence here in his topic and I will verify and confirm validity.

If this validation succeeds, pffffffff can send me then the hex sequence of the mkey hash for his own wallet.dat that supposedly holds at least 10BTC. pffffffff is solely responsible to handle his wallet best on an air-gapped computer to avoid any compromise of his valuable wallet.

Together with suggestions from pffffffff how his father wrote dates, I will then perform at least the following exhaustive searches (first only in full year's range 1900-2024):
YYYYMMDD, YYYY-MM-DD, MM/DD/YYYY, MM-DD-YYYY, MM.DD.YYYY, DD.MM.YYYY, YYYY/MM/DD,
Jan-Dec MM, YYYY
January-December MM, YYYY and whatever pffffffff else suggests.

I will report back if I succeed or fail. In the case of success, I don't know how to do it safely without risking my reputation here, if something goes wrong on pffffffff's side for whatever reasons.

My first idea was to use an escrow for exchange of 1BTC for the solution. Still this has risks for me if pffffffff screws things up and blames me. I don't want to be negatively flagged for any possible screw-up that I'm not responsible for. I can't verify that the original wallet.dat isn't damaged by any means or is fake or whatnot.

It seems to be safer to simply give pffffffff the solution and hope for the best that he won't scam me. I'm not happy with this either, because pffffffff's account has no reputation. He can go with the full 10BTC without much consequences, because who cares when I flag him that he didn't pay the offered 1BTC. Likelyhood of reward seems low to me.

Maybe I'm overseeing some better solution. Open for suggestions...

Edit: I should better pass, though. Just bother Dave, even when he charges more. 8BTC is better than no BTC.