Sign in to follow this  
BlueMana

Un-Terminatable process

Recommended Posts

Hi, so I have two process calling DebugActiveProcess on each other, hopefully making them unclosable. It works fine for one process(calling DebugActiveProcess for other process making it unclosable), but not for the other process. I don't know if there is anything else I need do do besides call DebugActiveProcess in each process. Here is my code: Process 1: Searches for other processes via window, and calls DebugActiveProcess on it
#include <windows.h>
#include <process.h>

int APIENTRY WinMain(HINSTANCE hInstance,
                     HINSTANCE hPrevInstance,
                     LPTSTR    lpCmdLine,
                     int       nCmdShow)
{
	HWND hWindow=0;

	do{
		hWindow = FindWindowEx(NULL, NULL, "test","test");
		Sleep(1000);
	}
	while(!hWindow);

	SendMessage(hWindow, 0x55, _getpid(), NULL);

	unsigned long id =0;
	GetWindowThreadProcessId(hWindow, &id);

	if(!DebugActiveProcess(id))
		MessageBox(0,"Failed",0,0);
	else
		MessageBox(0,"Success",0,0);

	while(true)
		Sleep(1000);

return 0;

}

Process 2: Creates window, waits for message w/ other processes id in it, then calls DebugActiveProcess
#include <windows.h>


LRESULT WINAPI MsgProc( HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam )
{
	switch( msg )
    {
		case 0x55:
			if(!DebugActiveProcess(wParam))
				MessageBox(0, "Failed",0 ,0);
			else
				MessageBox(0,"Success",0,0);
			break;
	}
    return DefWindowProc( hWnd, msg, wParam, lParam );
}


int APIENTRY WinMain(HINSTANCE hInstance,
                     HINSTANCE hPrevInstance,
                     LPTSTR    lpCmdLine,
                     int       nCmdShow)
{
	WNDCLASSEX wc;

	wc.cbSize = sizeof(WNDCLASSEX); 
	wc.style			= CS_HREDRAW | CS_VREDRAW;
	wc.lpfnWndProc	= MsgProc;
	wc.cbClsExtra		= 0;
	wc.cbWndExtra		= 0;
	wc.hInstance		= hInstance;
	wc.hIcon			= 0;
	wc.hCursor		= LoadCursor(NULL, IDC_ARROW);
	wc.hbrBackground	= (HBRUSH)(0);
	wc.lpszMenuName	= 0;
	wc.lpszClassName	= "test";
	wc.hIconSm		= 0;
    RegisterClassEx(&wc);

	CreateWindow("test", "test", 0, 0, 0, 0, 0, NULL, NULL, hInstance, NULL);

	MSG msg;
	while(true)
	{
		Sleep(1500);
		PeekMessage(&msg, NULL, 0,0,PM_REMOVE);
	}
}

Any ideas?

Share this post


Link to post
Share on other sites
I'm guessing that this is actually a feature of Windows. It would be a Bad Thing to just let any application set themselves up so they couldn't be terminated.

Share this post


Link to post
Share on other sites
The first problem I notice is that you're sending and relying on a randomly numbered message. Use WM_USER instead.
Also, are you properly using WaitForDebugEvent? Do you resume the threads of the process being debugged after they are suspended by the DebugActivePricess?

Share this post


Link to post
Share on other sites
Quote:
Original post by LessBread
Why do you want to spawn an "unterminable" process?


I'm writing a custom program to block bad websites and as such I don't want it to be closed.

[Edited by - BlueMana on November 12, 2005 2:25:11 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Extrarius
The first problem I notice is that you're sending and relying on a randomly numbered message. Use WM_USER instead.
Also, are you properly using WaitForDebugEvent? Do you resume the threads of the process being debugged after they are suspended by the DebugActivePricess?


I feel dumb asking this, but I can't figure out whats wrong with my enumerate threads code. It doesn't ever break out of the do loop :(.


HANDLE hSnap = CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD, id);
THREADENTRY32 Thread;
Thread.dwSize = sizeof(THREADENTRY32);

if (hSnap == INVALID_HANDLE_VALUE)
MessageBox(0,"Error",0,0);

if (Thread32First(hSnap, &Thread))
{
do
{
HANDLE hThread = OpenThread(THREAD_SUSPEND_RESUME, FALSE, Thread.th32ThreadID);
if(hThread && ResumeThread(hThread) != 0xFFFFFFFF)
{
CloseHandle(hThread);
}
else
MessageBox(0,"Failed",0,0);
}while(Thread32Next(hSnap, &Thread));
}

CloseHandle(hSnap);



Also, I added a WaitForDebugEvent loop

DEBUG_EVENT DebugEv; // debugging event information
DWORD dwContinueStatus = DBG_CONTINUE; // exception continuation

while(true)
{

//do stuff

WaitForDebugEvent(&DebugEv, 100);
ContinueDebugEvent(DebugEv.dwProcessId,
DebugEv.dwThreadId, dwContinueStatus);
}




Do I need anything else? I just want the other process to run normally, while still being debugged.

[Edited by - BlueMana on November 12, 2005 2:31:14 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by BlueMana
I'm writing a custom program to block bad websites and as such I don't want it to be closed.


Stop right there. You should not be doing this; all this will ensure is that people such as myself will never, ever, ever use a program as badly behaved as yours.

Share this post


Link to post
Share on other sites
Quote:
Original post by Catafriggm
Quote:
Original post by BlueMana
I'm writing a custom program to block bad websites and as such I don't want it to be closed.


Stop right there. You should not be doing this; all this will ensure is that people such as myself will never, ever, ever use a program as badly behaved as yours.



what?

Share this post


Link to post
Share on other sites
Quote:
Original post by BlueMana
Quote:
Original post by Catafriggm
Quote:
Original post by BlueMana
I'm writing a custom program to block bad websites and as such I don't want it to be closed.


Stop right there. You should not be doing this; all this will ensure is that people such as myself will never, ever, ever use a program as badly behaved as yours.



what?


unless its just for yourself, other people might want to use this. but if they can't close it...

Share this post


Link to post
Share on other sites
Short answer: resistance to termination is one of the deadly sins of programming. Up there with associating a bunch of common file types with your program without asking, installing a rootkit, etc. The kind of thing any programmer should be taken out back and shot for.

Share this post


Link to post
Share on other sites
Quote:
Original post by Catafriggm
Short answer: resistance to termination is one of the deadly sins of programming. Up there with associating a bunch of common file types with your program without asking, installing a rootkit, etc. The kind of thing any programmer should be taken out back and shot for.
Unless, of course, the purpose of the program is to secure a computer from guest accounts (which require local admin access because few existing programs work without it). Of course, if this is the case, the most difficult part is preventing uninstallation (which can easily be done even to a running process by scheduling a delete on reboot and then rebooting, or editing the appropriate config, etc).

Reguardless, I'm working on making a process that can't be terminated as an example, and if I get it working I'll post it here.

Share this post


Link to post
Share on other sites
Quote:
Original post by Extrarius
Quote:
Original post by Catafriggm
Short answer: resistance to termination is one of the deadly sins of programming. Up there with associating a bunch of common file types with your program without asking, installing a rootkit, etc. The kind of thing any programmer should be taken out back and shot for.
Unless, of course, the purpose of the program is to secure a computer from guest accounts (which require local admin access because few existing programs work without it). Of course, if this is the case, the most difficult part is preventing uninstallation (which can easily be done even to a running process by scheduling a delete on reboot and then rebooting, or editing the appropriate config, etc).

Reguardless, I'm working on making a process that can't be terminated as an example, and if I get it working I'll post it here.


Wow, thanks, that would be awesome!

Share this post


Link to post
Share on other sites
Ok, well I got my code working, and it creates a process that debugs itself by launching a copy of itself, _BUT_ it can still be terminated.

It seems that the behavior of TerminateProcess (or whatever the task manager uses) has been changed to allow any process to be terminated by the administrator.

Share this post


Link to post
Share on other sites
The right to dictate what programs run and what programs don't should not be taken away from the user. No good can come of this.

Share this post


Link to post
Share on other sites
Quote:
Original post by daerid
The right to dictate what programs run and what programs don't should not be taken away from the user. No good can come of this.


Lol, okay, okay, I get the point. This program is intended only for me so this isn't an issue really.

Share this post


Link to post
Share on other sites
Well, you can always use two processes which will "look" for each other. If process A is closed process B launches new instance of it, and vice versa. It's still killable, but this time not so easly.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Might as well just buy the driver kit[1] (free plus ~15$USD shipping to the US last I checked). Then, you could create make a special driver that allocates user space, loads the program there (making the proper adjustments for relocation and the like), and then runs it, all without ever touching the standard process tables (thus, no record exists that there is a program loaded, except for the driver itself).

Actually, it might be possible to do that without the DDK, but I'm not sure how to allocate memory that will stay around after the loader process terminates. I guess one option would be abusing the CreateRemoteThread function to inject the allocation into something interesting, such as the desktop process or maybe the idle process (hrmm, I don't think the latter is possible). I'll investigate when I get home.

If you have two drivers that check eachother as Kiput suggested, I'm not sure if there is a way to get rid of them at all (beyond a reformat)

[1] http://www.microsoft.com/whdc/devtools/ddk/default.mspx

-Extrarius

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this