Vulnerability and Exploit Detector 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 http://home.arcor.de/skanthak/ will become unavailable on January 31, 2017!

All web pages and other content will then be available solely on https://skanthak.homepage.t-online.de/.
Please update your bookmarks and references!


Vulnerability and Exploit Detector

[Screenshot of SENTINEL.EXE started on Windows XP by defective scanner software]

Purpose

The Vulnerability and Exploit Detector for Microsoft® Windows® NT consists of the executable files SENTINEL.DLL and SENTINEL.EXE.
They are used as canaries to indicate the execution of bogus or rogue DLLs and programs from unintended or unwanted locations, typically in order to detect and demonstrate programming errors which lead to weaknesses and vulnerabilities, or to catch and detect (malicious) code which exploits such weaknesses and vulnerabilities.
When placed in trusted locations of the search path, before untrusted locations like the CWD, they additionally act as sentinels and prevent the execution of bogus or rogue DLLs and programs.

Reason

Way too many Windows DLLs and programs, especially setup programs which typically have to be run with administrative privileges, suffer from poor insecure search path handling, resulting in well-known weaknesses like CWE-426: Untrusted Search Path, CWE-427: Uncontrolled Search Path Element and CWE-428: Unquoted Search Path or Element documented in the CWE, and allowing well-known attacks like CAPEC-471: DLL Search Order Hijacking documented in the CAPEC.

Operation

SENTINEL.EXE is typically placed as PROGRAM and/or PROGRAM.EXE in the root directory of the %SystemDrive%; if creation of 8.3 filenames is enabled SENTINEL.EXE can be copied as is and a short 8.3 filename PROGRAM or PROGRAM.EXE set:
"%SystemRoot%\System32\FSUtil.Exe" File SetShortName "%SystemDrive%\SENTINEL.EXE" PROGRAM.EXE
To list other locations (i.e. directories with a space in their name) where SENTINEL.EXE may be placed, start a Command Prompt and run the following command lines:
For /D /R "%SystemRoot%" %! In ("* *") Do @Echo %!
For /D /R "%ProgramFiles%" %! In ("* *") Do @Echo %!
If Defined ProgramFiles(x86) For /D /R "%ProgramFiles(x86)%" %! In ("* *") Do @Echo %!
For /D /R "%USERPROFILE%" %! In ("* *") Do @Echo %!
SENTINEL.DLL is placed in the CWD and/or the application directory of programs which load DLLs during load-time and/or runtime, using the filename of one or more DLLs loaded by the respective program or any (other) DLL loaded by it.
Note: on systems with AMD64 alias x64 processor architecture, SENTINEL.DLL is loaded only if its execution environment matches that of the calling process!

When executed, SENTINEL.DLL and SENTINEL.EXE write a message similar to that shown above to Windows' Event Log using the source Vulnerability and Exploit Detector.
To retrieve these messages from the Event Log, start a Command Prompt and run the following command line:

"%SystemRoot%\System32\WBEM\WMIC.Exe" NTEvent Where "SourceName='Vulnerability and Exploit Detector'" Get /Value
For a typical output of this command line see SENTINEL.TXT.

When SENTINEL.EXE runs in an interactive user session it also displays the message box shown above.
Note: the calling process can only be determined if it still exists and SENTINEL.EXE runs in the same (unprivileged) security context as the calling process, on systems with AMD64 alias x64 processor architecture also in the same (32- or 64-bit) execution environment as the calling process!
To test SENTINEL.EXE, execute it per double-click from Windows Explorer or call it from a Command Prompt.

When SENTINEL.DLL runs in an interactive user session it also displays one or more message boxes similar to the one shown above.
Note: the message box displayed during the initial call of SENTINEL.DLL (DLL_PROCESS_ATTACH) offers the choice to return success or failure to the calling process. The Win32 functions LoadLibrary() and LoadLibraryEx() yield ERROR_DLL_INIT_FAILED for failure, while Windows' module loader yields STATUS_DLL_INIT_FAILED.
To test SENTINEL.DLL, open a Command Prompt and run one of the following command lines:

"%SystemRoot%\System32\RegSvr32.Exe" /I /N /S "‹path›\SENTINEL.DLL"
"%SystemRoot%\System32\RegSvr32.Exe" /S "‹path›\SENTINEL.DLL"
"%SystemRoot%\System32\RegSvr32.Exe" /S /U "‹path›\SENTINEL.DLL"
"%SystemRoot%\System32\RunDLL32.Exe" "‹path›\SENTINEL.DLL",RunDLL

Limitation

When SENTINEL.DLL is (renamed and) used as static (load-time) dependency of an arbitrary executable (a program or another DLL), loading of this executable usually fails due to unresolved external symbols or ordinals, and SENTINEL.DLL is not run: SENTINEL.DLL does not export the symbols and ordinals of the original DLL.

This limitation can be overcome by forwarding the missing exports to the original DLL using a .Def file:

LIBRARY ‹module›

EXPORTS
        ‹symbol›=[C:\Windows\]System32\‹filename›.‹symbol› @‹ordinal› PRIVATE
        …
        @‹ordinal›=[C:\Windows\]System32\‹filename›.#‹ordinal› @‹ordinal› NONAME PRIVATE
        …
Caveat: forwarding is only possible to DLLs with extension .Dll!
Note: original DLLs located in Windows' system directory %SystemRoot%\System32\ can be referenced with their relative pathname System32\‹filename› since the windows directory %SystemRoot%\ is in the search path too.

A complete set of forwarder DLLs for all system DLLs of Windows XP and Windows 7 is available upon request.

Background information

Execution of bogus or rogue programs

The most prominent notorious, well-known and well-documented example is the unintended execution of
%SystemDrive%\Program.Exe or (for example)
"%SystemDrive%\Program Files\Internet.Exe" alias
"%ProgramFiles%\Internet.Exe" instead of the intended execution of (again for example)
"%SystemDrive%\Program Files\Internet Explorer\IExplore.Exe" alias
"%ProgramFiles%\Internet Explorer\IExplore.Exe" due to missing quotes around the long filename or pathname of the executable file that contains spaces when used in a command line like
%SystemDrive%\Program Files\Internet Explorer\IExplore.Exe -nohome alias
%ProgramFiles%\Internet Explorer\IExplore.Exe -nohome.

The resulting weakness is listed as CWE-428: Unquoted Search Path or Element in the CWE.

This (unfortunately way too) common programmer's beginner's error is documented in the MSDN articles for the Win32 functions CreateProcess(), CreateProcessAsUser(), CreateProcessWithLogonW(), CreateProcessWithTokenW() and WinExec() under the heading Security Remarks, for the Win32 function CreateService(), and (for example) in the MSKB articles 134425, 139427, 140724 and 812486.

The (to say the very least) weird braindead behaviour of these Win32 functions which lets this beginner's error go undetected (without a properly named sentinel placed aside all executable files with a space in their name and all directories with a space in their name which contain executable files) is documented in the MSDN articles referenced above under the heading Parameters and exists since the introduction of long filenames with Win32 in Windows NT 3.1 (and of course Windows 95 too) more than 20 years ago:

[…] the module name must be the first white space-delimited token in the lpCommandLine string. If you are using a long file name that contains a space, use quoted strings to indicate where the file name ends and the arguments begin; otherwise, the file name is ambiguous. For example, consider the string "c:\program files\sub dir\program name". This string can be interpreted in a number of ways. The system tries to interpret the possibilities in the following order:
c:\program.exe files\sub dir\program name
c:\program files\sub.exe dir\program name
c:\program files\sub dir\program.exe name
c:\program files\sub dir\program name.exe
These Win32 functions play try & error where they should but fail and return an error to their caller!

Note: the following rules of interpretation are missing in the documentation:

To perform a quick (but non-exhaustive) check whether your Windows installation is affected, start a Command Prompt, run the following command lines, and inspect their output:

FType | "%SystemRoot%\System32\Find.Exe" /I "=%ProgramFiles%\"
FType | "%SystemRoot%\System32\Find.Exe" /I "=%ProgramFiles"
FType | "%SystemRoot%\System32\Find.Exe" /I "=%CommonProgramFiles"
FType | "%SystemRoot%\System32\Find.Exe" /I "=!USERPROFILE:\%USERNAME%=\!"
FType | "%SystemRoot%\System32\Find.Exe" /I " %ProgramFiles%\"
FType | "%SystemRoot%\System32\Find.Exe" /I " %ProgramFiles"
FType | "%SystemRoot%\System32\Find.Exe" /I " %CommonProgramFiles"
FType | "%SystemRoot%\System32\Find.Exe" /I " !USERPROFILE:\%USERNAME%=\!"
"%SystemRoot%\System32\WBEM\WMIC.Exe" Service Get PathName /Value | "%SystemRoot%\System32\Find.Exe" /I "\Windows "
"%SystemRoot%\System32\WBEM\WMIC.Exe" Service Get PathName /Value | "%SystemRoot%\System32\Find.Exe" /I "=%ProgramFiles%\"
"%SystemRoot%\System32\WBEM\WMIC.Exe" Service Get PathName /Value | "%SystemRoot%\System32\Find.Exe" /I "=!USERPROFILE:\%USERNAME%=\!"
For a more thorough check download, read and run the batch scripts SLOPPY.CMD, SLOPPY7X.CMD and SLOPPY7D.CMD.

If you detect an unquoted long filename or pathname containing spaces in a command line, direct the author(s) of the defective software (for example) to the MSKB articles 102739, 166827 and 170669, the MSDN articles Extending Shortcut Menus, Verbs and File Associations, Best Practices for File Associations, Registering Programs with Client Types and How to Register an Internet Browser or Email Client With the Windows Start Menu, plus the TechNet article Using Long File Names and request a fix for this well-known vulnerability!

If any element of the command string contains or might contain spaces, it must be enclosed in quotation marks. Otherwise, if the element contains a space, it will not parse correctly. For instance, "My Program.exe" starts the application properly. If you use My Program.exe without quotation marks, then the system attempts to launch My with Program.exe as its first command line argument. You should always use quotation marks with arguments such as %1 that are expanded to strings by the Shell, because you cannot be certain that the string will not contain a space.
The command line must specify a fully qualified absolute path to the file, followed by optional command-line options. Use quotation marks appropriately to ensure that spaces in the command line are not misinterpreted.
lpBinaryPathName [in, optional]
The fully qualified path to the service binary file. If the path contains a space, it must be quoted so that it is correctly interpreted. For example, "d:\\my share\\myservice.exe" should be specified as "\"d:\\my share\\myservice.exe\"".

To perform a quick (but non-exhaustive) check whether your Windows installation is affected by the other two aforementioned bugs, start a Command Prompt, run the following command lines and inspect their output:

FType | "%SystemRoot%\System32\Find.Exe" /V "."
FType | "%SystemRoot%\System32\Find.Exe" /V "\"
FType | "%SystemRoot%\System32\Find.Exe" /I " %L"
FType | "%SystemRoot%\System32\Find.Exe" " %1"
For a more thorough check download, read and run the batch scripts SLOPPY.CMD, SLOPPY7X.CMD and SLOPPY7D.CMD.

If you detect a simple filename or a partial (relative) pathname instead of a full (absolute) pathname or an unquoted argument (anywhere, not only) in the command lines printed by FType, direct the author(s) of the vulnerable software (for example) to the MSDN articles referenced above and request a fix for this well-known vulnerability!

Also ask the author(s) of the defective software why they don't use Application Verifier to test their software!

Calls to the CreateProcess API function are subject to attack if parameters are not specified correctly. AppVerifier generates an error if CreateProcess (or other related API functions) are called with a NULL lpApplicationName parameter and an lpCommandLine parameter that contains spaces. For example, it does not allow the following as the command line parameter:
            c:\program files\sample.exe -t -g c:\program files\sample\test
        
Using this command line, an application can inadvertently execute unwanted code if a malicious user installs his program to C:\Program.

Execution of bogus or rogue DLLs

The other prominent infamous and well-known example, first reported on September 18, 2000 as Georgi Guninski security advisory #21, 2000 and listed as CVE-2000-0854 in the CVE®, is the unintended execution of bogus or rogue DLLs (and programs) with the well-known filename of a system DLL (or a system program) from (usually) the CWD or the application directory instead of Windows' system directory due to insecure search path handling and the use of a simple filename or a relative (partial) pathname instead of an absolute (full) pathname, known as DLL spoofing alias DLL preloading, directory poisoning, binary planting, DLL hijacking and DLL side-loading.

The resulting weaknesses are listed as CWE-426: Untrusted Search Path and CWE-427: Uncontrolled Search Path Element in the CWE.

The posts MS09-014: Addressing the Safari Carpet Bomb vulnerability, More information about the DLL Preloading remote attack vector and An update on the DLL-preloading remote attack vector on Microsoft's Security Research and Defense Blog give additional information.

For loading of DLLs the proper and secure search path handling is documented in the MSDN articles Dynamic-Link Library Security and Dynamic-Link Library Search Order, the Security Advisory 2269637, the MSKB articles 2389418 and 2533623, plus the post Load Library Safely:

Applications can control the location from which a DLL is loaded by specifying a full path or using another mechanism such as a manifest.
Wherever possible, specify a fully qualified path when using the LoadLibrary, LoadLibraryEx, CreateProcess, or ShellExecute functions.
Use fully qualified paths for all calls to LoadLibrary, CreateProcess, and ShellExecute where you can.
This exploit may occur when applications do not directly specify the fully qualified path to a library it intends to load.
Always specify the fully qualified path when the library location is constant.

Additionally see the MSDN articles Self-Registration as well as DefaultIcon, LocalServer and LocalServer32:

The server must register the full path to the installation location of the DLL or EXE module for their respective InprocServer32, InprocHandler32, and LocalServer32 keys in the registry.
This is a REG_SZ value that specifies the full path to the executable name […]
Specifies the full path to a 16-bit local server application.
Specifies the full path to a 32-bit local server application.

[…]

The ServerExecutable value, which is of type REG_SZ and is supported starting with Windows Server 2003, works in conjunction with the LocalServer32 subkey to prevent any ambiguity when using the CreateProcess function. LocalServer32 specifies the location of the COM server application to launch, and this information is passed as the first parameter lpApplicationName for CreateProcess. Depending on the implementation of CreateProcess, this information might be ambiguous. For this reason, if ServerExecutable is specified, COM passes the ServerExecutable named value to the lpApplicationName parameter of CreateProcess. If ServerExecutable is not specified, COM passes NULL as the value for the first parameter of CreateProcess.

To help provide system security, use quoted strings in the path to indicate where the executable filename ends and the arguments begin.

Note: the MSDN articles InprocHandler, InprocHandler32, InprocServer, InprocServer32 and ToolBoxBitmap32 fail to specify the use of full (absolute) pathnames and need to be corrected!

Again: if you detect a simple filename or a partial (relative) pathname instead of a full (absolute) pathname in a call to a Win32 function that loads an executable file, in a command line, in the Registry, in a DESKTOP.INI file etc. as well as an unquoted argument in a command line, direct the author(s) of the vulnerable software (for example) to the MSDN articles referenced above as well as Guidelines For Developers and request a fix for this well-known vulnerability!

Known vulnerabilities

Some, but not all (now fixed) individual vulnerabilities due to insecure search path handling only in Microsoft products are documented in the MSKB articles 306850, 819125, 905890, 959426, 2264107, 2533623, 2570947, 2686509, 2719662, 3063858, 3072620, 3072631, 3074162, 3080348, 3108347, 3108371, 3108381, 3108664, 3110329, 3116162, 3121461, 3121918, 3134228, 3140709, 3148789 and 3163610, the Security Bulletins MS06-051, MS09-014, MS09-015, MS11-071, MS12-034, MS15-063, MS15-069, MS15-070, MS15-082, MS15-132, MS16-007, MS16-014, MS16-025, MS16-041 and MS16-070, plus the Security Advisories 953818, 2269637, 2719662 and 3074162.
At the time of writing the Security Advisory 2269637 lists 29 additional Security Bulletins!

The vulnerability fixed by 3121918 is listed as CVE-2016-0014 in the CVE®: whenever an application used Win32 functions involving the Encrypting File System, FEClient.Dll was loaded using its simple filename instead of its fully qualified (absolute) pathname %SystemRoot%\System32\FEClient.Dll.
Please notice the entries for January 2016 on Acknowledgments – 2016.

A variant of this programming error is documented in the MSDN articles for the Win32 functions LoadLibrary() and LoadLibraryEx() under the heading Security Remarks.

For the execution of programs some, but not all (now fixed) individual vulnerabilities due to insecure search path handling only in Microsoft products are documented in the MSKB articles 264061, 269049, 2781197, 2823482 and 2847927, plus the Security Bulletins MS00-052, MS13-034 and MS13-058.

The MSKB article 249321 but proposes to replace an absolute (full) pathname with a simple filename which introduces this vulnerability!
Note: a Registry entry of type REG_EXPAND_SZ with value %SystemRoot%\System32\UserInit.Exe would but avoid both errors!

For the Win32 functions CreateProcess(), CreateProcessAsUser(), CreateProcessWithLogonW() and CreateProcessWithTokenW() another (now fixed) individual vulnerability where the command processor was called using the simple filename CMD instead of its fully qualified (absolute) pathname %COMSPEC% alias %SystemRoot%\System32\CMD.Exe is documented in the MSKB article 2922229 and the Security Bulletin MS14-019.
Please notice its Acknowledgements section, or see the entries for April on Acknowledgments – 2014.

The post MS14-019 - Fixing a binary hijacking via .cmd or .bat file on Microsoft's Security Research and Defense Blog gives additional information.

This vulnerability is listed as CVE-2014-0315 in the CVE®.

[Screenshot from german MSKB article 2647300: REGEDIT.EXE showing command lines with unquoted 'long' pathnames and a simple filename] Many setup scripts for device drivers of many vendors (including many WHQL certified device drivers available from Windows Update and the Microsoft Update Catalog) suffer from both beginner's errors too!

See the screenshot on the right for some examples of command lines with unquoted long pathnames and a simple filename.

Please notice the entries for May 2014 and June 2015 on Security Researcher Acknowledgments Microsoft Online Services - Prior Months.

Programs that are run from the user's Downloads directory %USERPROFILE%\Downloads\, or the Temp directory %TEMP%\ alias %USERPROFILE%\AppData\Local\Temp\ or %SystemRoot%\Temp\ respectively, typically and especially (self-extracting or self-unpacking) installers, almost always load some DLLs from these directories (which are their application directory), and typically also execute their payload from there.

IExpress installers like CAPICOM-KB931906-v2102.exe, a security (sic!) update documented in the MSKB article 931906 and the Security Bulletin MS07-028, DotNETFX.Exe and LangPack.Exe for the .NET Framework versions 1.0, 1.1 and 2.0, and many more are well-known examples for arbitrary code execution vulnerabilities, and since Windows Vista due to UACs installer detection privilege escalation vulnerabilities too!

All executable installers built with
InnoSetup load and execute DWMAPI.Dll or UXTheme.Dll, …;
InstallShield load and execute RichEd32.Dll, …;
NSIS before version 2.50 and 3.0b5 load and execute ShFolder.Dll, DWMAPI.Dll or UXTheme.Dll, SetupAPI.Dll, …;
WiX toolset before version 3.10.2 load and execute MSI.Dll, Version.Dll, …;
All self-extracting executable archives built with
7-Zip load and execute DWMAPI.Dll or UXTheme.Dll, …;
WinRAR before version 5.31 load and execute DWMAPI.Dll or UXTheme.Dll, RichEd20.Dll, RichEd32.Dll, …;

Known weaknesses

Each and every program not installed in Windows' system directory %SystemRoot%\System32\ (see Raymond Chen's TechNet magazine article Windows Confidential: History—the Long Way Through for some hindsight) that is statically linked against DLLs which are neither installed in the program's application directory nor listed as known DLLs (see but Windows Confidential: The Known DLLs Balancing Act) or that (delay-)loads DLLs which are not installed in the program's application directory without using their full (absolute) pathname is susceptible to DLL hijacking.

This attack is listed as CAPEC-471: DLL Search Order Hijacking in the CAPEC.

Well-known examples of such programs are

%SystemRoot%\Explorer.Exe:
loads and executes %SystemRoot%\ACLUI.Dll instead of %SystemRoot%\System32\ACLUI.Dll;
%SystemRoot%\RegEdit.Exe:
as above;
%SystemRoot%\Write.Exe;
%SystemRoot%\System32\SysPrep\SysPrep.Exe:
loads and executes %SystemRoot%\System32\SysPrep\CryptBase.Dll, …;
%SystemRoot%\System32\WBEM\WMIC.Exe;
Programs like %SystemRoot%\System32\SysPrep\SysPrep.Exe which silently gain full administrative privileges per UACs auto-elevation (mis)feature in protected administrator accounts and request administrative privileges in standard user accounts, or programs like %SystemRoot%\RegEdit.Exe which request full administrative privileges in protected administrator accounts, execute these bogus or rogue DLLs with full administrative privileges too.

Note: since creation (or replacement) of files in %SystemRoot%\ or %SystemRoot%\System32\SysPrep\ needs administrative privileges, this weakness alone does not allow privilege escalation; together with UACs auto-elevation (mis)feature for protected administrators, which can be (ab)used to create (or replace) arbitrary files in %SystemRoot%\ and below using the command line

"%SystemRoot%\System32\WUSA.Exe" "‹cabinet file›" /Extract:"‹target directory›"
it but becomes an exploitable vulnerability!

Implementation and build details

SENTINEL.DLL and SENTINEL.EXE are pure Win32 binary executables, written in ANSI C without the use of the MSVCRT libraries, built with the platform SDK for Windows Server 2003 R2 for use on Windows 2000 and newer versions of Windows NT.

SENTINEL.DLL exports DllCanUnloadNow and DllGetClassObject for calls from COM, DllInstall, DllRegisterServer and DllUnregisterServer for calls from RegSvr32.Exe, and RunDllW for calls from RunDLL32.Exe.

SENTINEL.DLL and SENTINEL.EXE are available for the I386 alias x86, AMD64 alias x64 and IA64 processor architectures of Windows NT.

Code authenticity and integrity

SENTINEL.DLL and SENTINEL.EXE are digitally signed using an X.509 certificate issued by WEB.DE TrustCenter E-Mail Certification Authority.
Serial number
73420882
0x04605052
Fingerprint
MD5: e5 0b 01 66 ce 2e 7a 03 f4 98 39 37 f6 f9 9f ba
SHA-1: 79 05 5d 63 2f 03 31 83 04 e2 ff 3b 25 b9 cc b6 70 ad ec 31
Download and install the CA and root X.509 certificates of WEB.DE to validate and verify the digital signature.

Download

AMD64\SENTINEL.DLL, AMD64\SENTINEL.EXE, I386\SENTINEL.DLL, I386\SENTINEL.EXE, IA64\SENTINEL.DLL, IA64\SENTINEL.EXE and the setup script SENTINEL.INF are packaged in the (compressed and digitally signed) cabinet file SENTINEL.CAB.
X:\> EXTRACT.EXE /D SENTINEL.CAB
Microsoft (R) Cabinet Extraction Tool - Version 5.1.2600.5512
Copyright (c) Microsoft Corporation. All rights reserved..

 Cabinet SENTINEL.CAB

03-16-2016  8:47:44p A---        32,065 SENTINEL.INF
03-16-2016  6:40:30p A---        28,312 AMD64\SENTINEL.DLL
03-16-2016  6:40:30p A---        28,824 AMD64\SENTINEL.EXE
03-16-2016  6:39:36p A---        27,288 I386\SENTINEL.DLL
03-16-2016  6:39:36p A---        27,288 I386\SENTINEL.EXE
03-16-2016  6:41:20p A---        39,064 IA64\SENTINEL.DLL
03-16-2016  6:41:20p A---        42,648 IA64\SENTINEL.EXE
                 7 Files        225,489 bytes

X:\>
Execute the command line
"%SystemRoot%\System32\Expand.Exe" /R SENTINEL.CAB /F:* "‹target directory›"
on Windows Vista and newer versions of Windows NT to extract all files into the specified directory, preserving their paths.
Note: Expand.Exe from prior versions of Windows NT ignore the paths and junk them!
Use Extract.Exe from the Support Tools on Windows XP and Windows Server 2003 instead.

Installation

The installation requires administrative privileges.

The setup script SENTINEL.INF copies SENTINEL.DLL and SENTINEL.EXE as %SystemRoot%\System32\.Dll and %SystemRoot%\System32\.Exe, as %SystemDrive%\Program.Dll and %SystemDrive%\Program.Exe, as "%ProgramFiles%\Common.Dll" and "%ProgramFiles%\Common.Exe", as "%ProgramFiles%\Internet.Dll" and "%ProgramFiles%\Internet.Exe", as "%ProgramFiles%\Microsoft.Dll" and "%ProgramFiles%\Microsoft.Exe", as "%ProgramFiles%\Windows.Dll" and "%ProgramFiles%\Windows.Exe", as "%CommonProgramFiles%\Microsoft.Dll" and "%CommonProgramFiles%\Microsoft.Exe", with various filenames into the user's Downloads directory "%USERPROFILE%\Downloads\" and the system's Temp directory %SystemRoot%\Temp\, creates Software Restriction Policies alias SAFER hash rules to allow execution of SENTINEL.DLL and SENTINEL.EXE from any path, defines the message source for the Event Log in the registry, creates an entry Vulnerability and Exploit Detector under Installed Updates, and finally executes both SENTINEL.DLL and SENTINEL.EXE from the installation directory to demonstrate and verify their correct function.

Note: on systems with AMD64 alias x64 processor architecture the installation must be run in the native (64-bit) execution environment to install SENTINEL.DLL and SENTINEL.EXE for both processor architectures!

Automatic online installation

If visited with Internet Explorer, this web page will prompt to install (the contents of) the package using Internet Component Download.
Note: on systems with AMD64 alias x64 processor architecture Internet Explorer (x64) must be used!

Manual offline installation

Download the package SENTINEL.CAB and verify its digital signature, then open it in Windows Explorer, extract its contents preserving the directory structure, right-click the extracted setup script SENTINEL.INF to display its context menu and click Install to run the installation.
Note: SENTINEL.EXE is run during installation for every processor architecture and displays the dialog box shown on top!

Deinstallation

Not provided.

Contact

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!

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!
[Counter]
• Copyright © 1995-2016 • Stefan Kanthak • <­skanthak­@­arcor­.­de­>