Cannot extract files from .7z and .rar (RAR4) archives with unencrypted filenames

[wdDiamant]

When attempting to extract a .7z with unencrypted filenames, i get the following error in the CLI.

2023-03-08 11:20:10.5991|ERROR|Microsoft.CST.RecursiveExtractor.Cli.RecursiveExtractorClient|Exception while extracting. SharpCompress.Common.CryptographicException:Encrypted 7Zip archive has no password specified. ( at SharpCompress.Compressors.LZMA.AesDecoderStream..ctor(Stream input, Byte[] info, IPasswordProvider pass, Int64 limit)
at SharpCompress.Compressors.LZMA.DecoderRegistry.CreateDecoderStream(CMethodId id, Stream[] inStreams, Byte[] info, IPasswordProvider pass, Int64 limit)
at SharpCompress.Compressors.LZMA.DecoderStreamHelper.CreateDecoderStream(Stream[] packStreams, Int64[] packSizes, Stream[] outStreams, CFolder folderInfo, Int32 coderIndex, IPasswordProvider pass)

When trying to extract a .rar with unencrypted filenames, i get no error but it just creates a damaged copy of the .rar.

Same issue with the .net standard library variant.

Steps to reproduce:

1. Create a text file.
2. Add it to an .7z archive using 7zip or to an .rar archive using WinRar without checking the Encrypt filenames option.
3. Try to extract the archives using the RecursiveExtractor Tool.

[gfs]

Hi @wdDiamant,

I can't reproduce this on completely unencrypted archives.

I am able to reproduce this when a 7z is created with a password which encrypts the files, but the filename decrypt option is disabled.

I am also able to reproduce the second issue you reported with encrypted RAR5 files. We do not have support for encrypted RAR5 files (which WinRar just calls "RAR") as the dependency which we use to parse rar files does not support them. Encryption is supported for "RAR4" files. However, the behavior expressed in the CLI does seem non-optimal.

For the 7z issue I'll check to see if there's something we can do on our end with how we call into sharpcompress and if not, perhaps file an issue with them.

For the rar issue, I'll also check if we can provide a better behavior, but without a dependency that supports RAR5 encrypted files we won't be able to extract those files only warn that they cannot be extracted properly.

[wdDiamant]

Hi @gfs,
thanks for the answer. I forgot to mention, that i have this problem with encrypted archives only. Luckily u managed to reproduce the 7z issue i meant. I encountered exactly the same issue with encrypted RAR4 archives with the "Encrypt file names" option disabled. I am using RecursiveExtractor 1.2.10 and WinRar 6.21 to create the RAR4 archive.

[gfs]

@wdDiamant Thanks for the extra information. I can reproduce this on rar4 files which are encrypted with plain names as well.

This comes down to an issue with the way we were checking if the archive was encrypted/if a password was needed. The behavior differs between an encrypted archive with encrypted file names (which we were testing for) and those without encrypted file names and requires a tweak to how we check if the provided passwords are correct. This should be something we can fix in recursive extractor, likely this week.