Dmitry Glavatskikh

I found another topic from 2024 that appears to be very close to my current experience. In other words, you’ve already read Igor’s reply to your question :-) So either rebind the *.7z file association to 7z-FM, or go blame Windows support for hijacking the opening of 7z archives with their substandard code, which doesn’t support encrypted archives.

If the FHEXTRA_CRYPT_HASHMAC flag is set in the cryptographic header, RAR5 uses HMAC-SHA256 instead of raw crc-32/blake2 hashes. unrar/crypt5.cpp void ConvertHashToMAC(HashValue *Value,byte *Key) { if (Value->Type==HASH_CRC32) { byte RawCRC[4]; RawPut4(Value->CRC32,RawCRC); byte Digest[SHA256_DIGEST_SIZE]; hmac_sha256(Key,SHA256_DIGEST_SIZE,RawCRC,sizeof(RawCRC),Digest); Value->CRC32=0; for (uint I=0;I<ASIZE(Digest);I++) Value->CRC32^=Digest[I] << ((I & 3) * 8); } if (Value->Type==HASH_BLAKE2) {...

[LZMA-SDK] Unpacking XZ of unknown size

Yeah, the header of the local file is damaged. Someone tried to spoof the executable extension (.cmd -> .png), but didn't fix the header checksum. That's why 7-Zip refuses to open this archive. BUT there is also a "QuickOpen" record with the correct copy of the header. I think WinRAR prefers to use QO if it is available. I've attached a synthetic example.

Yeah, the header of the local file is damaged. Someone tried to spoof the executable extension (.cmd -> .png), but didn't fix the header checksum. That's why 7-Zip refuses to open this archive. BUT there is also a "QuickOpen" record with the correct copy of the header. I think WinRAR prefers to use QO if it is available. I have attached this RAR5 archive in a password protected ZIP. Password: "malware"

CAB archive extraction failure (7-Zip v23.01)