Brute-forcing fails on Windows 10 with fopen: ASCII.chr: No such file or directory

[hashimaziz1]

Firstly, thanks for your work on this amazing tool, I used it successfully with the default wordlist just a few months ago. This time I'm having an issue with a particularly tough .rar file, and I've thrown all sorts of huge wordlists at it. However when I try to enable brute-force mode by creating a zero-byte file named brute.txt, selecting it as a custom wordlist, clicking Start, and confirming again that I want to run brute force, I get the following output:

https://imgur.com/slHiYCm

Also as an aside, is there any reason you decided to make brute force behave this way instead of just adding it as another option to the JTR dropdown? It seems like that would be a lot more intuitive and less prone to error.

[illsk1lls]

That is strange as it is working on my end. And you should not be seeing an "Unsupported FILETYPE" for any type of RAR that the script supports (If you close the script with the red x on the window instead of "pressing any key to continue" it wont clean up after itself, can you post the first 20 or so chars of the first line in the file %ProgramData%\JtR\run\pwhash - i would like to make sure the hash type is recognized by the script, it should look like rar3 or rar5 surrounded by $ or something similar)

Can you try making a new dummy archive with 7z or winrar that is password protected and see if the feature works at all on your end?

The reason wordlist selection is so unintuitive, is the 8191 char limit per line for CMD scripts, I am already near the max with the main menu.

[hashimaziz1]

The reason wordlist selection is so unintuitive, is the 8191 char limit per line for CMD scripts, I am already near the max with the main menu.

That makes sense, I assumed there had to be a reason you were doing it that way, although maybe you could change Custom to Local to make it more intuitive as it took me a while to realise it was basically the local option compared to using custom wordlist links at the top of the script.

Can you try making a new dummy archive with 7z or winrar that is password protected and see if the feature works at all on your end?

My bad, I just realised my initial file that I got from the net is a .zip rather than a .rar, should that make a difference? I created another .zip and got the same error, then created a .7z and got an even worse one:

https://imgur.com/xAybOJt

So either way brute-force mode with any archive seems to fail on my system. I'm running an ancient i3-2100 with integrated graphics if that makes any difference. Also still get OPENCL UNAVAILABLE and UNSUPPORTED FILETYPE in the title and the usual error in the console itself.

Trying again with the original .zip and force-exiting before cleanup shows the following in %ProgramData%\JtR\run\pwhash:

Subs.zip:$pkzip$8*1*1*0*8*24*b892*d213da...

The .zip is just an archive of subtitles that I got from a relatively rare BluRay torrent (so finding good non-official subtitles for it will be next to impossible) and that the uploader was insane enough to put a pass on, I can send it to you if it'll help.

[illsk1lls]

ok so unsupported filetype is supposed to be there and the hash detection part isn't bugging out, which is good

Is your main system language, English?

[hashimaziz1]

Maybe I'm missing something, but isn't zip a supported filetype? It's the simplest/most ubiquitous archive type on Windows and the dialog where you select the archive lists it as the first example. Yeah, system lang is English, I have Arabic (Egypt) installed but never use it.

[illsk1lls]

pkzip is not openCL supported afaik, zip2 zip3 etc are