Application Verifier Provider 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!


Application Verifier Provider

An Application Verifier Provider for Microsoft® Windows® XP and newer versions of Windows NT is a DLL which accepts DLL_PROCESS_VERIFIER as reason in its DllMain() routine and then returns the address of an initialized RTL_VERIFIER_PROVIDER_DESCRIPTOR structure to Windows' module loader.
Caveat: the call of the DllMain() routine with DLL_PROCESS_VERIFIER as reason happens before the call(s) with DLL_PROCESS_ATTACH as reason!
Caveat: Application Verifier Provider are loaded and initialized before the DLLs which implement the Win32 API; only the native API implemented by NTDLL.DLL is available for them!

See A Debugging Approach to IFEO and A Debugging Approach to Application Verifier for more details.

Purpose

The Application Verifier Provider VRFKNTHK.DLL is designed to discover some well-known and well-documented, but nevertheless (way too) common programmer's beginner's errors in Win32 applications and DLLs: CWE-426: Untrusted Search Path, CWE-427: Uncontrolled Search Path Element and CWE-428: Unquoted Search Path or Element listed in the CWE, as well as CAPEC-471: DLL Search Order Hijacking listed in the CAPEC.

VRFKNTHK.DLL helps software developers, integrators, packagers and testers to detect and fix these bugs in their own Win32 applications and all DLLs they use.

Note: VRFKNTHK.DLL works independent of Microsoft's Application Verifier!

Reason

Errors in the path handling of executable modules, especially in executable installers and self-extractors where such bugs are obviously industry standard, typically result in easy to exploit weaknesses and vulnerabilities.
Vulnerability and Exploit Detector and Executable installers considered harmful provide information about the history of these bugs and (some of) the affected products.

Operation

VRFKNTHK.DLL hooks the Win32 functions (in alphabetical order) AddDllDirectory(), ChangeServiceConfigA() and ChangeServiceConfigW(), CreateProcessA() and CreateProcessW(), CreateProcessAsUserA() and CreateProcessAsUserW(), CreateProcessInternalA() and CreateProcessInternalW(), CreateProcessWithLogonW(), CreateProcessWithTokenW(), CreateServiceA() and CreateServiceW(), LoadLibraryA() and LoadLibraryW(), LoadLibraryExA() and LoadLibraryExW(), LoadModule(), LoadPackagedLibrary(), SearchPathA() and SearchPathW(), SetDefaultDllDirectories(), SetDllDirectoryA() and SetDllDirectoryW(), SetSearchPathMode(), ShellExecuteA() and ShellExecuteW(), ShellExecuteExA() and ShellExecuteExW() plus WinExec(), exported from the DLLs ADVAPI32.DLL, KERNEL32.DLL, KERNELBASE.DLL, SECHOST.DLL and SHELL32.DLL, to log all calls of these Win32 functions with the values of their arguments, to check the values of (some of) the arguments and to call the native function RtlApplicationVerifierStop() to yield a verifier stop if one of the checks fails.

Caveat: due to a deficiency of Windows' module loader, forwarded exports are not hooked!

Note: no checks are performed when the Win32 function LoadLibraryEx() is called with the flag LOAD_LIBRARY_AS_DATAFILE since the DLLs DllMain() routine is not called then.

Note: the checks performed for calls of the Win32 functions LoadLibrary*() don't evaluate the known DLLs since these vary with Windows NT versions.

Note: the checks performed for calls of the Win32 functions LoadLibrary*() don't evaluate the flags set by the Win32 function SetDefaultDllDirectories() since this Win32 function is not available on all versions of Windows NT.

Note: the checks performed for calls of the Win32 function LoadLibraryEx() don't evaluate the flags to alter or restrict the search path since the optional update 2533623 as well as the security update MS12-081 alias 2758857 which introduced these flags are not available for all supported versions of Windows NT and may not be installed on every system for which it is available.

Note: the checks performed for calls of the Win32 function SearchPath() don't evaluate the flags set by the Win32 function SetSearchPathMode() since the security update MS09-015 alias 959426 which introduced the latter Win32 function may not be installed on every system for which it is available.

For every Win32 application ‹filename›.‹extension› you want to test, create the following Registry entries:

REGEDIT4

; Copyright © 2011-2017, Stefan Kanthak <skanthak@nexgo.de>

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\‹filename›.‹extension›]
"GlobalFlag"=dword:00000100
"VerifierDebug"=dword:00000000
"VerifierDlls"="VrfKnthk.dll"
"VerifierFlags"=dword:80000000

When ‹filename›.‹extension› is run under a debugger, each verifier stop prints a debug message and yields a breakpoint; if run without debugger, each verifier stop prints a debug message and continues.

===========================================================
VERIFIER STOP 0000FFFF: pid 0x89DC:
The application or a component it uses called LoadLibrary*() without providing an absolute local pathname for the module to load.

	7C801B21 : LoadLibraryA
	768817D8 : RichEd20.dll
	76881DD8 : CRYPTUI.DLL+0x00001DD8
	76881D80 : CRYPTUI.DLL+0x00001D80
===========================================================
This verifier stop is continuable.
After debugging it use `go' to continue.
===========================================================
is a typical debug message printed from a verifier stop of VRFKNTHK.DLL.
The 4 parameters of these debug messages are:
  1. the full name of the called Win32 function,
  2. the offending pathname, filename, directoryname, applicationname or command line passed to the Win32 function,
  3. the caller of the Win32 function,
  4. the caller's caller of the Win32 function;
    both callers are printed as modulename plus offset to help locating the culprit.
Note: use a utility like Sysinternals DebugView to watch the debug messages without a debugger.

Verifier stop codes and debug message texts

0xFFFF
The application or a component it uses called AddDllDirectory() without providing an absolute local pathname for the directory.
0xFFFF
The application or a component it uses called ChangeServiceConfig() without providing an absolute local pathname for the service executable.
0xFFFF
The application or a component it uses called CreateProcess*() without providing an absolute local pathname for the application to start.
0xFFFF
The application or a component it uses called CreateProcessInternal() without providing an absolute local pathname for the application to start.
0xFFFF
The application or a component it uses called CreateService() without providing an absolute local pathname for the service executable.
0xFFFF
The application or a component it uses called LoadLibrary*() without providing an absolute local pathname for the module to load.
0xFFFF
The application or a component it uses called LoadModule() without providing an absolute local pathname for the module to load.
0xFFFF
The application or a component it uses called SetDllDirectory() without providing an absolute local pathname.
0xFFFF
The application or a component it uses called ShellExecute*() without providing an absolute local pathname for the file to execute.
0xFFFF
The application or a component it uses called WinExec() without providing an absolute local pathname for the application to start.
0xFFFE
The application or a component it uses called AddDllDirectory() with the pathname of a not existing directory.
0xFFFE
The application or a component it uses called SetDllDirectory() with the pathname of a not existing directory.
0xFFFE
The application or a component it uses called …*() with the filename or pathname of a not existing file (which might be searched via PATH).
0xFFFD
The application or a component it uses called CreateProcess*() without providing the pathname of the executable in the 'lpApplicationName' parameter.
0xFFFC
The application or a component it uses called …*() without providing an absolute local pathname for the working directory.
0xFFFB
The application or a component it uses called …*() with the filename or pathname of a not existing working directory.
0xFFFA
The application or a component it uses called SetSearchPathMode() to disable 'safe process search mode'.

Examples

The bogus DLLs placed in the application directory %USERPROFILE%\Downloads\ of the example programs to demonstrate their vulnerabilities act as transparent proxies to the DLLs in Windows' system directory %SystemRoot%\System32\: they export all symbols and ordinals of the corresponding original DLL ‹filename›.DLL, forward them to the same symbols and ordinals of System32\‹filename›.DLL, and return TRUE from their DllMain() routine.
// Copyright © 2009-2017, Stefan Kanthak <skanthak@nexgo.de>

#pragma comment(linker, "/DLL")
#pragma comment(linker, "/ENTRY:_DllMainCRTStartup")
#pragma comment(linker, "/EXPORT:‹symbol›=System32\\‹filename›.‹symbol›,@‹ordinal›,PRIVATE")
…
#pragma comment(linker, "/EXPORT:‹ordinal›=System32\\‹filename›.#‹ordinal›,@‹ordinal›,NONAME,PRIVATE")
…
#pragma comment(linker, "/SUBSYSTEM:Windows")

#include <windows.h>

BOOL	WINAPI	_DllMainCRTStartup(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
	return TRUE;
}
Note: bogus DLLs built for the I386 alias x86 processor architecture of Windows NT work on the AMD64 alias x64 processor architecture too: Windows' module loader loads them and resolves their forwarded exports, but does not call their DllMain() routine!

Example 0

Download the executable installers 7z1602.exe and 7z1602-x64.exe, save them in the directory %USERPROFILE%\Downloads\ and execute them just until they display their first dialog box which prompts for the target directory.

EXAMPLE0.TXT shows the output from Windows' command line debugger NTSD.EXE during execution of 7z1602.exe on Windows XP, where a bogus UXTHEME.DLL is loaded from the program's application directory C:\Documents and Settings\Stefan\Downloads\ instead Windows' system directory C:\Windows\System32\.

EXAMPLE0.LOG shows the output from Windows' command line debugger NTSD.EXE during execution of 7z1602-x64.exe on 64-bit Windows 7, where a bogus UXTHEME.DLL is loaded from the program's application directory C:\Users\Stefan\Downloads\ instead Windows' system directory C:\Windows\SysWOW64\.

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 EoP in addition to the LCE!

Example 1

EXAMPLE1.TXT shows the output from Windows' command line debugger NTSD.EXE during execution of the program
// Copyright © 2009-2017, Stefan Kanthak <skanthak@nexgo.de>

#pragma comment(lib, "KERNEL32.LIB")

#pragma comment(linker, "/ENTRY:WinMainCRTStartup")
#pragma comment(linker, "/SUBSYSTEM:Windows")

#include <windows.h>

void	WinMainCRTStartup()
{
	HMODULE hModule = LoadLibrary("C:\\Windows\\System32\\CRYPTUI.DLL");
	if (hModule == NULL)
		ExitProcess(GetLastError());

	if (!FreeLibrary(hModule))
		ExitProcess(GetLastError());

	ExitProcess(ERROR_SUCCESS);
}
on Windows XP, where a bogus RICHED20.DLL is loaded as runtime dependency of CRYPTUI.DLL from the program's application directory C:\Documents and Settings\Stefan\Downloads\ instead Windows' system directory C:\Windows\System32\.

Caveat: no fix available!

Use Software Restriction Policies alias SAFER to disable execution in untrusted directories!

Example 2

EXAMPLE2.TXT shows the output from Windows' command line debugger NTSD.EXE during execution of the program
// Copyright © 2009-2017, Stefan Kanthak <skanthak@nexgo.de>

#pragma comment(lib, "KERNEL32.LIB")

#pragma comment(linker, "/ENTRY:WinMainCRTStartup")
#pragma comment(linker, "/SUBSYSTEM:Windows")

#include <windows.h>

void	WinMainCRTStartup()
{
	HMODULE hModule = LoadLibrary("C:\\Program Files\\Common Files\\System\\WAB32.DLL");
	if (hModule == NULL)
		ExitProcess(GetLastError());

	if (!FreeLibrary(hModule))
		ExitProcess(GetLastError());

	ExitProcess(ERROR_SUCCESS);
}
on Windows XP, where a bogus MSOERT2.DLL is loaded as load-time dependency of WAB32.DLL from the program's application directory C:\Documents and Settings\Stefan\Downloads\ instead Windows' system directory C:\Windows\System32\.

Note: to fix this weakness, call

LoadLibraryEx("C:\\Program Files\\Common Files\\System\\WAB32.DLL", NULL, LOAD_WITH_ALTERED_SEARCH_PATH);
to load WAB32.DLL!

Example 3

EXAMPLE3.TXT shows the output during execution of the 32-bit program from example 2 on 64-bit Windows 7, where bogus CRYPTDLG.DLL, CRYPTUI.DLL, MSOERT2.DLL, UXTHEME.DLL, MSIMG32.DLL, SECUR32.DLL, VERSION.DLL and MSFTEDIT.DLL are loaded from the program's application directory C:\Users\Stefan\Downloads\ instead Windows' system directory C:\Windows\SysWoW64\.

EXAMPLE3.LOG shows the output during execution of the 64-bit program from example 2 on 64-bit Windows 7, where bogus CRYPTDLG.DLL, CRYPTUI.DLL, MSOERT2.DLL, UXTHEME.DLL, MSIMG32.DLL, SECUR32.DLL, SSPICLI.DLL, VERSION.DLL and MSFTEDIT.DLL are loaded from the program's application directory C:\Users\Stefan\Downloads\ instead Windows' system directory C:\Windows\System32\.

Example 4

EXAMPLE4.TXT shows the output from Windows' command line debugger NTSD.EXE during execution of the fixed 32-bit program
// Copyright © 2009-2017, Stefan Kanthak <skanthak@nexgo.de>

#pragma comment(lib, "KERNEL32.LIB")

#pragma comment(linker, "/ENTRY:WinMainCRTStartup")
#pragma comment(linker, "/SUBSYSTEM:Windows")

#include <windows.h>

void	WinMainCRTStartup()
{
#ifdef _WIN64
	HMODULE hModule = LoadLibraryEx("C:\\Program Files\\Common Files\\System\\WAB32.DLL",
#else
	HMODULE hModule = LoadLibraryEx("C:\\Program Files (x86)\\Common Files\\System\\WAB32.DLL",
#endif
	                                NULL, LOAD_WITH_ALTERED_SEARCH_PATH);
	if (hModule == NULL)
		ExitProcess(GetLastError());

	if (!FreeLibrary(hModule))
		ExitProcess(GetLastError());

	ExitProcess(ERROR_SUCCESS);
}
from example 2 on 64-bit Windows 7, where a bogus VERSION.DLL is loaded as (indirect) load-time dependency and a bogus MSFTEDIT.DLL is loaded as runtime dependency of WAB32.DLL from the program's application directory C:\Users\Stefan\Downloads\ instead Windows' system directory C:\Windows\System32\.

EXAMPLE4.LOG shows the output during execution of the fixed 64-bit program from example 2 on 64-bit Windows 7, where bogus SSPICLI.DLL and VERSION.DLL are loaded as (indirect) load-time dependencies and a bogus MSFTEDIT.DLL is loaded as runtime dependency of WAB32.DLL from the program's application directory C:\Users\Stefan\Downloads\ instead Windows' system directory C:\Windows\System32\.

Note: to fix the first weakness, embed the application manifest

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
          manifestVersion="1.0">
    <file name="SSPICLI.DLL"
          loadFrom="%SystemRoot%\System32\SSPICLI.DLL" />
    <file name="VERSION.DLL"
          loadFrom="%SystemRoot%\System32\VERSION.DLL" />
</assembly>
in the program!
Caveat: the loadFrom attribute of the file element is not documented by Microsoft!

Note: to fix the second weakness, call

SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32);
before any other Win32 function in your programs!
Caveat: on Windows 7, the optional update 2533623, the security update MS12-081 alias 2758857, or one of its successors have to be installed to make the Win32 function SetDefaultDllDirectories() available!
Note: to enforce its presence, create a load-time dependency to SetDefaultDllDirectories()!

Example 5

EXAMPLE5.TXT shows the output from Windows' command line debugger NTSD.EXE during execution of the program
// Copyright © 2009-2017, Stefan Kanthak <skanthak@nexgo.de>

#pragma comment(lib, "KERNEL32.LIB")
#pragma comment(lib, "OLE32.LIB")
#pragma comment(lib, "SHELL32.LIB")

#pragma comment(linker, "/ENTRY:WinMainCRTStartup")
#pragma comment(linker, "/SUBSYSTEM:Windows")

#define _WIN32_WINNT	0x0500

#include <windows.h>

void	WinMainCRTStartup()
{
	HRESULT	hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED | COINIT_DISABLE_OLE1DDE);
	if (hr == S_OK)
		hr = ShellExecute(NULL, NULL, "..", NULL, NULL, SW_SHOWNORMAL);

	CoUninitialize();
	ExitProcess(hr);
}
on Windows XP, where bogus CLBCATQ.DLL, COMRES.DLL, RICHED20.DLL and SETUPAPI.DLL are loaded as runtime dependencies of OLE32.DLL and CRYPTUI.DLL, and a bogus SHELL32.DLL is loaded as load-time dependency of CLBCATQ.DLL from the program's application directory C:\Documents and Settings\Stefan\Downloads\ instead Windows' system directory C:\Windows\System32\.

Caveat: no fix available!

Use Software Restriction Policies alias SAFER to disable execution in untrusted directories!

Example 6

EXAMPLE6.TXT shows the output during execution of the 32-bit program from example 5 on 64-bit Windows 7, where bogus PROPSYS.DLL, APPHELP.DLL, NTMARTA.DLL, CRYPTSP.DLL, RPCRTREMOTE.DLL and SXS.DLL are loaded as runtime dependencies of SHELL32.DLL, ADVAPI32.DLL, OLE32.DLL, RPCRT4.DLL and OLEAUT32.DLL, and a bogus VERSION.DLL is loaded as load-time dependency of IEFRAME.DLL from the program's application directory C:\Users\Stefan\Downloads\ instead Windows' system directory C:\Windows\SysWoW64\.

EXAMPLE6.LOG shows the output during execution of the 64-bit program from example 5 on 64-bit Windows 7, where bogus CRYPTBASE.DLL, PROPSYS.DLL, APPHELP.DLL, NTMARTA.DLL, CRYPTSP.DLL, RPCRTREMOTE.DLL and SXS.DLL are loaded as runtime dependencies of RPCRT4.DLL, SHELL32.DLL, ADVAPI32.DLL, OLE32.DLL and OLEAUT32.DLL, and a bogus VERSION.DLL is loaded as load-time dependency of IEFRAME.DLL from the program's application directory C:\Users\Stefan\Downloads\ instead Windows' system directory C:\Windows\System32\.

Note: to fix the first weakness, call

SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32);
before any other Win32 function in your programs!
Caveat: on Windows 7, the optional update 2533623, the security update MS12-081 alias 2758857, or one of its successors have to be installed to make the Win32 function SetDefaultDllDirectories() available!
Note: to enforce its presence, create a load-time dependency to SetDefaultDllDirectories()!

Note: to fix the second weakness, embed the application manifest

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
          manifestVersion="1.0">
    <file name="VERSION.DLL"
          loadFrom="%SystemRoot%\System32\VERSION.DLL" />
</assembly>
in the program!
Caveat: the loadFrom attribute of the file element is not documented by Microsoft!

Background information

Microsoft's Application Verifier should detect unquoted pathnames containing spaces in calls to the Win32 functions CreateProcess*() according to the MSDN article Using Application Verifier Within Your Software Development Lifecycle:
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.
Unfortunately the MSDN article but tells a blatant lie: Application Verifier does not perform the check described there!
The sad truth is that Application Verifier performs no checks for all the (way too) common path handling errors referenced above!

Mitigations

Implementation and build details

VRFKNTHK.DLL is a pure native DLL, written in ANSI C without the MSVCRT libraries, built with the platform SDK for Windows Server 2003 R2 for use on Windows XP and newer versions of Windows NT.

VRFKNTHK.DLL is available for the I386 alias x86, AMD64 alias x64 and IA64 processor architectures of Windows NT.

Code authenticity and integrity

VRFKNTHK.DLL is digitally signed using an X.509 certificate issued by WEB.DE TrustCenter E-Mail Certification Authority.
Serial number
73633199
0x04638daf
Fingerprint
MD5: 25 a0 d6 b0 bc 37 fe 49 42 d1 64 ca e6 7a f5 7f
SHA-1: 47 79 b5 28 f0 84 e6 ce f8 77 7b 62 dc c4 b3 1f fe de 07 14
-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAxSwxNrFPXXn6y5Abl+0pH7faIK0xVAh70reOBrwSykab/0kIwz0QJldXNTLl
ZaSb4T7A5il2oqhiHUS53owsguXrDaJ+l+iTuCR/NrOVBJ0Xi+1Kv+ni/jb3cLvTS/BQJtFm
fVW3HHtYrQQcYCpd/AVzg1k2p46BEbGfFpjfFREdM589UDSzaiIOWSEBec8RI3HVqIMiG2qL
seuQot9shOcNcV2Y2AgTKHBUrWz10kbCWf8g5QA2hjmSMRvRtBOovCgvSF0nDFk4Odrn9nLB
PVq763s2vh/riO9cheTeg4N/ldbnAywdjLAwwJ1qynh2p/s/V5cnsoav7SZRGDyAoQIDAQAB
-----END RSA PUBLIC KEY-----
Download and install the CA and root X.509 certificates of WEB.DE to validate and verify the digital signature.

Note: the digital signature remains valid past the certificates expiration date due to its counter signature alias timestamp!

Download

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

 Cabinet VRFKNTHK.CAB

12-05-2016  6:59:24p A---        11,519 VRFKNTHK.INF
12-05-2016  6:55:26p A---        56,448 AMD64\VRFKNTHK.DLL
12-05-2016  6:53:40p A---        45,184 I386\VRFKNTHK.DLL
12-05-2016  6:54:56p A---        90,240 IA64\VRFKNTHK.DLL
                 4 Files        203,391 bytes

X:\>
Execute the command line
"%SystemRoot%\System32\Expand.exe" /R VRFKNTHK.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.

Note: on systems with AMD64 alias x64 processor architecture the installation must be run in the native (64-bit) execution environment to install VRFKNTHK.DLL 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 VRFKNTHK.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 VRFKNTHK.INF to display its context menu and click Install to run the installation.

Deinstallation

The deinstallation requires administrative privileges.

On Windows XP and Windows Server 2003 open the Add/Remove Programs applet of the Control Panel, tick the checkbox Updates, select the entry Application Verifier Provider underneath Systemkonfiguration and click the Remove button.

On Windows Vista and newer versions of Windows NT open the Control Panel and click the entry View installed updates underneath the Programs and Features or Programs category.
In Installed Updates select the entry Application Verifier Provider underneath Systemkonfiguration and click the Uninstall menu entry.

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!

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