john
john copied to clipboard
openwall
7z-opencl false positives
When I run john --devices=1,2,3,4 --format=7z-opencl --wordlist=output.txt --fork=4 a.7z.hash it gives the following output:
Using default input encoding: UTF-8
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 10 for all loaded hashes
Cost 3 (compression type) is 128 for all loaded hashes
Will run 32 OpenMP threads per process (128 total across 4 processes)
Node numbers 1-4 of 4 (fork)
Device 2: NVIDIA RTX A5000
Device 1: NVIDIA RTX A5000
Device 4: NVIDIA RTX A5000
Device 3: NVIDIA RTX A5000
Press 'q' or Ctrl-C to abort, almost any other key for status
aaa127aa8g (a.7z)
3 1g 0:00:00:01 DONE (2023-01-22 19:59) 0.6329g/s 20739p/s 20739c/s 20739C/s aaa127aa8g..aai278cb1g
aaa128aa7g (a.7z)
4 1g 0:00:00:01 DONE (2023-01-22 19:59) 0.6250g/s 20480p/s 20480c/s 20480C/s aaa128aa7g..aai872cb1g
aaa217aa8g (a.7z)
1 1g 0:00:00:01 DONE (2023-01-22 19:59) 0.6211g/s 20352p/s 20352c/s 20352C/s aaa217aa8g..aai718cb2g
Waiting for 3 children to terminate
aaa721aa8g (a.7z)
2 1g 0:00:00:01 DONE (2023-01-22 19:59) 0.6211g/s 20352p/s 20352c/s 20352C/s aaa721aa8g..aai281cb7g
Use the "--show" option to display all of the cracked passwords reliably
Session completed
It shouldn't be like that. Here's the OpenCL devices list:
# john --list=opencl-devices
Platform #0 name: NVIDIA CUDA, version: OpenCL 3.0 CUDA 12.0.89
Device #0 (1) name: NVIDIA RTX A5000
Device vendor: NVIDIA Corporation
Device type: GPU (LE)
Device version: OpenCL 3.0 CUDA
Driver version: 525.60.13 [recommended]
Native vector widths: char 1, short 1, int 1, long 1
Preferred vector width: char 1, short 1, int 1, long 1
Global Memory: 24247 MB
Global Memory Cache: 1792 KB
Local Memory: 48 KB (Local)
Constant Buffer size: 64 KB
Max memory alloc. size: 6061 MB
Max clock (MHz): 1695
Profiling timer res.: 1000 ns
Max Work Group Size: 1024
Parallel compute cores: 64
CUDA cores: 4096 (64 x 64)
Speed index: 6942720
Warp size: 32
Max. GPRs/work-group: 65536
Compute capability: 8.6 (sm_86)
Kernel exec. timeout: no
PCI device topology: 25:00.0
Device #1 (2) name: NVIDIA RTX A5000
Device vendor: NVIDIA Corporation
Device type: GPU (LE)
Device version: OpenCL 3.0 CUDA
Driver version: 525.60.13 [recommended]
Native vector widths: char 1, short 1, int 1, long 1
Preferred vector width: char 1, short 1, int 1, long 1
Global Memory: 24247 MB
Global Memory Cache: 1792 KB
Local Memory: 48 KB (Local)
Constant Buffer size: 64 KB
Max memory alloc. size: 6061 MB
Max clock (MHz): 1695
Profiling timer res.: 1000 ns
Max Work Group Size: 1024
Parallel compute cores: 64
CUDA cores: 4096 (64 x 64)
Speed index: 6942720
Warp size: 32
Max. GPRs/work-group: 65536
Compute capability: 8.6 (sm_86)
Kernel exec. timeout: no
PCI device topology: 41:00.0
Device #2 (3) name: NVIDIA RTX A5000
Device vendor: NVIDIA Corporation
Device type: GPU (LE)
Device version: OpenCL 3.0 CUDA
Driver version: 525.60.13 [recommended]
Native vector widths: char 1, short 1, int 1, long 1
Preferred vector width: char 1, short 1, int 1, long 1
Global Memory: 24247 MB
Global Memory Cache: 1792 KB
Local Memory: 48 KB (Local)
Constant Buffer size: 64 KB
Max memory alloc. size: 6061 MB
Max clock (MHz): 1695
Profiling timer res.: 1000 ns
Max Work Group Size: 1024
Parallel compute cores: 64
CUDA cores: 4096 (64 x 64)
Speed index: 6942720
Warp size: 32
Max. GPRs/work-group: 65536
Compute capability: 8.6 (sm_86)
Kernel exec. timeout: no
PCI device topology: 61:00.0
Device #3 (4) name: NVIDIA RTX A5000
Device vendor: NVIDIA Corporation
Device type: GPU (LE)
Device version: OpenCL 3.0 CUDA
Driver version: 525.60.13 [recommended]
Native vector widths: char 1, short 1, int 1, long 1
Preferred vector width: char 1, short 1, int 1, long 1
Global Memory: 24247 MB
Global Memory Cache: 1792 KB
Local Memory: 48 KB (Local)
Constant Buffer size: 64 KB
Max memory alloc. size: 6061 MB
Max clock (MHz): 1695
Profiling timer res.: 1000 ns
Max Work Group Size: 1024
Parallel compute cores: 64
CUDA cores: 4096 (64 x 64)
Speed index: 6942720
Warp size: 32
Max. GPRs/work-group: 65536
Compute capability: 8.6 (sm_86)
Kernel exec. timeout: no
PCI device topology: 81:00.0
I guess there's something wrong with the 7z-opencl adapter..? Please reply soon, thanks.
a.7z.hash:
a.7z:$7z$128$19$0$$16$db981981ae5872fded67a023d9bd748f$1027129121$16$6$e253eaa33495cf96882591f554d61d4c
@fred913 I think this is a fine bug report to have in here - you just need to provide more info, and we need to see if the issue is still present in our latest code in this repo or not.
What version of JtR are you using? Please provide the output of john --list=build-info, and also please retest using the latest code from this repo.
As I can see, the issue is that you got 4 different passwords cracked for the same input file, and presumably these are all false positives. I just went through the git commits log since our previous release 1.9.0-jumbo-1 and I don't see us knowingly fix any 7z false positive issue (we did fix some that could produce false negatives). Yet I am not able to reproduce the issue using our latest code - when I put the 4 passwords you got cracked into a wordlist file, 7z-opencl did not crack any against your hash. Maybe other content of your output.txt matters - would you be able to share this entire file, or produce a minimized test case that you'd be able to share?
I see you also posted this to john-users, but the message in the moderation queue to there is misformatted and isn't exactly a user discussion - if it's a bug in some older version (which would kind of make the message suitable for there rather than here), at best we'd only be able to acknowledge that - we're not going to fix a bug in an old version. So let's continue here and focus on our latest code from this repo. Thanks.
@fred913 can you reproduce using something like this? (Without fork and/or using the cpu format).
$ john --format=7z-opencl -mask=aaa127aa8g a.7z.hash
Or
$ john --format=7z-opencl --wordlist=output.txt a.7z.hash
Or
$ john --format=7z --wordlist=output.txt a.7z.hash
john --format=7z-opencl -mask=aaa127aa8g a.7z.hash
@claudioandre-br Sure! It gives me the following output:
# john --format=7z-opencl -mask=aaa127aa8g a.7z.hash
Device 1: NVIDIA GeForce RTX 3090
Using default input encoding: UTF-8
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 10 for all loaded hashes
Cost 3 (compression type) is 128 for all loaded hashes
Will run 40 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
Warning: Only 1 candidate left, minimum 20992 needed for performance.
aaa127aa8g (a.7z)
1g 0:00:00:00 2.941g/s 2.941p/s 2.941c/s 2.941C/s aaa127aa8g
Use the "--show" option to display all of the cracked passwords reliably
Session completed
As for the CPU format:
# john --format=7z -mask=aaa127aa8g a.7z.hash
Using default input encoding: UTF-8
Loaded 1 password hash (7z, 7-Zip [SHA256 512/512 AVX512BW 16x AES])
Cost 1 (iteration count) is 524288 for all loaded hashes
Cost 2 (padding size) is 10 for all loaded hashes
Cost 3 (compression type) is 128 for all loaded hashes
Will run 40 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
Warning: Only 1 candidate left, minimum 640 needed for performance.
0g 0:00:00:00 0g/s 1.587p/s 1.587c/s 1.587C/s aaa127aa8g
Session completed
Also the format with OpenCL support, with only one password given:
# john --format=7z-opencl -mask=aaa127aa8g a.7z.hash
Device 1: NVIDIA GeForce RTX 3090
Using default input encoding: UTF-8
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 10 for all loaded hashes
Cost 3 (compression type) is 128 for all loaded hashes
Will run 40 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
Warning: Only 1 candidate left, minimum 20992 needed for performance.
aaa127aa8g (a.7z)
1g 0:00:00:00 2.941g/s 2.941p/s 2.941c/s 2.941C/s aaa127aa8g
Use the "--show" option to display all of the cracked passwords reliably
Session completed
As you see the problem is still.
@solardiz
Here's some of my system information:
john
# john --help
John the Ripper 1.9.0-jumbo-1 OMP [linux-gnu 64-bit x86_64 AVX512BW AC]
Copyright (c) 1996-2019 by Solar Designer and others
Homepage: http://www.openwall.com/john/
nvidia-smi
# nvidia-smi
Mon Jan 23 10:52:41 2023
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 525.60.11 Driver Version: 525.60.11 CUDA Version: 12.0 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 NVIDIA GeForce ... On | 00000000:3D:00.0 Off | N/A |
| 30% 28C P8 21W / 350W | 0MiB / 24576MiB | 0% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
| 1 NVIDIA GeForce ... On | 00000000:40:00.0 Off | N/A |
| 30% 26C P8 22W / 350W | 0MiB / 24576MiB | 0% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
| 2 NVIDIA GeForce ... On | 00000000:41:00.0 Off | N/A |
| 30% 30C P8 24W / 350W | 0MiB / 24576MiB | 0% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
| 3 NVIDIA GeForce ... On | 00000000:B1:00.0 Off | N/A |
| 30% 24C P8 17W / 350W | 0MiB / 24576MiB | 0% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
| 4 NVIDIA GeForce ... On | 00000000:B2:00.0 Off | N/A |
| 30% 26C P8 21W / 350W | 0MiB / 24576MiB | 0% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
| 5 NVIDIA GeForce ... On | 00000000:B4:00.0 Off | N/A |
| 30% 27C P8 16W / 350W | 0MiB / 24576MiB | 0% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
| 6 NVIDIA GeForce ... On | 00000000:B5:00.0 Off | N/A |
| 30% 27C P8 19W / 350W | 0MiB / 24576MiB | 0% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
By the way, you may notice that the machine has changed from 4xA5000 to 7xRTX3090. Actually I also tried it on an NVIDIA A40 of mine but none of them worked with JtR. I actually don't know why.
As for the output.txt, I'm afraid it's hard to share it as it is 3GB big (it shows that it's gonna take me 5 hours to upload it onto my Google Drive). Here's a piece of Python script how you can generate a same one:
# pip install tqdm
import itertools
import string
from tqdm import tqdm
password_dict_file = open("./output.txt", "w")
# aaaaa1111a
total = (26**5) * (24) * 1
bar = tqdm(total=total, unit="passes")
for first_5 in itertools.product(string.ascii_lowercase, repeat=5):
# 1 2 7 8
for mid_4_num in [
'2178', '7218', '1278', '1287', '7182', '2817', '2781', '8721',
'1827', '8712', '8172', '8127', '1728', '7812', '8217', '1782',
'2871', '7281', '1872', '2718', '8271', '7128', '7821', '2187'
]:
# llldddlldl
curr = "".join(first_5) + "".join(mid_4_num) + "g"
curr_2 = curr[0:3] + curr[5:8] + curr[3:5] + curr[8:10]
password_dict_file.write(curr_2 + "\n")
bar.update(1)
password_dict_file.close()
It just takes 1 minute to generate one, if you use pypy (v3.9).
But as for reproducing the situation, it's also a good idea to try with a tiny wordlist:
# head -n10 output.txt
aaa217aa8g
aaa721aa8g
aaa127aa8g
aaa128aa7g
aaa718aa2g
aaa281aa7g
aaa278aa1g
aaa872aa1g
aaa182aa7g
aaa871aa2g
I'm pretty sorry for the mistake to post a misformatted mail in the maillist. But I'm actually sure that my machine is running a latest version of JtR. If you wish to help more detailed help, I may also try to share the SSH login information to you (in somewhere secret). Thanks!
Another thing is that, I'm running john using a shell alias. Here's one of the lines in my bashrc profile:
alias john="/root/autodl-tmp/john-1.9.0-jumbo-1/run/john"
But...everything changed after recompiling using the latest code, instead of the latest release.
# john-latest --devices=1,2,3,4,5,6,7 --format=7z-opencl --wordlist=output.txt --fork=7 a.7z.hash
Using default input encoding: UTF-8
Loaded 1 password hash (7z-opencl, 7-Zip archive encryption [SHA256 AES OpenCL])
Cost 1 (iteration count) is 524288 for all loaded hashes
Cost 2 (padding size) is 10 for all loaded hashes
Cost 3 (compression type) is 128 for all loaded hashes
Cost 4 (data length) is 6 for all loaded hashes
Will run 5 OpenMP threads per process (35 total across 7 processes)
Node numbers 1-7 of 7 (fork)
Device 2: NVIDIA GeForce RTX 3090
Device 1: NVIDIA GeForce RTX 3090
Device 6: NVIDIA GeForce RTX 3090
Device 3: NVIDIA GeForce RTX 3090
Device 4: NVIDIA GeForce RTX 3090
Device 5: NVIDIA GeForce RTX 3090
Device 7: NVIDIA GeForce RTX 3090
2: LWS=32 GWS=41984 (1312 blocks)
1: LWS=32 GWS=41984 (1312 blocks)
Press 'q' or Ctrl-C to abort, 'h' for help, almost any other key for status
5: LWS=32 GWS=20992 (656 blocks)
4: LWS=32 GWS=41984 (1312 blocks)
6: LWS=32 GWS=41984 (1312 blocks)
7: LWS=32 GWS=20992 (656 blocks)
3: LWS=32 GWS=41984 (1312 blocks)
6 0g 0:00:00:06 0.52% (ETA: 11:56:28) 0g/s 24059p/s 24059c/s 24059C/s acu781lx2g..adm821ow7g
5 0g 0:00:00:06 0.46% (ETA: 11:58:37) 0g/s 24025p/s 24025c/s 24025C/s acu172lx8g..add712nj8g
7 0g 0:00:00:06 0.46% (ETA: 11:58:37) 0g/s 24163p/s 24163c/s 24163C/s acu821lx7g..add218nj7g
3 0g 0:00:00:06 0.52% (ETA: 11:56:28) 0g/s 24198p/s 24198c/s 24198C/s acu817lx2g..adm812ow7g
1 0g 0:00:00:07 0.52% (ETA: 11:59:41) 0g/s 23990p/s 23990c/s 23990C/s acu182lx7g..adm871ow2g
2 0g 0:00:00:07 0.52% (ETA: 11:59:41) 0g/s 23854p/s 23854c/s 23854C/s acu871lx2g..adm817ow2g
It works then! john-latest is a shell alias of the john binary I compiled using the latest code commit.
It works then!
So, the latest source code (bleeding) works as expected. This is good news. Please continue using the "john-latest" version (latest code from this repository).
Thanks for reporting.
We'll probably keep this open for a while to think about what happened.
I don't see us knowingly fix any 7z false positive (OpenCL) issue
If there's anything I can help like reproducing the problem, please tell me so that I can try my best to help.
[edited
If you have free time please try to find out what fixed the bug:
I would try these first: https://github.com/openwall/john/commit/c6601b13a373af4955ff1bcbd428eaf6f557fc8e https://github.com/openwall/john/commit/c10ade989e1d69753ec50ea117e0ee7b45d218b7
But you can find more candidates here: https://github.com/openwall/john/commits/bleeding-jumbo/src/opencl_7z_fmt_plug.c https://github.com/openwall/john/commits/bleeding-jumbo/src/7z_common_plug.c
Maybe related, we have TrustPadding = Y in default john.conf, but our code has it default to 0 (like N) if it's not found. So if someone runs with a substituted john.conf that doesn't have all of what we have in our usual one, they get different behavior of 7z formats - this is probably undesirable. I don't know if this played any role in the testing here, or probably not. Just sharing.
At least for this hash, one must set TrustPadding = Y:
$ ../run/john
John the Ripper 1.9.0-jumbo-1+bleeding-6be5461b67 2024-06-12 22:25:59 +0200 OMP [linux-gnu 64-bit x86_64 AVX2 AC]
Copyright (c) 1996-2024 by Solar Designer and others
[...]
$ cat ../run/john.conf | grep TrustPadding
TrustPadding = N
$ ../run/john --format=7z-opencl --wordlist=../../output.txt ../../a.7z.hash --keep
Device 1: pthread-AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx
Note: Will keep guessing even after finding a possible candidate.
Using default input encoding: UTF-8
Loaded 1 password hash (7z-opencl, 7-Zip archive encryption [SHA256 AES OpenCL])
Cost 1 (iteration count) is 524288 for all loaded hashes
Cost 2 (padding size) is 10 for all loaded hashes
Cost 3 (compression type) is 128 for all loaded hashes
Cost 4 (data length) is 6 for all loaded hashes
Will run 8 OpenMP threads
Note: Passwords longer than 23 rejected
LWS=2 GWS=16 (8 blocks)
Press 'q' or Ctrl-C to abort, 'h' for help, almost any other key for status
Warning: Only 5 candidates buffered, minimum 16 needed for performance.
aaa127aa8g (a.7z) (a.7z)
aaa128aa7g (a.7z) (a.7z)
aaa217aa8g (a.7z) (a.7z)
Waiting for 3 children (a.7z)
aaa721aa8g (a.7z) (a.7z)
5g 0:00:00:02 DONE (2024-06-16 18:39) 1.852g/s 1.852p/s 1.852c/s 1.852C/s aaa127aa8g (a.7z)..aaa721aa8g (a.7z)
Session completed.
$ rm ../run/*.pot; cat ../run/john.conf | grep TrustPadding
TrustPadding = Y
$ ../run/john --format=7z-opencl --wordlist=../../output.txt ../../a.7z.hash --keep
Device 1: pthread-AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx
Note: Will keep guessing even after finding a possible candidate.
Using default input encoding: UTF-8
Loaded 1 password hash (7z-opencl, 7-Zip archive encryption [SHA256 AES OpenCL])
Cost 1 (iteration count) is 524288 for all loaded hashes
Cost 2 (padding size) is 10 for all loaded hashes
Cost 3 (compression type) is 128 for all loaded hashes
Cost 4 (data length) is 6 for all loaded hashes
Will run 8 OpenMP threads
Note: Passwords longer than 23 rejected
LWS=2 GWS=16 (8 blocks)
Press 'q' or Ctrl-C to abort, 'h' for help, almost any other key for status
Warning: Only 5 candidates buffered, minimum 16 needed for performance.
0g 0:00:00:02 DONE (2024-06-16 18:44) 0g/s 1.931p/s 1.931c/s 1.931C/s aaa127aa8g (a.7z)..aaa721aa8g (a.7z)
Session completed.
At least for this hash, TrustPadding = N is harmful enough to warrant a warning or something.
Looks like we figured out the likely reason @fred913 saw a behavior change - not a code change, but likely some of the runs having/finding our default john.conf and others not.
At least for this hash,
TrustPadding = Nis harmful enough to warrant a warning or something.
I think the very reason magnum introduced this setting is he expected it'd sometimes be the other way around. So would we print a warning either way?
So far, I think the only actionable item here is to make it such that the default in john.conf and in the code are the same.
@fred913 When you wrote "It works then!" did you mean just the lack of false positives or that it'd also detect the correct password? Do you know the correct password for that file now? Is it correctly detected by john? With TrustPadding = Y or TrustPadding = N?
I remember it clearly. When I say that it's working, it shows the correct password. Yes it is the correct password. I didn't modify the default configuration but just built the latest version of JtR at that time.
Solar Designer @.***> 于2024年6月30日周日 05:36写道：
@fred913 https://github.com/fred913 When you wrote "It works then!" did you mean just the lack of false positives or that it'd also detect the correct password? Do you know the correct password for that file now? Is it correctly detected by john? With TrustPadding = Y or TrustPadding = N?
— Reply to this email directly, view it on GitHub https://github.com/openwall/john/issues/5228#issuecomment-2198344945, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ7IKH57Y657YO2X6HK4FGLZJ4SE7AVCNFSM6AAAAABJI24QEOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJYGM2DIOJUGU . You are receiving this because you were mentioned.Message ID: @.***>
Thank you @fred913! So my best guess is that when you saw false positives (with an older version), you didn't have our default john.conf that sets TrustPadding = Y. I just don't have any better guess. I also felt that we need to make our compile-time and our john.conf defaults the same anyway (whether this guess is right or not), so I've just made this change.
But...everything changed after recompiling using the latest code, instead of the latest release.
# john-latest --devices=1,2,3,4,5,6,7 --format=7z-opencl --wordlist=output.txt --fork=7 a.7z.hash
@fred913 Looks like we forgot to ask you - when you switched to our latest code, did you also regenerate a.7z.hash with the latest 7z2john.pl or did you continue with the old file you had generated with the release?
Regardless, can you see if the output of 7z2john.pl remains the same or changes (and in what way) between these two versions of the code, when run your archive above?
It didn't change. I didn't update the 7z2john script file. What I did is regenerate the hash of the same file with the same tool.
Btw, I'll try to get the old archive file on my hands again.
I think the very reason magnum introduced this setting is he expected it'd sometimes be the other way around. So would we print a warning either way?
I've only heard of one (alleged) case and no sample was ever shown. The impact can be huge (either as in this issue case but also performace) so it should definitely default to Yes - but of course a warning wouldn't harm.
