0

I have been analyzing several EXE installers using 7-Zip, which sometimes interprets .exe files as archives and displays their internal structure. In some of these files I have noticed two unusual entries:

  • A very large entry called [0] (hundreds of KB or even MB), which appears to be a section but is not visible in standard PE tools like CFF Explorer, PEView or x64dbg
  • Another file-like entry simply called SIGNATURE

This behavior occurs in .exe files that do not appear to be compressed with UPX or other common compression tools (as confirmed by tools like Detect It Easy). The file also appears to be a standard Windows Portable Executable.

My questions are:

  1. What exactly do the [0] and SIGNATURE entries represent in this context? Are they part of the PE structure, overlay data, digital signature, or something else?
  2. Why does 7-Zip interpret them as separate entries, while other PE analysis tools ignore or do not display them?
  3. Is there a way to replicate this behavior? For example, can I generate a minimal .exe file (e.g., compiled in C/C++ or using a specific tool) that causes 7-Zip to show [0] and/or SIGNATURE?
  4. Could this be related to how the file was compiled, signed, or integrated with resources?

Any information on what causes 7-Zip to parse some parts of a PE file differently would be greatly appreciated.

It seems that binary content interpreted as being contained within [0] is automatically displayed by 7-Zip when you open the file.

Screenshots:

Here 7-Zip interprets and displays SIGNATURE and [0] entries, which seem to be sections or embedded files

7-Zip

CFF Explorer does not show those sections that 7-Zip used to show

CFF Explorer

It's possible that 7-Zip interprets certain parts of the file (such as overlay data, unused space, or embedded metadata) as if they were archive entries. This might explain why it shows [0] and SIGNATURE, while standard PE tools ignore them.

Alternatively, these entries could represent special sections or metadata structures that only 7-Zip is able to detect and display explicitly — possibly due to how it parses the binary without strictly adhering to the formal PE section table.

I'd appreciate any insight into whether this behavior is specific to 7-Zip’s parsing logic or if there's an actual hidden structure in the file that other tools overlook.

Improve this question

2 Answers 2

Reset to default
2

What exactly do the [0] and SIGNATURE entries represent in this context? Are they part of the PE structure, overlay data, digital signature, or something else?

The CERTIFICATE part is not a PE section, it's a representation of PE directory SECURITY entry (#4). This is the digital signature. It is never loaded from the image so it has no section, but it is contained in the image and 7-Zip attempts to represent it.

[0], [1] and so forth represent unclaimed space in the file between the sections.

Strangely enough, 7-Zip doesn't show overlays/tail data, i.e. unclaimed space beyond all the sections.

Why does 7-Zip interpret them as separate entries, while other PE analysis tools ignore or do not display them?

I'm sure there are many PE analysis tools that do display at least the certificate part.

Is there a way to replicate this behavior?

See an answer to your first question and do that. Write in some data into SECURITY entry, and you'll see the CERTIFICATE "file". Make a hole between sections, or between the last section and SECURITY data (as represented in the directory) - and you'll get [N] entries.

To expand upon the last point: VirtualAddress field in SECURITY directory entry supposed to be a file offset for the data, and Size should be its size; there are however files in the wild with bogus data in that directory entry. I've found one on my PC (BitRock InstallBuilder's uninstall.exe). It doesn't contain an actual signature (it does, however, contain some tail data past all the sections) yet its SECURITY entry is filled in with some garbage in the VirtualAddress field (and normal looking size). 7-Zip takes that VirtualAddress as given and assumes this to be a valid file offset (it isn't, as the value is huge and the file is fairly small); it then adds huge [0] section as a fill-in between the last section and that offset.

So all you need to do to replicate this is to write some arbitrary data (just need to make the offset large enough) into SECURITY data directory entry.

Improve this answer
0

After further testing and AI queries, i discovered a simple and reproducible way to trigger the [0] and SIGNATURE entries to appear in 7-Zip when opening an .exe file, even with minimal binaries.

How did I replicate this behavior?

Here is a simple and reproducible method to make 7-Zip show these entries in any .exe file:

1. Create a self-signed code signing certificate:

Powershell

New-SelfSignedCertificate -DnsName "TestCert" -CertStoreLocation "cert:\CurrentUser\My" -Type CodeSigning

2. Append arbitrary binary data to an existing .exe:

Command Prompt

copy /b original.exe + payload.bin modified.exe

This will add data to the end of the executable that will not be part of the PE

⚠️I remember that this command does not work on Powershell!⚠️

3. Sign the modified executable:

⚠️ Note on signtool:
The signtool utility is part of the Windows SDK and is not available by default in standard PowerShell or CMD. To use it:

  • Open a Developer Command Prompt for Visual Studio (like x64 Native Tools Command Prompt)
  • Or manually add the path to signtool.exe in your system's PATH environment variable

Developer Command Prompt for Visual Studio

signtool sign /n "TestCert" /fd SHA1 .\modified.exe

This will sign the executable making the files appended to the end of the executable read-only.

What Happens in 7-Zip?

When you open modified.exe in 7-Zip , it will show:

  • A large entry named [0] — likely representing the unclaimed space between sections or overlay data appended to the file
  • An entry called SIGNATURE — which corresponds to the Authenticode digital signature

Why Does 7-Zip Show These?

7-Zip treats PE files more like potential archives than strictly structured binaries. It tries to extract and expose any internal content it can parse, even if it's not a real section.

This explains why:

  • [0] shows up as a pseudo-section (interpreted overlay/unclaimed space)
  • SIGNATURE appears as a separate file-like entry (parsed from the Authenticode signature)

Standard PE tools ignore these because they follow the formal PE layout strictly.

In conclusion

⚠️ Clarification on Read-Only Data:
The appended data isn't technically marked as "read-only" by the operating system. However, any modification to it after signing will invalidate the Authenticode signature . Therefore, for the signature to remain valid, this data should be treated as immutable — effectively making it "read-only" in practice.

This behavior is not limited to installers or packed executables — it can be easily reproduced on minimal .exe files by appending data and signing them.

By understanding how 7-Zip parses PE files differently, we can better interpret what [0], [1], and SIGNATURE really mean

After all this I managed to replicate this behavior in my custom installer and 7-Zip clearly shows these special areas 7zip

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.