Quote from: morbius55 on Today at 01:31:14 PM

What would be the minimum data required to decrypt a private key? Would it be ckey! and mkey, what about salt, is that part of the mkey? All depends on having the correct passphrase of course. My corrupt wallets have been either fragmented with groups of ckeys that have been separated from the mkey, or other data in the wallet has been corrupted causing the wallet to be unusable with normal methods. I'm pretty sure that the hex values of the mkey and ckeys can be found quite easily by using Winhex or similar. If possible, it would be fantastic to have a tool for manually inputting the keys and passphrase that doesn't get tied up with other corrupt data in the wallet.dat.

1. The target address. ( maybe not see below)
2. The passphrase (and encryption method)
3. The exact 32 (consecutive) bytes of the private key somewhere in the file.

For un-encrypted keys:
The principle is very simple and assumes that the key is still somewhere in the (corrupted / partly overwritten etc.) file.
You slide over all of the remaining file data in 32 byte sized blocks and turn every block into a address (of the same target address method).
Then you compare the generated address to the target address.
If there is no match you move or slide the block to the next _nibble or ^byte.
Then when your byte scanner moves above the correct block of bytes, that holds the correct byte sequence, the resulting address will match the target address.
You can then print out/save the found data/key and exit.
This will work without the presence of any btree structure and without (looking for) the original database index keys because it only looks for the exact 32 bytes of key itself and not the combined database index entry plus relevant data.
In this respect this method will outperform recovery tools that only look for the standard database index key entries and their following variable field.
So it's as close to a RAW method as it can possibly get, simply because one nibble or byte more, or one less and you will completely miss your target.
It will work most of the time but not in case of missing/corrupt bytes in the key itself and for fragmented keys because then it will obviously produce a mismatch in target address.
In that case your chances on a success are extremely limited and will depend on how hard you decide to push it further with the scrambled data that is left.
You could start and try to rotate individual bytes but it could take forever, this is not something I would advice in combination with this method.
In case you do not know the target address you will have to verify the actual balance of every address that rolls out of those scanned blocks on the blockchain.
So you could even do it with less.

For encrypted keys it will get a bit more difficult because your goal then is the decryption of partial encrypted data and then you (usually) also need the preceding 16 bytes (CBC Cypher Block Chain) as part of the decryption method to enable the decryption of the next block of data depending on the decryption method you use, there are several but it get's a bit technical here it is best imagined that you no longer search for the exact key but for a block of data that 'makes sense' by this i mean when your output will be mostly garbage and non base16 characters then you know that you are off target, and when a block arrives with a perfect string of only base16 hexadecimal bytes then you can be absolutely sure that you have something of real value.
I always compare it to turning a knob of those old analog radio's it's mostly noise until a crystal clear channel pops up.