Well, there is no secret at all. The neo code is open source and even already linked above.
Here for instance is the verify function:
https://github.com/neo-project/neo/blob/...et.cs#L476
while ToAesKey (), which I agree is a little bit confusing, but for us it doesn't deal with aes, it just converts the password into a double-hashed digest... is defined here:
https://github.com/neo-project/neo/blob/...#L140-L141
After you have all the components you just put all together: 2+2= 4 minus 1 is 3. quick maths
btw, I didn't mention an important detail: the algortihm uses the binary bytes for each "iteration", i.e. the algorithm actually is sha256 (sha256_raw (sha256_raw ($pass)))
That means, the output could be represented as hex (I don't know if there already exist a standard hash format supported by some crackers for NEO... it seems that jtr just uses a custom dynamic format with a hexadecimal representation of the hash) while the intermediate digests are not converted to hex but are uses as raw binary bytes.
Note: this hash algorithm is very dangerously fast to crack, it is quite easy to crack. Not salted. just 3 iterations won't be enough to make it secure. Also note... this format is not implemented in hashcat yet, you would need to request it on github with all details and example hashes etc.
Here for instance is the verify function:
https://github.com/neo-project/neo/blob/...et.cs#L476
while ToAesKey (), which I agree is a little bit confusing, but for us it doesn't deal with aes, it just converts the password into a double-hashed digest... is defined here:
https://github.com/neo-project/neo/blob/...#L140-L141
After you have all the components you just put all together: 2+2= 4 minus 1 is 3. quick maths
btw, I didn't mention an important detail: the algortihm uses the binary bytes for each "iteration", i.e. the algorithm actually is sha256 (sha256_raw (sha256_raw ($pass)))
That means, the output could be represented as hex (I don't know if there already exist a standard hash format supported by some crackers for NEO... it seems that jtr just uses a custom dynamic format with a hexadecimal representation of the hash) while the intermediate digests are not converted to hex but are uses as raw binary bytes.
Note: this hash algorithm is very dangerously fast to crack, it is quite easy to crack. Not salted. just 3 iterations won't be enough to make it secure. Also note... this format is not implemented in hashcat yet, you would need to request it on github with all details and example hashes etc.