I have a Process called "Agent" it spawns a new process called "Connect". This "Connect" process loads the service dll's. The "Connect" process start a sub process(cmd.exe), I would like to know if for some reasons the loaded dll's cause a hang or a crash, how to ensure that "cmd.exe" is terminated.
Use CreateProcess to spawn the new process. The involves setting up and passing in a PROCESS_INFORMATION structure: which will contain a handle to the new process (hProcess) if the call to CreateProcess works.
You can now do a WaitForSingleObject on this process handle to see when the process finishes. WaitForSingleObject allows you to timeout if the object does not trigger (i.e. process does not terminate), and hence take action (TerminateProcess I presume).
Related
I've got an SSD that is failing. Some of its data can't be read anymore.
I would like to know which files are affected.
I've created some small program that uses regular functions (CreateFile, ReadFile) to read files.
The program has some watchdog thread that monitors the thread that issues the IO functions. If they take too long, the thread marks somewhere the file is damaged and tries to kill the IO thread and the process.
My issue is using TerminateThread and TerminateProcess does not kill the thread/process. It hangs there, forever, until I log out.
Trying to kill using TaskManager also fails, of course (it used to use NtTerminateProcess, I don't know what it does nowadays).
Does anyone know a way that would kill my process?
According to the Doc: TerminateProcess function
This function stops execution of all threads within the process and
requests cancellation of all pending I/O. The terminated process
cannot exit until all pending I/O has been completed or canceled. When
a process terminates, its kernel object is not destroyed until all
processes that have open handles to the process have released those
handles.
When a process terminates itself, TerminateProcess stops execution of
the calling thread and does not return. Otherwise, TerminateProcess is
asynchronous; it initiates termination and returns immediately. If you
need to be sure the process has terminated, call the
WaitForSingleObject function with a handle to the process.
I suggest you could try to use Job Objects.
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
The new AspNetCoreModule module just like IIS somehow detects when an application crashes and restarts it. How is it implemented? Just by asking Windows if a process still exists or something more subtle (like a RPC call maybe)? What happens if a process just hangs resulting in HTTP timeouts?
When AspNetCoreModule creates the child process, it immediately check the whether the child process is up by connecting it via socket and exist code. If the child process is up, the module calls RegisterWaitForSingleObject with processInformation.hProcess and some callback, so that if child process exists, the callback will be called. In the case, the child process hangs, the module will return 502 back to the client after timeout and will not kill the child process.
I am trying to attach debugger(windbg,ollydbg) to running process but there's an error saying Debugger is already attached then how can i detach that unknown debugger from that process?
Process includes multi thread, one thread can be attached to debugger and other can't.
The process might be spawning a second process which attaches to the first process for debugging using DebugActiveProcess() in order to prevent people from debugging the first process. Keep in mind that a process cannot debug itself using this method, so a second process must be spawned to do this.
Things you could try:
Use any sort of process monitor or even task manager to figure out what process the first process spawns
Inject code into the second process to call DebugActiveProcessStop() to detach it from the first process
Hook DebugActiveProcess() (kernel32.DebugActiveProcess, ntdll.ZwDebugActiveProcess, or in kernelmode) and redirect it to attach to a different dummy process
Kill the second process
Prevent the second process from getting a handle to the first process with the needed permissions - DebugActiveProcess() will then fail
Use alternative debugging methods (Cheat engine with VEH debugging for example) that don't use the normal debugging API's and therefore bypass this problem
What is the difference between killing an application using the close button and ending the process from the Task Manager?
I am aware of the fact that hitting the close button posts a WM_CLOSE message in the message queue, but I don't know what happens when we kill a process from Task Manager (or any similar application like Killbox or Process Explorer).
When you click the "X" button in the title bar of an application's window, that sends the window a WM_CLOSE message. This is a "graceful" shutdown—the application processes the message, handles any necessary cleanup tasks, and can even refuse to shut down if it so desires (by returning zero in response to the message). WM_CLOSE is simply a request that the window or application terminate; the window is not destroyed until the application itself calls the DestroyWindow function.
When you press the "End Task" button in Task Manager, Windows will first try to send the application (if it is a GUI application) a WM_CLOSE message. In other words, it first asks nicely and gives the app a chance to terminate itself cleanly.*
If you fail to close in response to that initial WM_CLOSE message, the Task Manager will follow up by calling the TerminateProcess function. This function is a little bit different because it forcefully terminates the application's process and all of its threads without asking for permission from the app. This is a very harsh method of closing something, and should be used as a last resort—such as when an application is hung and is no longer responding to messages.
TerminateProcess is a very low-level function that essentially rips the user-mode part of a process from memory, forcing it to terminate unconditionally. Calling TerminateProcess bypasses such niceties as close notifications and DLL_PROCESS_DETACH. Your application does not have the ability to refuse to close, and there is no way to catch/trap/hook calls to TerminateProcess. All user-mode code in the process simply stops running for good. This is a very unclean shut down procedure, somewhat akin to jerking the computer's power plug out of the wall.
* Note that this only true if you use the "Applications" tab of Task Manager to kill the application. If you use the "Processes" tab, this step is skipped and the TerminateProcess function is called immediately. This distinction is reflected in the caption on the respective buttons. For the "Applications" tab, the button is lableled "End Task"; for the "Processes" tab, the button is labeled "End Process".
Killing the process with WM_CLOSE simply signals the process with the message and allows the target to handle the message and exit gracefully. Alternatively, the process could choose not to exit in its WM_CLOSE handler.
Killing the process via task manager will do so with TerminateProcess which is far harsher:
The TerminateProcess function is used to unconditionally cause a
process to exit. The state of global data maintained by dynamic-link
libraries (DLLs) may be compromised if TerminateProcess is used rather
than ExitProcess.
This function stops execution of all threads within
the process and requests cancellation of all pending I/O. The
terminated process cannot exit until all pending I/O has been
completed or canceled. When a process terminates, its kernel object is
not destroyed until all processes that have open handles to the
process have released those handles.
TerminateProcess is asynchronous;
it initiates termination and returns immediately. If you need to be
sure the process has terminated, call the WaitForSingleObject function
with a handle to the process. A process cannot prevent itself from
being terminated.
If you close an application using the close button you let the application to perform necessary closing tasks if any. If you kill a process from task manager there is no chance for application to perform those tasks, you just terminate the application without informing.