Passwords with a length greater than 28 for 7z, and 23 for 7z-opencl, don't work.

[IamC8]

I wrote a small bash script to show the problems.

#!/bin/bash


#--format=7z-opencl --device=2 (Max Length is 23)
#--format=7z (Max Length is 28)
# Anything greater than 28 for 7z, and 23 for 7z-opencl, doesnt work?
pwd=$(tr -dc A-Za-z0-9 </dev/urandom | head -c 23)

# Create random file name
file_name=$(tr -dc A-Za-z0-9 </dev/urandom | head -c 5)

# Name files to use
file_7z="./"$file_name".7z"
raw_file="upload_test.txt"
hashes="./7z_hashes.txt"
passwords="./wordlist.txt"

# Create random file to 7z and encrypt
dd if=/dev/zero of=$raw_file bs=1M count=10

# Create random passwords in wordlist.txt
for ((i = 0 ; i < 10 ; i++)); do
	str_len=$(var=100 && shuf -i 1-${var} -n 1)
	str=$(tr -dc A-Za-z0-9 </dev/urandom | head -c $str_len)
	echo $str >> $passwords
done

# Add created pwd to wordlist.txt
echo $pwd >> $passwords

# Make 7z encrypted file
7z a $file_7z -p$pwd $raw_file

# John magic
~/src/john/run/7z2john.pl $file_7z > $hashes
~/src/john/run/john --wordlist=$passwords $hashes --format=7z-opencl --device=2
~/src/john/run/john --wordlist=$passwords $hashes --format=7z
~/src/john/run/john --show -format=7z-opencl $hashes

# Print usefull info
echo "Password is: "$pwd 
echo "7z encrypted file is: "$file_7z
echo "Pwd length is: ${#pwd}"


# Remove created files
rm $file_7z # REM this line to decrypt file manually to test?
rm $raw_file
rm $hashes
rm $passwords

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

• Ubuntu 20.04
• Linux ssd250 5.15.0-91-generic 101~20.04.1-Ubuntu SMP Thu Nov 16 14:22:28 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

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

[claudioandre-br]

any password with a length greater than 28 for 7z, and 23 for 7z-opencl, doesn't decrypt 7z files.

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?

[solardiz]

it looks like you can remove this limitation on CPU format if you disable SIMD.

Specifically, this is done by the --disable-simd option to configure, e.g. make distclean && ./configure --disable-simd && make -sj4. Of course, performance is expected to be worse.

do you think there is anything we can improve?

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 john.conf). We're already printing a few other informational messages that could fall under the same category, and be controlled together.

[solardiz]

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.

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.

We could then disable that with a slight reduction of verbosity level (on the command-line or in john.conf). We're already printing a few other informational messages that could fall under the same category, and be controlled together.

This verbosity control isn't implemented yet.