When I got a new MacBook with an M1 Pro chip, I was excited to see the performance benefits. The first thing I did was to fire up hashcat which gave an impressive benchmark speed for NT hashes (mode 1000) of around 9 GH/s, a solid doubling of the benchmark speed of my old Intel MacBook Pro. But, when it came to actually cracking things, the speed dropped off considerably. Instead of figuring out why, I decided to try my hand at writing my own NT hash cracker, because I’m kind of addicted to writing single use tooling in rust then taking time to perf optimise it.
This is an update on this previous post on foreign NT hashes where I got things a little wrong by believing the source encoding matters for an NT hash. It doesn’t really, let me show you why.
I spent a bit of time exploring further, in particular, I took it down to a test case. Jameel gave me his name as a password in Arabic:
Included as a picture because WordPress is messing with my UTF8.
“echo d8acd985d98ad9842031|xxd -ps -r” can give it to you straight That’s Jameel1 in Arabic. It’s encoded in UTF8 in most places, whose bytes are:
If you’ve ever cracked a hash with hashcat, you’ll know that sometimes it will give you a $HEX[0011223344] style clear. This is done to preserve the raw byte value of the clear when the encoding isn’t known (or there’s a colon “:” character).
Investigation Driven by an inability to crack the majority of a certain set of hashes I suspected were in a foreign charset, I decided to have a closer look at what was going on. Let’s take a look at the following examples:
This was an epic week for password cracking, we had lots of new hashes and lots of competition to see who could crack the most the fastest.
BLUF: I put together a cracking technique, and tested it against other techniques, generating some insight into the best performing cracking techniques. Rockyou with hob064 rules won, but my technique came a close second, and had a faster crack speed. Get the script here.