The detector already used the CLR data-directory RVA to split DLLs into
NativeDll / ManagedDll; EXEs were a single undifferentiated Exe kind.
Apply the same CLR check to EXEs so callers can tell a protected .NET
executable from a native one without unpacking. Routing is unchanged:
both EXE kinds go to the EXE pipeline.
- CLI per-file lines and the run log now print NativeExe / ManagedExe
(the kind comes from the same Debug formatting as the DLL variants).
- The web API's detect()/unpack_file() kind strings become
'native-exe' / 'managed-exe'; the web UI gains matching labels, and
the trap-retry guard (DLL-probe recovery) keys off both EXE kinds.
Golden corpus unchanged (35/35 byte-identical); kind is classification
only and never affects output bytes.
Managed EXE builds differ from their native counterparts in the old
layout: the encrypted import-name table pointer is null (their imports
are just the CLR bootstrap stub), the config block's entry-point field
is 0, and the COR20 header / BSJB metadata stream / CLR resources are
stored verbatim in the protected file rather than arriving through the
section-block pass.
- Skip the import-string walk when the table pointer is null instead of
chasing header garbage as a pointer chain (previously a caught
out-of-bounds panic reported as corrupt input).
- Keep the protected header's entry point when the config block stores
0, instead of overwriting it with 0.
- Restore the COR20 header, BSJB metadata stream, and CLR resources
verbatim from the protected file after the .text dd8 pass, and
suppress the native COR20-directory clearing when the restore ran.
Validated by decompiling the unpacked managed EXEs with ilspycmd: full
assemblies (types, methods, IL bodies) decompile cleanly. Golden corpus
unchanged (35/35 byte-identical).
Momoko-Ayase