brute forcing sha256 - need help locating salt in open source code

[megadodgy]

Hi respected Hashcat members,

Yep it's another new guy who needs some help. Hi! 

I have familiarized myself with hashcat enough to run some brute force attempts on a SHA256 hash and successfully tested it.

My issue is with a crypto wallet of mine, NEO in particular. Due to some rather uninformative instructions on their website and also a bad decision of mine to make a new variation of my my password. Yes short story is I locked myself out without backing up private key.

Please hear me out as I have been working hard to try and do this myself and I thought I was on my way (i still have my modest 2x1070 rig having an attempt at a 3 day custom charset and mask brute force on my wallets password hash)

Using SQLite Db reader to open my wallet's .db3 file I found the stored passwordHash along with 2 other fields called IV and MasterKey (not sure how these other 2 come in to play) - So, bingo! i thought I found it and started my current bruteforce attempt.

I had an idea to create a new wallet file with a super simple 4 letter password - I explored this wallet db3 file, got the stored password hash and copied/pasted that into (a backup copy) of my own wallet file. Amazingly when saving it this actually worked and I was able to open my wallet through the provided neo-gui. Of course that is about all I can do though as this would be an absolutely major fault in their (NEO's) product security. No transferring my balance to a new wallet. (so close yet so far)

Having access to the features in the wallet gui i decided to run the Change Password tool. This too worked but when i checked the stored PasswordHash compared to a plain SHA256 encryption of the same password they were indeed different (salted is my guess).

So you may be asking what do I need help with ? Well the code for the wallet is open source on github and after contacting neo with no response I needed to discuss with some experts elsewhere. 

Is it possible for some one on these forums to look at or assist me with the code on github and determine the hashing process for the stored passwords, im sure there is a salt used. If i can just get the salt then i can add that to my brute force attempts yeah ?

If this Forum is not the right place for this I do apologize and if someone could then contact me on email separately who may be able to help.

The github is https://github.com/neo-project/neo-gui/t...er/neo-gui (or just in case i can not yet post links its available on the neo site through the download page link)

[atom]

Someone would need to read through the sources to find out how the hash is built. After that, one need to write a new hashcat kernel to do it. Nothing that can be done in a few hours.

[Chick3nman]

You will likely be interested in the code on this page more than anything else:

https://github.com/neo-project/neo/blob/.../Helper.cs

[megadodgy]

Thanks for the this I will see how I go at trying to rebuild the hash and yes i have come to the grim reality that i wont have access any time soon - unless i can come up with the same password again (that is the part that sucks, if i made up the new variation of my password.... then why cant i do it again)

[Notagain]

Thanks for the this I will see how I go at trying to rebuild the hash and yes i have come to the grim reality that i wont have access any time soon - unless i can come up with the same password again (that is the part that sucks, if i made up the new variation of my password.... then why cant i do it again)

Hi, i'm in a similar situation. How are you getting on with this?

I've looked at the PasswordHash in a .db3 file from a neo-gui wallet and it appears to be a hex hash with 32 characters. However I'm led to believe that a SHA256 hash has 64 characters.

So, looking at the code linked on github above shows a selection of hash and encryption functions. In the .db3 file the other fields IV and MasterKey seem to relate to an AES encryption. IV = initialization vector.

The output of AES encryption can be (I think) 32 characters long.

Question is then....is the PasswordHash actually being stored in an AES encrypted format - where do the extra 32 characters come from to get a 64 character SHA256 hex hash?

Sorry if this all seems a bit amateurish (n00b) but it's become a bit of an obsession and I can't figure out the next step.

Thanks for any further help or pointers that the community could offer

[philsmd]

PasswordHash does not seem to use AES (or any other type of decryption) at all. It seems to be just
sha256 (sha256 (sha256 ($pass)))

and therefore tripple sha256

I do not have an example hash, but I think that you are confusing hexadecimal lengths vs binary length.
sha256 is 32 raw bytes (binary) and therefore 64 (32 * 2) hexadecimal characters.

[Notagain]

Thanks philsmd, i'm going to spend the day looking into hexadecimal length vs binary length.
Can I be cheaky and ask where did you glean the triple SHA256 from (if it's not letting trade secrets go!) ?

[philsmd]

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.

[royce]

And if you need it before it's added to hashcat, you'll have to fall back to other tools. John the Ripper supports it with a dynamic mode (CPU only):

Code:

Format label                         dynamic_1027
Disabled in configuration file      no
Min. password length                 0
Max. password length                 36 [worst case UTF-8] to 110 [ASCII]
Min. keys per crypt                  64
Max. keys per crypt                  1680
Flags
Case sensitive                      yes
Truncates at (our) max. length      no
Supports 8-bit characters           yes
Converts internally to UTF-16/UCS-2 no
Honours --encoding=NAME             n/a
Collisions possible (as in likely)  no
Uses a bitslice implementation      no
The split() method unifies case     yes
Supports very long hashes           no
A $dynamic$ format                  yes (Flat buffer SIMD)
A dynamic sized salt                no
Parallelized with OpenMP            no
Number of test vectors               24
Algorithm name                       sha1(sha1(sha1($p))) (hash truncated to length 32) 128/128 AVX 4x1
Format name                          
Benchmark comment                    
Benchmark length                     -1
Binary size                          16
Salt size                            0
Tunable cost parameters              
Example ciphertext                   $dynamic_1027$b8443c12b3066dac22b3857b2fb779b4

... and MDXfind also supports it.