Protect a single exe

[Luigi]

Greetings

I have a single .exe:

• TCP/IP server
• have an user interface
• is not a service / have no service
• without auth / no auth
• it's like a 'calc.exe', someone can use
• not have a protection to multiples instances
• writed unknow language (delphi, C)
• have an access to data base
• the original .exe does not have top bar (not close, minimize, restore, etc)
• the .exe does not have a multiples instances protection like _Singleton()
• it's a single .exe

All this in the only one .exe

I know... This .exe is very bad... beginner... homemade code...

Requirements

• this .exe must be run 24h
• many users need use this .exe
• I need build a way to protect this .exe, with user/pass
• register each who/login/logout
• detect each Windows Login and force .exe's block
• if .exe crash, force re-open
• it's possible open 1, 2, 3, many instances of .exe, and each .exe's instance call a data base instance... This is not required. I need to keep only one instance, the oldest. The most youngest instance must be killed.
• many diferents peoples (userA, userB, userC) access this host by RDP (Remote Desktop Protocol) with same username/password and I need kwnows try user .exe

Q. Can use diferents Windows's users? No.
R. Each new login means a new instance's .exe and a new data base's intance... this is bad.

 

I have tried others ways, but have no success...

If is possible open a calc.exe in one windows session and use the same calc.exe's instance by another user, maybe this is a good way.
Write a script to open this session and use this shared instance...
Maybe is possible use _WinAPI_CreateDesktop?

 

tscon.exe can be an alternative?

So...
I write this scripts, they not completed, but have basic functions and can protect the 'teste.exe'.

Have some bugs, and for me, CPU load is high...

 

Compile teste.au3 first, then run monitor.au3

 

@TODO LIST

• set $hGui2 always on top over $HANDLE
• more tests with others programs/exe
• improve log's messages

 

 

monitor.au3

teste.au3

Edited June 14, 2018 by Luigi

[ViciousXUSMC]

At a basic level this is what NTFS permissions are for.

Give only the user or group you want access the Read & Execute permission, deny the rest.

 

Else you can run something in the background that says (example, not runnable code)

If @UserName <> "Allowed User Name" Then ProcoessClose() and FileWriteLog()

I think native functions are cleaner and better than using AutoIT has a hack to get it done.

[Jos]

Your description is quite vague... what about you try again but this time be much clearer in what you exactly want to accomplish?

Jos 

[Luigi]

Try again. Sorry my english.

For example, I have an aplication, this is a server (the application), and need run 24h.

It's only a single one exe, with a TCP/IP server.

Does not have a user control.

Its not work with multi user, not have a Windows Service.

It's a very basic application, like a 'calc.exe'... But control functions over network.

Anyone can access the main aplication and change anything.

How protect it?

The problem is the same to try protect 'calc.exe', and allow some registered users to access it, not everyone.

Read the HELP's AutoIt, I find some funcions like '_WinAPI_SwitchDesktop'...

Is possible run this application in special 'Desktop' and allow access over script with a some authentication?

I have AD (Active Directory).


This problem for me, is the same to try protect the 'calc.exe'.

 

 

I always need run the same instance of .exe.

The .exe does not have a control of multiples instances, and any instance run a conection with data base, very bad.

I have one Windows Account for this machine, not allow multi users.

I can't logout... kill the instance, .exe not work.

Many peoples need work with this .exe, not all the same time, but in multiples times.

But I need have a control: WHO IS USING THE .exe IN THIS MOMENT.

Edited June 13, 2018 by Luigi

[orbs]

you say:

15 minutes ago, Luigi said:

Does not have a user control.

...

Anyone can access the main aplication and change anything.

i don't understand: does this application have UI, or not? or is the UI a different program that controls the background application?

i see why NTFS permissions are not the way to go - it cannot limit concurrent connections. if you want to have your application running only once, then use _Singleton().

 

 

[jchd]

30 minutes ago, Luigi said:

Anyone can access the main aplication and change anything.

How protect it?

The problem is the same to try protect 'calc.exe', and allow some registered users to access it, not everyone.

On the contrary to above remark, I believe that standard OS access rights can solve the issue.

[Luigi]

33 minutes ago, orbs said:

i don't understand: does this application have UI, or not? or is the UI a different program that controls the background application?

The TCP/IP server and UI is the same .exe. There are only one .exe, and it make all.

[Luigi]

34 minutes ago, orbs said:

i see why NTFS permissions are not the way to go - it cannot limit concurrent connections

Correct. I believe, does not limit concurrent connections.

All new connection maybe is a diferent user.

 

35 minutes ago, orbs said:

if you want to have your application running only once, then use _Singleton()

The .exe is not AutoIt script.
This is an aplication from other developer, and have no source code.

[ViciousXUSMC]

So do the users of the application access it by connecting to the server via RDP or is it terminal based like SSH?

I cant think of a way to have somebody use "calc.exe" on a remote server without connecting to the server and logging in.

 

I am having a hard time to determine the way you are working, it sounds like you have a single user program designed to run on a user machine and put it on a server and are trying to make it a multi user program.  You can only do so much if the program is not made for that kind of application. 

Edited June 13, 2018 by ViciousXUSMC

[Luigi]

2 hours ago, ViciousXUSMC said:

So do the users of the application access it by connecting to the server via RDP

Yes, all conections are made by RDP.
How all users need access the same instance of .exe, all users always use the same account (user/pass).
The network have Active Directory, and any user have yours personal ID.
But, I access the SERVER, I not see the .exe's instance, need open a new .exe, of course, another instance.
The solution to access the same .exe's instance, are all diferent peoples (userA, userB, userC, etc), always use the same user( userX ).

Unfortunally, the .exe is very homemade, I don't say in english: very start program... niewbie programer... 

Not is coorporative application.

Thinking in 'calc.exe'... This single file, run everything... It is a UI, a server (TCP)... Every in one!

It's very stupid create a script to protect a program like 'calc.exe'...
Unfortunaly, I have this task: knows (save in log) who (diferents peoples) is using a (the same instance of) 'calc.exe'.

A .exe's instance, this can be shared with another user?

tscon.exe can share a instance with another user?

 

There are one way to run my .exe in a separated Desktop, and give access by auth, using _WinAPI_CreateDesktop ?

 

[careca]

What about an autoit application that simply moves and forces position of the window for the standalone application outside the desktop?

And unless you open autoit application and write the correct password, the other window is always unreachable.

This way, only the person with the password can make changes to the application in the UI.

The autoit code would be a simple winmove refreshing every second or checking position every second or whatever.

Edited June 13, 2018 by careca

[Luigi]

2 hours ago, careca said:

autoit application that simply moves and forces position

@careca, this is an alternative...

 

 

Edited June 14, 2018 by Luigi

[Juvigy]

Put the EXE for example calc.exe in a Citrix desktop. You can know who is logged in in the citrix and using the app. And you can have AD logins to the citrix desktop so only registered and allowed users can use the app. Users will not be able to change anything in the citrix environment.

[orbs]

 

14 hours ago, Luigi said:

Yes, all conections are made by RDP.
How all users need access the same instance of .exe, all users always use the same account (user/pass).

so when a person connects via RDP, it is always to the same session... and obviously terminates the connection of the currently connected user.

17 hours ago, Luigi said:

I have one Windows Account for this machine, not allow multi users.

how about using that same user account your users are using, instead of that one Windows account? so the users' account is always logged-on, your app is available to that user, and any new person trying to connect will only take control of the exiting session (and obviously terminate the current connection... but you are probably already aware of that).

the challenge in this case is how to force disconnect instead of log-off when a user has finished his work; and how to re-launch your app if a user accidentally closes it. agree?

 

Edited June 14, 2018 by orbs

[ViciousXUSMC]

Instead of RDP use something like TeamViewer and have the server auto log in and auto launch the application.

Use group policy to disable logoff or shutdown options for that generic account.

Or see if you can use policy to notify a user of a RDP request and give them permissions to deny/accept a disconnect before somebody takes over the session.

Also wrapping the .exe in Autoit with _Singleton() should ensure only one instance gets run just incase somebody sneaks into the server outside of your security setup.

So remove any shortcuts to the .exe directly and make them open it with the autoit wrapper. 

[orbs]

you can also introduce a "watchdog" service - a script scheduled to run at startup under the local SYSTEM account, constantly running in the background, monitoring the active processes. it it finds that your app is running only one time, under the dedicated user account - this is OK. if your app is not running (closed by the user, or the user has logged off) - start the app under the local SYSTEM account, so even though it is not accessible to users, it is still functional. if it is running under the local SYSTEM account, and another instance is detected under the dedicated user account - let it run and close the instance running under the local SYSTEM account. this way, at all times, there is only one instance of your app running, and is accessible to users.