Valid HTML 4.01 Transitional Valid CSS Valid SVG 1.0

Me, myself & IT

ATTENTION: due to the termination of my provider's homepage service, the web pages and all content located below will become unavailable on January 31, 2017!

All web pages and other content will then be available solely on
Please update your bookmarks and references!

Executable installers considered harmful

Executable installers as well as self-extracting executable archives (SFXs, typically seen on Microsoft® Windows® only) are braindead insanely stupid in concept and dangerous in practice!
They should be considered harmful and treated as unwanted programs malware!

Problems and deficiencies


Mitigations for (end) users and (their) administrators

Mitigations for developers

Detection of vulnerable executables

  1. Create an UAC-enabled protected administrator test account;

  2. Create an empty file %SystemRoot%\Debug\SAFER.log, grant your test account at least append data permission to it, then remove the permissions for all other accounts;

  3. Create the following Registry entries to enable Software Restriction Policies, without restrictions, with advanced logging, for all users, for all executable files and DLLs:

    ; Copyright © 2005-2017, Stefan Kanthak <>
    "DefaultLevel"=dword:00040000                 ; 'Unrestricted'
    "Levels"=dword:00071000                       ; Enable all levels
    "PolicyScope"=dword:00000000                  ; Apply to 'Users' and 'Administrators'
    "TransparentEnabled"=dword:00000002           ; Apply to executable files and DLLs
    Note: Win32 applications and DLLs are subject to Software Restriction Policies independent of their file extension!
  4. Logon with your test account;

  5. Create an empty directory (or use the existing directory %USERPROFILE%\Downloads\);

  6. Open a command prompt in the choosen (empty) directory and run the following command line to create hardlinks to all system DLLs found in the search path in it:

    For %! In ("%PATH:;=" "%") Do For %? In ("%~!\*.DLL"
                                             "%~!\*.TSP") Do If Not Exist "%~nx?" MkLink /H "%~nx?" "%?"
    Note: the command processor and its builtin MkLink command have to be run under the NT AUTHORITY\SYSTEM account!
  7. Copy your executables into this directory and execute them per double-click;

  8. Determine the DLLs your executables loaded from the application directory by running the following command line in the still open command prompt:

    "%SystemRoot%\System32\Find.exe" /I "%CD%\" "%SystemRoot%\Debug\SAFER.log"
  9. Fix the vulnerable executables and retest them!


Download the executable installers 7z1602.exe and 7z1602-x64.exe, save them in the prepared directory %USERPROFILE%\Downloads\ and execute them just until they display their first dialog box which prompts for the target directory: Note: on all supported versions of Windows NT, UXTHEME.DLL is loaded from the program's application directory %USERPROFILE%\Downloads\ instead Windows' system directory %SystemRoot%\System32\ alias %SystemRoot%\SysWoW64\ respectively, resulting in an LCE vulnerability.
Note: on Windows Vista and newer versions of Windows NT, 7z1602.exe and 7z1602-x64.exe request administrative privileges via their embedded application manifest, resulting in an additional EoP vulnerability!

Advantages of native installation packages

The point is: well-known package formats allow you to inspect things, binary executables generally don't.
In more detail:
  1. It's not a vulnerability, but a weakness and (design) bug in the first place: there is no need to execute (potentially malicious) programs from (potentially) untrusted sources or with questionable (unknown or even malicious) contents to install software.
    This weakness turns into a vulnerability, if

  2. Binary executables are generally opaque: you can't tell what they actually do unless you have their source (and built them yourself in a trusted environment), or until you reverse engineer them completely.
    In case of installers, you need the sources of the installer (plus its unpacker), the sources of the creator and the sources of the script used to build the final binary executable.

  3. The format of these packages is well-known and documented, they can be unpacked and their contents as well as their instructions/scripts read and inspected.
    The tools to create/build, edit/modify, unpack and even rebuild them are typically part of the OS's package manager or provided as part of the OS's SDK.

Always use the target platforms native package or archive formats to distribute your software or files!
The problem are the morons who build binary executables to install software (or just unpack some files) and hand these binary executables to unsuspecting and unskilled users, expecting them to actually execute them.
This really nasty behaviour of almost all developers/companies out there trained users to execute almost anything they get their hands on.
The solution for this is simple: � � � � � � �


If you miss anything here, have additions, comments, corrections, criticism or questions, want to give feedback, hints or tipps, report broken links, bugs, errors, inaccuracies, omissions, vulnerabilities or weaknesses, …:
don't hesitate to contact me and feel free to ask, comment, criticise, flame, notify or report!

Use the X.509 certificate to send S/MIME encrypted mail.

Notes: I dislike HTML (and even weirder formats too) in email, I prefer to receive plain text.
I also expect to see a full (real) name as sender, not a nickname!
Emails in weird formats and without a proper sender name are likely to be discarded.
I abhor top posts and expect inline quotes in replies.

Terms and conditions

By using this site, you signify your agreement to these terms and conditions. If you do not agree to these terms and conditions, do not use this site!
• Copyright © 1995-2017 • Stefan Kanthak • <­skanthak­@­arcor­.­de­>