My graphics card cannot be detected on the Intel ARC platform and cannot be cracked using GPU acceleration about john HOT 11 CLOSED

Hi. We've probably already fixed this issue, please try with our latest Windows build available from here: https://github.com/openwall/john-packages/releases/tag/jumbo-dev (also linked from the "Download Windows Build" badge in the README.md in this repo). Please let us know of your results.

Unfortunately, the 1.9.0-jumbo-1 release that you reported this issue against is rather old, and in general we expect GitHub issues to be used for latest code that we actually have here on GitHub. Thank you!

Separately:

if the hash is too long, Hashcat will truncate and reject it.

This sounds confused. If the hash is too long, then perhaps it's simply not a valid hash, and should in fact be rejected. Or did you mean candidate password rather than hash?

from john.

Hello, thank you very much. Following your instructions, it can now function normally.

Separately:

if the hash is too long, Hashcat will truncate and reject it.

This sounds confused. If the hash is too long, then perhaps it's simply not a valid hash, and should in fact be rejected. Or did you mean candidate password rather than hash?

For this reason, it is another open-source cracking software Hashcat, which I have previously attempted to use for cracking. But the target compressed file that I want to crack has a capacity of 6GB, so the hash value file calculated through rar2John. exe reaches 42.8MB, which is too long. I asked the open-source community and they said that Hashcat is currently unable to handle it, and Hashcat will truncate excessively long hashes.
Thank you again! Here is a screenshot of how I successfully cracked it according to your instructions:

from john.

Thank you. This explains it, and great to know things appear to work now.

@simplete Since we don't have a card like yours, we'd be interested in test results for it. Would you be able to run (on an idle system, not concurrently with your RAR cracking) this command: john --test --format=opencl > log.txt and send us log.txt? This may take a long while to complete. You can interrupt and then john --restore your RAR cracking.

Does anyone else reading this know of an equivalent to tee -a that would work on Windows out of the box? @alainesp maybe? Also, @alainesp it looks like your recent OpenCL DLL loading changes helped here - thank you!

from john.

@simplete Since we don't have a card like yours, we'd be interested in test results for it. Would you be able to run (on an idle system, not concurrently with your RAR cracking) this command: john --test --format=opencl > log.txt and send us log.txt? This may take a long while to complete. You can interrupt and then john --restore your RAR cracking.

Sorry, I don't have any other available idle systems here. I ran this command on Windows 11. The following is a screenshot of the run and the log file:




log.txt

from john.

Thank you very much!

Sorry, I don't have any other available idle systems here.

I meant that you would temporarily stop the attack on your 11.txt (which would make this system idle), then run this test, then continue the attack with john --restore. Is this what you did? Or did you run this test while also cracking 11.txt at the same time?

In the log, there are 74 successful tests, but also 7 failing ones. And this ends in a fatal failure for solarwinds-opencl, which may be because of issues with solarwinds-opencl or it may be memory leaks accumulated from previous tests. To find this out, can you please run john --test --format=solarwinds-opencl?

For others reading this:

$ tr -d '\0' < log.txt | grep -ac DONE
74
$ tr -d '\0' < log.txt | grep -a FAILED
Benchmarking: argon2-opencl [Blake2 OpenCL]... FAILED (cmp_one(2))
Benchmarking: sha512crypt-opencl, crypt(3) $6$ (rounds=5000) [SHA512 OpenCL]... FAILED (cmp_all(1))
Benchmarking: ethereum-opencl, Ethereum Wallet [PBKDF2-SHA256 Keccak OpenCL]... FAILED (cmp_all(1))
Benchmarking: ethereum-presale-opencl, Ethereum Presale Wallet [PBKDF2-SHA256 AES Keccak OpenCL]... FAILED (cmp_all(1))
Benchmarking: geli-opencl, FreeBSD GELI [PBKDF2-SHA512 AES OpenCL]... FAILED (cmp_all(1))
Benchmarking: mscash2-opencl, MS Cache Hash 2 (DCC2) [PBKDF2-SHA1 OpenCL]... FAILED (cmp_all(1))
Benchmarking: pgpdisk-opencl, PGP Disk / Virtual Disk [SHA1 AES/TwoFish/CAST OpenCL]... FAILED (cmp_all(1))

For argon2-opencl, it failing at cmp_one(2) suggests that Argon2d works (would be index 1), but Argon2i fails.

from john.

Using PowerShell

#Using the alias
run\john --test --format=sha*crypt-opencl | tee 1.txt

#Using the cmdlet
run\john --test --format=sha*crypt-opencl | Tee-Object -FilePath 2.txt

/windows/02Jan$ ls -l *.txt
-rwxrwxrwx 1 root root 1056 jan 19 09:43 1.txt
-rwxrwxrwx 1 root root 1006 jan 19 09:46 2.txt

$ file *.txt
1.txt: Unicode text, UTF-16, little-endian text, with CRLF line terminators
2.txt: Unicode text, UTF-16, little-endian text, with CRLF line terminators

from john.

Thanks @claudioandre-br! Why is the second file smaller? Does this also capture stderr (I guess not) and do you know a way to do so (like 2>&1 we'd use in a Unix shell)?

Separately, we might want to reconsider printing some stuff to stderr (just have it go to stdout along with everything else). The way we split what goes to stdout vs. stderr now feels more annoying and arbitrary than useful and expected.

from john.

Why is the second file smaller?

Part of the output is missing (was lost).

diff -a 1.txt 2.txt

< Raw:	10032 c/s real, 326808 c/s virtual
---
> Raw:	8328 c/s
[...]

I'll re-check it later.

from john.

@claudioandre-br Oh, we don't print c/s virtual if the virtual time appears to be 0. This can happen, and is fine, since we can in fact use very little CPU time when running almost entirely on an OpenCL device.

from john.

I meant that you would temporarily stop the attack on your 11.txt (which would make this system idle), then run this test, then continue the attack with john --restore. Is this what you did? Or did you run this test while also cracking 11.txt at the same time?

@solardiz Sorry, there is an issue with my understanding. There were no other applications occupying the GPU while running this test.

In the log, there are 74 successful tests, but also 7 failing ones. And this ends in a fatal failure for solarwinds-opencl, which may be because of issues with solarwinds-opencl or it may be memory leaks accumulated from previous tests. To find this out, can you please run john --test --format=solarwinds-opencl?

The following is the result of running 'John -- test -- format=solarwinds opencl >log_solarwinds-opencl.txt':

log_solarwinds-opencl.txt

from john.

@simplete OK, thank you very much! Now we have a better understanding of how JtR behaves on this sort of card.

from john.