|
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.
|
|
|
|
|
"Also, if the application uses LoadLibrary and GetProcAddress to find the addresses of functions, your IAT hook will not work."
Does that mean if I compare the addresses of HookedFunction() and LoadLibrary(HookedFunction) I would be able to detect IAT hooks in my process?
If so, any suggestions on how I might generalize this to every running process?
|
|
|
|
|
hxhl95,
The chapter about hooks from the Rootkits book by Hoglund is lengthy, and goes into great detail describing the most common hooking techniques used by malicious code. Rather than post the entire chapter (which would be HUGE), I just copied brief selections to give you an idea of what the general concept is. I left out a bunch of explanatory material. Alot of interesting information about the techniques used by malicious software are explained on: Rootkit[^]
But, if you are trying to detect unauthorized hooks in your process address space (or others on the Local Machine), the concept is examine the address range of the DLL that exports the function called in the IAT of your process (the DLLs are all dynamically loaded by the system into your process address space), and determine if the address actually listed in the IAT corresponds to that range.
If the process instead calls LoadLibrary and GetProcAddress to load the DLL on demand, the address entry in the IAT will NOT exist, so any malicious injected DLL code could not possibly overwrite the IAT address. (Actually, I'm unsure if the Operating System creates a temporary IAT entry at this point, but, I assume that it doesn't.)
Go to SysInternals and download Process Explorer[^](FREE) to get a graphic representation of which dynamically loaded DLLs exist in your Process addesss space. Also,VMMap[^] is a very useful utility for understanding process address space memory allocations.
An excellent overview of the Portable Executable format and its structures when loaded into memory is located at: Peering Inside the Portable Executable, Matt Pietrek[^]
|
|
|
|
|
Yes, I've been exploring that and I think I can continue from here.
Thanks a lot for your help Baltoro! 
|
|
|
|
|
Hi guys,
I have VS2005 and VS2008 installed on my development machine. Whenever I develop a DLL I have to link with the /MT (Multi-Threaded) option if I want to use it on any other machine. If I compile the DLL on a machine with VS2005 only, however, I don't have to use the /MT option, I can use the /MD (Multi-Threaded DLL) and the DLL can be used on any machine.
Has anyone else come across this? Is there a way to resolve this?
Thanks.
|
|
|
|
|
You should deploy the runtime on the target machines, see [^].
 If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Thanks but I have already installed the VC++ 2005 and 2008 runtime libraries on the target machine. That doesn't help, though. I am developing on a Windows 7 machine. Should that make a difference?
|
|
|
|
|
What is the error you get?If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
/MD means: all that MFC/C-runtime stuff will live in a set of external DLLs which i will ship with my application.
MT means: put all that MFC/C-runtime stuff into the DLL itself so i don't have to distribute the runtime libraries with my application.
|
|
|
|
|
Thanks Chris. I know what the /MD and /MT switches are for. What I don't understand is why the /MD switch would work on a machine with VS2005 only and not on the other.
|
|
|
|
|
Hi,
because of the CRegistry class and some other classes in my Application I need to have Administration rights for it. I want to have the same effect like set the "Run programm as Administrator" checkbox in the compatibility options of my Application, but in my Visual C++ code. I`m using the Visual Studio 2008.
I discovered, that AdjustTokenPrivileges is the function I probably need, but I don`t understand how to use it.
I get my token using the following lines:
HANDLE hToken = NULL;
if (!OpenProcessToken(GetCurrentProcess(), TOKEN_DUPLICATE,&hToken)) {
AfxMessageBox("Error");
}
CloseHandle(hToken);
But I don`t know how to set the Privileges to the token, and I don`t understand how to set it for my whole application?
Can someone help me?
Thank you!
|
|
|
|
|
Try it
However, I hold it in a service code, that is started by SYSTEM user...
(Die Funktion aktiviert eine existierende Begünstigung,
verteilt aber nichts, wenn diese für den Benutzer nicht vorhanden ist)
BOOL AdjustTokenPrivileges(LPCTSTR lpName)
{
BOOL bRes = TRUE;
HANDLE hToken;
if (OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES, &hToken)) {
LUID luid;
if (LookupPrivilegeValue(NULL, lpName, &luid)) {
TOKEN_PRIVILEGES tp;
tp.PrivilegeCount = 1;
tp.Privileges[0].Luid = luid;
tp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
if (!::AdjustTokenPrivileges(hToken, FALSE, &tp, sizeof(TOKEN_PRIVILEGES), NULL, NULL)) {
bRes = FALSE;
}
} else {
bRes = FALSE;
}
CloseHandle(hToken);
} else {
bRes = FALSE;
}
return bRes;
}
void Usage()
{
AdjustTokenPrivileges(SE_RESTORE_NAME);
AdjustTokenPrivileges(SE_BACKUP_NAME);
...
}virtual void BeHappy() = 0;
|
|
|
|
|
I need to get the font of a static control, but the documentation says WM_GETFONT will return null if the control is using the system font. How can I get the system font?
[Edit]
I see GetStockObject can return the font, but there are many options. Which one of those do I need:
DEVICE_DEFAULT_FONT Windows NT/2000/XP: Device-dependent font.
DEFAULT_GUI_FONT Default font for user interface objects such as menus and dialog boxes. This is MS Sans Serif. Compare this with SYSTEM_FONT.
OEM_FIXED_FONT Original equipment manufacturer (OEM) dependent fixed-pitch (monospace) font.
SYSTEM_FONT System font. By default, the system uses the system font to draw menus, dialog box controls, and text.
Windows 95/98 and Windows NT: The system font is MS Sans Serif.
Windows 2000/XP: The system font is Tahoma
SYSTEM_FIXED_FONT Fixed-pitch (monospace) system font. This stock object is provided only for compatibility with 16-bit Windows versions earlier than 3.0.There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
We've been using GetStockObject(DEFAULT_GUI_FONT) and that has worked from Win95 to Windows 7. What do you need it for?
|
|
|
|
|
| Thanks. I derive a class from cstatic with functions for changing font size and name. I do it by calling CWnd::GetFont, changing what I need and then calling CWnd::SetFont There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
Can anyone suggest a library/control for editing HTML that can be added to a program written in C/C++ that only uses the Windows API (no MFC etc). We currently use nBit's HTML Editor OCX[^] but this has some small issues and hasn't been updated since 2006. The library/control will need to be royalty free.
|
|
|
|
|
|
Thanks for trying but MFC is not an option (I did mention that).
|
|
|
|
|
Sorry, I didn't notice it.
|
|
|
|
|
|
I am using visio 2007 in one of the editor in my application, in which I want to add new menu items to the visio objects. That means when I right-click on the object, I should get my new meni item with the sub-menus inside it.The problem here is, I am able to add new menu items to the visio object but sub-menus, I could not add. Can someone help me out by providing me necessary information to resolve this?
|
|
|
|
|
CMFCRibbonPanel class do not implement any method for changing the control name at running time,
I think there should be a method like CMFCRibbonPanel::SetName since there is method like CMFCRibbonPanel::GetName so How could we change the name of this control dynamically?
|
|
|
|
|
0. Try the SetWindowText(..) function
1. Debug the drawing of the text and find an access to the found member  virtual void BeHappy() = 0;
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
