Posts: 52
Threads: 15
Joined: Oct 2017
06-11-2020, 05:38 PM
(This post was last modified: 06-11-2020, 05:41 PM by svobodnui11.)
I re-read everything that’s possible on the Internet and on the forms that didn’t find the answer, here is my mistake my mistake is
I will modify the hash according to the rules of the forum, it turns out such a hash
What I did:
hashcat64.exe -a3 -D1 -m15700 $ethereum$s*8192*8*1*64symbol*64symbol*64symbol 123456789?d?d45678
Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256
Hash '$ethereum$s*8192*8*1*64symbol*64symbol*64symbol': Token encoding exception
No hashes loaded.
1 - changed the txt encoding to ANSI, UTF-8, UTF8-no Bom
2 - copied hash with cmd john in cmd hashcat
3 - checked that with other versions of complexity everything is fine
4 - reinstalled opencl
5 - I got the hash with my hands and through utilities like John and others everything is right
6 - tried different PCs and with enabled features --force and -O
tell me where to dig for 2 days I can’t understand what’s wrong, the file is not broken with it everything is fine wallets understand it
Posts: 2,267
Threads: 16
Joined: Feb 2013
why do you not use a hash file, i.e. a file that contains the hash.
The shells (cmd/bash) have various special symbols that need to be escaped, it's always safer to use a file.
Posts: 52
Threads: 15
Joined: Oct 2017
(06-11-2020, 07:08 PM)philsmd Wrote: why do you not use a hash file, i.e. a file that contains the hash.
The shells (cmd/bash) have various special symbols that need to be escaped, it's always safer to use a file.
I use hash file but have error
Posts: 52
Threads: 15
Joined: Oct 2017
(06-11-2020, 07:08 PM)philsmd Wrote: why do you not use a hash file, i.e. a file that contains the hash.
The shells (cmd/bash) have various special symbols that need to be escaped, it's always safer to use a file.
use hash file but have error - no hash loaded
using a hash file or just copying a hash I always get the same error, tried all the options and different operating systems, I have been using your software for years. I even tried to change the encoding of the file also did not help
Posts: 2,267
Threads: 16
Joined: Feb 2013
test with the example hash from https://hashcat.net/wiki/example_hashes (search from 15700 and copy the hash into a file).
If the example hash is loading correctly without any errors, try to change that example hash step-by-step (field-by-field) to make it look like your target hash. After each field you change, you try to load it and see if it is accepted.
This way you will figure out which fields are not accepted and why it is rejected. (of course the overall hash needs to be complete, but you can just copy-paste one field from the target to the example and test again, replacing the fields one-by-one without cutting the hash and without making the hash shorter, the number of fields must remain the same)
Please report back with clear information why and which field is not working for you (your analysis of this testing/debugging). thx
Posts: 52
Threads: 15
Joined: Oct 2017
(06-13-2020, 12:09 PM)philsmd Wrote: test with the example hash from https://hashcat.net/wiki/example_hashes (search from 15700 and copy the hash into a file).
If the example hash is loading correctly without any errors, try to change that example hash step-by-step (field-by-field) to make it look like your target hash. After each field you change, you try to load it and see if it is accepted.
This way you will figure out which fields are not accepted and why it is rejected. (of course the overall hash needs to be complete, but you can just copy-paste one field from the target to the example and test again, replacing the fields one-by-one without cutting the hash and without making the hash shorter, the number of fields must remain the same)
Please report back with clear information why and which field is not working for you (your analysis of this testing/debugging). thx
I’ve done this all for a long time, right now it's shameful and everything’s ok, the complexity is only 8192 and in example 262144, can I throw a hash or the file for the test in my LAN?
Posts: 2,267
Threads: 16
Joined: Feb 2013
you can't post hashes here... if you are really sure that you already tried everything and it still isn't working, not even with the latest beta version from https://hashcat.net/beta/ , we could probably make an exception and you can send a hash with known password via PM (not publicly here) to me. Thx
Posts: 52
Threads: 15
Joined: Oct 2017
(06-13-2020, 12:46 PM)philsmd Wrote: you can't post hashes here... if you are really sure that you already tried everything and it still isn't working, not even with the latest beta version from https://hashcat.net/beta/ , we could probably make an exception and you can send a hash with known password via PM (not publicly here) to me. Thx
Yes, I tried both beta and older versions, I don’t understand where the error is, I send
Posts: 2,267
Threads: 16
Joined: Feb 2013
I've now spend (wasted ? ) some minutes investigating this and it seems that already the input file (the UTC file that you would normally use for the ethereum2john.py conversion to a hash) is completely broken and manipulated.
It contains non-hex characters in the "ciphertext" ("myui") and within the "mac" checksum code "gh" etc. This is of course manipulated by hand, maybe somebody is messing with you ?
Hexadecimal characters can only be within this range 0-9a-f i.e 0123456789abcdef (no "m", no "y", no "u", no "i", no "g", no "h", here. This is of course some human manipulation of the file to make it NOT crackable, but be aware it could also be that other not that obvious parts are manipulated, for instance the "3333" parts etc look quite suspicious to me, but I could be wrong here... therefore I wouldn't waste any second with this crap).
As expected, this was just pebcak... there is no bug in hashcat... it's very obvious that somebody changed the UTC file to make it non-crackable, by replacing/inserting characters that are not valid (non-hex)
Posts: 52
Threads: 15
Joined: Oct 2017
(06-13-2020, 01:48 PM)philsmd Wrote: I've now spend (wasted ? ) some minutes investigating this and it seems that already the input file (the UTC file that you would normally use for the ethereum2john.py conversion to a hash) is completely broken and manipulated.
It contains non-hex characters in the "ciphertext" ("myui") and within the "mac" checksum code "gh" etc. This is of course manipulated by hand, maybe somebody is messing with you ?
Hexadecimal characters can only be within this range 0-9a-f i.e 0123456789abcdef (no "m", no "y", no "u", no "i", no "g", no "h", here. This is of course some human manipulation of the file to make it NOT crackable, but be aware it could also be that other not that obvious parts are manipulated, for instance the "3333" parts etc look quite suspicious to me, but I could be wrong here... therefore I wouldn't waste any second with this crap).
As expected, this was just pebcak... there is no bug in hashcat... it's very obvious that somebody changed the UTC file to make it non-crackable, by replacing/inserting characters that are not valid (non-hex)
could you indicate the line where there is an error, it’s just that the file was in its local storage and no one touched it all this time, I think I’m not sure what it is.
please tell me exactly where the mistake is for understanding the future, thank you so much
|
