Hello! I've seen some applications that start some other apps (like installations) on y remote-computer under a certain user-account. How is this done?
Printable View
Hello! I've seen some applications that start some other apps (like installations) on y remote-computer under a certain user-account. How is this done?
the ShellExecute() method allows to execute any commands in a folder.
ShellExecute(handle, NULL, <path_to_folder>, NULL, NULL, SW_SHOWNORMAL);
check MSDN for further details
Thanx for your reply, but that is not what I need. I want to have an C++ Application on one computer, lets say 192.168.0.1. From this Application I want to start another Application on the computer 192.168.0.2. I think this cannot be done with ShellExecute.
okay
There are few ways to do this.
1 you should have the Administrator rights including registery so then you can execute any app on that machine remotely using the scripts.
2 create a service on that machine, which should act as a server and can accept connection using sockets/Named Pipes/IPC and then send the command from client to that server and then using the ShellExecute() command run that application.
3 Create a service which should run the specific application after an interval.
4 Instead of creating a service you can create an application which can perform the above (2,3) tasks.
Hi jawadhashmi and thanx for your reply again. I saw a product, which was able to start some part of it on a remote computer WITHOUT having any service/application installed before on it: Take a fresh window-installation and it worked! I'am curious how this is possible.
okay
can you check from which user you were installing/executing that application. As i know if you have Administrator rights including of registery then using the script you can run and install any sort of application to remote machine.
May be that application is using this technique.
Yes.Quote:
Originally posted by jawadhashmi
can you check from which user you were installing/executing that application.
Okay, but HOW is it done ;)Quote:
As i know if you have Administrator rights including of registery then using the script you can run and install any sort of application to remote machine.
May be that application is using this technique.
- How can I access to remote registry as an administrator from a C++-Application?
- How can I then use the registry to start something?
I have not worked over it. But i can give you the idea how to do it, for specific API you have to check the MSDN.
In the windows registry there is an option of Registry ->Connect network registry. From this dialouge you can enter the name of your lan computer and can see its registry. So there must be an API to accomplish it.
As there is concern of Executing any application remotely using Registry. You can find the paths of the executable files of specific applications to view remotely and then using any other command to run them.
Check for the script and MSDN.
Thanx again, I'LL have a try!
You could accomplish this using (distributed) COM. All COM-based applications can be invoked in this way, even over a network, and you can setup particular account and security priveleges to enable or prevent access. However, there is a fairly steep learning curve associated with COM. If you're not familiar with it, I suggest looking into the ATL libraries which will take some of the hard work out of it all. As ever, MSDN has all the relevant articles and documentation.
HTH
One way to do this is using WMI from with a VBscript, for example:
Note that for security reasons any program you run using this method is not allowed to create a window on the remote machine. But you should be able to use it to strat an unattended installation, for example.Code:strUser = "User"
strPassword = "password"
' Connect to the WMI service on the target system
Set objWMILocator = CreateObject("WbemScripting.SWbemLocator")
Set objWMIService = objWMILocator.ConnectServer( strComputer, "\root\cimv2:Win32_Process", _
strUser , strPassword )
Set objProcess = objWMIService.Get("Win32_Process")
Err = objProcess.Create("cmd /C dir *.txt > %TEMP%\out.tmp", null, null, intProcessID)
Strictly saying it might be not necessarily unattendedQuote:
Originally posted by wayside
Note that for security reasons any program you run using this method is not allowed to create a window on the remote machine. But you should be able to use it to strat an unattended installation, for example.
The plan of invasion:
1. Get the user\password info (user should be admin at remote station) or use current credentials (if the user has admin rights for remote station)
2. Establish a connection to remote station with given credentials (see WNetAddConnection2())
3. Copy to ADMIN$ share the service module which will play a role of remote agent for our process
4. Create service at remote (see CreateService())
5. Start service (see ControlService()) and establish a communication channel to it
6. If any visual information is needed for remote user you can:
- create thread in your service and set for it current input desktop (OpenInputDesktop()) and default window station WinSta0 (this method is insecure if you don't impersonate an interactive use) and create any window(s) you like to show out OR
- create a remote thread in explorer.exe running currently and run any visual agent (step-agent of your remote agent) from this thread OR
- create an additional desktop and run your process on it and switch to this desktop preventing any ineractive user's activity OR
- ...anything else :)
7. Do any task you need (install, register, copy or something else)
8. Terminate/Close (app .exe) and Stop (service .exe) all agents
9. Delete service record from remote registry (see DeleteService())
10. Delete all unnecessary binaries from remote station
11. Delete remote connection (see WNetCancelConnection2())
Seems not so easy, uh? :)
PS. Instead of service you could use DCOM outproc server
CoCreateIntanceEx() allows you to specify the machine on which to start a COM server app.
Run dcomcnfg.exe on that remote machine to setup user accout under which the app will run.
Yes WMI is probably the best solution. I know I have seen something about remote scripting which I think provides the ability to run scripts on other systems, but I don't know if it uses WMI or anything else. However anything that can be done using scripts can be done using C++.
Also, there is something called RPC. It is a networking protocol; look in the Network Protocols in the Platform SDK. It is a very sophisticated and powerful system. It originated in the Unix environment and therefore can be used with most systems, in cased that matters. COM uses it for interprocess communication and (actually it is DCOM) for inter-system communication. Therefore it might be better to use DCOM instead of RPCs directly, but if you only want to execute an existing program, perhaps a RPC would be easier. I know very little more about RPCs, except that COM uses the same MIDL type of langauge and such that is used for RPCs.
Which is essentially what a RPC does except it does not use ShellExecute.Quote:
Originally posted by jawadhashmi
2 create a service on that machine, which should act as a server and can accept connection using sockets/Named Pipes/IPC and then send the command from client to that server and then using the ShellExecute() command run that application.
Service registration/unregistration at remote also uses RPC.Quote:
Originally posted by Sam Hobbs
...perhaps a RPC would be easier. I know very little more about RPCs, except that COM uses the same MIDL type of langauge and such that is used for RPCs.
A sufficient obstacle for RPC (and DCOM as well) usage is that any its functionality(interface at least) should be registered, as far as I know, before it been used. Unfortunately I'm not experienced in RPC at all.
Is there some way to get Windows Installer to install a program on a remote computer? If so, perhaps that mechanism could be used to install then start a program on a remote computer.
Which is a good thing, since otherwise systems would be much more vulnerable to installation of malicious software.Quote:
Originally posted by Igor Vartanov
A sufficient obstacle for RPC (and DCOM as well) usage is that any its functionality(interface at least) should be registered, as far as I know, before it been used.