About WIN2k services

I. Summary
II. WIN2K services
III. Basic Process of Service Startup and Shutdown
IV. Service Programming
V. Service Security
VI. Service Management
VII. End

I. Summary
The services under Windows NT are similar to the daemon processes under * NIX, and more software are designed as services. After the launch of XP, it is very useful to implement multi-user switching through services.
From a security perspective, if we look at WIN's services, there are many topics, such as running permissions and running time.
This article will introduce and talk about some items of the WIN service in some aspects. The content is not refined due to horizontal restrictions.

II. WIN2K services

The WIN32 service consists of three parts: service application, Service Control Program (SCP), and Service Control Manager (SCM ).

I. Service Control Manager

Service Control Manager (Service Control Manager) is a part of WIN system when the system starts. It is a Remote Procedure Call (RPC) server. This is also the core of the WIN service system.
SCM is mainly responsible for the following:
· Maintain the installed Service Database
· Start services and driver services when the system starts or has commands
· Enumeration of installed services and drivers
· Maintain the running service and driving status
· Transfer control requests to run services
· Lock and unlock the Service Database
SCM maintains the Service database in the registry, located at: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices. The sub-keys are installed services and driver services. The name of each sub-key is the service name, which is specified by the CreateService function of the Service Security Program during installation.

When the system is installed, the initial database is created. This database contains the device drivers when the system starts. Information about each service and driver in the database includes:
· Service type. Whether the service is implemented by itself or shared with other services, whether it is the core driver or the file system driver.
· Startup type. Whether the service or driver service is automatically started when the system starts or whether the SCM is used to receive control requests to start. The Startup Type also indicates whether the service is disabled.
· Error control level. Specifies the error handling if the service or driver fails to start.
· Full path of the execution file.
· Attaching dependency information determines the proper sequence of startup. For a service, this information includes the specified service that the SCM needs to start before the service starts, the name of the load sequence group to which the service belongs, and the identifier of the startup sequence of the service in the Group. For the driver service, this information includes the specified driver to be started before the driver starts.
· There is an additional account name and password for the service. If no account is specified, the Service uses the LocalSystem account.
· For the driver, append the driver object name for the I/0 system to load the device driver. If the object name is not specified, the I/O system creates a default name based on the driver service name.

Ii. service control procedures

The Service Control Program (SCP) is a functional block that controls the service application and a bridge between the service application and the Service Manager (SCM. The service control program can complete these actions:
· If the Service Startup type is SERVICE_DEMAND_START, the service control program starts the service.
· Send control requests to running services
· Query the current status of a running service
These actions require opening the handle of a service object.

· Start services

To start a service, the service control program uses the StartService function. If the database is locked, the StartService function fails. In this case, the service control program needs to wait and call StartService again. You can use QueryServiceLockStatus to query the status of the Service database.

When a service control program starts a service, you can use the StartService function to specify the parameters passed to the ServiceMain function of the service. After a new thread is created to execute ServiceMain, StartService returns. The service control program can use the QueryServiceStatus function to query the status of the started service. In the SERVICE_STATUS structure initialization, dwCurrentState should be SERVICE_START_PENDING, while dwWaitHint is a millisecond interval, indicating the time that the Service Control Program should wait for when QueryServiceStatus is called. After the initialization is complete, the service changes the Service State dwCurrentState to SERVICE_RUNNING.

If the service does not change its status within 80 seconds plus the last wait time, the Service Control Manager determines that the service has stopped responding and records the event and stops the service.

If the program starts the driver service, StartService will return after the device driver initialization is complete.

· Service control request

The service control program sends a control request to the running service through ControlService. This function specifies that the control value is passed to the HandlerEx function of the specified service. The control value can be a user-defined code or the following basic control code:
· Stop service: SERVICE_CONTROL_STOP
· Service suspension: SERVICE_CONTROL_PAUSE
· Resume the suspended service: SERVICE_CONTROL_CONTINUE
· Return service update status information: SERVICE_CONTROL_INTERROGATE

Each service can specify the control value it receives and processes. To determine which basic control value is received by the service, you can use the QueryServiceStatus function or specify SERVICE_CONTROL_INTERROGATE to call the ControlService function. In the SERVICE_STATUS structure, dwControlsAccepted returns whether the service can be stopped, paused, and restored. All services can receive SERVICE_CONTROL_INTERROGATE.

The QueryServiceStatus function returns the latest status of the specified service and does not obtain the updated status of the service. Use
SERVICE_CONTROL_INTERROGATE controls to call the ControlService function to determine whether the status is the current information.

3. service applications

A service application is the main program of a service. It is the executable code of one or more services. This will be explained in detail in the programming of the service.

III. Basic Process of Service Startup and Shutdown

When the system starts, SCM starts all automatically started services and the services that these services depend on. If an auto-start service depends on a "Manual" service (which requires commands to be started), the service will also be automatically started. The order of service loading is determined by the following:
1. Group Order
2. Loading Order of services in a group
3. Services on which each service depends

When the startup is complete, the system executes the startup validation program (by the Registry's HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl
The value of BootVerificationProgram in. By default, this value does not exist .). After the first user logs on, the system simply reports that the startup is successful. You can independently provide a startup validation program to check system problems and report the startup status to SCM, using the yybootconfigstatus function.

After the system is started successfully, the system clones and saves a database backup as the last-known-good (LKG) configuration. If the current database causes system startup failure, you can use backup to recover it. The backup database is saved in:
HKEY_LOCAL_MACHINESYSTEMControlSetXXXServices.
The XXX value is also saved in:
HKEY_LOCAL_MACHINESystemSelectLastKnownGood.

If the SERVICE_ERROR_CRITICAL error is returned when the service is automatically started, SCM restarts the machine and uses the LKG configuration. If the LKG configuration has been used, the startup will fail.

The ErrorControl value of the service in the Registry indicates how SCM handles service errors. If the value is SERVICE_ERROR_IGNORE (0) or is not specified, SCM only ignores the error and continues to start the service. If the value is SERIVCE_ERROR_NORMAL (1), the cause of the error is recorded in the event log. If the error control is SERIVCE_ERROR_SEVERE (2) or SERIVCE_ERROR_CRITICAL (3), the Service reports a startup error. SCM records Event Logs, calls the ScreverToLastKnownGood function, switches the System Registration configuration to the LKG version, and then calls NtShutDownSystem to restart the system. If the system has used the LKG version, restart it.

Generation of LKG version: After SCM starts all self-starting services in the system startup phase, it is necessary to determine the LKG configuration. By default, a successful start includes successful start of all services and logon of a user. If there is a SERIVCE_ERROR_SEVERE (2) or SERIVCE_ERROR_CRITICAL (3) error in the service startup phase, this is the failed startup. If SCM successfully starts the service, Winlogon calls the yybootconfigstatus function to send a message to SCM when a user logs on. After all services are successfully started and logon information of yybootconfigstatus is received, SCM calls NtInitializeRegistry to save the current STARTUP configuration information.

Third parties can replace Winlogon validation with their own definitions, which can be in the registry:
The program in KHLMSYSTEMCurrentControlSetControlBootVerificationProgam is determined. You can use this to add the definition of successful startup of the system. Start the verification program and set HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogonReportBootOK to 0 to prohibit Winlogon from calling yybootconfigstatus. In this way, after the SCM starts the service, wait until the verification program calls the NotifyBootConfigStatus function to notify you that the logon is successful, and then save the LKG configuration.

The SCM execution file is WINNSystem32Service.exe, which runs in Console mode. The Winlogon process starts SCM early in system startup.
SvcCtrlMain runs immediately after the screen becomes blank. It runs before Winlogon loads graphical identity authentication and displays the logon interface GINA.

SvcCtrlMain first creates a synchronization event initialized by nonsignaled named SvcCtrlEvent_A3752DX. After completing the steps for preparing to accept the SCP command, SCM sets this event to the signaled state. SCP confirms SCM through the OpenSCManager function. This function prevents SCP from contacting SCM before SCM Initialization is complete by waiting for SvcCtrlEvent_A3752DX to be signaled.

SvcCtrlMain then calls the ScCreateServiceDB function to establish the SCM Service database. It first reads from the registry:
HKLMsystemCurrentControlSetControlServicegroupOrderlist, lists the service group names and their startup sequence, searches for the content of HKLMSYSTEMcurrentControlSetServices, and creates an entry for each primary key in the Service database. SCM itself is a self-starting service and device driver, and is marked as a boot error for boot and system startup drivers, that is, all boot drivers marked as boot drivers and system boot drivers will be loaded before SCM is started, and the I/O manager will load these boot drivers before the user mode process is executed. ScCreateServiceDB reads the group key value of the service to determine the group to which the service belongs and associates it with the previously created group list. This function also uses the DependOnGroup and DependOnService functions to query the dependencies between services and groups.

When the service is started, SCM may need to call Lsass. SCM will wait for Lsass to notify the LSA_RPC_SERVICE_ACTIVE synchronization event at the end of its initialization, Winl