06-03-2016, 01:39 AM
(06-02-2016, 12:07 PM)kefir Wrote: Isn't the only sane approach here to support wide character encodings in hashcat, all the way from character entry through to the kernels on the GPUs? I'm certainly not interested in running with ?s or ?S to try all specials in Unicode (I've not used either of those before). I'm specifying the charset with --custom-charsetX=<chars>.
That's the gist of it and you have lots of friends, me included. We know what we want but we're not quite sure what we do NOT want.
I've had ideas of making JtR 100% Unicode-aware - meaning, all representation of strings anywhere would be UTF-32 internally. But then it hit me it doesn't solve the MAIN problem at all, which is exactly the problem you raise here: Just HOW should we treat masks and stuff? That problem is not technical! We can't solve it by adding support way inside the inner workings. We need to DECIDE how things should work in practice. And I'm not anywhere near an answer.
(06-02-2016, 12:07 PM)kefir Wrote: I'm just surprised that a couple of UTF-8 encoded password like abc€ß and €bß hashed with a single sha1 seem to cause this much trouble. Or please let me know how to crack the hashes
That very problem (and many other IRL problems) is covered by my "internal codepage" strategy. As much as I hate it, I can't see a better solution that doesn't get nasty. In JtR you'd just say "-internal-codepage=cp1252" and everything would be sweet.
(06-02-2016, 12:07 PM)kefir Wrote: You mention jtr, I was hoping to have more success with that as my next attempt. I'd be happy to receive any pointers, will try to read up on charsets/utf8 in jtr today.
I spent quite a lot of time trying to add real Unicode support to Hashcat but it ended up in the bin. I think I need to coordinate with Atom and other staff. This is complex shit.
magnum