PsExec Internals

Abstract: This is a short reversing review of one interesting tool from Mark Russinovich (www.sysinternals.com). Here is a short description from utility homepage: "Utilities like Telnet and remote control programs like Symantec's PC Anywhere let you execute programs on remote systems, but they can be a pain to set up and require that you install client software on the remote systems that you wish to access. PsExec is a light-weight telnet-replacement that lets you execute processes on other systems, complete with full interactivity for console applications, without having to manually install client software. PsExec's most powerful uses include launching interactive command-prompts on remote systems and remote-enabling tools like IpConfig that otherwise do not have the ability to show information about remote systems." You may read this and download the utility from the following link: http://www.sysinternals.com/ntw2k/freeware/psexec.shtml . Actually, I had requests before from System Administrators regarding possibility to start programs on remote system without installing any additional software on it. That's why this tool appeared to be very interesting for me. Regretfully, Mark did not give any tips of how this utility works, so one pretty Sunday (the weather was pretty awful outside) I've fired up IDA and looked inside this tool.

"All genius appear simple..."

First of all I've found that psexec.exe contains embedded binary resource PSEXESVC, that is actually a PE-executable, more exact it's a Win32 service. Some initial reversing of PSEXESVC discovered that this is a server part of utility responsible for starting processes and redirecting I/O to/from client system. However, lets start from very beginning and describe what psexec.exe do in sequence.

As it expected first things utility do is checking host operating system and parameters validity, an example if the application to copy and execute exists on the host system. I think here is no need to describe this part in details, any programmer working over console application do the same things (again and again in endless loop...).

After parameters validated psexec obtains pointer and size of PSEXESVC resource:

HRSRC hSvc = FindResource (NULL, "PSEXESVC", "BINRES" );
   if ( !hSvc ) return 0; 
HGLOBAL hGbDesc = LoadResource (NULL, hSvc); 
DWORD dwSvcSize = SizeofResource (NULL, hSvc); 
PBYTE pPsExeSvc = LockResource (hGbDesc); 

Then creates file in "//RemoteSystemName/ADMIN$/System32" named PSEXESVC.EXE and saves resource into it. If there is no existing session with permissions to access RemoteAdmin(ADMIN$) share it tries to establish new session using username and password specified in command line via call to WNetAddConnection2 as following:

DWORD
   PsExecRemoteLogon (
   LPCSTR lpComputerName,
   LPCSTR lpUserName,
   LPCSTR lpPassword
   )
   {
	char szFullPath [_MAX_PATH];
	NETRESOURCE NetResource;
	sprintf (szFullPath, "%s//IPC___FCKpd___1quot;);
	// Initialize NetResource structure, omitted here
	...
	return (NO_ERROR == 
		WNetAddConnection2 (
			&NetResource, 
			lpPassword, 
			lpUserName, 
			0)
		);
   } 

If no error happen we have PSEXESVC.EXE in //SystemRoot/System32 folder on remote system. Note, if the executable to start remotely must be copied to the remote system, it will be also placed into that folder. After this psexec.exe install and start PSEXESVC service using SCM API (OpenSCManager, CreateService, StartService). Full description of these calls in source would take pretty much place, and I don't see much need to do this.

After start PSEXESVC creates named pipe "psexecsvc", and start reading messages from it. For this moment we have server part installed and started on remote system, ready to accept command messages. All other work is typical for client/server applications (for better understanding of writing server applications I strongly recommend Jeffrey Richter, Jason D.Clark "Programming Server-Side Applications for MS Windows 2000"). So psexec.exe copies executable to start to remote system if necessary, opens psexecsvc pipe on remote host (CreateFile), fill in message structure with necessary parameters (command line arguments, username&password if specified and etc...) and sends it into //RemoteSytem/pipe/psexecsvc (TransactNamedPipe API call).

On receiving this message PSEXESVC creates three named pipes instances "psexecsvc-app_name-app_instance-stdin", "psexecsvc-app_name-app_instance-stdout", "psexecsvc-app_name-app_instance-stderr". As you may suspect psexec.exe connects to each of these pipes and creates separate threads to work with each one. Using console functions (GetStdHandle, ReadConsole, WriteConsole and etc..) standard I/O streams (input, output, error) redirected to/from remote system through previously mentioned named pipes.

On exiting application psexec.exe stops and uninstall PSEXESVC service, removes it's binary from remote host and removes console executable if it was copied.

As a result you have telnet like application with extensive use of Windows NT/2000 features, it can be effectively used by system administrators for common administration tasks. The only hole (mentioned on utility homepage) is security: "If you omit a username the remote process runs in the same account from which you execute PsExec, but because the remote process is impersonating it will not have access to network resources on the remote system. When you specify a username the remote process executes in the account specified, and will have access to any network resources the account has access to. Note that the password is transmitted in clear text to the remote system". As you can see this tool is dangerous to use for remote administration via Internet or sometimes even in corporate network (as dangerous as telnet an example). One of the possible extension for this tool would be securing communication of psexec and psexesvc with encryption. However, in combination with IPSEC (if IP used as transport for CIFS) it can be successfully used even today.