7z archive that doesn't get cracked by JtR
magnumripper opened this issue · 9 comments
We've got a sample off-list. Password is 1234.
Sample contains malicious code so beware.
I created some fresh 7z header encrypted archives for testing but all of them were cracked fine by the current code. I wonder where the problem is.
$ 7z t malicious_test.7z
7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=utf8,Utf16=on,HugeFiles=on,64 bits,8 CPUs x64)
Scanning the drive for archives:
1 file, 541480 bytes (529 KiB)
Testing archive: malicious_test.7z
Enter password (will not be echoed):
--
Path = malicious_test.7z
Type = 7z
Physical Size = 541480
Headers Size = 248
Method = LZMA2:26 7zAES
Solid = +
Blocks = 1
Everything is Ok
Files: 2
Size: 837861
Compressed: 541480
It's a solid archive, right? Do we support that?
Hashcat doesn't load it. "Salt-value exception".
This was not correct, see below
I don't know if we support solid archives now. The format has changed a lot. It is quite unlikely that my original code supported solid archives; it was pretty limited.
I tried to create a solid 7z archive earlier but didn't succeed. This is what I was trying,
$ 7z a -mx=9 -mhe -ms=on testing-header-encryption.7z test.txt -p
Update: With some trial-and-error, I was able to create a solid 7z header encrypted archive.
testing-header-encryption.zip (rename to .7z from .zip, the password is "1234").
This file gets successfully cracked while the off-list sample doesn't.
$ 7z t testing-header-encryption.7z
7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=utf8,Utf16=on,HugeFiles=on,64 bits,8 CPUs x64)
Scanning the drive for archives:
1 file, 46136 bytes (46 KiB)
Testing archive: testing-header-encryption.7z
Enter password (will not be echoed):
--
Path = testing-header-encryption.7z
Type = 7z
Physical Size = 46136
Headers Size = 248
Method = LZMA2:16 7zAES
Solid = +
Blocks = 1
Everything is Ok
Folders: 1
Files: 2
Size: 63284
Compressed: 46136
One difference is the "LZMA2:26" vs. "LZMA2:16". Not sure what it means.
Hashcat doesn't load it. "Salt-value exception".
I accidentally used an ancient version of Hashcat. Current hashcat loads it but doesn't crack it, just like JtR.
I'll send the sample to @philsmd and see if he has any idea.
Removed padding early-reject checks for now. They are still there for incomplete hashes.
Performance was almost not hurt at all, but it will be if attacking many different 7z hashes at once.