If an executable is made to run as a window service and someones tries to edit its memory or inject some code into, this becomes harder?
I mean , since the process is shown only in the services list rather than the processlist it means that it is harder to hook it and there must be other methods of editing the memory/hooking the process .
Thanks in advance,
Related
I have a weird case of (TCP) listening port conflicts on my hands.
The application uses a lot of ports. Less than a hundred but some tens. This is probably irrelevant, I get the conflict on the first bind operation which happens to be a listener.
I can repeatedly close and restart the application in quick succession without issue. To my awareness I neatly stop all threads and dispose all sockets on close.
The issue arises when the application is updated. To allow the executable and its dependencies to be overwritten, the update is delegated to an updater application. The main application starts the updater and immediately closes itself (in a graceful fashion, using a WM_CLOSE message). The updater unzips the update package and overwrites the binaries and what more. When done, it restarts the (now updated) main application.
At this point the main application reports the port conflict. It is a port that was used by the previous version.
I understand Windows reuses sockets under the hood, keeping them open even when an application closes them and then uses the same cached socket when the application connects again. So I figured Windows could be fooled by the new version, not recognizing it as the same application.
But here's the kicker. The updater stays up for a while, allowing the user to read the update report. The user can close it, if he doesn't it will automatically close after one minute. It appears that while the updater is running, the main application cannot be started without the port conflict occurring. As soon as the updater is closed, the main application can be started without issue again. And the updater itself does NOTHING with sockets!
Starting the updater and the main application is done using Process.Start(). It is as if something links the processes (of main app and updater). Task manager however confirms that the main application is really gone after is closed automatically.
Mind blown. Any insights would be much appreciated.
NineBerry's links were insightful but when trying to create an extension method for Process that takes an inherit argument I ran into the problem that ProcessStartInfo properties do not map nicely to the Win32 STARTUPINFO struct at all. This prevented me from keeping it compatible with existing code which used some features of ProcessStartInfo that I could not transfer to a call to CreateProcess. I do not understand how Process.Start() does this under the hood and could not be bothered anymore after I discovered a workaround.
It appears that setting ProcessStartInfo.UseShellExecute to true makes the whole problem go away. This may not be good for everybody because it has some additional properties but for me this was sufficient.
On GitHub people have asked for a ProcessStartInfo property that allows control over the the inherit value. It does not seem to be picked up yet and would likely only be implemented for future .NET Core releases.
A take on the seemingly discrepancy between ProcessStartInfo on the one hand and STARTUPINFO on the other hand would still be interesting so if anyone would care to explain, please do.
I apologize for the length of the question, but I believe it is difficult to understand the “why” without the background.
Background: I have two applications running in a Windows Embedded Standard 7 environment. They should be the only two applications running on the machine. One, called “Controller”, is written in C++ the other, “DBconnector”, is written in c#. This is not new code. It has been in active use and development for almost 20 years.
The purpose of the software is to run a manufacturing machine for producing parts. These machines are big and dangerous if the program crashes. Long ago, I discovered that if the network went down for some reason, all the threads in the application would stall – not just the network thread. This was disastrous since leaving the controller in a state with the wrong relays on in extremely rare circumstances could cause the machine to literally explode. Note: Several things have been added to the software and hardware to prevent this now. While this danger doesn’t really exist anymore, stability is still extremely important. I never want the operator to be stuck in a state where they can’t hit the reset button. My solution at the time was to move the networking tasks into a separate application. The OS was windows XP based at the time. I have no idea if the problem still exists in windows 10 since I really don’t want to rewrite hundreds of thousands of lines of code to try and merge the two programs now.
The development of the two programs diverged such that the one that controlled the machine, Controller, was designed for extreme stability and the other, DBconnector, was where dangerous things like networking and most file I/O happened. Communication between the two programs is facilitated using a memory mapped file that they both can access. I have no problem sharing window handles or process id’s or any other data that might be needed between the two programs.
Here is my question. How can I make the Controller application display the GUI of DBconnector? For example, I have started to add functionality to Controller that requires DBconnector to display the quality control sheets that are held on a web site on company servers. I want for an operator to be able to pull up the quality control sheet directly on the machine. The operator currently only interacts with the Controller application. I don’t want Controller to be able to access the network. Also, C# has some tools to make displaying a web page easy. It seems to me that the place to do this is DBconnector. The problem is that DBconnector runs in the background and cannot currently be seen or accessed by a user. So, the question is how to solve this.
First option I have tried is to tell DBconnector to come forward and put Controller in the background. Then, when the user is done, Controller comes back to the front. I have made this to work using some hacks, but it is inconsistent. The trick I used was to minimize and then maximize DBconnector which seems to bring it to the front most of the time and try to hold focus on one or the other. There still might be a way to do it this way, but it needs to be something that is consistent.
The second option is to run the DBconnector application inside of one of Controller’s windows. I have no idea how to do this. I thought about using ATL or COM, but I think these run as threads within Controllers process rather than as a separate application.
The third option I’ve considered is to create a window inside Controller that intercepts and passes all user input messages directly to Dbconnector using a windows message handle and takes a screenshot of DBconnector whenever the it is invalidated and passes it through the memory mapped file. Currently, this is what I am swaying towards.
Are there any suggestions on how to do the first and last option better, or how to do the second option at all, or another solution that I have missed? Keep in mind that our current hardware is running Windows Embedded Standard 7. The project is currently in visual studio 2015. The C++ window technology is MFC implemented using libraries originally from around 2003 I think. DBconnector is in .NET framework 4 in C#.
I have a console application that writes on a txt files information retrieved from a database. Until now I manually executes the executable generated by the console application.
Now I need to automatize the invocation of the .exe from my web application, so that each time a specific condition happens in my code behind I can run the .exe with a logic "fire and forget".
My goals are:
1) Users must not be affected in any way by the console application execution (the SQL queries and txt file generation might take around 3 to 5 minutes), therefore the logic of "fire and forget" delegated to a separate process.
2) Since the executable will be still run manually in some cases, I would prefer having the all logic in one place, in order to avoid the risk of having a different behaviour.
Can I safely use System.Diagnostics.Process to achieve this?
System.Diagnostics.Process cmd = new System.Diagnostics.Process();
cmd.Start("Logger.exe");
Does the process automatically ends or do I have to set a timeout and explicitly close it? Is it "safe" in a web application environment with different users accessing the web application let them call the executable without the risk of concurring accesses?
Thanks.
EDIT:
Changed to use the built in class for more clarity, thanks for the hint.
As far as the mechanics, I assume CommandLineProcess wraps Process? If so, I don't see anything necessarily wrong with it, at first glance. I just have some issue with running this as an executable from a web application, as you are more likely to reduce security to get it working than rearchitect (if you follow the normal path I see in development).
If you encapsulate the actual business code in a class library, you can run the code in the web application. The main rule is the folder it saves to should be under webroot (physically or logically) so you don't have to reduce security. But, if the logic is encapsulated, you can run the "file creeator" in the web process without spinning up a Process.
Your other option is wrap the process in a service (I like a non-HTTP WCF service, but you can go windows service, if you want). I would only go this direction if it makes sense to follow a SOA path with a service endpoint. As this is likely to be isolated to a single application, in process makes more sense (unless you are saving to a directory outside of webroot).
Hope this makes sense.
Yes, it will die on it's own - provided that the .exe file will terminate on it's own. It will run with the same credentials of the web server.
Keep in mind this is considered unsafe, since you are executing code based on whatever your webapp is doing. However, the problem is with .exe files being executed this way in general and not with the actual users accessing the app.
Similar question here How do I run a command line process from a web application?
I running a process for doing some task. Suppose 10 person are requesting to run that process then what will happen?
Whether it will maintain a queue or ?
I am writing the program in C#.
Any answers will be appreciated :)
If you have a simple Application, windows will always create a new process and load the executable within this place.
To have a single application which will get notified if the same user starts the same application a second time you can use the SingleInstance approach.
If you want that several users on the same machine will use the same instance you need to break down another fence. This can be achieved by using a windows service. In this case every user start it's own GUI (maybe using the SingleInstance behaviour) and this GUI will sync the showing up task list with a running service in the background.
Further infos about writing services you find an stackoverflow, google or at msdn.
is there a way to be notified when a program is executed or terminated by a user in c#? I am talking about all the programs that a user can execute, not just a certain program. I would like to be notified whenever a user execute .exe files.
I can't even think of a keyword to google.
any suggestions would be appreciated!
The closest thing I know of would be to use Hooks.
You can use WH_SHELL Hooks to receive notification any time a new, non-owned, top level window is created or destroyed by the system. This isn't the same as a process, but it's pretty close in many cases, and potentially more useful in others (since it'd show a new word document window opening after one was already opened, even though they're using a shared process).
You might be able to combine that with EnumProcess to check to see if the process list has changed. This would work for tracking windows applications (but not services or console-based applications running in an existing console).
In Microsoft .NET Framework 3.5, you can get a list of Processes and register for the Process.Exited event. I suppose someone could implement a polling system in which they continually looked for new Processes, but that doesn't really notify you when something launches.
-- EDIT --
You might find this article useful. If you're willing to write a kernel mode driver, you can control every process start and finish.
Now, if you really want to get wild, you can hook into Microsoft Detours. Here is an interesting article about that.