I am instrumenting our Embedded Linux system for GCOV. Currently, there are places in the code where reboot(LINUX_REBOOT_CMD_RESTART) is called and that abruptly reboot the firmware. I need to be able to gracefully shutdown each user space process and then reboot the firmware. Is there a system call that I can call instead of reboot(LINUX_REBOOT_CMD_RESTART) that will call do this by essentially call each applications init script with the stop parameter? for e.g. "/etc/init.d/myapp stop"
Related
I am trying to figure out who killed my process from taskmanager. Since taskmanager uses TerminateProcess and to Terminate a process remotely, it opens a Process Handle first.
So I am trying to look for UserMode ways to get a notification when a remote process tries to open a handle to my process.
I am aware there are possible solutions for this from Kernel mode using Driver Callbacks etc. But currently I am looking for User Mode possible solutions
I am trying to figure out who killed my process.
There is no official way to do that.
I am trying to look for UserMode ways to get a notification when a remote process tries to open a handle to my process.
There is no such notification in user mode.
The only way I can think of doing this is to use SetWindowsHookEx() to globally inject a custom DLL into every running process, and then you can have that DLL manually hook OpenProcess() directly, such as with a detour.
The hook can then compare the function's dwProcessId parameter value against your app's current process ID, which you can store in a block of globally shared memory while your app is running, such as via CreateFileMapping()+MapViewOfFile() (see Sharing Files and Memory and Creating Named Shared Memory).
In my usecase i need to send API call upon Windows machine shutdown/reboot.
The script i created works as expected from the PowerShell console, but not when defined in gpedit.msc's shutdown scripts location.
I am assuming this is because WiFi adapter somehow gets down before the script gets executed. Added some debug prints and seems that it is a corect observation.
To prove it more i re-defined the same script in user login scripts location - and it worked as expected indeed.
My question is whether it is really correct that a WiFi adapter disconnects before the shutdown script steps into the process, and if yes - is there any way to outsmart it with PowerShell script?
(My theory is that trapping/delaying a WiFi adapter in a shutdown could adress the case, but even if i knew how to do that i smell the same issue here - the adapter will go down before the trap pops up...)
EDIT: the thing is definitely with the adapter power on shutdown call. If i define the User Logoff script - the script works even if i do reboot or shut down.
So despite i didn't find a way to intercept the NW adapter power supply on shutdown (as well as no comprehensive technical documentation of this feature), i definitely found out a way to acheive my usecase - define the user logoff scripts instead of shutdown scripts.
I want to write a program to detach dll injection or vulnerability exploit by creating a monitor thread for all processes.I want to do this in user level instead of inserting a driver.
I try to use AppInit_DLLs to create a thread at DllMain,but it's not work if a program don't load user32.dll.
I try to listen a new process creation event and suspend new process for loading my monitor dll,but it's not work well.
Is there any methods to hook all new processes before they start run?
Most programs are run via double click so explorer.exe is the process which uses CreateProcess to launch them
Hook explorer.exe and make CreateProcess and ShellExecute/Ex hook the created processes also and so on
You can do some more by hooking all the running processes with the same technique once your injector opens thus you absolutely are hooking all user mode processes
Make sure to have the proper rights if you aren't running as admin you won't be able to hook processes running as admin
The functions you need to hook are usually CreateProcess NtCreateProcess ShellExecuteInfo/Ex
You will be using NtSuspendProcess and NtResumeProcess to set your hooks before the process has a chance to defend itself but tls callbacks may be already called , and in case of NtCreateProcess , CreateProcess you can use CREATE_SUSPENDED then ResumeThread with the thread handle you get from the function
if you want to go deeper you can hook NtCrateFile as any attempt to execute exe or load a dll will need to open the file to allocate the image in the memory
Our group has long running processes which run daily. The processes are typically started at 9pm on any given day and run until 7pm the next day. Thus they typically run 22hrs/day. They are started by scheduled tasks on servers under a particular generic user ID, and they start and run regardless of whether or not that user ID is logged on. Thus, they are windowless console executables.
The tasks orchestrate computations running on a large server farm. Generally these controlling tasks run uninterrupted for the full 22hrs/day. However, we often have a need to stop and restart these processes. Because they control a multitude of tasks running on our server farm, it is important that they be shut down cleanly, so that they can stop and shut down all the server farm processes. Which brings me to our problem.
The controlling process has been programmed to respond to ctrl-C and ctrl-break signals. This works fine when the process is manually started in a console where we have access to the console and can "type" ctrl-c or ctrl-break in the console window. However, as mentioned, the processes typically run as windowless scheduled tasks. Hence we cannot "type" anything into a non-existent console window. Because they are console processes that execute without a logon process, the also must be able to execute in a completely windowless environment. So, how do we set up the process to listen for a shut-down signal?
While the process does indeed listen for a ctrl-C and ctrl-break signal, I can see no way to send that signal to a process. This seems to be a fundamental problem in Windows, or am I wrong? I am aware of SendSignal.exe, but so far have been unable to get it to work. It fails as follows:
>SendSignal 26320
Sending signal to process 26320...
CreateRemoteThread failed with 0x00000005.
StartRemoteThread failed with 0x00000005.
0x00000005 == Access is denied.
Trying "taskkill" without -F results in:
>taskkill /PID 24840
ERROR: The process with PID 24840 could not be terminated.
Reason: This process can only be terminated forcefully (with /F option).
All other "kill" functions kill the process immediately rather than sending a signal.
One possible solution would be a file-watch based solution: create a watch for some modification of a specific file. But this is a hack and we would prefer to do it with appropriate signaling. Has anyone solved this issue? It seems to be so very basic a functionality, and it is certainly trivial to do it in a Unix environment. Surely Microsoft has provided SOME mechanism to allow clean shut down of a windowless executable?
I am aware of the thread below, whose question is virtually identical (save for the specification of why the answer is necessary, i.e. why one needs to be able to do this for a windowless, console-less process), but there is no answer there excpet for "use SendSignal", which, as I said, does not work for us:
Can I send a ctrl-C (SIGINT) to an application on Windows?
There are other similar questions, but no answers as yet.
Any help appreciated.
[Upgrading #Anon's comment to an answer for visibility]
windows-kill worked perfectly and managed to resolve access denial issues faced with SendSignal. A privileged user would have to run it as well of course.
windows-kill also supports both ctrl-c and ctrl-break signals.
I have a C++ Windows application that was designed to be a Windows service. It executes an updater periodically to see if there's a new version. To execute the updater, _execv() is used. The updater looks for new versions, downloads them and stops the Windows service (all of these actions are logged), replaces the files, and starts the service again. Doing that in CLI mode (not going into service mode) works fine that way. According to my log files, the child process is launched, but the parent process (the Windows service) exits.
Is it even "allowed" to launch child processes in Windows services, and, why does the service exit unexpected then? My log files show no error (I am even monitoring for segfaults etc which is written to the log).
Why are you using _execv() rather than doing it the windows way and using CreateProcess()?
I assume you've put some debug into your service and you aren't getting past the point where you call _execv() in your service?
_execv replaces the existing process with a new one running the file you pass as the parameter. Under Unix (and similar) that's handled directly/natively. Windows, however, doesn't support that directly -- so it's done by having the parent process exit and arrange for a child process to be started as soon as it does.
IOW, it sounds like _execv is doing exactly what it's designed to -- but in this case, it's probably not what you really want. You can spawn a process from a service, but you generally want to use CreateProcessAsUser to create it under a specified account instead of the service account (which has a rather unusual set of rights assigned to it). The service process will then exit and restart when it's asked to by the service manager when your updater calls ControlService, CreateService, etc.