hashcat Forum

I'm wanting to utilize my GPU with hashcat to crack some hashes that are a variation of lookup2/lookup8/Jenkins(not quite sure if the name, it was the version by Bob Jenkins prior to SpookyHash). I've got this working in Rust and I think I've ported it correctly to OpenCL, I'm having trouble setting up the rest for Hashcat though..

I've referenced the RAR5 implementation and browsed other algorithms to try make sense of what's going on. My ported code aside, I can provide a hash and hardcode a match against it in the CL file for COMPARE_M. It's a 64-bit value that I split into two u32 in parse_hash function and for the compare method.

What I'm not sure about is how to work on the input from the dictionary, I see pws[gid].pw_len; and pws[gid].i[0]; used in other files assuming that's it? I've got an nvidia GPU so the other thread that mentions enabling printf() doesn't appear to work which leaves me with a blackbox for what's going on in this file. If one of the dictionary values was "hello world" would pws[gid].i[0] reference "h" as 0x68?

I've noticed some weird results in trial and error testing where some caching might be involved, how can I avoid the caching? I am using the current command: hashcat -a 0 -m 99000 'f5023ded0a75ed99' test_pd2.dict --potfile-disable
. The hash example "f5023ded0a75ed99" is "hello" in plain text,

As the algorithm is a variation it's rather specific to the hashes used by the game Payday 2. It might not be of use to the community but I'd be happy to contribute documentation from my learning notes/experience to help others implementing algorithms in future. I believe this is the last hurdle for me to sort out to get the algorithm working.

Still having trouble figuring this out. If my results say the digest is 100% recovered but status is "Exhausted" instead of "Cracked" when testing with hardcoded compare values to match the ones stored in the digest in the parse_hash function, what change is missing to cause this difference? The hash is listed but with no key matched to it, I was thinking that the first attempted key would have been paired but perhaps this is matching with the compare before the first key(hello) is checked.

Could anyone spare some time to show a very basic .cl file for a simple hash algo like FNV-1a 32-bit? Here is the Rust equivalent that you could run in Rust REPL in the browser:




That outputs a hash of "4f9f2cab" for "hello".

> pws[gid].i[0]

No, "i" is an array of u32 values. As most hashes are processed as 32 bit integers (not 8 bit chars) it faster this way. You just have to make sure to handle the endianess of the algorithm correctly. From what I can see from the above code it's simply little endian. Also note that you have 4 chars per 32 bit integer not 1. Means i[0] has chars 0, 1, 2 and 3 of the password.

> If my results say the digest is 100% recovered but status is "Exhausted" instead of "Cracked"

It should automatically do that. If not you do not have all the loaded hashes cracked. Maybe you marked the hash as NEVER_CRACK ?

(10-06-2016, 05:45 PM)atom Wrote: [ -> ]> pws[gid].i[0]

No, "i" is an array of u32 values. As most hashes are processed as 32 bit integers (not 8 bit chars) it faster this way. You just have to make sure to handle the endianess of the algorithm correctly. From what I can see from the above code it's simply little endian. Also note that you have 4 chars per 32 bit integer not 1. Means i[0] has chars 0, 1, 2 and 3 of the password.

Thanks for that, I was under the impression of single characters being converted to u32 not them being packed per index value. So with the string "hello" as the password, I'd get the first 4 characters/bytes right? {0x68, 0x65, 0x6c, 0x6c} or the other way around 6c 6c 65 68?

> It should automatically do that. If not you do not have all the loaded hashes cracked. Maybe you marked the hash as NEVER_CRACK ?

I had "hello" in the dictionary file and was matching against it's hash as shown in the provided command line. I've implemented the new algorithm based on the RAR5 commit(with updated paths since code/files moved), made some tweaks such as min/max len and hashconfig, etc. I was modifying the RAR5 m13000.cl file but have since changed to m00200_a0.cl for reference instead, my tweaks are very similar or identical to it. Tested with "hello" and "70de51425df9d787"(MySQL323 / 200) hash and it reports cracked, tweaked the copy/pasted m00200_a0.cl with one change:

Code:

COMPARE_S_SIMD (0x70de5142, 0x5df9d787, z, z);

Run:  hashcat -a 0 -m 99000 '70de51425df9d787' test_pd2.dict --potfile-disable

Output:



Recovered at 100% suggests the hardcoded compare values matching the hash matched it as expected, but instead of a Cracked status it says Exhausted and the hash is provided above with no matched key? Without the hardcoded change it will hash "hello" into the MySQL323 hash split into a,b for the compare and report it as Cracked with the hash paired with key "hello"..

I'm closing this to avoid confusion. Discussion was continued here: https://github.com/hashcat/hashcat/issues/524