-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Passwords with a length greater than 28 for 7z, and 23 for 7z-opencl, don't work. #5390
Comments
The maximum password length supported by the CPU format is 28 (23 for OpenCL). $ john --list=format-all-details --format=7z
Format label 7z
Disabled in configuration file no
Min. password length 0
Max. password length 28 So, it is by design. Looking at the source code, it looks like you can remove this limitation on CPU format if you disable SIMD. Anyway, do you think there is anything we can improve? |
Specifically, this is done by the
For some cracking modes/options, we print warnings or refuse to work when the requested candidate password lengths exceed the format's maximum. However, for wordlist mode without a min/max length requested, this is tricky since the candidates' length range will depend on what's in the wordlist and isn't known when cracking just starts. We could maybe be checking and print warnings the first time a candidate password exceeds the format's maximum, but it'd have performance impact on fast hashes. We could alternatively be printing the format's maximum on each run just in case the user would find it unexpected. Not as a warning, but as an informational message. We could then disable that with a slight reduction of verbosity level (on the command-line or in |
This was non-trivial given all the special cases, but is now implemented. Limited to cracking modes where the lengths range isn't specified by the mode itself or command-line options. I'd appreciate testing.
This verbosity control isn't implemented yet. |
I wrote a small bash script to show the problems.
NOTES
As stated, any password with a length greater than 28 for 7z, and 23 for 7z-opencl, doesn't decrypt 7z files.
I believe this is a bug.
System
John
Version: 1.9.0-jumbo-1+bleeding-047dc0775c 2023-12-14 16:58:50 -0300
Build: linux-gnu 64-bit x86_64 AVX2 AC OMP OPENCL
SIMD: AVX2, interleaving: MD4:3 MD5:3 SHA1:1 SHA256:1 SHA512:1
CPU tests: AVX2
$JOHN is ./
Format interface version: 14
Max. number of reported tunable costs: 4
Rec file version: REC4
Charset file version: CHR3
CHARSET_MIN: 1 (0x01)
CHARSET_MAX: 255 (0xff)
CHARSET_LENGTH: 24
SALT_HASH_SIZE: 1048576
SINGLE_IDX_MAX: 2147483648
SINGLE_BUF_MAX: 4294967295
Effective limit: Number of salts vs. SingleMaxBufferSize
Max. Markov mode level: 400
Max. Markov mode password length: 30
gcc version: 9.4.0
GNU libc version: 2.31 (loaded: 2.31)
OpenCL headers version: 1.2
Crypto library: OpenSSL
OpenSSL library version: 01010106f
OpenSSL 1.1.1f 31 Mar 2020
GMP library version: 6.2.0
File locking: fcntl()
fseek(): fseek
ftell(): ftell
fopen(): fopen
memmem(): System's
times(2) sysconf(_SC_CLK_TCK) is 100
Using times(2) for timers, resolution 10 ms
HR timer: clock_gettime(), latency 65 ns
Total physical host memory: 15864 MiB
Available physical host memory: 10630 MiB
Terminal locale string: en_ZA.UTF-8
Parsed terminal locale: UTF-8
The text was updated successfully, but these errors were encountered: