Barrier problems

Jan 30, 2009 at 2:25 PM
I hooked both GetFileAttributes and CreateFile.  The simplified hook handler as followings:

CreateFile_Hook(...) {
...
GetFileAttributes(...) // Intended to call original API but called hooked API actually
...
CreateFile(...) // Call original API as expected
...
}

GetFileAttributes_Hook(...) {
...
CreateFile(...) // Intended to call original API but called hooked API actually
...
GetFileAttributes(...) // Call original API as expected
...
}

I want to call unhooked GetFileAttributes in CreateFile_Hook but it invoke GetFileAttributes_Hook.  Anyone have any idea how to achieve?
Coordinator
Jan 30, 2009 at 4:33 PM
This is something that is currently not supported with easyhook. And I also think that it will never be supported (there is simply no need for it and it would cause many side-effects).

But after all, it shouldn't cause any harm. The call stackk enforced by EasyHook with your example looks like this:

CreateFile_Hook ->  GetFileAttributes ->  GetFileAttributes_Hook  ->  CreateFile -> the unhooked API

and GetFileAttributes_Hook ->  CreateFile ->  CreateFile_Hook  ->  GetFileAttributes -> the unhooked API

I can't imagine a scenario where this would cause any handler code to break, unless there is something wrong with its design.

regards
chris
Coordinator
Jan 30, 2009 at 4:38 PM
Edited Jan 30, 2009 at 4:39 PM
If it is still a problem the only thing you can do is the following:

[ThreadStatic]
static boolean IsHookHandler;

CreateFile_Hook(...) {
        if(IsHookHandler)
                return CreateFile(...);

        IsHookHandler = true;

        try{
        ...
        GetFileAttributes(...) // Intended to call original API but called hooked API actually
        ...
        CreateFile(...) // Call original API as expected
        ...
        }finally{
                IsHookHandler = false;
        }
       
}

GetFileAttributes_Hook(...) {
        if(IsHookHandler)
                return GetFileAttributes(...);

        IsHookHandler = true;

        try{
        ...
CreateFile(...) // Intended to call original API but called hooked API actually
..
GetFileAttributes(...) // Call original API as expected
...
        }finally{
                IsHookHandler = false;
        }

}

Jan 31, 2009 at 3:12 AM
What I am doing is hooking the clipboard API to provide my special implements of clipboard.  I do have a scenario that the Hooked API won't call the original API as followings:

GetClipboardData_Hook(...) {
...
CountClipboardFormats(); // Intented to call original API
...
}

CountClipboardFormats_Hook(...) {
...
never call original CountClipboardFormats
...
}



I have a workaround is as followings but I am not sure if there is any harmful effects.

#define ESCAPEHOOK \
DWORD adwTIDs[1]; \
adwTIDs[0] = GetCurrentThreadId(); \
LhSetGlobalExclusiveACL(adwTIDs, 1);
#define RESUMEHOOK \
LhSetGlobalInclusiveACL(adwTIDs, 1);

GetClipboardData_Hook(...) {
...
ESCAPEHOOK
CountClipboardFormats(); // Intented to call original API
RESUMEHOOK
...
}

Coordinator
Jan 31, 2009 at 8:41 AM
No that's a bad idea... I mean it may work but...:

__declspec(thread) int IsHookHandler = false; // per-thread variable


CountClipboardFormats_Hook(...) {
        if(IsHookHandler)
               return;
...
never call original CountClipboardFormats
...
}


GetClipboardData_Hook(...) {
...
IsHookHandler = true;

        __try{
        CountClipboardFormats(); // Intented to call original API

               .....
        }__finally{
                IsHookHandler = false;
        }
}

regards
chris
Feb 4, 2009 at 1:25 AM
Thanks Chris,

We change our code according to your suggestions and it works.  Just want to know if it is possible to get the function pointer to access the original API function.  

NTSTATUS LhInstallHook_suggested(
            void* InEntryPoint,
            void* InHookProc,
            void* InCallback,
            TRACED_HOOK_HANDLE OutHandle
void* OutOriginalAPIAccessPoint // function pointer to call original API
);

or it is already availiable in the TRACED_HOOK_HANDLE structure?

Best regards,
Steve