In this post i will not present any new tricks but i will instead discuss a new issue introduced in later versions of Windows regarding thread creation.
In a previous post, i quickly explained the ntdll "NtCreateThreadEx" function and its flag HideFromDebugger 0x4 that when passed to the function causes the new thread to be created hidden from debuggers.
In this post we will see another interesting flag that i prefer to call it SuppressDllMains 0x2. Let's see this in disassembly.
As we can see in the image above, the "PspAllocateThread" function inspects the "Flags" parameter. If the SuppressDllMains 0x2 flag is set, then the function sets the "SkipThreadAttach 0x8" bit flag in the new thread's TEB.
Similarly for the 64-bit version of the function. If the "SuppressDllMains" flag is passed, then the "SkipThreadAttach 0x8" bit flag is set in both the 32-bit TEB and 64-bit TEB of the new thread.
N.B. The bit flags are at offset 0xFCA in 32-bit TEB's and at offset 0x17EE in 64-bit TEB's.
Now let's see what the "SkipThreadAttach" bit flag does. To track this, we will have to shift to user-mode.
In OllyDbg, search for the "\xCA\x0F" (0xFCA) in ntdll.dll and see which functions make use of the "SkipThreadAttach 0x8" bit flag.
The ntdll "RtlIsCurrentThreadAttachExempt" function was among the results i found.
This function returns false if the "SkipThreadAttach" bit flag is not set.
If the "SkipThreadAttach" bit flag is set, another bit flag "RanProcessInit 0x20" is tested. If not set, the function returns true. Otherwise, the function returns false. In C code it looks something like below.
Searching for all references to the "RtlIsCurrentThreadAttachExempt" function, i found one interesting place in ntdll.dll where this function is called, that is LdrpInitializeThread.
The "LdrpInitializeThread" function is for calling the DllMain's of loaded dlls ( and TLS callbacks as well) each time a thread is initializing (with the "fdwReason" parameter set to DLL_THREAD_ATTACH) or is exiting (with the "fdwReason" parameter set to DLL_THREAD_DETACH).
Taking the "LdrpInitializeThread" function in disassembly, we can see that if the ntdll "RtlIsCurrentThreadAttachExempt" function returns true e.g. due to the "NtCreateThreadEx" function being called with the "Flags" parameter set to SuppressDllMains 0x2, the DllMains and TLS callbacks of loaded modules will not be called in the context of the new thread. See image below.
A good example for this is the "DbgUiIssueRemoteBreakin" function in ntdll.dll of Windows 7. This function is called by the "DebugActiveProcess" function to create the attaching thread in the context of the process to be debugged.
In Windows XP, the thread created by the "DbgUiIssueRemoteBreakin" function caused the DllMains and TLS callbacks of loaded modules to be called, presenting another layer of protection against attaching.
In Windows 7, since the "DbgUiIssueRemoteBreakin" function ends up calling the "NtCreateThreadEx" function with the "Flags" parameter set to 0x2 (SuppressDllMains), no DllMain's or TLS callbacks are called for the debugger thread.
You can download the demo of this post from here and source code from here.
You can follow me on Twitter @waleedassar
Any comments or ideas are very welcome.
In a previous post, i quickly explained the ntdll "NtCreateThreadEx" function and its flag HideFromDebugger 0x4 that when passed to the function causes the new thread to be created hidden from debuggers.
In this post we will see another interesting flag that i prefer to call it SuppressDllMains 0x2. Let's see this in disassembly.
As we can see in the image above, the "PspAllocateThread" function inspects the "Flags" parameter. If the SuppressDllMains 0x2 flag is set, then the function sets the "SkipThreadAttach 0x8" bit flag in the new thread's TEB.
Similarly for the 64-bit version of the function. If the "SuppressDllMains" flag is passed, then the "SkipThreadAttach 0x8" bit flag is set in both the 32-bit TEB and 64-bit TEB of the new thread.
N.B. The bit flags are at offset 0xFCA in 32-bit TEB's and at offset 0x17EE in 64-bit TEB's.
Now let's see what the "SkipThreadAttach" bit flag does. To track this, we will have to shift to user-mode.
In OllyDbg, search for the "\xCA\x0F" (0xFCA) in ntdll.dll and see which functions make use of the "SkipThreadAttach 0x8" bit flag.
The ntdll "RtlIsCurrentThreadAttachExempt" function was among the results i found.
If the "SkipThreadAttach" bit flag is set, another bit flag "RanProcessInit 0x20" is tested. If not set, the function returns true. Otherwise, the function returns false. In C code it looks something like below.
Searching for all references to the "RtlIsCurrentThreadAttachExempt" function, i found one interesting place in ntdll.dll where this function is called, that is LdrpInitializeThread.
The "LdrpInitializeThread" function is for calling the DllMain's of loaded dlls ( and TLS callbacks as well) each time a thread is initializing (with the "fdwReason" parameter set to DLL_THREAD_ATTACH) or is exiting (with the "fdwReason" parameter set to DLL_THREAD_DETACH).
Taking the "LdrpInitializeThread" function in disassembly, we can see that if the ntdll "RtlIsCurrentThreadAttachExempt" function returns true e.g. due to the "NtCreateThreadEx" function being called with the "Flags" parameter set to SuppressDllMains 0x2, the DllMains and TLS callbacks of loaded modules will not be called in the context of the new thread. See image below.
A good example for this is the "DbgUiIssueRemoteBreakin" function in ntdll.dll of Windows 7. This function is called by the "DebugActiveProcess" function to create the attaching thread in the context of the process to be debugged.
In Windows XP, the thread created by the "DbgUiIssueRemoteBreakin" function caused the DllMains and TLS callbacks of loaded modules to be called, presenting another layer of protection against attaching.
In Windows 7, since the "DbgUiIssueRemoteBreakin" function ends up calling the "NtCreateThreadEx" function with the "Flags" parameter set to 0x2 (SuppressDllMains), no DllMain's or TLS callbacks are called for the debugger thread.
You can download the demo of this post from here and source code from here.
You can follow me on Twitter @waleedassar
Any comments or ideas are very welcome.
I guess "DisableThreadLibraryCalls()" is related to the whole thing?
ReplyDeleteNo, not exactly. The method presented in this post prevents the system from invoking the DllMains and TLS callbacks of **ALL** loaded modules for the new thread. This occurs very early at the prologue of the ntdll "LdrpInitializeThread" function.
ReplyDeleteWhile the "DisableThreadLibraryCalls" or "LdrDisableThreadCalloutsForDll" function prevents the system from invoking the DllMain and TLS callbacks of the **specified** module in argument hModule for **all** threads even those to be created later on. This occurs later than the "SkipThreadAttach" bit test.
I knew this flag sounded familiar. :-)
ReplyDeletehttp://board.b-at-s.info/index.php?showtopic=7345&#entry11337
I remember coming across this when windows 7 first came out and I couldn't figure out why the break-in thread wouldn't go through ldr_data callbacks. There is another flag you might find interesting SupressDebugMsg. If this flag is set for the thread that maps a view of an image section (NtMapViewOfSection), it won't queue the event with the process's debug port. I.e. LoadLibrary() will not generate an event. Check
ReplyDeleteI have already blogged about "SuppressDebugMsg".
DeleteHere:
http://waleedassar.blogspot.com/2012/11/suppressdebugmsg-as-anti-debug-trick.html
Also see:
http://forum.tuts4you.com/topic/30513-hiding-threads-from-debuggers/
hehe didn't notice. found your blog off reddit. nice though.
ReplyDelete