I need to prevent an application from being started on a windows machine. The most obvious way (having an infinite loop and using EnumProcesses/OpenProcess/TerminateProcess) implies that the target application/process has already been started and also that it ran for a certain period of time.
Renaming/editing/patching/deleting the target application sadly isn't an option.
If you are running Windows 7 or newer (or anything based on it), then you can use the AppLocker feature:
http://technet.microsoft.com/en-us/library/dd723686(v=ws.10).aspx
Without replacing the code inside the unwanted executable? I don't think you can. Unless you break into the Windows kernel at least. See if the unwanted program has a schedule or a trigger that causes it to run. Maybe you can get rid of them. Hope this helps.
You can use CBT hook to inject hook dll into applications.
Then desired process can be terminated from inside hook procedure.
This applies to Windows 2000 and above.
Related
So I have spent that past week and a half working on code to simply setup the hook procedure for wh_shell for a program that will replace explorer.exe in the registry and will run as the main desktop program. There seems to be very little information and sources for using this outside of just the windows API which is a bit undescriptive and doesn't explain everything to a great detail. For some reason I just cant get it to work, no matter if I run it inside of explorer.exe, or if I replace the register and make it the default shell. I'm going to ask a couple of things in this post because I think that if you can answer one of these questions you likely have the answer to more.
So first I just have a question about hooks in general: When I run the SetWindowsHookEx(...) function -resource below- it says for var lpfn that a dll is not necessary if the hook is only used to monitor the current process. Now obviously when monitoring events such as window_created, those are events within a different processes which makes me think that the hookproc has to be within a DLL(which is how ive programmed so far). But this is questionable to me because when u are running SetWindowsHookEx(...) the process I wish to monitor do not yet exist until the user decides to start them. Do these processes notify the system when wh_shell events are being done so that I my hook doesnt need to get placed into every process upon creation, or is it more like when I run SetWindowsHookEx(...) with wh_shell that it will place a hook in all processes when the are created. The second resource states that the system just calls the hookproc when these things happen, so then do I even need a DLL, or what process does it need to be hooked to because I dont think it needs to be hooked into everything.
So second I have a question regarding setting my process as default shell - see resources - the resource states any process that registers itself as the default shell(which I assume is just modifying the registry to my process, if not and there is more please let me know) needs to call the SystemsParameterInfo(...) function. So first, does this func need to be called before running SetWindowsHookEx(...) or is there some expected spot it should be elsewhere in my code? Then in regards to the other variables it doesnt specify for, just curious what the recommended would be to set them as, like what are they set as for explorer.exe, and maybe a few other examples(including things NOT to do).
Finally for the sake of testing, using the console will be the most helpful to me here. The console will be used for input to run functions and commands for now(like open the register and swap back the shell to explorer.exe). If my hookproc is within a DLL, I need it to output some messages, I dont want to muddle the same console and I also dont even know if it will output to the same console, so what might be a recommended or potential solution for outputs(again this is temporary and for testing so it doesnt have to be perfect or even great)?
Also I would think windows 11 shouldn't be an issue, but I havent tested on windows 10 system...
I havent included any code as Im pretty sure most of this stuff can be answered without it and that its so few lines of code that its not like typical questions where its like examine my code and help me, maybe some example code you can show me would be really helpful.
Thankyou!
SetWindowsHookEx(...)
https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexa
defaultShell
https://learn.microsoft.com/en-us/windows/win32/winmsg/about-hooks#wh_shell
regards to WH_SHELL section
Testing Environment:
Windows 11 vm running in Hyper-V Manager
You haven't mentioned an important parameter in your description and that is the last argument of SetWindowsHookEx, the thread id.
When it is set to 0 then ..
'[in] Specifies the identifier of the thread with which the hook procedure is to be associated. If this parameter is zero, the hook procedure is associated with all existing threads running in the same desktop as the calling thread.'
That said, then like everything in Windows programming nothing is as what the documentation states, its as if the documentation is a wish-list Microsoft will like Windows to be when it grows up.
Actually even if you manage to get everything right you will see that the shell messages you will get will be VERY few compared to what the documentation states.
I am working on the same issue and when I get it going I will post the results here.
We have a bigger software running on Win CE6 without problems. The core functionality is implemented in a COM server DLL that provides connection points. The COM client program registers event handlers for the connection points on program startup to get status notifications etc. On program exit it unregisters the handlers by calling the corresponding IConnectionPointImpl::Unadvise methods.
Now, we are porting the program to run on Win EC 7. The new Board Support Package (BSP) for Win EC 7 works well. There are also different versions with different options, created at different times with different sources from Microsoft, but our software always show the same issue.
On program startup, ~10s after launch, IConnectionPointImpl::Unadvise is called unexpectedly on all registered event handlers. We only have one method in our source code that calls IConnectionPointImpl::Unadvise and this is definitely not executed.
The issue appears ~95%, but sometimes the program starts and runs without problems. We cannot use the Debugger because of the size of the program, the performance is very poor.
We guess, that the COM runtime calls the IConnectionPointImpl::Unadvise methods for some reasons. But we have no idea, how to prevent this.
Has anybody observed the same issue? Is there a solution/workaround available? Thanks.
So we finally found how solve this problem.
We remove our dependency on MarshalByReObject and replace it by a proper implementation of ISerializable.
That allow us to load properly inside custom AppDomain our assembly and events are not loose anymore.
But this has a side effect on path where assembly a configuration file are loaded. To solve this we also implement an AppDomain.AssemblyResolve event which allow us to redirect the loading in a proper place.
I hope this can help you ;)
I'm facing an issue with TerminateProcess() function.
The application I'm currently writing a JobScheduler app that schedules and launches job at a specific time.
For this purpose, I'm using CreateProcess() to execute my JobLauncher.
The JobLauncher process then launches a console program (using createprocess ) which effectively executes the job executable, waits for its termination and monitors the duration, user and kernel times elapsed etc.
In order to kill the job from the JobScheduler I firstly started using TerminateProcess() but it does not allow me to close the executable itself properly. I mean i found no way to hook any termination event.
Until I find a better way than a brutal TerminateProcess(), I wrote an intermediate solution using the GenerateConsoleCtrlEvent() in the calling program.
In the job application that launches the target job executable, I installed a handler using SetConsoleCtrlHandler().
And in the handler, I can terminate the process of the job and notifies my thirdparties properly.
This is the better solution I found for now.
Is there a better way to programmaticaly and properly close a process ?
Do you this solution is completly absurd ?
I'm not a "system-level" specialist developer though...
Z.
This well know Windows console problem and you can find some solutions here.
We used on internal console utility which has name "Kamikaze". It worked as described here and for me it's a best solution cause there is no problem with porting between Windows versions and Windows architectures (x86, x64).
I'm new to Windows API programming. I am aware that there are ways to check if a process is already running (via enumeration). However, I was wondering if there was a way to listen for when a process starts and ends (for example, notepad.exe) and then perform some action when the starting or ending of that process has been detected. I assume that one could run a continuous enumeration and check loop for every marginal unit of time, but I was wondering if there was a cleaner solution.
Use WMI, Win32_ProcessStartTrace and Win32_ProcessStopTrace classes. Sample C# code is here.
You'll need to write the equivalent C++ code. Which, erm, isn't quite that compact. It's mostly boilerplate, the survival guide is available here.
If you can run code in kernel, check Detecting Windows NT/2K process execution.
Hans Passant has probably given you the best answer, but... It is slow and fairly heavy-weight to write in C or C++.
On versions of Windows less than or equal to Vista, you can get 95ish% coverage with a Windows WH_CBT hook, which can be set with SetWindowsHookEx.
There are a few problems:
This misses some service starts/stops which you can mitigate by keeping a list of running procs and occasionally scanning the list for changes. You do not have to keep procs in this list that have explorer.exe as a parent/grandparent process. Christian Steiber's proc handle idea is good for managing the removal of procs from the table.
It misses things executed directly by the kernel. This can be mitigated the same way as #1.
There are misbehaved apps that do not follow the hook system rules which can cause your app to miss notifications. Again, this can be mitigated by keeping a process table.
The positives are it is pretty lightweight and easy to write.
For Windows 7 and up, look at SetWinEventHook. I have not written the code to cover Win7 so I have no comments.
Process handles are actually objects that you can "Wait" for, with something like "WaitForMultipleObjects".
While it doesn't send a notification of some sort, you can do this as part of your event loop by using the MsgWaitForMultipleObjects() version of the call to combine it with your message processing.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
\Image File Execution Options
You can place a registry key here with your process name then add a REG_SZ named 'Debugger' and your listner application name to relay the process start notification.
Unfortunately there is no such zero-overhead aproach to recieving process exit that i know of.
In a windows project I am working on, I intend to have a menu selection that copletely restarts the app. Is there a Windows or C++ function that does this?
There isn't a built-in for this, but a well-designed application can simply stop everything that's going on and then loop back to the start. If you want a true 'fresh start', you will have to spawn a new process (possibly as the last thing you do before the old one shuts down.)
No, you must do it yourself.
For instance, you can run external process which will wait until you exit your application, and then run it again.
Actually you might want to take a look at the Restart Manager API that came in with Windows Vista. As ever you can p-invoke this to your hearts content and theirs explicit support coming for it in Visual C++ 2010.
Already needed to do this. The easiest way without any further reading would be to write a simple .bat-file (either by hand or dynamically by your application) starting your program and then calling that bat-file from your application.
The bat-file may even contain a line to remove itself after having started your app...
You want to call CreateProcess and then close your current instance of the application gracefully with ExitProcess(), or if you link to the C runtime, just return from main().
But first you should ask yourself why you need to recreate the process in the first place.
ExitWindowsEx is what you want. You can also run the shutdown.exe utility built into windows.
shutdown -t0 -r (restart the system after 0 seconds)