achow101, thanks for this feedback!

Because of your feedback I did found more as 600 private keys on HDD because of preamble „0x3081d30201010420” (compressed) and “0x308201130201010420” (not compressed).

As I know the public key is generated over private key (One of thousand examples: https://www.crypto-lyon.fr/how-to-get-an-address-from-a-private-key-on-bitcoin.html).

Now my next doubt: If no public key is found (mkey and private keys are present), then the script stops the recovery. Please start to see with the line 1463 in pywallet.py Version 2.2. Why the script pywallet.py try to find mkey, public keys but not private keys as first? Is here some hidden logic?  

Before I start to extend the code of pywallet.py. I need some support from this forum.
My first step is to understand the data structure behind ckeyA.

Example as HEX values:
47000104636B65794104500E6D9173EDF9C623461F23BF27A9CDF74B011C75D348364FDEC49605F D8A14E896DEBFC0BF189D55D5A38B861A506BDE3E2AEB7D481DC1FE0116251AFB906F8286310001 3092F0D25C86D3259732547660F985AB36CF8A4BB6C1815DA2AB990DF9F7F1B3993C9553E028257 676C85189177C311E16

How I understand the structure until now:
<47000104636B657941> <preamble ckeyA (9 Byte)>
<04500E6D9173EDF9> < public key signature (8 Byte)>
<C623461F23BF27A9CDF74B011C75D348364FDEC49605FD8A14E896DEBFC0BF189D> <uncompressed public key (33 Byte)> <55D5A38B861A506BDE3E2AEB7D481DC1FE0116251AFB906F82863100013092F0D25C86D32597325 47660F985AB36> <”something” + private key signature (46 Byte)> <CF8A4BB6C1815DA2AB990DF9F7F1B3993C9553E028257676C85189177C311E16> <uncompressed private key (32 Byte)>

Do I split correct the bytes? The area “something + private key signature” is for me a black box up-to-now.

Thank you!

I created two files. One file with real ckey! and ckeyA. Second file is a copy from the first file without ckey!.

First file was created to check, that the wallet will be recognized. The second file is created to prove the algorithm second time.

In both cases the script pywallet.py does not recognize ckeyA.

Here are more dateails

Description from my friend: He worked with the HDD and linux starts to recover data’s on this HDD. He does not recognize that. After some time he would like open some text files with source code. He was able to open the files, but the content of the files were not more readable. He stopped to work on this HDD and start to recover the wallet. He did not found the wallet. Also the file system is working, but with wrong file table. He had several copies of the same wallet on this HDD. Only one file content needed private key with transaction.

My work on that HDD: As I start to recover the wallet some years later, I did found one wallet with recovery tools. This file was not the right one. After it I used WinHEX to check whole HDD for ckey. I found several places on HDD with ckey (ckey! and ckeyA). As I saw, the recovery tools do not put all the ckey in one file, I tried to found a solution for that. Than I investigate that pywallet.py exist  . I start to work with that script. I was able to create several files with the same mkey and all ckeys. Last week I was count the checked ckeys and saw, that ckeyA are not used by pywallet.py.

Conclusion:
-   Correct mkey is present
-   Password is present
-   All ckey! are already checked
-   ckeyA are present, but not checked

Actual situation: some years ago (around 2015) a friend crashed his HDD. After some yeara he asked me to help him to recover the wallet on this HDD. The friend still knows the password for the wallet. I extracted mkey and ckey!. I used pywallet.py (version 2.2 from jackjack) to recover the wallet.dat. Now I investigate that the HDD contains around 100 “ckeyA“=“hex: 63 6B 65 79 41“. As I see the pywallet.py does not use ckeyA to recover the private keys. Script pywallet.py use ckey! to find the private keys (maybe I am wrong). The thread "link" show me that every ckeyA content public and private key. achow101 wrote about that.

Plan: I would like extend the script “pywallet.py” to include the algorithm for ckeyA. Jackjack is unfortunately offline since 2018. The fork from mikeborghi is just a copy from last version from jackjack.

My first questions are:
How is the exact structure behind ckeyA in hex notation? How are the data’s encrypted?

Here are abligatory information:
Bitcoin Client Software and Version Number: Not exactly knows (around beginning of 2015)
Operating System: Windows 7 and Linux (different versions)
System Hardware Specs: Systems with Intel CPU and a lot of diferent HDD. This is not relevant for the problem.
Description of Problem: Recovery private keys behind ckeyA
Any Related Addresses: not relevant
Any Related Transaction IDs: not relevant
Screenshot of the problem: not relevant
Log Files from the Bitcoin Client: not relevant

Thanks a lot in advice!