7z-opencl false positives #5228
Comments
|
a.7z.hash: |
|
Sorry but it shouldn't be here. |
|
@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 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 I see you also posted this to |
|
@fred913 can you reproduce using something like this? (Without fork and/or using the cpu format). Or Or |
@claudioandre-br As for the CPU format: Also the format with OpenCL support, with only one password given: As you see the problem is still. @solardiz
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. # 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 |
|
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 |
|
But...everything changed after recompiling using the latest code, instead of the latest release. It works then! |
So, the latest source code (bleeding) works as expected. This is good news. Thanks for reporting. We'll probably keep this open for a while to think about what happened.
|
ghost
added
the
|
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: But you can find more candidates here: |
|
Maybe related, we have |
|
At least for this hash, one must set $ ../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.At least for this hash, |
|
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
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 |
|
@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 |
|
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
<#5228 (comment)>,
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 |
@fred913 Looks like we forgot to ask you - when you switched to our latest code, did you also regenerate Regardless, can you see if the output of |
|
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'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 |
|
As mentioned in #5688 (comment) I believe the real problem here is #4956 and/or #5176 - we currently don't decompress a "DELTA + stored" archive to check the CRC. Without even a padding check, we end up with no checks at all, so any candidate ends up as a crack. Leaving this closed as the mentioned issues are open. |
When I run
john --devices=1,2,3,4 --format=7z-opencl --wordlist=output.txt --fork=4 a.7z.hashit gives the following output:It shouldn't be like that. Here's the OpenCL devices list:
I guess there's something wrong with the 7z-opencl adapter..?
Please reply soon, thanks.
The text was updated successfully, but these errors were encountered: