06-13-2020, 01:48 PM
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)
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)