7z password hash can not be matched.

[linghaolu]

use 7z2john got the hash:
1.7z.bak:$7z$1$19$0$$16$24123907605ca41966bf97e3a6a695d5$1989029080$1312$1306$e807fbd8ebbbdbee7fdec7da65fcb66b8324e5cb9d7bd9f7ecbd4810ed7bea6905f4fd1793d80839c17fa4796c2d0012fc8a13c4456a62e140746195e39489ca2b46c5489387cee76e0e1ec3bc2afe87f7a8ab2e07b1033a61ba648e6aef2121aab35ca87f1c6c9503149e4e291cbc69a367d6e0eb2ef145356da44f63cb36ae4623940ac47b50fd10304845a33502b6b0764fe96fcc99d27a33308483526527d6e439262e63d2bb2fd2b8a3ed15a5bf87555496614029d57516336591de2f02ad96ce0c9d2f3b63c1451149cc88b089679ffe6f47cb12101f8f36209b4da3f5af36670500f2caa38b1ba8cc7dcc4d7698546a55b9a1e7ae60f8e5a56de5134f2c5a323f3ed0adb08eaa841956037ff98de29ad741a95290dca1edc8166814ccb0c4c6c2b2e8fcd58cd8218a1de6e3ea38771be294c65223869eb68c823fb3b870c74dd394d1f0a60d2d3848acdc31b3281398340ede32197c11f6b51cb582e05ffa77e620bb7a134d4ecda939f0db5a4b0a1a179ab20c545c10479fdd2a16bba9218922cc8378329f66313769f3cb56cc1216d130450330c0abfeccb58f617bdd16021a22f37412a0d0408dee825fa6a559685173e6955314a85880333e75b0b5b2e62c1fe6cf0a5d52350bd0ae96bb5d7d3f8a1a30f44efbfffe3d982e4d2840190eb11ec1e1f7844682b47de59b1a7b4c816ed7218de7a966694f172b4b75afcce47a1170e09dd1fc8cbf2c621986eb2610d4136ddf865befa4b4264831f7070e0de6413e973649700e784cf0e96434863848c3624b3db9c48fb84ef22d8447f0d4aef30dfc1d7527a724d056cf85d76d26c7561b0b9b6c707508aa3438454fdae7e72e354b5cce401bc2c03671259a4be977e9699358c06d9166d9e9bc586043873a8390c17a7d13a218a3d21f2e936777cbdc61882f8a5104fab75e14f282adfc12411b3f338cfb0cc30fe92f0feaf12a61cde2cc0cc38549d98cb3279bc7cc55e362a699d831d0bbdf25ec2e076b9aab1aa4a97979a1e7441316ebc814af17cc4f83f02723b977ccd468a1b99ccd0ff05bf202e2965d918faec0df200c4f453646c23222c848fd75a27753868bd9f3d60b958ad987a153dc4650db62f1c3d659647a71c43d5bbd2eb7bb340f97c84356c82e8039534558858f0030bb625e06721a8482d4e4ee6c2d318028be88cc0b5f8a85c9814cad70b0d23ba79e9dad9d1d86890904718b918043b29a720a5b47411dca34fc4c7134c0bc71005628e7c1df681f1b622ddd8e599cd325d7af7fe184f13487648d7abe98dc65d41b7d712c77897fa11f946a7ca76273b426ec1c52cf263543cecab3abcb7f011d66f8d371f9ebd499b58233ed74e3422e0f4df23366e16b558fe917b35a9abd6e990195309478bab77acef7e96ec2bbea6452651adaf13290eca77ac8395bd205a4ad51aabb9992b12e9095d34bd492fef3b0a7097734ab95f81cdd3e69811fa4c26c52758fdad53700507a822fdbcf1aef055bb96b2a88ef35888067269c7346bd504080f92f9b067a02b90170ddee386a1b50da5de9da13f81638a05140a3b01d3c91158028b3793e511d5ec5606cbded8f25d67956bf7bb3f8a96e7b402758965807cfaf562e289102bd52165097beebe58f6f22fc0a05232d238fc05d330decdd8c92bc5cc08db42484035b5027c0bf3cd2aab010e0cc2914f8d3ab63f0fb84f77f4825cd6d338e62198ae31806f7cfd18cb63d39d638a8e7b3447e007fceaf8627fdf194e8f54a62819dee56835129e77f5308702791e2776d4de1bb91cc664b561f9eb744547d8106a0d10307f0c008bdaccc1322e55e52b110685cd7ab2ad0$8230$5d00004000

the expected password is t.me/qyoyoq
but the passwd can not be matched from the wordlist.

[magnumripper]

You are likely using a too old version of John. I just tested it:

Using default input encoding: UTF-8
Loaded 1 password hash (7z, 7-Zip archive encryption [SHA256 256/256 AVX2 8x AES])
Cost 1 (iteration count) is 524288 for all loaded hashes
Cost 2 (padding size) is 9 for all loaded hashes
Cost 3 (compression type) is 1 for all loaded hashes
Cost 4 (data length) is 1655 for all loaded hashes
Will run 16 OpenMP threads
Press 'q' or Ctrl-C to abort, 'h' for help, almost any other key for status
Warning: Only 95 candidates buffered, minimum 128 needed for performance.
t.me/qyoyoq      (1.7z)     
1g 0:00:00:00  2.703g/s 256.8p/s 256.8c/s 256.8C/s t.me/qyoyoa..t.me/qyoyo|
No remaining hashes
Use the "--show" option to display all of the cracked passwords reliably
Session completed. 

[magnumripper]

I'm closing the issue but feel free to reply it with follow-up.

[linghaolu]

You are likely using a too old version of John. I just tested it:

Using default input encoding: UTF-8
Loaded 1 password hash (7z, 7-Zip archive encryption [SHA256 256/256 AVX2 8x AES])
Cost 1 (iteration count) is 524288 for all loaded hashes
Cost 2 (padding size) is 9 for all loaded hashes
Cost 3 (compression type) is 1 for all loaded hashes
Cost 4 (data length) is 1655 for all loaded hashes
Will run 16 OpenMP threads
Press 'q' or Ctrl-C to abort, 'h' for help, almost any other key for status
Warning: Only 95 candidates buffered, minimum 128 needed for performance.
t.me/qyoyoq      (1.7z)     
1g 0:00:00:00  2.703g/s 256.8p/s 256.8c/s 256.8C/s t.me/qyoyoa..t.me/qyoyo|
No remaining hashes
Use the "--show" option to display all of the cracked passwords reliably
Session completed. 

looks like you tested a wrong hash. I updated the hash yesterday（I posted a wrong hash at first）. the file name is 1.7z.bak

[magnumripper]

I'm using latest bleeding from here but the 7z format hasn't change for a while.

I updated the hash yesterday（I posted a wrong hash at first）

OK, I can't crack your updated hash. Did you create it using a fresh 7z2john as well? (never mind the last sentence)

[magnumripper]

Interestingly enough, hashcat can crack that hash. I will investigate.

[magnumripper]

OK, if you edit run/john.conf and change TrustPadding to N, john will crack it (hashcat does not trust padding).

The padding size is 6, so the risk of a false positive is slim. This is the second time ever I've heard of a 7z archive with broken padding (and the first time I got a sample), but perhaps we should change the default. That is devastating for performance though.

Do you happen to know exactly what 7z program created that archive?

[magnumripper]

That is devastating for performance though.

It's not that bad for small files. For this one, it goes down by 5%. For large archives it can be much worse because we need to unzip all decrypted data to verify each and every password candidate.

[magnumripper]

perhaps we should change the default

A middle ground change would be to ignore the TrustPadding setting for small files, with some threshold we need to decide. Also we should add a warning when trusting it.

[solardiz]

Per #5228, TrustPadding = N may lead to false positives (does hashcat have them as well?), so it's not only about speed.

[linghaolu]

Do you happen to know exactly what 7z program created that archive?

Sorry, I dont know either. This is not the only one, I met some other 7z files like this.

[magnumripper]

Per #5228, TrustPadding = N may lead to false positives (does hashcat have them as well?), so it's not only about speed.

Right. So we could ignore that setting when padding is large enough (in this case 48 bits, should be safe). For small size padding (can be zero, hashcat can't couldn't even attack those in the past) we could perhaps emit a warning about false positives and (if possible) soft-enable FMT_NOT_EXACT (if that implies --keep-guessing which it does IIRC). That setting should ideally be be per-salt (see also #4483).

[magnumripper]

Hmm wait, this is backwards. For the first reported case it was actually TrustPadding = Y that lead to FP false negative because that archive somehow (allegedly) had its padding incorrect, and we trusted it so never did the slow checks. So this issue and #5228 is the opposite case. Very weird, and means we might need to set this format FMT_NOT_EXACT anyway, for any salt.

I/we should try to nail what might be wrong in sevenzip_decrypt().

[magnumripper]

@linghaolu are your sure that with the correct password, you can unpack the whole archive without errors?

[magnumripper]

OK, if you edit run/john.conf and change TrustPadding to N, john will crack it (hashcat does not trust padding).

That is devastating for performance though.

It's actually TrustPadding = Y that is fast, because if padding isn't correct, we early reject on bad padding.

[linghaolu]

@linghaolu are your sure that with the correct password, you can unpack the whole archive without errors?

Yes, 100% no errors.
I tested it with 7zip pc desktop, and ubuntu 7z cmd, all works without errors.
here is the ubuntu cmd unpack output:

7z e 1.7z

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=C.UTF-8,Utf16=on,HugeFiles=on,64 bits,12 CPUs 12th Gen Intel(R) Core(TM) i5-1245U (906A4),ASM,AES-NI)

Scanning the drive for archives:
1 file, 3178310322 bytes (3032 MiB)

Extracting archive: 1.7z

Enter password (will not be echoed):

Path = 1.7z
Type = 7z
Physical Size = 3178310322
Headers Size = 1410
Method = LZMA2:24 7zAES
Solid = +
Blocks = 5

Everything is Ok

Folders: 3
Files: 67
Size: 3190743192
Compressed: 3178310322

[magnumripper]

I tested it with 7zip pc desktop, and ubuntu 7z cmd, all works without errors. here is the ubuntu cmd unpack output:

7z e 1.7z

OK but the initial hash you posted for 1.7z didn't fail. The failed hash was from 1.7z.bak, does that show the same output when decrypting? Or was it a copy of the archive? In that case, how come you had different hashes?

[linghaolu]

I tested it with 7zip pc desktop, and ubuntu 7z cmd, all works without errors. here is the ubuntu cmd unpack output:

7z e 1.7z

OK but the initial hash you posted for 1.7z didn't fail. The failed hash was from 1.7z.bak, does that show the same output when decrypting? Or was it a copy of the archive? In that case, how come you had different hashes?

The 2 diffrent files have the same file name, one is ok while another one failed, so I made a mistake at first . The file in the cmd "7z e 1.7z" is the file 1.7z.bak.

[magnumripper]

I tested it with 7zip pc desktop, and ubuntu 7z cmd, all works without errors. here is the ubuntu cmd unpack output:

7z e 1.7z

OK but the initial hash you posted for 1.7z didn't fail. The failed hash was from 1.7z.bak, does that show the same output when decrypting? Or was it a copy of the archive? In that case, how come you had different hashes?

The 2 diffrent files have the same file name, one is ok while another one failed, so I made a mistake at first . The file in the cmd "7z e 1.7z" is the file 1.7z.bak.

I can't see how that could be the file corresponding to the failing hash: Your output from 7z e 1.7z here says Method = LZMA2:24 7zAES while the failing hash has LZMA1 compression per below.

Anyway, with debug output from john using the hash currently posted in OP, I get:

Type 01 (LZMA1) AES length 1312, packed len 1306, pad size 6, crc len 8230
Padding : 00040004 0004
Initial padding check failed
AES len 1312, pad size 6
LZMA decoding passed, 1306/1306 -> 8230/8230, props 5d000040
CRC len 8230
CRC check passed (768e2cd8)
t.me/qyoyoq      (?)     
1g 0:00:00:00 DONE (2025-03-07 11:49) 25.00g/s 25.00p/s 25.00c/s 25.00C/s t.me/qyoyoq
No remaining hashes

As the data passes both full decryption without any error and also the CRC-32, it's very likely correct. But the padding should be six zeros yet for some reason it's 000400040004. If the program creating the file would mistakingly have used PKCS#12 padding, it would be 060606060606 so that's not it. Perhaps the program that created the file just fails to fill the padding so it's more or less random data.

So not our bug, but we still need to handle it some way. I'll have look at debug output from the #5228 sample and see if I get more clues from it.

[magnumripper]

I can't see how that could be the file corresponding to the failing hash: Your output from 7z e 1.7z here says Method = LZMA2:24 7zAES while the failing hash has LZMA1 compression per below.

Nevermind this, apparently it's normal although I can't fathom how.

[magnumripper]

For the first reported case it was actually TrustPadding = Y that lead to FP false negative because that archive somehow (allegedly) had its padding incorrect

Forget about "allegedly" - this was #2532 and we actually got a private sample back in 2017 and diving in my archives I could even find it. It has too little padding (4 zero bytes instead of 12) but ignoring that, it's perfectly crackable and can be inflated to sensible data.

But the padding should be six zeros yet for some reason it's 000400040004. If the program creating the file would mistakingly have used PKCS#12 padding, it would be 060606060606 so that's not it. Perhaps the program that created the file just fails to fill the padding so it's more or less random data.

For reference the padding in #2532 comes out as fe07000010908c0200000000 instead of 12 zero bytes. So no pattern seen.

[magnumripper]

So to recap in one place:

• We have at least two cases (this and 7z archive that doesn't get cracked by JtR #2532) where we can't trust padding because they aren't what the spec. says, yet they decompress to perfectly fine files so it can't be FP.
• We also have the opposite in 7z-opencl false positives #5228 - loads of FP if we do not trust the padding. In that case however, I believe the problem is actually 7z formats: Support stacked methods/filters #4956 (due to Update 7z2john, fixing a conflict #5176 we currently don't decompress it to check the CRC) so we can ignore that for now. We need to do something about that issue though.
• Not trusting padding doesn't hurt small files much but is a huge performance problem for very large files.