please test the example hashes from https://hashcat.net/wiki/doku.php?id=example_hashes
try to make the example hashes work and also try to crack the hashes with password hashcat
after everything works with the example hashes, try to check what kind of hash your target hash is (the signature, start is important like $ethereum$s* ) and after that try to construct a similar hash with fields of the example hash modified with your info.
We for instance got a similar request a few weeks/months ago and the fields / hash wasn't even with valid hexadecimal data (for instance "x" as a hexadecimal char etc)... this hash was for sure tampered / modified, because the ethereum client doesn't generate .json files like this that do not even encode the raw data correctly into hexadecimal data. So my suggestion is to first try the example hashes and after that create a modified example hash (example_mod.txt where you replace the single field delimited by * with the data of your target hash and see when it stops working).
update: doing some little more research, I think it could have to do with this go-ethereum missing padding behaviour that seemed to be present in some/several very old geth (go-ethereum) versions that had (depending on the bytes in the "output", problem of zero-bytes + missing padding) shorted "ciphertext" fields: https://github.com/ethereum/go-ethereum/...r.json#L49 and https://github.com/ethereum/go-ethereum/...r.json#L73 ).
I think a problem here is that you can NOT really pad them manually without changing the algorithm (by adding some 00 at the start), because I think the input that is used to verify and compute the mac etc also uses the "wrong" input (so basically 2 "problems", not just the missing 00-padding to a fixed size in the JSON output)
also see: https://github.com/ethereum/go-ethereum/pull/3032 and https://github.com/hashcat/hashcat/issues/2017 (it's interesting that I did open this issue, but didn't really remember opening it or any details, but at least I did document it quite well, fortunately ).
It would make sense that you at least test/see if this is really the problem also for you, i.e. the ciphertext length shorter than 32 bytes... otherwise we can't really proceed here (without knowing if you are affected by this < 32 byte ciphertext padding bug)
try to make the example hashes work and also try to crack the hashes with password hashcat
after everything works with the example hashes, try to check what kind of hash your target hash is (the signature, start is important like $ethereum$s* ) and after that try to construct a similar hash with fields of the example hash modified with your info.
We for instance got a similar request a few weeks/months ago and the fields / hash wasn't even with valid hexadecimal data (for instance "x" as a hexadecimal char etc)... this hash was for sure tampered / modified, because the ethereum client doesn't generate .json files like this that do not even encode the raw data correctly into hexadecimal data. So my suggestion is to first try the example hashes and after that create a modified example hash (example_mod.txt where you replace the single field delimited by * with the data of your target hash and see when it stops working).
update: doing some little more research, I think it could have to do with this go-ethereum missing padding behaviour that seemed to be present in some/several very old geth (go-ethereum) versions that had (depending on the bytes in the "output", problem of zero-bytes + missing padding) shorted "ciphertext" fields: https://github.com/ethereum/go-ethereum/...r.json#L49 and https://github.com/ethereum/go-ethereum/...r.json#L73 ).
I think a problem here is that you can NOT really pad them manually without changing the algorithm (by adding some 00 at the start), because I think the input that is used to verify and compute the mac etc also uses the "wrong" input (so basically 2 "problems", not just the missing 00-padding to a fixed size in the JSON output)
also see: https://github.com/ethereum/go-ethereum/pull/3032 and https://github.com/hashcat/hashcat/issues/2017 (it's interesting that I did open this issue, but didn't really remember opening it or any details, but at least I did document it quite well, fortunately ).
It would make sense that you at least test/see if this is really the problem also for you, i.e. the ciphertext length shorter than 32 bytes... otherwise we can't really proceed here (without knowing if you are affected by this < 32 byte ciphertext padding bug)