ShadowSSDT hook

[iOutSide]

Hi, is it possible to hook also some functions in ShadowSSDT? I have protector, that looking for window hwnds, strings to catch debuggers,etc.

[mrexodia]

I thought they were already hooked?

[iOutSide]

Hm, In SSDT hooks in titanhide i see only:

int Hooks::Initialize()
{
    ExInitializeFastMutex(&gDebugPortMutex);
    int hook_count = 0;
    hNtQueryInformationProcess = SSDT::Hook("NtQueryInformationProcess", (void*)HookNtQueryInformationProcess);
    if(hNtQueryInformationProcess)
        hook_count++;
    hNtQueryObject = SSDT::Hook("NtQueryObject", (void*)HookNtQueryObject);
    if(hNtQueryObject)
        hook_count++;
    hNtQuerySystemInformation = SSDT::Hook("NtQuerySystemInformation", (void*)HookNtQuerySystemInformation);
    if(hNtQuerySystemInformation)
        hook_count++;
    hNtSetInformationThread = SSDT::Hook("NtSetInformationThread", (void*)HookNtSetInformationThread);
    if(hNtSetInformationThread)
        hook_count++;
    hNtClose = SSDT::Hook("NtClose", (void*)HookNtClose);
    if(hNtClose)
        hook_count++;
    hNtSetContextThread = SSDT::Hook("NtSetContextThread", (void*)HookNtSetContextThread);
    if(hNtSetContextThread)
        hook_count++;
    hNtSystemDebugControl = SSDT::Hook("NtSystemDebugControl", (void*)HookNtSystemDebugControl);
    if(hNtSystemDebugControl)
        hook_count++;
    return hook_count;
}

[mrexodia]

Yeah so? As far as I know SSDT::Hook also hooks the function in the shadow ssdt...

[mrexodia]

Oh nevermind it doesn't. Feel free to add this functionality (and make sure to provide a proof of concept)

[iOutSide]

Correct me, if its mistake, but as i know - shadow SSDT - its GUI functions, places not in ntoskrn, but in the win32k.sys.
Also ShadowSSDT hooks require KeStackAttachProcess to gui process, without it you haven't access in kernel to ShadowSSDT Service Table memory

[iOutSide]

Ok, Thanks. I will do more investigations and tests, and if will be success in adding that - i will prepare changes in code for it

[mrexodia]

See https://github.com/conix-security/zer0m0n/blob/master/src/driver/x64/hook.c#L89 and https://github.com/mrexodia/TitanHide/blob/master/TitanHide/ssdt.cpp#L21 it should be easy to extend that function to the shadow ssdt (and no need for KeStackAttachProcess I think, the same hook method should work for the shadow ssdt)

[Mattiwatti]

KeStackAttachProcess is needed because a process does not have win32k.sys mapped into its address space by default. This is only true for processes that have been converted to a GUI process. The best target for this is csrss.exe since it is always running and will be the first process to have win32k mapped.

Beware that hooking the shadow SSDT this way is not possible with a boot start driver (start = 0 or start = 1), and if start = 2, you will have to hope that at least session 0 CSRSS is already running by the time your driver is loaded. In those cases the best option is to set a PsSetLoadImageNotifyRoutine and wait for win32k.sys to load (it's loaded by smss). You will not be in a GUI process context during the notification, but win32k.sys will be mapped into system space and you can access the entire image including the shadow SSDT from within the callback. _{You can even write to win32k this way, but don't tell the Patchguard people that they missed this}

Here's a DIY snippet. The first function does exactly what TitanHide's SSDTfind() does, except it also finds the shadow SSDT (only on x64). This will work from any process context if win32k.sys has been loaded.
The second function should be called after doing some bookkeeping like retrieving function names and allocating space for the entries. This is the only part where a KeStackAttachProcess is required since it touches the actual service table which is in session space.

[fansstan]

i failed to hook shadow ssdt. the memory changed back after detach eprocess. I guess something happen in the RtlSuperCopy, so the change only occur on a copy ssdt.

KeStackAttachProcess is needed because a process does not have win32k.sys mapped into its address space by default. This is only true for processes that have been converted to a GUI process. The best target for this is csrss.exe since it is always running and will be the first process to have win32k mapped.

Beware that hooking the shadow SSDT this way is not possible with a boot start driver (start = 0 or start = 1), and if start = 2, you will have to hope that at least session 0 CSRSS is already running by the time your driver is loaded. In those cases the best option is to set a PsSetLoadImageNotifyRoutine and wait for win32k.sys to load (it's loaded by smss). You will not be in a GUI process context during the notification, but win32k.sys will be mapped into system space and you can access the entire image including the shadow SSDT from within the callback. You can even write to win32k this way, but don't tell the Patchguard people that they missed this

Here's a DIY snippet. The first function does exactly what TitanHide's SSDTfind() does, except it also finds the shadow SSDT (only on x64). This will work from any process context if win32k.sys has been loaded. The second function should be called after doing some bookkeeping like retrieving function names and allocating space for the entries. This is the only part where a KeStackAttachProcess is required since it touches the actual service table which is in session space.