#2373 a 0 byte qemu-uninstall.exe.nsis file gives data error on 7z extraction

[hgkamath]

A 0 byte qemu-uninstall.exe.nsis file inside a 7z archive throws data error on 7z extraction

Ref

1. https://github.com/ScoopInstaller/Main/issues/4164
2. https://gitlab.com/qemu-project/qemu/-/issues/1349 https://github.com/ScoopInstaller/Main/issues/4164#issuecomment-1336376550

Bug concerns being able to extract a 0 byte file from archive

last lines of log C:\vol\scoop_01\SCOOPG\apps\qemu\7.2.0-rc2\7zip.log

Sub items Errors: 1

Archives with Errors: 1

Sub items Errors: 1
ERROR: Data Error : lib\gdk-pixbuf-2.0\2.10.0\qemu-uninstall.exe.nsis

[Igor Pavlov]

Latest NSIS 3.08 supports new feature for uninstaller file,
and qemu uses that feature for qemu.
7-Zip 22.01 and older versions do not support that feature. So 7-Zip now can't unpack uninstaller file, because 7-zip expects only old-style uninstaller.
I'll try to fix the problem in next version of 7-Zip.

Technical details:
NSIS before 3.08 used "patch block" that creates uninstaller executable stub from installer executable stub. And new uninstaller (3.08) can be stored without that "patch block". That trick allowed to reduce the size of package before. That is why there was such complexity.

[Igor Pavlov]

Also I look that pe file headers of qemu installers.
And I see another problems in pe sections:

 SECTION HEADER #7
   .rsrc name
    2D18 virtual size
   67000 virtual address
    2E00 size of raw data
   15C00 file pointer to raw data

SECTION HEADER #8
  .reloc name
     908 virtual size
   6A000 virtual address
     A00 size of raw data
   16E00 file pointer to raw data

Probably they use some software that changes resource section .rsrc of pe file. But that program writes incorrect values to pe headers for next .reloc section.
Please ask them to check each step that you use to produce exe file. And check each program that they use.

[Sam Tansy]

But that program writes incorrect values to pe headers for next .reloc section.

If it creates incorrect header it should be their job to fix it.

[hgkamath]

I relayed the communication to the qemu issue, the first day itself.

If it creates incorrect header it should be their job to fix it.

I think, Igor was referring to possible addition corruption happening to the PE headers in the exe, that may or may not be the cause of the 7z throwing data error on the PE-archive stored within it.
The exe is able to execute and self-install to windows C:\Program Files\qemu\ .
Imho, archive/unarchive tools need to be robust to minor hiccups, and 7z should also be able to workaround it.

The dl.7z seems to be just the renamed exe

PS C:\WINDOWS\system32> cmd /c "fc /b C:\vol\scoop_01\SCOOPG\apps\qemu\7.2.0-rc4\dl.7z C:\tmpq\Downloads\qemu-w64-setup-20221208.exe"
Comparing files C:\VOL\SCOOP_01\SCOOPG\APPS\QEMU\7.2.0-RC4\dl.7z and C:\TMPQ\DOWNLOADS\QEMU-W64-SETUP-20221208.EXE
FC: no differences encountered

PS C:\WINDOWS\system32> cmd /c "dir C:\vol\scoop_01\SCOOPG\apps\qemu\7.2.0-rc4\dl.7z C:\tmpq\Downloads\qemu-w64-setup-20221208.exe"
 Volume in drive C is WinOS_1511A
 Volume Serial Number is DC21-D9A1

 Directory of C:\vol\scoop_01\SCOOPG\apps\qemu\7.2.0-rc4

12/12/2022  08:28 PM       150,228,008 dl.7z
               1 File(s)    150,228,008 bytes

 Directory of C:\tmpq\Downloads

12/12/2022  08:40 PM       150,228,008 qemu-w64-setup-20221208.exe
               1 File(s)    150,228,008 bytes
               0 Dir(s)   8,732,626,944 bytes free

The sha512 has matches with the checksum file given in the website https://qemu.weilnetz.de/w64/

PS C:\> Get-FileHash -Algo sha512 C:\tmpq\Downloads\qemu-w64-setup-20221208.exe |Format-List


Algorithm : SHA512
Hash      : FA65A9E9BA5011607C26305C57342F7146466F9D274D7B3EDE9D8B7B4938AC0482AC45E573152A69C07EDDC579F47A565D90619113B
            51275BE01F5427B059E7D
Path      : C:\tmpq\Downloads\qemu-w64-setup-20221208.exe



PS C:\> Get-Content C:\tmpq\Downloads\qemu-w64-setup-20221208.sha512
fa65a9e9ba5011607c26305c57342f7146466f9d274d7b3ede9d8b7b4938ac0482ac45e573152a69c07eddc579f47a565d90619113b51275be01f5427b059e7d  qemu-w64-setup-20221208.exe

Its possible the exe is unofficially self-signed. The DigitCertUtil.exe also confirms that the certificate does not chain to trusted higher root certificate authorities.

PS C:\WINDOWS\system32> osslsigncode verify C:\tmpq\Downloads\qemu-w64-setup-20221208.exe
Current PE checksum   : 08F4FF9D
Calculated PE checksum: 08F4FF9D

Signature Index: 0  (Primary Signature)
Message digest algorithm  : SHA256
Current message digest    : F9D7B34F3F4F5F19C458FD81F824018460A54C1840DEB343C796FC131998BB5D
Calculated message digest : F9D7B34F3F4F5F19C458FD81F824018460A54C1840DEB343C796FC131998BB5D

Signer's certificate:
        Signer #0:
                Subject: /CN=Stefan Weil/emailAddress=sw@weilnetz.de
                Issuer : /O=CAcert Inc./OU=http:\/\/www.CAcert.org/CN=CAcert Class 3 Root
                Serial : 02F8CE
                Certificate expiration date:
                        notBefore : Apr 28 11:20:38 2022 GMT
                        notAfter : Apr 27 11:20:38 2024 GMT

Number of certificates: 3
        Signer #0:
                Subject: /CN=Stefan Weil/emailAddress=sw@weilnetz.de
                Issuer : /O=CAcert Inc./OU=http:\/\/www.CAcert.org/CN=CAcert Class 3 Root
                Serial : 02F8CE
                Certificate expiration date:
                        notBefore : Apr 28 11:20:38 2022 GMT
                        notAfter : Apr 27 11:20:38 2024 GMT
        ------------------
        Signer #1:
                Subject: /O=CAcert Inc./OU=http:\/\/www.CAcert.org/CN=CAcert Class 3 Root
                Issuer : /O=Root CA/OU=http:\/\/www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org
                Serial : 0E
                Certificate expiration date:
                        notBefore : May 23 17:48:02 2011 GMT
                        notAfter : May 20 17:48:02 2021 GMT
        ------------------
        Signer #2:
                Subject: /O=Root CA/OU=http:\/\/www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org
                Issuer : /O=Root CA/OU=http:\/\/www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org
                Serial : 0F
                Certificate expiration date:
                        notBefore : Mar 30 12:29:49 2003 GMT
                        notAfter : Mar 29 12:29:49 2033 GMT

Authenticated attributes:
        Message digest algorithm: SHA256
        Message digest: 8A00F57867BE173C77DDA23564C1986AACED9A327843B02AB565D1549AEA0549
        Signing time: Dec  8 02:15:06 2022 GMT
        Microsoft Individual Code Signing purpose
        URL description: https://qemu.weilnetz.de/
        Text description: QEMU Setup

The signature is timestamped: Dec  8 02:15:06 2022 GMT
Hash Algorithm: sha256
Timestamp Verified by:
                Issuer : /C=US/O=DigiCert, Inc./CN=DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA
                Serial : 0C4D69724B94FA3C2A4A3D2907803D5A

CAfile: (null)
CRL distribution point: http://crl.cacert.org/class3-revoke.crl
Use the "-TSA-CAfile" option to add the Time-Stamp Authority certificates bundle to verify the Timestamp Server.
ACE00000:error:1700006B:CMS routines:cms_get_enveloped_type:content type not enveloped data:crypto\cms\cms_env.c:41:
Timestamp Server Signature verification: failed
Failed to add store lookup file
Signature verification: failed

Number of verified signatures: 1
Failed

The qemu team sort of has a backlog when it comes to windows-side bugs and doesn't get to them fast enough. But i'll try ping again.

in summary:
It might be the case that the pe-header is a just coincidental parallel problem. While it is disconcerting, it might be a minor tooling issue.
As the executable can self-inflate itself smoothly, 7z should also be able to.

[hgkamath]

Also, qemu-project currently have the 7.2 release going on.

[Igor Pavlov]

As I wrote before, the problem with PE headers is separate problem.
7-Zip can't unpack that file, bacause qemu uses new nsis uninstaller feature unsupported by current 7-zip.

Actually when you unpack exe file, 7-zip uses several levels of parsing:
At first level 7-Zip sees PE (EXE) headers and tries to parse PE headers.
Then it sees NSIS installer inside big PE file, and it uses NSIS parser. It looks so:

1) NSIS PE EXE STUB with resources
2) NSIS data package (compressed)
3) SIGNATURE

7-Zip doesn't know about new feature inside nsis package. That is why we have unpacking error.

When I debugged that file, I saw that PE headers also incorrect , Probably it's because they inserted some resources and/or signature to exe stub with some incorrect way or with some incorrect tool. It doesn't interfere 7-Zip to unpack NSIS part, it's just distinct problem.

[Jason]

In NSIS 3.08, we did change the uninstaller code to a hybrid system, where if you don't use !uninstfinalize, it will act the same as the older versions to save space. If you do use !uninstfinalize, makensis will assemble and write out the uninstaller as a whole file, so you can do cool things like sign it, then it just adds the uninstaller back in just like a 'File' command in the script.

Technical details: in the exehead uninstaller code, you can just check 'parm2' (icon size): if it's zero, it's a single whole file; if it's non-zero, then it's an old style patched uninstaller.

PS: I developed the uninstaller code for this :).

There was a patch in NSIS for mingw-w64 a few months ago that disabled .reloc sections because the default setting changed, don't know if that applies here though.