TS hiding a bug? about john-tests HOT 9 CLOSED

Use -v (or -v -v or even more) to see what really happens. I bet it actually runs the CPU format, for some reason. Or perhaps the OpenCL format but the CPU device?

I thought it would be the "force format" column being set to N, but it's not:

(opencl)(gpu)(sha)(sha2),(X),(jumbo)&(opencl),40,sha512crypt-opencl,pw,SHA512crypt_tst.in,sha512crypt-opencl,Y,X,(1389)(1500),(1389)(1500)

from john-tests.

Doesn't happen here (although it's the same situation):

$ ../run/john -ses=./tst -pot=./tst.pot SHA512crypt_tst.in --wordlist=pw.dic -form=sha512crypt-opencl -dev=2
Device 2: GeForce GT 650M
Building the kernel, this could take a while
Build log: Error getting function data from server
Error -11 building kernel $JOHN/kernels/cryptsha512_kernel_GPU.cl. DEVICE_INFO=130
OpenCL error (CL_BUILD_PROGRAM_FAILURE) in file (common-opencl.c) at line (765) - (clBuildProgram failed.)

$ ./jtrts.pl -noprelims -stoponerror -type sha512crypt-opencl -pass=-dev=2
-------------------------------------------------------------------------------
- JtR-TestSuite (jtrts). Version 1.12.16, Sept 24, 2014.  By, Jim Fougeron & others
- Testing:  John the Ripper password cracker, version 1.8.0.2-bleeding-jumbo_omp [darwin13.4.0 64-bit AVX-autoconf]
--------------------------------------------------------------------------------

John Jumbo build detected.

form=sha512crypt-opencl           guesses:    0 -show=   0 unk unk : Expected count(s) (1389)(1500)  [!!!FAILED!!!]
Exiting on error.  The pot file ./tst.pot contains the found data
The command used to run this test was:

../run/john -ses=./tst -dev=2  -pot=./tst.pot SHA512crypt_tst.in --wordlist=pw-40.dic -form=sha512crypt-opencl

from john-tests.

I guess pw-40.dic (the file created by TS during run time) is not equal to pw.dic (a base file, the file that exists now).

• I noticed (now) that TS 'warned' GTX 570 as the device. So it has to be using the right device.
• It is memory related. It simply doesn't happen in any hardware/software (now I know where the 'bug' is. Not sure yet if it is a real bug).

I have the output of TestSuite (-v -v), in case you guys would like to see it.

Command executed by TS (wordlist files differ).

../run/john -ses=./tst -pot=./tst.pot SHA512crypt_tst.in --wordlist=pw-40.dic -form=sha512crypt-opencl 2>&1 >/dev/null

Me

../run/john -ses=./tst -pot=./tst.pot SHA512crypt_tst.in --wordlist=pw.dic -form=sha512crypt-opencl 2>&1 >/dev/null

from john-tests.

pw-40.dic is simply the first 40 lines of pw.dic.

So problems could be:

1. longer passwords deeper in the pw.dic file
2. many more input words in the pw.dic file
3. some other issue.

I have not looked 'into' this. I am simply following along reading this thread. I would be pretty surprised if the input file caused a format to fail like this, but it looks like that may be happening.

Can you try this (from command line)

head -40 pw.dic > pw-40.dic
../run/john -ses=./tst -pot=./tst.pot SHA512crypt_tst.in --wordlist=pw-40.dic -form=sha512crypt-opencl

and see if that works. If so, then this is obviously due (some how) to the larger pw.dic file.

from john-tests.

It works.

from john-tests.

and using -w=pw.dic fails? If so then there is something (size or length of some line), that is killing this (IMHO).

from john-tests.

It is working now. As I wrote above I saw (at that point) where the failing is happening.
This issue have to be closed as invalid noise.

Any possibility to run TS with more than head -40 ? To stress JtR a little bit more?

from john-tests.

The 40 was added to keep the run from taking forever.

If you want to do more for the opencl format, then create another input file (using more passwords), or tell me how many you want to use. I think for this format, I also used a small number of salts.

Anything can certainly be done. However, for someone that uses the TS a lot, having it take 30 minutes (or several hours) to run is not something I relish. If however we want to make some 'deeper' tests, we certainly can (keeping the faster ones there also). We would need new input files, and then add new lines into the jtrts.dat file to use them, BUT on these lines add the 'full' item (field 2 I think), so that these formats would NOT be run by default, only if the format itself is requested.

This request might not be a bad one for the slower formats, where I have really trimmed them down to get them to be tested on a default run. .....

from john-tests.

If possible, it is going to be a nice thing. TS failed to detect a real "blind programmer bug" here.

from john-tests.