|
The first rule of terminating a process is not to do it: prefer asking it to close down nicely. See http://support.microsoft.com/kb/178893[^]. That said, terminating a process is sometimes necessary as a last resort. The TerminateProcess[^] function will do the trick. It requires a process HANDLE but you only have a process id: use OpenProcess[^] to get a HANDLE from it.Steve
|
|
|
|
|
Try this....
HANDLE prHandle = OpenProcess(PROCESS_ALL_ACCESS, TRUE, dwProcessID);
if (NULL != prHandle)
{
TerminateProcess(prHandle, 0);
}
|
|
|
|
|
If you know the hwnd of the window, then you can use SendMessage Function to close the window....
|
|
|
|
|
| I'm not the one asking the question. Your suggestion is the procedure I outlined in my post. Steve
|
|
|
|
|
You are right Stephen, We two are in same direction. I just followed your reply thread. Not opened another thread, that's all. anyway sorry for the confusion.
|
|
|
|
|
|
Hi all,
I am having an exe application.I want to make this exe application as a child to another main application. So that, if the main application crashes and gets closed,the child application also gets closed. How can i do this?
Thanks,
|
|
|
|
|
Have the parent application pass a HANDLE to itself to the child process. Note that a process HANDLE is a Synchronization Object[^] which becomes signalled when the process to which it refers terminates, regardless of how this happens. The child process uses this HANDLE with one of the wait functions[^] and shuts itself down when it becomes signalled. That's the broad outline. Feel free to ask specific questions if you have any trouble implementing it.Steve
|
|
|
|
|
I am executing the exe from the main application using CreateProcess function.how to pass the parent handle to this child applcation?
|
|
|
|
|
| There's many possible ways, the most obvious being passing it on the command line. Steve
|
|
|
|
|
Hi all,
I am writing a custom control for my Win 32 application. IDE is VS2005 with MFC framework,
OS is Win Vista. Please see the code below and i could get the cell rectangle area by lplvcd->nmcd.rc.
void CExListCtrl::OnNMCustomdraw(NMHDR *pNMHDR, LRESULT *pResult)
{
LPNMLVCUSTOMDRAW lplvcd = reinterpret_cast<LPNMLVCUSTOMDRAW>(pNMHDR);
if(NULL == lplvcd)
*pResult = 0;
//1
if (lplvcd->nmcd.dwDrawStage == CDDS_PREPAINT)
{
*pResult = CDRF_NOTIFYITEMDRAW;
}
//2
else if (lplvcd->nmcd.dwDrawStage == CDDS_ITEMPREPAINT)
{
*pResult = CDRF_NOTIFYSUBITEMDRAW;
}
//3
else if (lplvcd->nmcd.dwDrawStage == (CDDS_ITEMPREPAINT | CDDS_SUBITEM))
{
//lplvcd->nmcd.rc - cell rect
*pResult = CDRF_DODEFAULT;
}
}
But when i tried to run the same code in Windows XP with Visula studio 2008, lplvcd->nmcd.rc.bottom and lplvcd->nmcd.rc.top value is always zero.
Does anybody know why it is happening?
Thanks,
Prasanth
|
|
|
|
|
MSDN: This member is initialized only by the CDDS_ITEMPREPAINT notification.
Version 5.80. This member is also initialized by the CDDS_PREPAINT notification  virtual void BeHappy() = 0;
|
|
|
|
|
Thank you Mr.Eugen Podsypalnikov.
Your solution seems to be gud. let me to try. 
Thanks,
Prasanth Vijayan
|
|
|
|
|
Dears,
Is it possible to put comments in .rgs (COM related) file?
Please help.
Regards,
Krishnakumar
|
|
|
|
|
| I don't think so. The MSDN syntax docs (the first link on this page[^]) don't list any comment symbol, nor do any of the examples. L u n a t i c F r i n g e
|
|
|
|
|
|
How can insert menu to dialog by ce application?
CMenu m_menu;
m_menu.LoadMenuW(IDR_MENU_MAIN);
CMyCEApplicationDlg dlg;
m_pMainWnd = &dlg;
dlg.SetMenu(&m_menu);
RunTime the code "dlg.SetMenu(&m_menu);" is error.
|
|
|
|
|
i already find the reason,
beacause
"
m_menu.LoadMenuW(IDR_MENU);
dlg.SetMenu(&m_menu);
"
should be put in Dialog InitDialog method;
|
|
|
|
|
It is a good practice to check return value of functions like LoadMenu() to know if the call is succeeded or not.
|
|
|
|
|
Hi all,
I'm curious as to whether there are methods to detect forms of hooking on windows. I've been trying the WH_DEBUG hook to no success, code is below and it crashes every app under the explorer.exe tree.
HHOOK debughook;
LRESULT CALLBACK DebugProc(int nCode,WPARAM wParam,LPARAM lParam){
return CallNextHookEx(debughook,nCode,wParam,lParam);
}
int APIENTRY WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow)
{
debughook=SetWindowsHookEx(WH_DEBUG,DebugProc,hInstance,0);
Any help with that would be appreciated, as well as any other suggestions on hook detection. My original goal was to make an effective keylogger detection app, but as of now that doesn't seem very likely anymore.
Thanks.
edit: is there any reason why a global IAT patch doesn't seem to work on SetWindowsHookExA?modified on Wednesday, March 10, 2010 8:24 PM
|
|
|
|
|
This is an excellent question. If you search over at MSDN you will discover: Win32 Hooks[^]
The problem is that, if you want to detect ALL hooks, you're going to have to think about the Hooking techniques. The sneakiest hooks do NOT use the standard available Windows techniques. And, of course, Windows does not want you interferring in its Hooking Chain, so they don't provide you with an easy method of monitoring hook activity.
|
|
|
|
|
Of course. In fact, I haven't even considered going into kernel land yet, only usermode methods of detecting hooks.
The article is interesting but I can't seem to use any of that to detect installed hooks. 
|
|
|
|
|
There is also a complete reference on Windows Hooks over at MSDN: HOOKS[^]. I'd guess that you've already read it.
|
|
|
|
|
In the book, "Rootkits: Subverting the Windows Kernel", by Greg Hoglund, the author devotes an entire chapter to Hooks, and in particular, IAT hooking, which is probably the best way to detect malicious code. I have copied a section here to give you an idea. He discusses hooking in terms of a rootkit injected into a remote computer.
Import Address Table Hooking
The simpler of the two userland hooking processes is called Import Address Table hooking. When an application uses a function in another binary, the application must import the address of the function. Most applications that use the Win32 API do so through an IAT, as noted earlier. Each DLL the application uses is contained in the application's image in the file system in a structure called the IMAGE_IMPORT_DESCRIPTOR. This structure contains the name of the DLL whose functions are imported by the application, and two pointers to two arrays of IMAGE_IMPORT_BY_NAME structures. The IMAGE_IMPORT_BY_NAME structure contains the names of the imported functions used by the application.
When the operating system loads the application in memory, it parses these IMAGE_IMPORT_DESCRIPTOR structures and loads each required DLL into the application's memory. Once the DLL is mapped, the operating system then locates each imported function in memory and overwrites one of the IMAGE_IMPORT_BY_NAME arrays with the actual address of the function.
Once your rootkit's hook function is in the application's address space, your rootkit can parse the PE format of the target application in memory and replace the target function's address in the IAT with the address of the hook function. Then, when the function is called, your hook will be executed instead of the original function.
You can see that this is a very powerful yet rather simple technique. It does have its drawbacks, though, in that it is relatively easy to discover these types of hooks. On the other hand, hooks like these are used frequently, even by the operating system itself in a process called DLL forwarding. Even if someone is trying to detect a rootkit hook, determining what is a benign hook as opposed to a malicious hook is difficult.
Another problem with this technique has to do with the binding time. Some applications do late-demand binding. With late-demand binding, function addresses are not resolved until the function is called. This reduces the amount of memory the application will use. These functions may not have addresses in the IAT when your rootkit attempts to hook them. Also, if the application uses LoadLibrary and GetProcAddress to find the addresses of functions, your IAT hook will not work.
|
|
|
|
|
I have copied a brief section here about the general techniques involved in looking for User Mode IAT hooks, again, from "Rootkits: Subverting the Windows Kernel". I have left out the description of Inline Hooks, because they are implemented in assembly language and require some experience in disassembling.
Looking For Hooks
A memory-based detection method is to look for hooks within the operating system and within processes. There are many places where a hook can hide, including the following:
Import Address Table (IAT)
System Service Dispatch Table (SSDT), also known as the KeServiceDescriptorTable
Interrupt Descriptor Table (IDT) with one per CPU
Drivers' I/O Request Packet (IRP) handler
Inline function hooks
The basic algorithm for identifying a hook is to look for branches that fall outside of an acceptable range. Such branches would be produced by instructions like call or jmp. Defining an acceptable range is not difficult (for the most part). In a process Import Address Table (IAT), the name of the module containing imported functions is listed. This module has a defined start address in memory, and a size. Those numbers are all you need to define an acceptable range.
Likewise for device drivers: All legitimate I/O Request Packet (IRP) handlers should exist within a given driver's address range, and all entries in the System Service Dispatch Table (SSDT) should be within the address range of the kernel process, ntoskrnl.exe.
Finding Interrupt Discriptor Table (IDT) hooks is a bit more difficult, because you do not know what the acceptable ranges should be for most of the interrupts. The one you know for sure, however, is the INT 2E handler. It should point to the kernel, ntoskrnl.exe.
Inline hooks are the hardest to detect, because they can be located anywhere within the function—requiring a complete disassembly of the function in order to find them—and because functions can call addresses outside the module's address range under normal circumstances. In the following sections, we will explain how to detect SSDT, IAT, and some inline hooks.
Finding IAT Hooks
IAT hooks are extremely popular with current Windows rootkits. IAT hooks are in the userland portion of a process, so they are easier to program than kernel rootkits, and do not require the same level of privilege. Because of this, you should make sure your detection software looks for IAT hooks.
Finding IAT hooks is very tedious, and implementing a search for them requires many of the techniques covered in previous chapters. However, those steps are relatively straightforward. First, change contexts into the process address space of the process you want to scan for hooks. In other words, your detection code must run within the process you are scanning.
Next, your code needs a list of all the DLLs the process has loaded. For the process, and every DLL within the process, your goal is to inspect the functions imported by scanning the IAT and looking for function addresses outside the range of the DLL the function is exported from. After you have the list of DLLs and the address range for each one, you can walk each IAT of each DLL to see whether there are any hooks. Particular attention should be paid to Kernel32.dll and NTDLL.DLL. These are common targets of rootkits, because these DLLs are the userland interface into the operating system.
If the IAT is not hooked, you should still look at the function itself to determine whether an inline hook is present.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
