So I'm assuming it would get mauled again, rather than being in it's original raw form?

The hex view is before being loaded into core. I have seen both a 2016 and 2013 date shown in 2 different wallet dumps for that legacy address, last image first line.
Something to note is that i haven't done a rescan while this wallet has been loaded into core. Would that have a different outcome regarding what keys/addresses it would show. Still don't understand the encrypted wallet thing though.

Can this command decrypt the wallet.dat in the directory even if it has never been loaded into bitcoin core? Also, does it leave that file sitting in the directory unencrypted? Thanks for any info.

Pywallet confirmed that it is encrypted and that the passphrase is correct. This wallet file is not a pywallet recovered file, it is a wallet.dat recovered from the hard drive with recuva and showed that it originally came from the usual appdata/roaming/ bitcoin file path on the drive. I have shown some screenshots below which includes one of the wallet info command in the daemon bitcoin-wallet utility(this is before bitcoin core has done it's thing with the wallet). I have shown a hex view of the wallet and highlighted the address that the wallet dumps show, and also the address I'm after(strange that this address is in an encrypted wallet, yet core can pull it out of there with it's private key and the resulting wallet is unencrypted). Another strange thing is the dates of the addresses(2013). Cheers.
https://imgur.com/a/8WxPaJj

Is there a way of not entering a passphrase for the recovered wallet but still entering the correct passphrase for the actual recovery, ie leaving the recovered wallet decrypted?

I can;t understand how it even used the wallet without causing an error. Not sure why there ends up being one old style address in there.

When I load an old wallet into Bitcoin Core, it changes from 96kb to over 600kb and only shows one legacy format key and the rest are new keys(presumably a thousand). I also expected the wallet file to be encrypted but it isn't. The wallet seems to load okay without throwing a corruption message out but does not show any old keys etc. I have shown four screenshots here of the debug log, from starting up with this wallet file. Thanks.
https://imgur.com/a/tjdKISW

Cheers again for your help.

I'm only using copies, but thanks for your reply.

Thanks for your help.

Thanks, how do I run that on my wallet files? My wallet files are In D:\Bitcoin, and Daemon is in the same. I have 3 wallet files with different names. Does the bitcoin-wallet offer any more tools?

How do you run salvagewallet in the latest version. Thanks.

The wallet seemed to load okay into the latest Bitcoin Core but I don't see the address. Here is a wallet dump of it, i'm not sure if I loaded the wallet into core correctly as it seems more complicated than older versions. Why are all the addresses in the newer format? I have obviously deleted most of the private key info.
https://imgur.com/a/vQ5cpCn

The comment he made about compressed key recovery is in the first comment of this page.

JackJack mentions that pywallet didn't recover compressed keys. Could that be why i'm not able to recover anything from this wallet? Does the old pywallet have trouble recovering and dumping newer wallets. Does a wallet from 2015 fall into this category? Cheers.

I have reason to believe that a wallet.dat i found that is from from 2015 could contain the private key i am after. It seems that my brother in law has got his information mixed up. I opened this particular file up with a file viewer 4 and i could read the address i'm after within it. Do you think i could have any luck with either your code alterations or the newer version of pywallet. Cheers. I didn't have any luck when i ran pywallet on the whole hard drive which contains this wallet file.

I'm probably not making myself clear. I have scanned the whole Hard drive with pywallet on multiple occasions, when the hard drive has been mounted in a separate enclosure and connected via usb. The scans have been successful in recovering wallets but i find that the results have sometimes been inconsistent. The last time I tried a scan i used every passphrase upper and lowercase, but that didn't yield as many results as an earlier one that included less passphrase variations(i do know the correct passphrases that my brother in law used). I have done quite a few scans this way and have managed to dump the recovered wallets. Some of the wallet.dats i recovered were obtained by using recuva(a file retrieval software). I put those files on to a usb stick and ran those through pywallet with limited success. I think they are corrupted but they are from the correct time(2011-2013). The version of pywallet used is the original one using python 2.7. I don't know if the updated one is any better, but i did see JackJack saying that some things in the original "have always been broken" so maybe i should try it? I just wondered whether the pywallet scan of a hard drive from another laptop is fully accessed by the scan. Thanks for your time.

Someone mentioned that it could be a pgp file?

Thanks for the reply. It was from a pywallet recovered wallet via some wallet.dat files that I moved to a thumb drive from the hard drive using recovery software. I have got some inconsistent results with pywallet when searching the whole hard drive. In past searches it has found up to 300 keys, but the last couple of attempts using even more passphrases has produced only 103 at the most. Something else i wondered about was the possible unencrypted keys it says it has found. Do you know whether pywallet will search a whole hard drive that you have mounted in an enclosure and connected via usb, including any partitions it has? Thanks again.

I might have to send the file to someone trusted to have a look at as I'm not sure what I'm doing. I have got python 2.7 installed but it is a lot of text to enter in a command line. Thanks for your time.