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.

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.

Thank you but I'll pass if it's the wallet.dat file.

And once you decided to pass along the wallet.dat file to others, please consider sending only the encrypted mkey alongside with the necessary data to unencrypt it with the password.
Just follow the instructions given by PowerGlove (although you'll have to use a tool to display the wallet.dat's contents in hex)

Or do you have an air-gap machine? (Wikipedia: air-gap)
If so, you can safely extract the encrypted mkey (famously called "hash") with the open-source tools suggested by others without the worry of it being malicious since it wont be able to transmit data outside the machine in case of the worst case scenario.

Very nice and informative explanation, PowerGlove. I would give you some more merits for it if only I had more sMerits left (I prefer to keep at least about 10+ or so to be able to give them when I stumble over really merit worthy posts, um, like yours).

Anyway, you're probably one of few with highest merits/posts ratio. Keep up your excellent contributions!

I was always interested how this works. AFAIR, you can do the exhaustive hash crunching with tools like Hashcat and John the Ripper. They have it as a defined method of cracking implemented. I read about it, but never used it myself so far (didn't have to). So it's really nice to have some details explained by you.

If I don't mix things up, both tools had some tool scripts to extract the data portion (encrypted mkey, salt, iteration count) you've described. I will remember your post to cross-check, once I will have to tackle such a cracking problem.

BTW, great suggestion to always check with a known challenge if a cracking procedure will actually be able to find a correct result! You don't want to spend time and energy with a flawed cracking recipe or the wrong (buggy) tools.


It's up to OP what he makes of it.

Maybe I'm too trusting, but I always try to give people (that I don't know) the benefit of the doubt, and try to read their posts in the best possible light before jumping to conclusions...

In case OP really is just a super skittish person that's genuinely looking for help, I spent a little time on this, and came up with the following:

Like other people have pointed out, it's safe to share just the "mkey" value from an encrypted wallet file. The thing is, OP doesn't want to download or run anything, which makes it really tough to guide them. So, I created a test wallet using the closest version (0.12.1) of Bitcoin that I could find (closest to the date that the address posted here was funded, that is), and then went through the source code for both that and Berkeley DB, to try to figure out exactly how things were laid out back then.

I came up with a really tidy/short Python script to pull out the relevant data (the encrypted key, the salt, and the iteration count). It's so short, in fact, that the sequence can actually be performed manually.

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. Then, you copy those four bytes along with the 66 bytes that follow it. Using the test wallet I created, for me that comes out like this (spaces removed):

43000130ac71182a748152bb788fb9deb11f2f5a55f5e848d66586747cc000826d4c0c350032153d50cbf924a2ac1dc5f6279436089ca0271b64c0e66f00000000c6fe040000

The blue part is the 48-byte encrypted master key (it's 48 bytes because 16 bytes of padding are appended to the 32-byte key before it's encrypted). The green part is the 8-byte salt (needed for the key derivation function to work). The orange part is the 4-byte (little-endian) iteration count (also needed for the key derivation function). If the uncolored parts differ from the above, then you're probably not at the correct offset and should skip to the next match (or, your file was created by a build of Bitcoin that differs in some way from the one that I'm basing all of this on).

The first 16 bytes of the encrypted master key aren't necessary to brute-force the passphrase (just the last half of the encrypted key, and the encrypted padding will suffice), so those bytes can be zeroed before sharing, like this (ignore the bolding and the underlining for now):

430001300000000000000000000000000000000055f5e848d66586747cc000826d4c0c350032153d50cbf924a2ac1dc5f6279436089ca0271b64c0e66f00000000c6fe040000

If OP shares the above bytes from their own file, then people (me included) can try to help them find the correct passphrase without them actually risking anything at all.

That procedure works as follows:

(1) Take a candidate passphrase, and after appending the salt to it, hash it (with SHA-512) a certain number of times (the iteration count, which is 327366 in the above extract).

(2) Take the first 32 bytes of the 64-byte iterated-hashing result and then use that as the key to attempt decryption (with AES-256) of the last 16 bytes of the 48-byte encrypted master key (the bolded part).

(3) Take the 16 potentially-decrypted bytes from the previous step and then do a bitwise exclusive-or on them with the 16 underlined bytes.

(4) If the result is 16 bytes all with the value 16 (10 in hex), then you've probably (with the odds astronomically in your favor) found the correct passphrase.

(If anyone tries to implement the above procedure, then before throwing joules at a search for OP's passphrase, I suggest shaking the bugs out of your implementation by first testing it against my example extract: the passphrase for that is "MasterExploder".)

The first post you created here was the one below and even though the address in that post started with "13" as well but it was an entirely different address. It also contained 10 bitcoins not 0.04 like the one you are now claiming you have moved.

That's because it's the safest way to ask someone to bruteforce a wallet.dat's mkey encryption passphrase. (a.k.a the wallet's password)
And it's verified to be safe by people who know how it works.

You can research how the wallet is encrypted here: https://en.bitcoin.it/wiki/Wallet_encryption
Then double-check what the article said in the code: /src/wallet/crypter.cpp and /src/wallet/crypter.h
(open-source is amazing isn't it?)

Basically, what you'll give is just an encrypted "master key" ("mkey", not a master private key) which is encrypted with your password.
The "wallet recovery service" will be able to decrypt it once he stumbled upon the correct password
But since it's just a decrypted master key, it's useless without the actual wallet.dat file where the private keys that are encrypted with that mkey.

Verified
But it doesn't change anything, lol
Come on, contact someone, there are plenty of knowledgeable and talented people here.
I can't wait, I want to know how it's all going to end, I have impatience syndrome.

Hey Bitcointalk!

HFRFOKi0BCWlZx/Y9uMO3YlHceKMkCkOrxPGPpKz9PK9GyVluSpVvlTsMh/ABOaAd5ijY9R9cHiKASPFrvL5DCk=

You ignore all the intelligible answers in this thread, arrange auctions, behave strangely, do not provide any evidence (signing the bitcoin wallet) that you sent.

I also don't believe that you use fake addresses, but your behavior is strange, pull yourself together.

That's exactly what people tell me

Well, even if the highest bid is zero, I'm going to pick someone anyway eventually. So it's not exactly like selling a fake wallet

Likely 100% of sold wallet.dat files are fake and rigged files that appear to control coins when in fact there are real private keys in those wallets. There are still some stupids that pay money for such files (do they?), so how do you want to convince someone that a) your wallet.dat is real and genuine and b) your clues to the wallet encryption secret are in fact usable and valid to have a chance to find it?

I would be surprised if someone offers you more than maybe 0.01BTC for this gamble. LOL and on top you expect to get 9BTC when a cracker succeeds. Just why would a cracker feel obligated to pay you that amount? Sign a contract, yeah, sure, good luck...

Always somewhat interesting with what ideas some come up. Do what you want if you're the only heir.

I don't get it, why e.g. you don't want to contact Dave from walletrecoveryservices. He's a professional, he has the gear and knowledge to brute-force wallet encryption secrets. He will guide you, he doesn't ask for your wallet.dat file usually, he will assist you to extract the little data portion of the encrypted encryption key needed to find the wallet's encryption secret (no private key is exposed or compromised by this little data). You don't have to pay anything upfront to Dave.



Disclaimer: I'm not part of Dave's business and I don't have any other affiliation with it.

So that's your angle: selling a fake wallet, just like many others have been doing for years.

This tx doesn't proof anything, you better sign this wallet now. I can find the transaction at the time then I took a shit today and say I did it.
But this will not help you in any way to find a person who agrees to your terms.
Take an offline computer, call a knowledgeable person, do as he tells you and solve your problem, and do not invent useless and risky auctions here.

There was another wallet if that helps

138PicFJhWSmD42zyHpVLBf2N2MDK5FcxS

And I moved the coins around the same time I created my first post here

I still have it

At this point, i only can say good luck finding people who could trust you and agree to such terms. There are too many fake wallet.dat file being sold on internet.

An auction? Why complicate everything, there are at least 2-3 people on the forum who can figure it out and help you, and in all seriousness you can trust them with your life.
Just stop being a stubborn pussy and take action, the years go by, you get old and bitcoin still stays there. You could get hit by a car tomorrow, you know?
Ask for help and we will help you choose a few trusted people here who will help you.

No, I'm going to auction it off

If you get the file and the money starts moving, I expect 9 BTC

If they never move, I keep the bid

Yep. But OP doesn't want to download anything. And since I don't expect him to write his own software, he'll just keep opening a new topic every year.

@OP: get an offline computer if you're afraid of malware stealing your Bitcoin.

Counting from year 0...2025 with 366 days per year, I'm to lazy to properly account leap years, it's 741,150 possible dates (including incorrect February 29^th in non-leap years) in one particular style of formatting THE DATE.

With the right tools it's a piece of cake for those who know how to do it, to try every possible date with some common formatting. Who cares if you need a few hours for one style of formatting to exhaust every possible date? OP could try them all, if he wanted.

He could even first cut corners and try first only every possible date in the intervall 1900...2025 for all date formatting styles he can come up with. That's just 45,750 dates per style. That's what I would do first.

I'm sure some knowledgable members here would and could give OP enough advise how to automate an exhaustive search.

I'm pretty confident I could do it. Might need me some read-up as it's a long time ago I last did a wallet cracking recovery (someone in another forum forgot his spending PIN for the Schildbach Bitcoin wallet for Android, didn't even remember the length of the PIN correctly, so I worked my way up from 4-digit and higher; it took me some days to finally find the correct PIN as I didn't want to use heavy energy-demanding gear for the task. I wasn't too sure if the crack attempt would finally yield a positive hit. It felt good when it did.).

Maybe it would be "easy" if he listened to the advice he received when he first started a discussion on this topic. If you have the attitude "I don't want this, I won't try this" how will you solve the problem that brings you the 10 BTC reward? If I were in his place, I would try every advice and try all the possible dates that came to my mind - because if the password is really a date set by his father, then he didn't make up some nonsense date, but it is something that was very important to him.

Maybe he can try the lowercase 'the date', although there are more variations, without space, capital 'The date' or some similar combination. 

Finding their own post history on the forum is too complicated for someone who believes cracking a wallet file is easy.

It is not complicated only for beginners, because many times we could see that even some older members ask about things that they should know, considering that they have been on the forum for years. Let's take the example of @jerry0, who obviously doesn't know how to check his post history - because if he knew, he wouldn't be asking the same questions for years

---

---

Maybe the letters in THE DATE offer some solution - because each letter represents a number on old keyboards that contained numbers below the letters. Those who used mobile phones 20+ years ago wrote text messages in a completely different way than today.

84 33 28 3 - year 1984, March 28

The only problem here is to understand which date format was used.
Perhaps your location will help here, since in the USA the MM/DD/YYYY format is more often used and in the European part DD/MM/YYYY

I think that if you have any records of your father or messages, correspondence where he used some date assignments or something related to it, then you can at least understand what format he has and then parse all possible dates starting from 1970, as indicated by @NotATether, I think it will make your search much easier.

The format won't be a problem if OP still remembers it. But still, it should not be so big. There are only 1.7 billion or so values between the 1970 epoch and right now.

*Then again, I know how easy it is to forget things that I haven't written down, so I won't discount the fact that OP by now has probably forgotten everything about the password if he hasn't written it down.

Maybe it's a wedding date or any other special date, so 2010 may not be enough. But the date format may be a problem, I can think of many different ways to write "October 3th, 2024".

If the date really is the password to the wallet.dat then you just need Hashcat. Maybe you don't even need hashcat because the amount of valid combinations for the date are extremely small compared to say searching all 16-character passwords. Just get a GPU farm, make a script that will write all the dates between say 2010 and 2018 or something, varying by the second, and let it run for a few hours.

Have you tried:  "August 23, 2015, 10:45:31 AM"

What? A user has his own post history right from his own profile, there's a link to a user's own post history. Well, if that's already too complicated for some newbies, how do they even survive? Asking for a friend... jokes aside.


I glimpsed over your first topic from 2023. Were the details you posted from some notes from your father?

Have you tried some rather obvious choices for "THE DATE" like date of Bitcoin Whitepaper, date of Bitcoin Genesis block, date of your father's registration on bitcointalk, his birthdate, his wedding date, your birthdate? You may need to try various typing styles or what's just common for your father. Have you tried THE DATE literally, as written here in italics?  

To systematically check every possible way and not missing something AND if you're that paranoid to avoid using tools for this, you need to be very good at not making errors and document every trial carefully. Reliable and reputable tools exist and are better for this, but you need to learn to use them properly when you want to refuse "easy guides". Many guides by good and reputable members are already in this forum.


I see no problem with using well reputed tools. You can do your stuff on an offline computer and completely wipe it afterwards, if you don't trust the tools. Just don't let it go online after you've exposed your wallet.dat on it.


Well, then do your own research. Your wallet.dat file won't reveal its password by itself. Whatever guide you find, you can ask here if you don't understand some steps. You may get answers here, too.

Of course, you shouldn't send your wallet.dat file, that's a given. You shouldn't even keep this wallet.dat file on an online computer which security status you can't assess! Store it in multiple copies only on offline devices and/or storage media. Judging by the balance of the one address you revealed, I recommend multiple redundant copies, two distinct places to avoid a single point/place of failure.

Sensitive data like private keys in a Bitcoin Core wallet.dat file are encrypted with a random encryption key. This encryption key then is AES encrypted with the wallet.dat's encryption password/passphrase, IIRC. To access and use private keys of your wallet, you need the wallet's encryption password/passphrase. The AES encrypted random encryption key by itself doesn't reveal anything about your wallet's private keys. So it's safe to share this AES encrypted chunk as long as you keep your wallet.dat safe and secure and only in your possession.

In your other thread you refused to get help by a good member of this forum who is unfortunately not anymore amoung us. When you say, tools like btcrecover and its setup to tackle your problem is above your head and you don't want external help from forum members, then you probably only have below professional option left.

If you want professional help, I can recommend to contact Dave (you will need to read past first posts full of skepticism by natural crypto space reflexes).
Dave will not ask for your wallet.dat file, he only needs that AES encrypted chunk of bytes. There are tools to extract those specific bytes from your wallet.dat. Dave will guide you accordingly in private communication. You only pay Dave if he accepts your challenge and when he succeeded to find the password of your wallet.


Promisses, promisses, ...

Good luck and progress with your wallet.dat.

Maybe because he couldn't find it - it's always easier to open a new topic and start the whole story from the beginning. However, with such an attitude, it is certainly not realistic to expect success - but perhaps it is not something that should be considered a tragedy.

Assuming that the story is true, the person who set up the protection had two possible goals - the first is that no one can gain access to those coins, and the second is that only those who will be intelligent enough to understand how to unlock them can get them.

If you got that wallet.dat from stranger or random website on internet, it's likely you got fake wallet.dat. Read this explanation,

---

It's good you took some precaution. But if really you think it's not fake wallet.dat, your only option is brute-force using software such as BTCRecover or Hashcat.

FYI, those are under the premise that the actual password is simply "the date".
Not easy if it's just a clue left by your father.

For example: my easily-accessible written account list doesn't have the actual password but a clue for me to remember which of my common passwords to use.

But at least if you try to bruteforce, you can deduce that the password is not simply a date if it exhausted the search.
That's not doable by hand though since you'll be typing each of the possible millions of combinations manually so you'll need the "stuff" to do that.
At least use the suggested "open-source" tool BTCRecover which you can audit the source code.

Why didn't you continue in your last topic?

Then just start typing those easy passwords. Good luck!

Going to be hard to crack if you are not willing to download pywallet and hashcat.

It seems that someone send you wallet.dat file and then the person who sent it to you is asking for a payment, I guess?

Take note there's no easy way to crack a wallet.dat file if the wallet is fake or even it's authentic if it's secured with a long passphrase. You can't bruteforce it in one day, a week, or months it would take decades, and the sad thing is, it might not even have stored BTC on the wallet.

I do not really understood what you posted but I guess you want someone to help your brute force the wallet.dat password so that you can have access to the wallet and have access to the bitcoin on it. Definitely you bought the wallet and which means you have been scammed.

I've got wallet.dat and I was told by many different people that it's going to be easy to crack

But

I'm not going to download your stuff, I'm not going to follow any "easy guides" on the Internet, I'm not sending you anything

If I somehow get the whole balance, I can pay 1 BTC, no problem