TS: Test more modes

[magnumripper]

We currently only test wordlist mode, without rules.

We should test variants of the wordlist mode (rules, loopback, --min/max-length, dupe suppression, --mem=1, pipe and stdin) as well as other modes (incremental, markov, mask, perhaps some external mode). These tests can be performed using just a few, or even one single format (descrypt and NT would be a good choice because they include 7-bit, Unicode and short length).

Example:

1. (on the fly) produce a dictionary using --incremental --stdout. Pick all the first 500 words and then 1000 more out of eg. 150000 (randomly distributed but using a fixed random seed - so reproducible!).
2. (on the fly) produce NT hashes from the dict
3. run JtR on the NT hashes, using --incremental
4. delete the generated files

If the above is cleverly implemented, the same function can be used with markov or other modes instead of incremental.

[frank-dittrich]

descrypt and dummy would also be a good choice:
Both are core formats, stable, well tested.
One of them is salted, the other isn't.

[magnumripper]

Actually we could be smarter than saying "500", "1500" and "150000". We could use eg. 2xMKPC, 48xMKPC and 48,000xMPKC so for NT (mkpc=32) we'd pick the first 64 words plus 1536 more, out of 1,5 million words.

This would mean we auto-adjust to eg. OpenCL formats with huge batches.

[magnumripper]

I prefer NT over dummy because it lets us verify thread-safety in Unicode functions too. But for testing core we could use dummy.

EDIT NT has its own Unicode functions... so we may want to support some other format as well.

[jfoug]

There was Inc at one time, but the char files changed. The script does an msg of the chr file and will not continue if it does not match. Since they changed the script no longer uses them.

[magnumripper]

That why I propose to create the test files on the fly. For these few formats, jtrts.dat can include the necessary functions to create the hashes. There's no point in testing incremental with all 300 formats. It would just take a lot of time.

[jfoug]

But if the process being tested is producing the test cases, does that not scream invalid?

[magnumripper]

That's true, in many cases. I was mostly thinking about fork/mpi/node tests. The test file should be produced with neither of those options. We'd also test many things in cracker.c and loader.c that is not really used in the --inc --stdout that produces the files. BTW we could also test --resume this way (perhaps starting with --max-runtime).

But yes, maybe we should keep the thing you have in there, but update it with 1.8.0 incremental too.

[magnumripper]

#56 added resume tests, which includes basic mode tests.