that's often the problem with user problem reports: unfortunately you just can't rely at all at the output / results they post. They just make the most strange and noobish mistakes and this is just confusing / distracting a lot.
Again, I tested with a 32 byte salt and a < 32 byte ciphertext and I get a "Token length exception" with the unpatched version.
The hash above seems to have an invalid salt length, it's exactly 42 characters (with the x counted too as replacement chars).
I think this problem is now pebcak and the patch should fix the orginal problem. You are probably testing with your tampered / modified hash again, not with the hash that has an exactly 32 character long salt and a < 32 character long ciphertext.
Again, for me (and I tested now several, several times with different lengths) your problem doesn't make sense unless you are not using the output that comes directly from ethereum2john.py (with file names and colons removed).
You should get a "Token length exception" with the unpatched version and no more error message at all with the patched version. It works for me.... otherwise just make it more clear how long your salt length is, because with those xxx the hashes just look way too tampered (in length) and it doesn't make any sense at all why you are testing with those tampered hashes.
update: what makes it even much worse... you seem to test with hashcat v4.0.1 . Is this a joke !? I mean, I don't want to offend anybody here and you might have some excuse (no valid one of course) to use such an old version (see https://hashcat.net/hashcat for latest version), but at this point I actually get started to think I'm just wasting my time answering here. We need some careful and cautious testers to fix a potential problem or new feature to support shorter ciphertext length... but I'm not going to waste my time here to explain why you shouldn't use a many years old and deprecated hashcat version. gosh damnit (sorry for the rant)
Again, I tested with a 32 byte salt and a < 32 byte ciphertext and I get a "Token length exception" with the unpatched version.
The hash above seems to have an invalid salt length, it's exactly 42 characters (with the x counted too as replacement chars).
I think this problem is now pebcak and the patch should fix the orginal problem. You are probably testing with your tampered / modified hash again, not with the hash that has an exactly 32 character long salt and a < 32 character long ciphertext.
Again, for me (and I tested now several, several times with different lengths) your problem doesn't make sense unless you are not using the output that comes directly from ethereum2john.py (with file names and colons removed).
You should get a "Token length exception" with the unpatched version and no more error message at all with the patched version. It works for me.... otherwise just make it more clear how long your salt length is, because with those xxx the hashes just look way too tampered (in length) and it doesn't make any sense at all why you are testing with those tampered hashes.
update: what makes it even much worse... you seem to test with hashcat v4.0.1 . Is this a joke !? I mean, I don't want to offend anybody here and you might have some excuse (no valid one of course) to use such an old version (see https://hashcat.net/hashcat for latest version), but at this point I actually get started to think I'm just wasting my time answering here. We need some careful and cautious testers to fix a potential problem or new feature to support shorter ciphertext length... but I'm not going to waste my time here to explain why you shouldn't use a many years old and deprecated hashcat version. gosh damnit (sorry for the rant)