Sorry, The FinderOuter doesn't support wallet files (bitcoin core backups) yet.
And please ask your questions in English so that I don't have to use Google Translate.

I'd recommend doing the following (more info here: https://github.com/Coding-Enthusiast/FinderOuter#running-the-finderouter):
1. Download FinderOuter release or source and build it yourself (deterministic builds and PGP signature will be added in near future)
2. Download Ubuntu
3. Verify Ubuntu's iso
4. Disconnect network cable (to remain offline)
5. Boot from a DVD or USB
6. Run FinderOuter

You may find it easier if you used Visual Studio (https://visualstudio.microsoft.com/vs/mac/), if you install that then all you have to do is to open the solution file (FinderOuter.sln) and change solution configuration to "Release" and build using Build > Build solution from menu or press Ctrl+Shift+B and you'll find the binary at

If you didn't want to download VS. then MSDN has some good posts to get you started on how to use dotnet commands.
https://docs.microsoft.com/en-us/dotnet/core/get-started
An example: https://docs.microsoft.com/en-us/dotnet/core/tutorials/cli-create-console-app
the dotnet build command: https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-build
Basically you'll have to run:

To have a comparison the Base-58 part searches for 1.4 million keys per second but the Base-16 part is searching for 1200 keys/sec on my PC.
I am trying to optimize ECC (which is what slows things down here) but unfortunately that will take a very long time to be ready.

That is correct.
To see this in action you can always create a new wallet using a wallet software that has these options already and see how they work (or take the harder route and check the source code of such wallet). For example Electrum supports these options and also can be run on TestNet. You can play around there with no cost and see how things work.

Keys being derived deterministically doesn't change the basics of how bitcoin works. If a certain key receives some coins the same key has to be used to spend those coin, doesn't matter how you created that key.

All addresses are exactly equal. The wallet (internally) categorize them for convenience.
Usually user chooses an address amount "receiving addresses" for example at m/x'/y'/z'/0/0 and receives some coins in the corresponding address. Then moves to next address m/x'/y'/z'/0/1 to receive again, and so on.
When the user wants to spend they spend the same coins using the same key (m/x'/y'/z'/0/0 and m/x'/y'/z'/0/1) but they send all the leftover to an address created by a new key like m/x'/y'/z'/1/0 then next spend's remainder goes to the address created from key at m/x'/y'/z'/1/1 and so on.

Change addresses aren't "special" addresses, they are simply a set of key pairs that are generated to be used as a change address. In an HD wallet since all keys are derived with a "path" you can decide to choose an slightly different path for the change addresses to get different (separate) keys. Usually only the last number in the path is changed.
For instance BIP-44 proposes usage of a 4 number system like this:
so if your main path is m/x'/y'/z'/0 then your change path is m/x'/y'/z'/1.

Knowing the path, the wallet keeps track of change addresses the same way it keeps track of any other address.
As for sending, a decent wallet has to have the option to allow the user to select "coins" (ie. unspent transaction outputs) at the same time be able to perform coin selection based on privacy settings chosen by the user.

ref: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#path-levels

Version 0.1.2 is released.
https://github.com/Coding-Enthusiast/FinderOuter/releases/tag/v0.1.2.0
See changelog for more details.
Most notable changes are:
- New feature: missing chars in base-16 encoded keys (unfortunately unlike other options this is very slow for now)
- Simplified Base-58 option to no longer need a checkbox for special case.
- Base-58 will return a friendly error message if a full private key was entered and was invalid.
- Some optimization and code cleanup.

What happens if a script contains OP codes that are not among the defined bytes from 0x00 to 0xb9? For example if it contained 0xcc.
Is it one of those "special" cases where we let it slide if for example it is not executed (eg. not-executed conditional branch or in PubkeyScripts)? Or are the rules more strict here?

More specifically what happens if a script contains the only named OP code that is 0xff (or OP_INVALIDOPCODE) which seems to be the only defined OP code without any case in interpreter
https://github.com/bitcoin/bitcoin/blob/5e12a61044b15e4e29ac786135a9ebb72d1bfc61/src/script/script.h#L190
This one seems to be slipping through as valid using conditional OPs!

True, but the idea is to explain the main steps of creating such addresses without repeating steps that are already known or explained elsewhere. The 4 byte checksum is a part of the Base58 encoding with checksum that is already known and used for P2PKH and P2SH addresses and WIFs.

If you have noticed I've also skipped calculating public key from private key, encoding a public key in compressed form, internals of hash computation, details of scripts such as data push lengths,... However, I can explain each part in details if anyone is interested; just reply here with the part you want more explanation on.

As a developer who prefers documentation I've always liked these step-by-step guides with actual values that could also be used in tests. Since my previous topic on the subject (Bech32 P2WPKH addresses)[1] was bumped I thought about creating a new one here maybe it could help other developers spend less time trying to understand how it works or for debugging their code,...
Read more about details in[2].

Pre-requirement
A P2SH address is the human readable form of a pay-to-script-hash pubkey script and as the name suggests it is a payment to hash of a script. In other words in order to create a P2SH address all we need is a script. This script can be anything from an empty script or a single OP code to complex smart contracts. You usually see it as a multi-signature redeem script (OP_m Pub1 Pub2 ... Pubn OP_n OP_CheckMultiSig).
In a P2SH-P2WPKH address this script is a special redeem script created by using the hash of the public key.

Steps for creating a P2SH-P2WPKH address:
1. Having a compressed[3] public key (0x02 or 0x03 followed by 32 byte X coordinate):

2. Compute SHA-256 hash of the public key:

3. Compute RIPEMD-160 hash of the result of SHA-256:

4. Build the redeem script that is OP_0 PushData<Step_3_Result>
(This redeem script also goes in signature script of a transaction while spending)

Now we use the script from step 4 to create the address (the following steps are similar to creating a P2SH address for a multi-signature redeem script)
5. Compute SHA-256 of the script (step 4)

6. Compute RIPEMD-160 hash of the result of step 5

7. Add P2SH version byte at the beginning of the result from step 6 and encode the result using Base-58 encoding with a checksum[4][5]
=> Final result


How about P2SH-P2WSH?
It is very similar to this but instead of starting from a public key we start from having a "script" (step 1) and instead of 2 hashes (step 2 and 3) only one hash is performed on it and that is a single SHA-256. The rest is the same.
1.

2&3. A single SHA256

4. Build the redeem script that is OP_0 PushData<Step_3_Result>

5. Compute SHA-256 of the script (step 4)

6. Compute RIPEMD-160 hash of the result of step 5

7. Add P2SH version byte at the beginning of the result from step 6 and encode the result using Base-58 encoding with a checksum


[1] Step by step guide to go from public key to a Bech32 encoded address
[2] https://bitcoincore.org/en/segwit_wallet_dev/
[3] Using uncompressed public keys would make the script non-standard and will practically lead to fund loss
[4] https://en.bitcoin.it/wiki/List_of_address_prefixes
[5] https://en.bitcoin.it/wiki/Base58Check_encoding

The encoding is Bech-32 not Base-58 and there is no SHA256 in this encoding, there is only playing around with bits. Read BIP-173 for details of how you should compute the checksum.

OK, let me see what I can do but unlike base-58 it will be very slow since it requires EC point multiplication which is slow by nature and my ECC code is particularly slow since I still haven't had time to optimize it.
I'll post an update here when it is finished.

That is part of the information I've already found that includes malleability fixes. But some parts are missing.
Let me be more specific, One case is invalid SigHash byte. I have found transactions (already mined) that have 0x00 as their SigHash byte (flag) which is clearly a bug and is not about encoding.
Is this currently fixed? At which fork (block height, is it along BIP66?)?
Also I'm wondering what other "special cases" exist that I'm not aware of. For instance is/was 0x05 (=0b0000_0101) considered valid SigHash and equal to SigHash_All?

I can't find that much information regarding historical bugs that concerned SigHash types. I have found a couple of transactions that should have been logically invalid but were accepted as valid in the history such as SigHash zero or the case where some garbage bytes are added at the end of the signature before the SigHash byte.
I'm also wondering whether such cases are invalid today or just non-standard.

I'd appreciate it if you could provide some detailed information about this.

This project is designed to only work for bitcoin but it may be used for any altcoin that is similar to bitcoin.
I took a quick look at Tron's source code and it seems like it is using the same curve (secp256k1) as bitcoin and has base58 encoding although I couldn't figure out if they use the same encoding for WIFs. If your key encoding is hexadecimal then it doesn't work but if it is a base-58 encoded string with a checksum and same additional bytes then you can use this tool.

I ran some tests with different compressed keys with 3 missing characters at different locations while editing the code to limit the search space (to shorten the time for tests), I couldn't figure out the issue since they all succeed.

---

https://github.com/Coding-Enthusiast/FinderOuter/commit/e949a711dc5dfcbaa01d393ebaa32e3ea8911507
With this commit, when an invalid but full key (no missing characters) is typed in that text box, the message is more clear about where the problem was.

Do you know the reason for the key being invalid (for example is it the checksum, invalid character or out of range value)? Or is it just producing a different address? (You could use bitaddress.org for decoding, it will tell you the reason).

It is GitHub that automatically adds the repository's source code as both a zip file and a tarball whenever a new release is published there (both named Source code) so that the source code at that exact commit is always available under the same binaries.
In any case, thanks for the report. I've added a short explanation to the ReadMe file that can hopefully prevent similar future confusions.

FinderOuter can run on any operating system. You just have to compile it yourself if you want to run it on Windows since I've only released the compiled version for 64-bit Linux OS. I can release more compiled versions if there is an overwhelming demand for it but security-wise it is best if you run it on a clean Linux specially if you are a windows user and want to use the same OS you use daily and may already be infected without you even knowing it.

hmm. Did you use the released zip file under "releases" and run it on Linux or did you compile it yourself? Because I can see you needing to install extra stuff for compiling (SDKs, Nuget packages,...) but there is no need to download anything else if you run the compiled version since it is self contained meaning even the framework (.net core) is included.

Version 0.1.1 is released.
https://github.com/Coding-Enthusiast/FinderOuter/releases/tag/v0.1.1.0
See changelog for more information.
Most notable changes are:
- A new feature for a special case where a compressed private key has 3 missing characters at unknown locations.
- Some small optimizations, bug fixes and improvements.

---

Future ideas (as soon as I publish my Bitcoin.Net library):
- Recovering mini private keys with missing characters (eg. a damaged physical coin)
- Converting versioned private keys (BIP-178 and a couple of Electrum versions) to normal keys
- Finding BIP-32 paths by only having the mnemonic/xkeys and a single child address/key

I'm not a math expert but I think it should take 20,825 times longer (58³=195,112)*. There is also the fact that the underlying algorithm will also be different that lacks most of the pre-computation that the current algorithm for known missing places has so it will be slightly slower. However, as I said before I have no idea how to generalize this so I hardcoded the heck out of it (only for this special case: missing 3 chars, probably will add a couple more smaller cases later), the benefit of it is that I know how to run it in parallel so the more threads your CPU has the faster it would run and I don't think 4 billion is going to take that long to finish.

* The problem with not knowing the missing places is that you'll have to first select different locations then loop through the 58 possible characters and keys are long (52/51 characters) so things get out of hand quickly. Example:

20,825 in last example (like others) is calculated using combination in mathematics which is n!/[k!(n-k)!] where n is 51 for compressed keys (52 char long with first one fixed to K or L) and k is 3 (the 3 missing places).

https://github.com/Coding-Enthusiast/FinderOuter/commit/73e8596993cdf68be49a4f20ba52afa2b1c1a5b1
Here is a preview, will publish a released version soon (the checkbox needs to be selected to enable this "special" case):