Technical Issues with Launch Control Software Management

Here are issues we have found posted about a piece of Launch Control software for windows. This site is not affiliated with this pieced of software. We are displaying this information soley as a consumer resource.

Launch Ctrl Tech Issues

(All information provided in this document is relative to the Launch Control for Windows32-bit version 1.0 and earlier. It may be changed in future versions without further notice.)

• THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND,
• EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
• IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.

Launch Control for Windows consists of two main modules:

• the dynamic-link library LC32.DLL
• he Monitor process LCONTROL.EXE

Launch Control dynamic-link library

      

The Launch Control dynamic-link library (DLL) used by Launch Control for Windows to monitor all process start or module load attempts of all existing processes. The Launch Control DLL loads itself into every existing process.

There are two ways to load the DLL used in Launch Control:

• registering it within AppCertDlls subkey of HKLM\System\CurrentControlSet\Control\SessionManager key; In this case the DLL loaded into every process at the moment when this process attempts to start another process using kernel32!CreateProcess() API function.
• registering it within AppInit_DLLS parameter of the HLKM\Software\Microsoft\Windows NT\CurrentVersion\Windows key; In this case the DLL loaded into every process at the time of this process initialization. (A complete information about using AppInit_DLLs registry value could be found here.)

When loaded as AppCertDll, the DLL exports a single system-specific function:

     

 NTSTATUS _stdcall CreateProcessNotify(LPCWSTR ApplicationName, ULONG Reason);

This function called from Kernel32.dll every time any process created by Kernel32 APIs.

When loaded as AppInit, the DLL registers following routine:

     

VOID _stdcall LoadDllNotify(ULONG NotificationReason, PLDR_DLL_NOTIFICATION_DATA NotificationData, PVOID Context);

 

This function called from Ntdll.dll every time a DLL loaded into the process context.

      

There are two different mechanisms used by Launch Control to register the LoadDllNotify. One for Microsoft Windows XP and other for Microsoft Windows Vista operating system:

• well documented API function ntdll!LdrRegisterDllNotification() used to register the LoadDllNotify routine under Microsoft Windows Vista. (Look here for further details.)
• since Microsoft Windows XP doesn't provide a special interface, LdrpDllNotificationList used directly to register the LoadDllNotify routine under Microsoft Windows XP.

     

 The Launch Control DLL receives control when any kind of process start or DLL load attempt occurs within a process. (let's call it "loading a module") The DLL calculates MD5 hash of the loaded module. The MD5 hash used then to determine if the module was patched or infected. Then, the DLL performs a RPC-request, containing module's full path, current process ID and the MD5 hash, to notify the Launch Control Monitor process about the module load attempt. The thread that loads a module stays suspended until the DLL receives a RPC-reply from the Monitor process.

The Launch Control Monitor process contains three main components:

• RPC server, that processes RPC requests from multiple Launch Control DLLs loaded within the system;
• Database engine, that manages the database of marked modules. This database contains of two tables: Allowed and Blocked, with MD5 hashed and names of currently allowed and blocked modules;
• Graphical user interface (GUI);

     

 The RPC server receives a message from a Launch Control DLL, containing full path and MD5 hash of a module being loaded and a process ID of a process that attempts to load the module. The RPC server calls the Database engine to check if the module with a specified MD5 hash exists within either Allowed or Blocked tables. If so, the RPC server immediately send a RPC-reply, containing the module's status, to a DLL.

     

 If no MD5 hash was found by the Database engine the RPC-server attempts to check if the specified module is digitally signed by a trusted publisher. The Windows Cryptographic services used to do this. If the module appears to be digitally signed, the RPC-server calls the Database engine again, to add the module's name and MD5 hash into the Allowed table. Then it send a RPC-reply to a DLL.

     

 If the module was not found within database tables and the module is not digitally signed, the RPC-server calls the GUI to display the Launch Control Alarm window to let the user to chose allow or block the module. Then, a RPC-reply sent, depending on user decision.

     

 Note, that thread that attempts to load a module stays suspended until the Launch Control Monitor makes a decision.