Manifest

While writing both of Schema-Manifest For Your EXE and Compile Schema-Manifest For EXE articles I’ve came across many (MANY!) exceptions where the result execute (or library) was corrupted and simply refused to run.

I’ve initially thought it was an issue with the manifest being encoded incorrectly;
i. e. Unicode.
– although Unicode manifest should be fully supported,
it is still your best interest to always keep the content ASCII encoded,
Both of my main editors Notepad2 and Notepad++ failed to supply a unified result,
keeping the output either Unicode or UTF-8 Without BOM,
and while 8bit-Unicode Without BOM is visually identical to ASCII,
each of the characters WILL be holding twice the size of a *pure* ASCII one.

and somehow I’ve got the feeling that it matters…

anyway,
I’ve used EditPlus, which made sure the output is truly ASCII,
and I was also aware of not opening the manifest file after saving them using Notepad2/Notepad++
since those two were generous enough to do some background conversion… :/

I’ve also pondered the thought of committing manifest files as a binary-content,
using a .gitattributes with *.manifest binary entry (I eventually avoided of doing so..)

but this also didn’t solved it for me,
chrome.exe and several other executed repeatedly reported of an error with the “side-by-side manifest”,
regardless of the accuracy of the content.

To put try/error aspects in perspective,
-there is a very annoying (but useful, I’m sure) caching mechanisem
the allows some modifications of the manifest to take place,
and it all seems to be OK, just to have a “manifest error” pop-up message just after a cold reboot.

Solution (partial). Part #1.

I’ve used for most of the cases ResHacker for both editing (includes saving the result)
and writing a fresh new manifest block to executes,
yeah… ammm… 😏︎ don’t do that.

The manifest data-block, is..
..let me thing how to describe it..
well, sensitive.

When compiling an application,
your make (nmake, cmake, etc..) will write it properly,
and so is Micosoft’s MT.EXE.

This is why I’ve extracted this binary and wrapped it with an easy to use batch-file,
which is available here: github.com/eladkarako/manifest.

Once downloaded and extracted, it will support writing/rewriting most of
execute and library files with no particular issue.

I’ve even included a generic manifest (without name/description),
that would allow you to apply support for font-scale/high-DPI,
standard security and Windows-10 compatibility for most execute/library files (drag&drop!)

Solution – mysterious/weirdly compiled executes.

I’m extracting executes from weird places..
sometimes it is an execute that has been modified,
it can be a weird file-offset, undefined linker-info/subsystem,
data ep section but usually it is the OVERLAY!!!

[$hit!]

When dealing with file that has base-reloc or resources addresses malformed
or encrypted you really have once choice: rebuild and relink the data properly.

~~^^yeah right^^~~

Old versions of ACProtect, Armadillo, ASPack, ASProtect,
UPX (plain or modified) or even VMware’s ThinApp (thinstall) will use some type of “”encryption”” which normally means that the location of the real-data is not perfectly aligned and accessible for you to edit,
-And once you’ve edit it, you’ve deemed the execute corrupted (or even flagged as “modified” for the internal algorithm to compare signatures – and prevent your natural execution from proceeding as it should.

the best advice is: DON’T TOUCH IT!!!

..but you’re here for the solution…

You have to override the embedded manifest with an external “side-by-side” manifest,
normally you can’t since if the execute (or library!) has an embedded manifest,
it will take precedence over an external “side-by-side” one,

ahhhmmm.. *cough* – you can change this behavior.

Run this registry file (copy&paste it to a new file with .reg extension and run it)

Windows Registry Editor Version 5.00

;manifest - prefer external side-by-side file over internal-resource

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide]
"PreferExternalManifest"=dword:00000001

A cold reboot is required,
(and you may have to trigger “an uncache” by renaming the file one time and rename it back again)

but afterwards,
You’ll be able to override the embedded manifest,
without the need to modify the execute file at all.