A forum for reverse engineering, OS internals and malware analysis 

Forum for discussion about user-mode development.
 #3366  by EP_X0FF
 Sun Nov 07, 2010 3:46 am
It is impossible to hide window totally, so you can spare your time. Take a look on that file.
Attachments
(14.33 KiB) Downloaded 82 times
 #3367  by sainfoin
 Sun Nov 07, 2010 3:51 am
thank you very much.

I also googled,and find some skills to kill process:

/* Window Attacking */

PostMessage(SendMessage) WM_CLOSE/WM_QUIT/WM_DESTORY/WM_NCDESTORY

SetParent->DestoryWindow

EndTask // Will make a direct call to the Win32 subsystem

PostMessage(SendMessage) 0x19 // by MJ0011, for MFC Application

for (int i=0; i<65536; i++)
{
PostMessage(HWND, i, 0, 0); // Message Flood
}

SetWindowLong(HWND, GWL_WNDPROC, (WNDPROC)YourDeadLock_Or_Crash_Function);


Is there a best way to protect process?

Thanks
 #3368  by EP_X0FF
 Sun Nov 07, 2010 3:56 am
PostMessage, SetParent see attached file.

For EndTask you need to intercept NtTerminateProcess. Once it will be done, this API will be unable to kill window/app (see IceSword as example).
 #3378  by EP_X0FF
 Sun Nov 07, 2010 11:33 pm
Not sure this will work for all kind of GUI based attacks. The best solution here - two processes. One running as service second as application for current user. If application terminated by unusual way service spawn another copy. Service itself must be protected from stopping/disabling/terminating (for example by action failure list). You can protect service registry by documented way - using Configuration Manager Registry Callback API. Such solution will work everywhere starting from Windows XP up to Windows 7 x64. No hacks, PatchGuard - OK, everything legal. Additionally you can use Object Callbacks starting from Windows Vista SP1, they will successfully protect your application from unauthorized access/termination. And of course for complete self-protection you need file system filter driver.
Don't forget - all this will protect you ONLY from user mode attacks. There is nothing to do with kernel mode ;)

ObRegisterCallbacks
CmRegisterCallback
CmRegisterCallbackEx
 #3379  by xqrzd
 Mon Nov 08, 2010 3:05 am
Not sure this will work for all kind of GUI based attacks.
You are right, I just tried this with Process Hacker, intercepting the messages worked for Process Hacker's WM_DESTROY, but it failed with WM_QUIT. When Process Hacker sent over WM_QUIT, my app intercepted and blocked WM_DESTROY and WM_NCDESTROY (and also 0x90, not sure what the name for this is) but my app still closed.
Don't forget - all this will protect you ONLY from user mode attacks. There is nothing to do with kernel mode ;)
:cry: