It is a poorly kept secret that the Microsoft Linker emits an undocumented data structure between the DOS stub executable and the actual Windows executable data. This data structure contains (poorly) encrypted information about the environment in which the executable was produced. The information can be used in computer forensics to identify authors of executables.

This excellent article explains the so-called 'Rich' header in great detail.

This tool can automatically patch any version of the Microsoft Linker so that it does not produce the 'Rich' header.

The images below compare an executable produced by an unpatched linker and one produced by a linker patched with this tool:

Before	After

link-patcher 1.0.0
Malte Thiesen <[email protected]>
Patches the Microsoft Linker so that it produces executables without the 'Rich' header

USAGE:
    link-patcher.exe [FLAGS] <input_file>

FLAGS:
    -a, --apply_patch    Applies the patch to the executable after a manual confirmation. A back-up of the original file
                         is created.
    -h, --help           Prints help information
    -V, --version        Prints version information

ARGS:
    <input_file>

The function that writes the 'Rich' header is called IMAGE::CbBuildProdidBlock() as revealed by the debug information for link.exe on the Microsoft public symbol server. The article linked above suggests a manual process that involves patching all call sites of this function. The patch lets the linker generate and write the structure but removes the instruction that advances the write pointer, so that the next chunk of data written overwrites the 'Rich' header.

I am using a different approach to reduce the amount of analysis I have to do. It is not trivial to find all call sites of IMAGE::CbBuildProdidBlock() automatically. Instead, I aim to patch the function itself, so that it always returns 0. Usually, the function returns the size of the generated header structure in bytes. If this is always 0, the effect is the same as with the other patch: the header data is created and written, but the write pointer is not advanced.

This is a rough overview of the patching process:

1. Find a range of bytes in the executable code segment where the two constants used by the function (Rich and DanS) appear in close proximity.
2. Disassemble the range of bytes using the excellent Capstone-rs crate.
3. Find the next ret instruction after the last usage of the constants.
4. Scan back to find the last modification of eax before ret. This is where the return value is set.
5. Replace this instruction with xor eax, eax and pad the remaining instruction bytes with nop. This sets the return value to 0.

As you can see, this approach is not very sophisticated, for instance, I don't do any flow analysis, I just assume that the next ret instruction is the one that is actually taken. Simple as it may be, in practice, the tool works just fine. It reliably finds correct patches for all versions of link.exe that I could get hold of.

The table below lists the found patches. I am using integration tests to verify that the patched linker executables are still working and do not produce a 'Rich' header.