openwall
Can't crack specific zip file with John, but I manged to do it on other OS
Hi! I'm using John The Ripper for crackin zip archibes under Kali Linux and Ubuntu 22 LTS, and it sometimes work, but sometimes doesn't. When I prepare a zip archive myself under Windows it cracks it perdectly, but sometimes there are files that I cannot crack. What's funny I have a file which I manged to cracked once. but now when I tried to do it again on second OS i can't.
I noticed that, the main difference between files I can crack or not is the result of zip2john command:
└─$ zip2john abc.zip > abc.hash
If this command don't print any result the cracking will be succesfull, but:
└─$ zip2john wtf.zip > wtf.hash
ver 2.0 wtf.zip/20240216_124713.pdf PKZIP Encr: cmplen=1294053, decmplen=1501317, crc=496001BE ts=692F cs=4960 type=8
When the result is like above cracking won't be succesfull, john will keep trying to find the password forever. I'm sure that this file is possible to crack, because I manged to do it once using thosuand of commands like umask, unshadow, changing permission, editing something inside the hash file, but now I try everything and can't repeat it.
Can you help me? I'm wonder what is the difference between those files which makes it so difficult to crack the second type as on the second example.
My build below:
Version: 1.9.0-jumbo-1+bleeding-aec1328d6c 2021-11-02 10:45:52 +0100
Build: linux-gnu 64-bit x86_64 AVX AC OMP
SIMD: AVX, interleaving: MD4:3 MD5:3 SHA1:1 SHA256:1 SHA512:1
System-wide exec: /usr/lib/john
System-wide home: /usr/share/john
Private home: ~/.john
CPU tests: AVX
CPU fallback binary: john-base-omp
OMP fallback binary: john-avx-non-omp
$JOHN is /usr/share/john/
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: 32768
SINGLE_BUF_MAX: 4294967295
Effective limit: Max. KPC 32768
Max. Markov mode level: 400
Max. Markov mode password length: 30
gcc version: 11.4.0
GNU libc version: 2.37 (loaded: 2.37)
Crypto library: OpenSSL
OpenSSL library version: 0300000b0
OpenSSL 3.0.11 19 Sep 2023
GMP library version: 6.3.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 34 ns
Total physical host memory: 1956 MiB
Available physical host memory: 846 MiB
Terminal locale string: en_US.UTF-8
Parsed terminal locale: UTF-8
Could you check if both operating systems are using the same version of john?
The zip format has received important fixes recently, so it is actually recommended that you use the latest version from this repository.
@matdoejunior Like Claudio said, you should consistently use our latest code for consistently best results. Using a distro's build from 2021 is suboptimal. That said, our known-relevant PKZIP support fixes pre-date your aec1328d6c 2021-11-02 by some months, so if that's the oldest version you're using then the problem may be different. Can you please generate a test archive you can't crack, with a known password and no sensitive info, and share it with us here, so that we test our latest code? Thanks!
As to differences between archive types, that debugging message you mentioned appears to be printed for all PKZIP archives (as opposed to the newer WinZip ones). There's still a lot of variance between different PKZIP archives, most relevantly 1- vs. 2-byte checksums. Until 3 years ago, we did in fact have false negatives (correct password not being detected as such) when an archive uses 1-byte checksum and we try 2-byte, see #4571, #4541, #4300.
Can you please generate a test archive you can't crack, with a known password and no sensitive info
@matdoejunior Re-reading what you wrote, it sounds like the only such archives are third-party, not any you know how to generate yourself. So probably not something that would be OK to share. If so, we'd appreciate it if you try cracking them with our latest or at least very recent code from this repo, building it from source or using a recent build from https://github.com/openwall/john-packages/releases
No communication from OP, so closing. Further comments can nevertheless be added.