By default, we cannot log on to the Windows desktop environment directly as the system account on the logon dialog box. In fact, the system account has long been "entrenched" in the systems. Think of it also, even responsible for user authentication Winlogon, LSASS and other processes are running as System identity, who can be qualified to test system? Now that the system account has already appeared in the systems, So just starting Windows Shell Program Explorer as the System account is the equivalent of logging on to Windows with system identity.
Start Explorer as the System account
Open a command prompt, enter the command "taskkill/f/im explorer.exe" and enter, which ends the current Account Explorer, the graphical user interface shell. Then, at the command prompt, continue entering "at Time/interactive%systemroot%explorer.exe" and enter. Where "Time" is a later time of the current system time, such as a second interval, the current system times can be entered at the command prompt at the "Time" command. A second later, the User Configuration is reloaded, and the shell process Explorer.exe for Windows starts with system identity.
To verify that Exeplorer.exe is running with system privileges
How do I know that Exeplorer.exe is running with system privileges?
From the Start menu, you can see that the system account is displayed on the top. Also, open Registry Editor, just to prove that HKCU is a hkus-1-5-18 link (s-1-5-18 is the SID of the system account). The proof method is simple: Under HKCU, create a new test subkey, and then refresh and see if the Test subkey appears under Hkus-1-5-18, and if so, then the system is currently loading the user hive for the systems account. Of course, the simplest is to enter the command "WhoAmI" under the command prompt symbol for verification, as shown in the illustration as "NT Authoritysystem" which proves that the current Exeplorer.exe is System permissions.
The actual usefulness of system permissions
What does the Explorer.exe of system permissions do in practice? The following author randomly enumerates several usages.
(1). Registry access
We know that under non-system privileges, users do not have access to certain registry keys, such as "Hkey_local_machinesam", "hkey_local_machinesecurity", and so on. These items record the core data of the system, and some viruses or Trojans will patronize it. For example, to create a hidden account with administrator privileges under a SAM project, such accounts are not visible in commands and in the Local Users and Groups Manager (LUSRMGR.MSC), creating a significant security risk. There is no barrier to access to the registry under "SYSTEM" permissions, and we open the registry to locate all hidden accounts under "Hkey_local_machinesamsamdomainsaccount".
(2) Access to System Restore files
System Restore is a kind of self-protection measure of Windows System, it establishes "system Colume Information" folder under each disk root directory, save some system information for System Restore to use. The file has a system, hidden property Administrator user does not have permission to operate. Because of this, it becomes a virus, Trojan's shelter, we can enter the folder under the system permissions to remove the virus. Of course, you can also turn off the "System Restore" to prevent such viruses, but this seems to be passive, some unworthy.
(3) Replacement of system files
Windows systems protect system files, and generally you will not be able to change the system files, because the system has a backup of the system files, it exists in the C:windowssystem32dllcache (assuming your system is installed in C disk). When you replace the system files, the system automatically restores the corresponding system files from this directory. Prompts you to insert the installation disk when there is no corresponding system file in the directory.
In practical applications if you sometimes need to DIY your own system to modify some of the system files, or with a high version of the system files to replace the lower version of the system files, so that the system functions. Windows XP, for example, only supports a single user telnet, if you want it to support multiple users telnet. You want to replace the corresponding file for window XP with a remote login file for Windows 2003. This is difficult to implement under non-system permissions, but can be easily implemented under system permissions.
Extracts the Termsrv.dll file from the Windows 2003 system, replacing the file under Windows XP with the same name under C:windowssystem32. (For WINDOWS XP SP2 You must also replace files of the same name under c:windows$ntservicepackuninstall$ and c:windowsservicepackfilesi386 directories). The appropriate system settings will allow Windows XP to support multiple user logons.
(4) Manual Antivirus
Users in the process of using the computer is generally used by the administrator or other Admin user login, poisoning or after the horse, viruses, Trojans are mostly run with administrator rights. We are in the system after the general use of anti-virus software to antivirus, if the killing soft paralyzed, or anti-virus software can only detect, but can not clear, this time can only shirtless, manual antivirus.
Under the Adinistrator authority, if the manual killing for some viruses powerless, generally to boot into safe mode, sometimes even in safe mode can not clean. If you are logged on with system privileges, it is much easier to get a virus.
Take a manual anti-virus as an example, (in order to screenshot in the virtual machine simulation of a period of time before a manual antivirus.) "Windows Task Manager", found that there is a suspicious process "86a01.exe", the administrator can not end the process, of course, can not remove the virus in the system directory of the original file "86a01.exe."
Log in to System privileges, the process is successfully completed, and then the virus original file is removed, the registry is cleared of relevant options, and the virus is completely cleaned out of the system.
Summarize
System permissions are the highest privileges on the systems that are higher than the administrator's permissions, and can be used to accomplish tasks that cannot be accomplished in many general situations. Of course, the maximum authority also means greater danger, just like holding "sword", do not kill innocent Ah! During use, we recommend that you use System administrator rights or general user rights, and only under special circumstances, use the systems permission