7z2john.py: Support "multiple unpacksizes"

[magnumripper]

To reproduce:

magnum@bull:src [bleeding-jumbo]$  7z a -mhe=on -p test.7z *.h
magnum@bull:src [bleeding-jumbo]$ ../run/7z2john.py test.7z >test.in
test.7z : multiple unpacksizes found, not supported fully yet!

[kholia]

@magnumripper can you please paste the resultant "hash" (contents of test.in) ?

[magnumripper]

Oh, I did not realize one was produced. Actually in this case (at least) this resulting hash does get cracked.

test.7z:$7z$0$19$0$1122$8$882b8f35c31561a60000000000000000$4103181897$2432$2418$a3eb004ddb5ba5bdc323066e58a548709cd0d85566335cb3a3db70372c0fed0a2f5d71c72033a691ae4c591e1e9828a381eff892faa37b3e00e4140db5805287a9de3a391c5bf71885414ccd3bc2e853fc193bfc9eef7f2e8107d3c34a66bc87eb4fc1d757e75118768a0a20b9ba3445b4d492ba013f393cf69206a70d705835389e2a5da3fd7e7c44cf75a8894ba77b016952c3bbd483ea307589870326cd78ed8990f4908afc63c10462289058fda07ab01219cecf14b5a9f51dac50d228c895b06ba6365069a0b5a69ea0f1226273a32773ef270f371a458f6fbbd9f2af8870d153a3354cc88947a904019a294eb6f538ca674d9448ab0f4e16172a2ad6e9767afeda96d11b8f6fe0aca05e917bf1c5cc78fd873da1e1a323f8bd4b7b68f0b1d690da5b422852232379e9c3e71d48227633bce312e2168c77e57307217bb1417dd2f1485a534d3d5bdea623ce93e019dac9358a43bc8056bb05c5fccd32e8493c725164d627daf419a3697db31f4afe77f427caebda87e021fc09f36cf5899ff6dff631fc933d164e1ad2b881331f21e66110cbaf838fe3a9e18438c1a5fb778ac9106248ecd17a7d81af99497b95f24f81b246d1cdb5217bfa5d4292193c1fac30e98bdca97ae32961fb296b8edf0765a9fcdba54387bdf095282464de82ab30fd673631d6f7c4a620c73827e92d76bf25a4240b59cd86183e6111d82119fa41379d686bc85b5704616badc1948f22344c1fff79b0114b9b013e4554e7c50611631ba13fe03a764c17e825a761ac5d6950c707deb47d99a34594b3fb633b2f694e0a823e5988f4500945700c04e54468274aa53adc48ac52a01228a46e548eb3e53c5ef72167023add6bf5c88950b0b6d929053c75492f603ea3f042f792da1a09bafe4a11ad834c568f6c927615c4ccb2b957fe320acff36079ed12d52e9f1e64db23544b40d3a8d477b8e4ba9b29202a54ab98878cdcf6f15493e0222f4365c32c91171654def62156290cde96b354e0553deb78b4651ac7f955f7708027474acf24268d778213f1c195d6b9e9e1e34a384032be59ee21a49253154d34540dbb985265874f7844292b696c612f1fb1a39267c53b9e4282c9320c4fe2f347b29a4dd9f0c412ad5b7953f79fbba6218a88a3d3864c3b2d4a34c6fb3168581e240379d4339ee2f2a1dcc9ebd7a61f86c13c7b12021873582e7a165ab744e31a73b0cd81f071d6584ab8ea5ecf58d59ee20ae1b36a91a7c6ba3a8e2456f4e77f33a76d875a2e5ff43534a85afc673d123f77bb5ff98a814ef78f57f02247542cede06b7ea6128a923015a567d9bcdaca3b872b5777f1af9bbd0094454af5f92c992c44a4b78b8509ff2da74ba4746c0552e88ba9b1b4fd3fcf191f0955a693ff00e4b1e987b221b6a592019cb584f313b8710bac4b648bdd83a343acbcb75a44245c26ece46abcb725a5c5f184ea1873db2021eefe6fcd04560048e3e1f24b98f7cbdb8eac0ea6b7aea44f07286dae867a672e210be10c8a1c5afa504768f9dd73f149cbbe4004bbcfe09da18cc51e0998555612a7b30fff31c738626d9f4e52128c92507940890ff16081072a6cdb1e9751d79c05529f2614f7ed60b76c727d7b70e61b6500d3378b927009b3b724eb6e4c2cac501863dc86e738ba476e15c50d596c848d1abd792aa2b769f4ced5f1653c75f8371e4dcbe750e8873eed122ec9232a365237155dce2b5603846848d3bbdd5403faa7e7d12388e6052253af3fcb0fe281802cf0dd80b8852bfe41f2bac91bef7dda56bdbc6b1ec82a0617d71a0fdbfe881c4965a30ccb52ef557f554ca1b37d3e8a0ad0024e20cb0e200d3b9739d7bcc42e8939219294ba855f7cb9e2212bef54ff2acd43ef829de1787292207a316addb7dd0f61b42ce4ceda01fd0de64abee5f8738119257d50a0e9d128b27293d52883ff8c8892f761d7f5c9f58ade2ea570820c87292c940deb968c790b1dd8439933e9c0db5a39184ba03bdcbb11bf605b8c59d04fbfb798dd1809973cd24fffaa2652cd22f4609d35b5fdf58d164c2fcf19c5a02d1253e8b89f5daa9a547fe4058dd6f0916fffa50f130b33b8b0b390a993f9254e87f36c851ec59ebef0db0d46e129ea61edac8e63763401ec77b223769c468136ff2f9d0a5e69824cb631cb0b5dca802582868ff90a8f64c205c19b79ad56878c1337edf865b9365815a4070b4dd53f955f8d9764150711a5ce3f5b7eb8163a37bca1821e72f5733ed15de4181c6f840d342158301aeddc2e54f7e78e4f64b8487586cf333a1ad7121f1d5dc369a647b90f5ca7f1c092826d1c07b8db6ec4de5b7c5e5b27dfe06f985260773d4e8dcc378c2b8d5da4325eae3f81d00d345ec7ff9b84409e72f88ca292bddaead6f4f7340858c2b455e9a425a209940e106d4cf670aed55a86361814446560d02b40e58a8dced6343d79c46c73727983c463a7afed662595d9d7567f50d127769ebcbfb6aaf316d39b8928f76132b7553464abc18e17b093fb397f2808c48ee53946980cf3b044453f6187eb1b4c56bad4cea2adb2aec746152206fde97aff01763ef8fe06f79940fa082f22351dccbf972b3349a3448bf942f0fde5ff7e465bdf337efe244d0b5e9fcf7b672af12260966a25ef299135f1b073c5e2b373c5987569f68da823f8db55b3c3968616bffafc7022775c5e180c07c8b100b792be9a48f6d4b0b0e8ec9b23d6ebaf7d26a45b948823d37ff62d6a70f6ee265760fffd0d8f7787f1f3267596da88315b214c344dab0283e6b21975a1fc744f7f55d72c02d8eb8ab1265d3c4e44ba1035e8dedb2f8ce0b5afd7a81e89c2c55beb650362218a008118828b4f53e409454f6169d0703b6a57baa8708999ba7599eac6e6fabe44413aa4e5099b0a11e634182ccc65e3f0585245f187eb8052c16d83ceea5091bbf45458f5a7b80109558bf0f3fb24cf1fce66ff6d3005c65136eb64e7568e567d59332492c8f82189914574f1f8bc60f7df4b21628b4894c3067337f57da861a1c37966ad87610a582507a7328626c025f9aabda7ae056f1e6a7748a46522b33ce54b84398afba701a42f93999658f66ffc5c6487fafc3ed4db6ec610f40563c935f2402d7501141df05a60ab6260711ce2a99496dd5351f061567caa51a607add8a015512837f5bce93b6b003db92f2994c831bb59330d7ffe8db727496ba14643ffc88f41bb12175dc95d84716b46e18e7eafc64d31a0ddeff8549ccbbf05aa339284646c42a6fb0d46e1e84b38c6d6b3188556f20be5f6d4a7db0cabadcef0b45c248afb63f898166277511651c43b25f0a40909ccdba6cb7ff29c7017b505715bdbd6ab1dbea39959ecce847efea9462cd3c6878524e131c210aab4018f0d366c800903efc807642046b1fa6b3df5dc2591bf1f492c06c5

This should also use Base64!

[kholia]

You got lucky this time ;). Maybe I should detect if the format will work and produce hash / warning accordingly.

[magnumripper]

What is the problem if/when it does not work? Can it happen at all when using header encryption?

[kholia]

If packsizes[idx] is equal (or almost equal) to folder.unpacksizes[idx] and there are multiple unpacksizes involved, then we don't have enough padding margin to detect if decryption was successful (hence we should print a warning).

If packsizes[idx] is equal (or almost equal) to folder.unpacksizes[idx] and if len(unpacksizes) == 1, then the CRC check should suffice.

[kholia]

What is the problem if/when it does not work? Can it happen at all when using header encryption?

JtR will continue cracking (without any success) for ever.

[magnumripper]

Maybe I misunderstand something but from what I can see in the format, the only thing that would happen is the risk of false positives increases (with a margin of 8 it should be really slim). It would not be a false negative.

[kholia]

If packsizes[idx] is equal (or almost equal) to folder.unpacksizes[idx] and there are multiple unpacksizes involved, then we don't have enough padding margin to detect if decryption was successful (hence we should print a warning) AND the CRC check would also not work in this particular case.

Effectively we won't we able to "crack" the archive even if we know the password, i.e. a false negative.

(hopefully I have done a better job of explaining stuff this time)

[kholia]

The CRC check fails since we only decrypt single stream (other streams are compressed ones) and the CRC is for those multiple streams.

[magnumripper]

OK, I see. I seem to get a 'margin' of 14 with my test case. That's plenty.
Is there some way to skip the CRC check in the format for these cases where it won't be correct anyway?

[kholia]

Currently no but the (pending) folder check stuff should solve these problems.

[kholia]

https://github.com/philsmd/7z2hashcat should be helpful :)

[magnumripper]

Yes, I'm planning to test it once I get a round tuit.

[magnumripper]

Closing this in favor of #2314