7-Zip / Support Requests / #570 Open WARNING: Cannot open the file as [7z] archive, Type = lzma

Igor Pavlov - 2024-07-03

It's not 7z archive.
It's lzma archive and some data after lzma archive.
try

7z x 8F2DB7.7z -t#

and look extracted files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alex - 2024-07-03

yes, I assumed that, there is no 7z signature in 8F2DB7.7z when open it in hex editor.

Extraction gives 2 files,
1.lzma - 1,8 KiB completely empty file, and 2 - 14,3 MiB data file

Thank you.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Hm, I tried to decompress another file marked as 7z archive, and it fails.

$ xz --decompress 656.7z
xz: 656.7z: File format not recognized

binwalk says:

MD5 Checksum:  763198cd19722121ab8684151937ff0f
Signatures:    436

DECIMAL       HEXADECIMAL     DESCRIPTION
----------------------------------------------------------------------
0             0x0             LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, missing uncompressed size

656.7z

Igor Pavlov - 2024-07-06

Probably it's lzma with modified header: 5 bytes instead of 13 bytes.
where 64-bit uncompressed size field was removed.
So you need some program that can extract it, or add 64-bit size field and extract it with lzma or 7-zip.

Last edit: Igor Pavlov 2024-07-06

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alex - 2024-07-06

In which place to add 8 zero bytes? I can't find in hex editor strings 'lzma' and bytes 6C 7A 6D 61

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Igor Pavlov - 2024-07-06

The lzma file format layout: Offset Size Description 0 1 LZMA model properties (lc, lp, pb) in encoded form 1 4 Dictionary size (32-bit unsigned integer, little-endian) 5 8 Uncompressed size (64-bit unsigned integer, little-endian) 13 Compressed data (LZMA stream)

maybe 0xffffffffffffffff is ok for Uncompressed size un that file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alex - 2024-07-06

You mean this way? I've added 8 bytes in the beginning at offset 0000005D.
File format not recognized

656-2.7z

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Igor Pavlov - 2024-07-07

5d is not offset.
look description above: 0xffffffffffffffff at offset 5.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alex - 2024-07-07

Igor,

got it: the offset had to be counted from the first byte to the left, and not down.
The hex editor shows the offset number Offset: 0x5. Btw, if count bytes from the left, start from "5D" it turns out to be the sixth byte? Why?

5D 00 00 80 00 00

after moodifying header command file show: "LZMA compressed data, streamed"
I was able to decompress it use 7z x 656-2.7z command:

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs Intel(R) Core(TM) i3-4005U CPU @ 1.70GHz (40651),ASM,AES-NI)

Scanning the drive for archives:
1 file, 1421070 bytes (1388 KiB)

Extracting archive: 656-2.7z
WARNING:
656-2.7z
Can not open the file as [7z] archive
The file is open as [lzma] archive

--
Path = 656-2.7z
Open WARNING: Can not open the file as [7z] archive
Type = lzma

ERROR: Unexpected end of data : 656-2

Sub items Errors: 1

Archives with Errors: 1

extraction use lzma not works:

lzma -d 656-2.7z
lzma: 656-2.7z: Filename has an unknown suffix, skipping (the same with .xz, too)

unlzma: 656-2.xz: Unexpected end of input

Work also via right click > extract here default Debian Xarchiver (although with error message)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Igor Pavlov - 2024-07-07

0000000000: 5D 00 00 80 00 38 50 6B 00 00 00 00 00 00 20 20 5D - properties 00 00 80 00 - dictionary size 38 50 6B 00 00 00 00 00 - uncompressed size instead of 0xffffffffffffffff 00 20 20 .... - start of data.

The program that must extract that file knows uncompressed size from another source. So the removed uncompressed size field from the header (5 bytes header instead of original 13 bytes header).

Last edit: Igor Pavlov 2024-07-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alex - 2024-07-07

That is, it was a file with a truncated (nonstandard) lzma header, with a missing uncompressed file size field. And since we didn't know the uncompressed file sizes initially, we padded this field with 8 empty bytes. And the proper lzma header should include 38 50 6B 00 00 00 00 00 uncompressed size field, in that case it decompresses normally.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Open WARNING: Cannot open the file as [7z] archive, Type = lzma

A free file archiver for extremely high compression

Group

Searches

Help

#570 Open WARNING: Cannot open the file as [7z] archive, Type = lzma

Discussion