Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 7 Jan 2020 17:27:17 +0100
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: opencl not finds the password. In CPU it founds.

Hi Ricardo,

On Sun, Jan 05, 2020 at 05:04:34PM -0300, Ricardo CYRYLZ MIESZKO wrote:
> When I use john with wordlist and --format=dmg-opencl or
> --format=7z-opencl it can't find the password. If I use without the opencl
> it finds.

That's bad, indeed.

> I noted that error and I can't find a solution fot that: "Error creating
> binary cache file: No such file or directory"
> 
> Much probably the binary creation error is the problem. How to solve it ?
> I can't even find this error message in the John sources. That's weird. It
> comes from some dependency maybe ?
> 
> I'm running on macOS Catalina, but the problem occurs in older macOS too.

Claudio has addressed that aspect here:

https://www.openwall.com/lists/john-users/2020/01/07/3

No, this non-working caching shouldn't be the cause of the main problem,
where JtR doesn't find the password.

> Device 3: AMD Radeon Pro 560X Compute Engine

Unfortunately, AMD GPU drivers / OpenCL backend tend to be really buggy,
especially on macOS.  On Linux, we're usually able to get most formats
to work on AMD GPUs, but some still fail.  When they fail, they usually
fail self-test, and then the attack doesn't proceed.  In your case, the
attack proceeds, so the self-test must have passed.  That's weird.  It
can be one (or more) of four things:

1. AMD GPU driver / OpenCL backend bug that somehow evaded detection on
self-test, but manifested itself in real cracking.

2. A JtR bug that somehow evaded detection on self-test, but manifested
itself in real cracking.

3. A difference in supported sub-types of these "hashes" between our CPU
and OpenCL formats, or in other words a lack of support for a sub-type
specifically in the OpenCL format.  This would also be a JtR bug in that
we should detect such unsupported "hashes" and refuse to run, rather
than run and fail to crack anything.

4. The password being so long that the difference in maximum supported
password lengths comes into play.  How many characters and bytes is it?

> 0:00:00:00 - Hash type: 7z-opencl, 7-Zip (min-len 0, max-len 23)
> 0:00:00:00 - Algorithm: SHA256 AES OpenCL
> 0:00:00:00 - Will reject candidates longer than 69 bytes

> Loaded 1 password hash (7z-opencl, 7-Zip [SHA256 AES OpenCL])
> Cost 1 (iteration count) is 524288 for all loaded hashes
> Cost 2 (padding size) is 7 for all loaded hashes
> Cost 3 (compression type) is 1 for all loaded hashes

> 0g 0:00:01:11 DONE (2020-01-05 15:51) 0g/s 652.8p/s 652.8c/s 652.8C/s

vs.

> 0:00:00:00 - Will reject candidates longer than 84 bytes

> Loaded 1 password hash (7z, 7-Zip [SHA256 128/128 SSE4.1 4x AES])
> Cost 1 (iteration count) is 524288 for all loaded hashes
> Cost 2 (padding size) is 7 for all loaded hashes
> Cost 3 (compression type) is 1 for all loaded hashes

> 1g 0:00:05:56 DONE (2020-01-05 17:01) 0.002804g/s 8.481p/s 8.481c/s
> 8.481C/s [****REMOVED]

The above excerpts are for 7z.  You say the problem also occurs for dmg.
Can you tell us how long the dmg password is as well?

Alexander

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.