Hi AHK club,
After writing many simple ahk scripts I really would like to be able to execute an AHK script or other executable remotely. In the office LAN I often need to restart a running process (video wall software) on around 15 different computers. I thought of using Windows Powershell for this but most of the machines do not use login/pass so (afaik) that will not work.
In the old ahk forums was a combination of scripts (https://autohotkey.com/board/topic/5440 ... ers-tcpip/) that could send a command to an IP+port. That is exactly what I am looking for but the old reference files are unavailable.
I do not mind writing code myself but am inexperienced in remote executing commands. I am looking for a hint to a script that offers this functionality. I am sure someone else has written an application like this. Hopefully I can make use of that starting point to adapt to my own needs.
Thanks for thinking with me (us) in advance.
Regards, Mark
Execute file remotely via ip+tcp port
-
- Posts: 14
- Joined: 23 Feb 2016, 07:07
Re: Execute file remotely via ip+tcp port
Here is a zip file with a backup of TheGood's archive :
https://www.dropbox.com/s/a9mlk4expmsn4 ... d.zip?dl=1
Have you looked ad PsExec to run on a remote PC?
https://docs.microsoft.com/en-us/sysint ... ads/psexec
https://www.dropbox.com/s/a9mlk4expmsn4 ... d.zip?dl=1
Have you looked ad PsExec to run on a remote PC?
https://docs.microsoft.com/en-us/sysint ... ads/psexec
Re: Execute file remotely via ip+tcp port
I would like to warn you of the risk you are taking.
By allowing an inbound connection to execute arbitrary code, you are creating a HUGE attack vector.
It would be MUCH better to only allow a limited set of functions (eg start the video wall software) - eg only scripts which are pre-existing on the remote machines can be remotely triggered.
If you allow arbitrary code, and even worse do not authenticate (Or use hard-coded credentials), you are basically building a wide open botnet.
By allowing an inbound connection to execute arbitrary code, you are creating a HUGE attack vector.
It would be MUCH better to only allow a limited set of functions (eg start the video wall software) - eg only scripts which are pre-existing on the remote machines can be remotely triggered.
If you allow arbitrary code, and even worse do not authenticate (Or use hard-coded credentials), you are basically building a wide open botnet.
-
- Posts: 14
- Joined: 23 Feb 2016, 07:07
Re: Execute file remotely via ip+tcp port
Thanks noname.
I know PsExec but think it only runs on logon based machines. If there is a way to make it run on machines without password then please correct me.
The download you offered is close to perfect! It contains most files needed to communicate via tcp/ip. Only file missing is File.ahk (and i'm unsure what is should do). Will look at it tomorrow.
[edit] It seems people have been using PsExec without logon credentials. That would be the simplest (and sophisticated) way although the option of executing any file type remotely seems highly unlikely to me.
I know PsExec but think it only runs on logon based machines. If there is a way to make it run on machines without password then please correct me.
The download you offered is close to perfect! It contains most files needed to communicate via tcp/ip. Only file missing is File.ahk (and i'm unsure what is should do). Will look at it tomorrow.
[edit] It seems people have been using PsExec without logon credentials. That would be the simplest (and sophisticated) way although the option of executing any file type remotely seems highly unlikely to me.
Last edited by Freestyler on 15 Feb 2018, 07:59, edited 1 time in total.
-
- Posts: 14
- Joined: 23 Feb 2016, 07:07
Re: Execute file remotely via ip+tcp port
@EvilC. All machines are connected via closed network. No internet involved and chance of abuse is extremely low. But thanks for the heads up.
Perhaps even better. The only command that will be sent is the restart videowall application. I'll look into allowing only that specific command just to be sure.
Perhaps even better. The only command that will be sent is the restart videowall application. I'll look into allowing only that specific command just to be sure.
Re: Execute file remotely via ip+tcp port
If you want quick, dirty and simple, then have each "client" monitor a network share for a file (Each client monitors a separate folder), and the "server" puts the files in the folder for each client. Once the client sees the file and takes the appropriate action, it deletes it, maybe even putting another file in the folder as the "response" to the server.
You could also then lock down the shares maybe, providing you a modicum of security.
You could also then lock down the shares maybe, providing you a modicum of security.
Re: Execute file remotely via ip+tcp port
Code: Select all
File_Hash(sFile, SID = "CRC32")
{
nSize:= File_WriteMemory(sFile, sBuffer)
Return Crypt_Hash(&sBuffer, nSize, SID)
}
File_AES(sFileFr, sFileTo, sPassword, SID = 256, bEncrypt = True)
{
If !(1 + hFileFr := File_CreateFile(sFileFr, 3, 0x80000000, 1))
Return "File not found!"
nSize := File_GetFileSize(hFileFr), VarSetCapacity(sBuffer, nSize + (bEncrypt ? 16 : 0))
File_ReadFile(hFileFr,&sBuffer,nSize), File_CloseHandle(hFileFr)
If !(1 + hFileTo := File_CreateFile(sFileTo, 2, 0x40000000, 1))
Return "File not created/opened!"
nSize := Crypt_AES(&sBuffer, nSize, sPassword, SID, bEncrypt)
File_WriteFile(hFileTo,&sBuffer,nSize), File_CloseHandle(hFileTo)
Return nSize
}
File_ReadMemory(sFile, pBuffer, nSize = 512, bAppend = False)
{
If !(1 + hFile := File_CreateFile(sFile, 4, 0x40000000, 1))
Return "File not created/opened!"
File_SetFilePointer(hFile, bAppend ? 2 : 0)
nSize := File_WriteFile(hFile, pBuffer, nSize)
File_SetEndOfFile(hFile)
File_CloseHandle(hFile)
Return nSize
}
File_WriteMemory(sFile, ByRef sBuffer, nSize = 0)
{
If !(1 + hFile := File_CreateFile(sFile, 3, 0x80000000, 1))
Return "File not found!"
VarSetCapacity(sBuffer, nSize += nSize ? 0 : File_GetFileSize(hFile))
nSize := File_ReadFile(hFile, &sBuffer, nSize)
NumPut(0, sBuffer, nSize, "char")
VarSetCapacity(sBuffer, -1)
File_CloseHandle(hFile)
Return nSize
}
File_CreateFile(sFile, nCreate = 3, nAccess = 0x1F01FF, nShare = 3, bFolder = False)
{
/*
CREATE_NEW = 1
CREATE_ALWAYS = 2
OPEN_EXISTING = 3
OPEN_ALWAYS = 4
GENERIC_READ = 0x80000000
GENERIC_WRITE = 0x40000000
GENERIC_EXECUTE = 0x20000000
GENERIC_ALL = 0x10000000
FILE_SHARE_READ = 1
FILE_SHARE_WRITE = 2
FILE_SHARE_DELETE = 4
*/
Return DllCall("CreateFile", "Uint", &sFile, "Uint", nAccess, "Uint", nShare, "Uint", 0, "Uint", nCreate, "Uint", bFolder ? 0x02000000 : 0, "Uint", 0)
}
File_DeleteFile(sFile)
{
Return DllCall("DeleteFile", "Uint", &sFile)
}
File_ReadFile(hFile, pBuffer, nSize = 1024)
{
DllCall("ReadFile", "Uint", hFile, "Uint", pBuffer, "Uint", nSize, "UintP", nSize, "Uint", 0)
Return nSize
}
File_WriteFile(hFile, pBuffer, nSize = 1024)
{
DllCall("WriteFile", "Uint", hFile, "Uint", pBuffer, "Uint", nSize, "UintP", nSize, "Uint", 0)
Return nSize
}
File_GetFileSize(hFile)
{
DllCall("GetFileSizeEx", "Uint", hFile, "int64P", nSize)
Return nSize
}
File_SetEndOfFile(hFile)
{
Return DllCall("SetEndOfFile", "Uint", hFile)
}
File_SetFilePointer(hFile, nPos = 0, nMove = 0)
{
/*
FILE_BEGIN = 0
FILE_CURRENT = 1
FILE_END = 2
*/
Return DllCall("SetFilePointerEx", "Uint", hFile, "int64", nMove, "Uint", 0, "Uint", nPos)
}
File_CloseHandle(Handle)
{
Return DllCall("CloseHandle", "Uint", Handle)
}
File_InternetOpen(sAgent = "AutoHotkey", nType = 4)
{
If Not DllCall("GetModuleHandle", "str", "wininet")
DllCall("LoadLibrary" , "str", "wininet")
Return DllCall("wininet\InternetOpenA", "str", sAgent, "Uint", nType, "Uint", 0, "Uint", 0, "Uint", 0)
}
File_InternetOpenUrl(hInet, sUrl, nFlags = 0, pHeaders = 0)
{
Return DllCall("wininet\InternetOpenUrlA", "Uint", hInet, "Uint", &sUrl, "Uint", pHeaders, "Uint", -1, "Uint", nFlags | 0x80000000, "Uint", 0) ; INTERNET_FLAG_RELOAD = 0x80000000
}
File_InternetReadFile(hFile, pBuffer, nSize = 1024)
{
DllCall("wininet\InternetReadFile", "Uint", hFile, "Uint", pBuffer, "Uint", nSize, "UintP", nSize)
Return nSize
}
File_InternetWriteFile(hFile, pBuffer, nSize = 1024)
{
DllCall("wininet\InternetWriteFile", "Uint", hFile, "Uint", pBuffer, "Uint", nSize, "UintP", nSize)
Return nSize
}
File_InternetSetFilePointer(hFile, nPos = 0, nMove = 0)
{
Return DllCall("wininet\InternetSetFilePointer", "Uint", hFile, "Uint", nMove, "Uint", 0, "Uint", nPos, "Uint", 0)
}
File_InternetCloseHandle(Handle)
{
Return DllCall("wininet\InternetCloseHandle", "Uint", Handle)
}
@evilC the idea of putting a shared file as trigger is a nice one
There is also "mailslot" protocol as message carrier on a lan ( or same PC)
https://autohotkey.com/board/topic/5547 ... mailslots/
Re: Execute file remotely via ip+tcp port
Here you go...
Each client has a "Commands" folder that you put AHK scripts to be run when each "command" is issued.
So if the server creates a file called "Test" (no ext) in a client's folder, it will see if it has "Commands\Test.ahk" and if so, run it.
Nice and extensible - the clients can have new features added, remotely, without having to restart them, and without changing the client code
ZIP attached with all the needed files, in correct folder structure
Code: Select all
#SingleInstance force
Gui, Add, Button, gTest w200, TEST
Gui, Add, Edit, Disabled w200 vOutput R10
Gui, Show
clientFolders := ["Client1"]
return
GuiClose:
ExitApp
Test:
for id, folder in clientFolders {
FileAppend, , % folder "\Test"
}
for id, folder in clientFolders {
responseFile := folder "\response.txt"
while (!FileExist(responseFile)){
Sleep 100
}
Gui, Submit, NoHide
FileRead, response, % responseFile
text .= response
GuiControl, , Output, % "Client " id " reports " text "`n"
FileDelete, % responseFile
}
return
Code: Select all
#SingleInstance force
#Persistent
Loop {
Loop, Files, *
{
cmd := "Commands\" A_LoopFileName ".ahk"
if (FileExist(cmd)){
Run, % cmd
FileDelete, % A_LoopFileName
FileAppend, OK, response.txt
}
}
Sleep 500
}
So if the server creates a file called "Test" (no ext) in a client's folder, it will see if it has "Commands\Test.ahk" and if so, run it.
Nice and extensible - the clients can have new features added, remotely, without having to restart them, and without changing the client code
ZIP attached with all the needed files, in correct folder structure
- Attachments
-
- ClientServer.zip
- (1.21 KiB) Downloaded 97 times
Re: Execute file remotely via ip+tcp port
Thinking about it, I am not so sure it is any less safe to just run the script that the server puts in the folder. If you could push a new script to a client's Commands folder anyway, little difference.
Maybe if you restrict write access to those folders, it would give you some security, or maybe best to not bother. up to you
Maybe if you restrict write access to those folders, it would give you some security, or maybe best to not bother. up to you
-
- Posts: 14
- Joined: 23 Feb 2016, 07:07
Re: Execute file remotely via ip+tcp port
Hi folks (esp @evilC)
Again thanks. I used the drop file on certain shared folder idea before and it worked flawless. But this time I thought of doing it a more proper way. To be honest I always thought my Quick and Dirty solution was 'not done' in IT. But hey, it worked.
For now i would still like to use a TCP connection. If that does not work i'll create shared folders on the client and run your (better than my old) code to execute the restart Videowall.
Man, i like the community here. Never failed
Again thanks. I used the drop file on certain shared folder idea before and it worked flawless. But this time I thought of doing it a more proper way. To be honest I always thought my Quick and Dirty solution was 'not done' in IT. But hey, it worked.
For now i would still like to use a TCP connection. If that does not work i'll create shared folders on the client and run your (better than my old) code to execute the restart Videowall.
Man, i like the community here. Never failed