Strange data in input of .cl program

[tylers1121]

Some time ago I had posted this request. And since noone had added that hashmode I decided to write module (for Early Murmurhash  that is used in one game) on my own. Also I decided to add module for another algorithm (for modified FNV-1a 64 bit which is used in that one game too). Both modules worked fine on my previous system (Win 10 Build 17763.1911) but on current one (Win 10 Build 19042.928) both don't work. Only thing that I had done is rebasing local git to the latest commit on GitHub and building it. I also cleaned kernel folder before each run as developement guide suggests. I've tried to reinstall drivers but that doesn't help. Problem is still here. But for other algos that are in repo at this moment all goes fine in mode -a 3. Currently I'm developing only -a 3 mode for both modules since that's the only thing that I was interested to do. I can't go back to previous install because I've reinstalled system from USB drive without saving previous information. Also I can't test this on another PC since it's the only PC I have.

I was trying to run hashcat like this
hashcat -b -m 26800 >> log_26800.txt
It prints data in log file in loop. And data is kinda weird. First pass or first two passes (which is or which are self test) are working normal, but after data starts to be kinda weird.

Source files as well as log
early_murmurhash_modified.zip
fnv1a64_modified.zip

[philsmd]

hmm, I didn't test it yet fully, but I normally don't use %s prints in kernel files.

I would rather print it in hex:

Code:

printf ("%08x %08x%08x%08x%08x %d\n", hash, w[0], w[1], w[2], w[3], pw_len);

In this case it could also be the problem with u32x vs u32 , but if you say it worked before, its' very unlikely the main problem.

how do you test it, are these the only parameters you use ?

I would recommend to use some command line options (also mentioned in the guide) like this:

Code:

-a 3 -n 1 -u 1 -T 1 --self-test-disable --backend-vector-width 1 --force hash.txt testmask

at least this way you restrict the kernel power and the amount of password candidates that are being tested (always better to start small and in a step-by-step approach when still developing the kernel).

Test it like this and if you still have some doubts, feel free to ask (and yeah, some devs here including me can also have a closer look at the source code if you still have problems with this new test).