SetWindowsHookEx and MSCTF.DLL (ctfmon.exe)

[bedlam]

Hi,

I've managed to download and compile the source code to AntiKeyLogger
http://psmantikeyloger.sourceforge.net/

I have run the program without errors and it pops up when ever a keyboard hook is detected, so far so good.

However, when using the MadCodeHook injection on SetWindowsHookEx, if ctfmon.exe is running, all calls are being routed and seem to be coming from MSCTF.DLL.....hmmm...i wonder u this is.

AntiKeyLogger allows MSCTF.DLL as a trusted application by default, so it is defeated if ctfmon.exe is running, which allows any keyboard hooks to go undetected.

I don't know much about MSCTF or ctfmon.exe, I will do some searching on the net to see what I can find...what is this MS crap.

If anyone is using MadCodeHook and the AntiKeyLogger, this may be interesting info for u.[/url]

[madshi]

I think ctfmon is a part of MS Office. Not sure, though.

[bedlam]

I found some info on ctfmon.exe, direct from MS site:

Ctfmon.exe is the file that is responsible for controlling the Alternative User Input technologies. It starts the Language Bar component (in the Systray) and remains running in the background even after you quit an Office XP program. It also starts each time Windows is started and remains in the background, regardless of whether an Office XP program is started.

Ctfmon.exe is designed to continue to run in the background during Windows sessions after the Office XP Alternative User Input components are installed.

During my testing with MadCodeHook and capturing SetWindowsHookEx Keyboard Hooks, I have found that when ctfmon.exe is running, all calls are being reported to come from MSCTF.DLL. I need to obtain the actual process name or application name that is installing the keyboard hook.

I know that ctfmon.exe or MSCTF.DLL are not malicious keyboard hooks, but if a malicious keyboard hook gets installed, the callback function to SetWindowsHookEx returns MSCTF.DLL as the calling process.

I need to know the malicious process name that installs the hook.
Does anyone have any ideas on how to get around this problem ??

I know this may have nothing to do with MAD components, I do appreciate you allowing me to discuss this problem here.

[madshi]

MSCTF.DLL can't be reported as a process, since it's a DLL only. Who does the reporting? If you hook SetWindowsHookEx, you can use GetCallingModule to ask which module called SetWindowsHookEx. Also you can use GetCurrentProcessId to find out which process called it.

[bedlam]

MSCTF.DLL can't be reported as a process, since it's a DLL only. Who does the reporting? If you hook SetWindowsHookEx, you can use GetCallingModule to ask which module called SetWindowsHookEx. Also you can use GetCurrentProcessId to find out which process called it.

Within the CallBack function for SetWindowsHookEx, I am using GetCallingModule() to find out which process/module is tring to run SetWindowsHookEx. Whenever I start a keyboard hooking program for testing, GetCallingModule() returns MSCTF.DLL (if ctfmon.exe is running) instead of my test keyboardhook.dll.

If ctfmon.exe is terminated, GetCallingModule() works as normal, returning keyboardhook.dll.

I will try GetCurrentProcessId, but it is the DLL name of the keyboardhook that I need to know.

Thanks for quick replies....

[madshi]

Don't know why that happens. Maybe msctf.dll hooks SetWindowsHookEx, too, or something like that. Maybe by using WH_DEBUG? I've no idea...

[bedlam]

Thanks for discuss madshi, i'll work on it tonight.

cheers.

[bedlam]

HI,

I've sorted the problem out now, I am using the IModule/IProcess interfaces to obtain the
OwnerProcess.ID of the Calling Module, this tells me which process launched the hook.

Is this code ok to use ??:

function SetWindowsHookExACallback(HookId: Integer; lpHookProc: TFNHookProc; hMod: Hinst; dwThreadId: DWORD): HHook; stdcall;
var
Modules: IModule;
Processes: IProcess;
callmod: cardinal;
callpid: cardinal;
begin
if (HookId = WH_KEYBOARD) or (HookId = WH_KEYBOARD_LL) then
begin
callmod := GetCallingModule();
Modules := Module(callmod);
callpid := Modules.OwnerProcess.ID;
Processes := Process(callpid);
WriteToLog('WH_KEYBOARD HOOK DETECTED: '+Modules.FileName+' '+inttostr(callmod));
WriteToLog('WH_KEYBOARD HOOK DETECTED: '+Processes.ExeFile+' '+inttostr(callpid));
end;
end;

Thanks for all advice.

[madshi]

While madKernel is powerful and nice to use, it's not really suited that much for a hook dll. Furthermore you don't even need it in this specific case.

WriteToLog('WH_KEYBOARD HOOK DETECTED: '+Modules.FileName+' '+inttostr(callmod));
WriteToLog('WH_KEYBOARD HOOK DETECTED: '+Processes.ExeFile+' '+inttostr(callpid));

Simply use "GetModuleFileName(callmod, ...)" to get the module name and "GetModuleFileName(0, ...)" to get the exe name. It's sooooo easy. You can delete all the other madKernel related code. You just need GetCallingModule + GetModuleFileName and that's it.

Btw, I already explained to you how to get the process which called the API. See my second comment in this thread.

[bedlam]

Yeah, I agree, i thought there would be an easier way than using all that extra overhead code. I didn't know calling GetModuleFileName(0, ...) would return the calling exe name.....I just realised now that the dll is part of the process being called.

I'm now getting the idea of all this inject stuff, just a little new to this kind of programming....more fun to come

[bedlam]

OK, I've stripped out all the MadKernel Code and I'm back to erros/AV's again whenever I try calling:
GetModuleFileName(callmod, ...) and GetModuleFileName(0, ...).

I use a logfile and whenever I call GetModuleFileName(...) the log is showing many repeated lines of calls to the Callback function.

I don't get any errors if I use the Process/Module functions from MadKernel.....What exeactly does your function GetCallingModule do to return the Module Handle of the calling DLL....I seem to have strange random errors when calling GetCallingModule from within my Hook callbacks.

Thanks.

[madshi]

Hard to say why you have problems without seeing your code...

[bedlam]

Ok....Ok...this is too much all this injecting and hooking.....

The stupid M$ CTFMON.EXE and MSCTF.DLL is itself an injected DLL which injects itself into all processes. The MSCTF.DLL has also installed all WH_???? Hooks, why I dont know. I'm certain that CTFMON.EXE is not a virus, it's part of M$ Office.

MSCTF.DLL was causing an endless loop within my CallBack procedures when calling RenewHook. I've fixed the problem now by checking if the CallingModule is MSCTF.DLL and if so, I do not call RenewHook, I simply pass the call back to NextHook.

All working fine now .....sorry to lay blame on your components.

I hope this provides some valuable info for anyone else with this kinf of problem.