7-zip 11600 Cracking - Benchmark around 600 kH/s, real world around 28 kH/s (7z 7zip)
#1
Hashmode: 11600 - 7-Zip

I am trying to crack a few 7-zip archives. Ironically I don't believe I created any of them to be 'uncrackable'. I incorrectly believed 7z was a weak cipher. I put these on a cloud provider and my threat model was I didn't want it to be the very first password that they tried (1234).

I have not yet tried a dictionary derived from password leaks. It may be a password like "qwerty" (simple function/rule of a US keyboard), but it should not be a password like "letmein" (grammar rules of English). So I have not focused on using a leak dictionary.

I have an RTX 3070. My benchmark is around 600 kH/s but in the real world it's around 28 kH/s = 28,000 hashes/second.

Is anything close to 600 kH/s = 600,000 hashes/second possible on this hardware? I am on The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) Linux and all my drivers seem to be working. I installed the 'everything' set in The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) so some convenience features (e.g. prebuilt dictionaries/rules) are included.

I think my commands and methodology are correct because I already cracked one 7z this way. I tried some of the stuff in the FAQ about the gpu being too slow. I am mostly running a straight mask bruteforce (?l?d) but I've also tried generating a dictionary of attacks with mp32. I am very intrigued by the max character parameter. I believe my passwords probably do not have the same character more than once. The parameter in my version only allows a max of 2 or greater. I would love to set it to 2 or greater, or maybe process the dictionary.txt with another linux command to remove pointless lines.

I have brute forced up to around 5 characters for plausible passwords. If I can do 600,000 H/s then I believe I can brute it. Otherwise I need to generate a much smaller key space.

I also have several RX 470 mining GPUs but it would take some work to set them up.

Creation dates of 7z I am cracking:
2015-12-14
2018-01-13
2020-11-12

Notably, it seems the pre-2019 files may use a weaker cryptography.

https://sourceforge.net/p/sevenzip/bugs/2176/

My crypto knowledge is just the 101 level. I don't know how important this flaw is.

Thanks for any help.
Reply
#2
I don't see a way to edit so here are my commands. I can go off The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) if needed.

---------------------------------------------------
* Hash-Mode 11400 (SIP digest authentication (MD5))
---------------------------------------------------

Speed.#01........:  5116.5 MH/s (93.68ms) @ Accel:20 Loops:1024 Thr:512 Vec:1

-------------------------
* Hash-Mode 11500 (CRC32)
-------------------------

Speed.#01........:  9249.2 MH/s (54.21ms) @ Accel:42 Loops:1024 Thr:256 Vec:1

---------------------------------------------
* Hash-Mode 11600 (7-Zip) [Iterations: 16384]
---------------------------------------------

Speed.#01........:  646.9 kH/s (88.11ms) @ Accel:10 Loops:4096 Thr:512 Vec:1

--------------------------------------------------------------------
* Hash-Mode 11700 (GOST R 34.11-2012 (Streebog) 256-bit, big-endian)
--------------------------------------------------------------------

Speed.#01........:  107.6 MH/s (83.57ms) @ Accel:3 Loops:128 Thr:512 Vec:1

hashcat -m 11600 dcim.johnhash --session dcim_brute5 -O -a 3 -1 upper_lower_nums_and_not_all_symbols.hcchr -2 lower_nums_and_not_all_symbols.hcchr -3 ?l?d --increment --increment-min 5 ?3?3?3?3?3?3?3?3?3?3 -w 3 -S

└─$ hashcat -m 11600 dcim.johnhash --session dcim_2 -O -a 0 -w 3  /run/media/asdf/sam-1024-nvme/asdf/6ch.txt
hashcat (v7.1.2) starting - session [dcim_2]

This hash-mode is known to emit multiple valid candidates for the same hash.
Use --keep-guessing to continue attack after finding the first crack.

CUDA API (CUDA 12.4)
====================
* Device #01: NVIDIA GeForce RTX 3070, 7139/7961 MB, 46MCU

OpenCL API (OpenCL 3.0 CUDA 12.4.131) - Platform #1 [NVIDIA Corporation]
========================================================================
* Device #02: NVIDIA GeForce RTX 3070, skipped

This hash-mode is known to emit multiple valid candidates for the same hash.
Use --keep-guessing to continue attack after finding the first crack.

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 20
Minimum salt length supported by kernel: 0
Maximum salt length supported by kernel: 51

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1

Optimizers applied:
* Optimized-Kernel
* Zero-Byte
* Single-Hash
* Single-Salt

Watchdog: Temperature abort trigger set to 90c

Host memory allocated for this attack: 1035 MB (27556 MB free)

Dictionary cache hit:
* Filename..: /run/media/asdf/sam-1024-nvme/asdf/6ch.txt
* Passwords.: 2751200914
* Bytes.....: 24514649144
* Keyspace..: 2751200914

[s]tatus [p]ause [b]ypass [c]heckpoint [f]inish [q]uit => s

Session..........: dcim_2
Status...........: Running
Hash.Mode........: 11600 (7-Zip)
Hash.Target......: $7z$1$[snip]...100000
Time.Started.....: Thu Jan 29 00:53:43 2026 (20 secs)
Time.Estimated...: Fri Jan 30 08:05:06 2026 (1 day, 7 hours)
Kernel.Feature...: Optimized Kernel (password length 0-20 bytes)
Guess.Base.......: File (/run/media/asdf/sam-1024-nvme/asdf/6ch.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#01........:    24502 H/s (74.97ms) @ Accel:10 Loops:4096 Thr:512 Vec:1
Recovered........: 0/1 (0.00%) Digests (total), 0/1 (0.00%) Digests (new)
Progress.........: 471040/2751200914 (0.02%)
Rejected.........: 0/471040 (0.00%)
Restore.Point....: 471040/2751200914 (0.02%)
Restore.Sub.#01..: Salt:0 Amplifier:0-1 Iteration:20480-24576
Candidate.Engine.: Device Generator
Candidates.#01...: lbocl -> mdhyw
Hardware.Mon.#01.: Temp: 63c Fan: 62% Util: 88% Core:1905MHz Mem:6800MHz Bus:16

[s]tatus [p]ause [b]ypass [c]heckpoint [f]inish [q]uit =>
Reply
#3
Yeah, this is something unfortunate about 7z, there are many factors that determine hashrate and the benchmark's hash is deliberately on the faster side, so it may not reflect real-world performance. The main one is how long the hash is, archive hashes like 7z are rather unique in that they aren't a fixed size and instead scale with the length of the compressed archive. Longer = slower, Shorter = faster and the benchmark hash is very small
Reply