ATL Thunk机制深刻分析
若是你有SDK的编程经验，就必定应该知道在建立窗口时须要指定窗口类，窗口类中的一种重要的参数就是窗口过程。任何窗口接收到的消息，都是由该窗口过程来处理。html
在面向对象编程中，若是还须要开发人员来使用原始的窗口过程这种面向过程的开发方式，面向对象就显得不那么纯粹了。因此，在界面编程的框架中，框架每每会隐藏窗口过程，开发人员看到的都是一个个的类。编程
若是要处理某一个消息，则须要在窗口对应的类中加入响应的message map便可。windows
那么，框架是如何将窗口过程跟窗口对应的类关联起来呢？ ATL中用的是一个叫thunk的机制。因为咱们收回来的dump有大量的窗口过程出问题的case，最后发现跟thunk有必定的关系，因此我对ATL的thunk作了 一番研究。app
Thunk的基本原理是分配一段内存，而后将窗口过程设置为这段内存。这段内存的做用是将窗口过程的第一个参数（窗口句柄）替换成类的This指针，并jump到类的WinProc函数中。这样就完成了窗口过程到类的成员函数的一个转换。框架
这里面有几个点须要重点研究一下：ide
- 何时分配thunk这段内存，又在何时将窗口过程设置为thunk的这段内存。
- 内存是怎么分配的，是一段堆上的内存吗？
- 这段内存究竟是什么东西？
咱们先来看看第一个问题：函数
何时分配thunk这段内存，又在何时将窗口过程设置为thunk的这段内存。this
ATL在建立窗口时，使用的窗口类是经过一段宏来定义的：DECLARE_WND_CLASS(_T("My Window Class"))atom
这段宏的定义以下：spa
#define DECLARE_WND_CLASS(WndClassName) \
static ATL::CWndClassInfo& GetWndClassInfo() \
{ \
static ATL::CWndClassInfo wc = \
{ \
{ sizeof(WNDCLASSEX), CS_HREDRAW | CS_VREDRAW | CS_DBLCLKS, StartWindowProc, \
0, 0, NULL, NULL, NULL, (HBRUSH)(COLOR_WINDOW + 1), NULL, WndClassName, NULL }, \
NULL, NULL, IDC_ARROW, TRUE, 0, _T("") \
}; \
return wc; \
}
能够看到，这个宏其实是在定义一个静态函数，他的功能是返回一个ATL::CWndClassInfo对象，这个对象实际上就是ATL对窗口类的封装，其中窗口过程被指定为StartWindowProc。
当用户调用CWindowImpl：：Create来建立窗口时，会调用到CWindowImpl的父类CWindowImplBaseT的create函数：
这个函数以下：
template <class TBase, class TWinTraits>
HWND CWindowImplBaseT< TBase, TWinTraits >::Create(HWND hWndParent, _U_RECT rect, LPCTSTR szWindowName,
DWORD dwStyle, DWORD dwExStyle, _U_MENUorID MenuOrID, ATOM atom, LPVOID lpCreateParam)
{
。。。。
// Allocate the thunk structure here, where we can fail gracefully.
result = m_thunk.Init(NULL,NULL);
.......
HWND hWnd = ::CreateWindowEx(dwExStyle, MAKEINTATOM(atom), szWindowName,
dwStyle, rect.m_lpRect->left, rect.m_lpRect->top, rect.m_lpRect->right - rect.m_lpRect->left,
rect.m_lpRect->bottom - rect.m_lpRect->top, hWndParent, MenuOrID.m_hMenu,
_AtlBaseModule.GetModuleInstance(), lpCreateParam);
.............
return hWnd;
}
能够看到，咱们首先对thunk用NULL进行了初始化，正如注释所说的，这这里初始化是由于若是分配内存失败了，能够更好的进行错误处理。实际上thunk也彻底能够在后面处理窗口的第一个消息时进行初始化。
接着调用windows API CreateWindowEx来建立窗口，前面咱们知道，这个窗口的使用的窗口类的窗口过程是StartWindowProc，咱们接着看它的处理代码。
template <class TBase, class TWinTraits>
LRESULT CALLBACK CWindowImplBaseT< TBase, TWinTraits >::StartWindowProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
CWindowImplBaseT< TBase, TWinTraits >* pThis = (CWindowImplBaseT< TBase, TWinTraits >*)_AtlWinModule.ExtractCreateWndData();
pThis->m_hWnd = hWnd;
// Initialize the thunk. This is allocated in CWindowImplBaseT::Create,
// so failure is unexpected here.
pThis->m_thunk.Init(pThis->GetWindowProc(), pThis);
WNDPROC pProc = pThis->m_thunk.GetWNDPROC();
WNDPROC pOldProc = (WNDPROC)::SetWindowLongPtr(hWnd, GWLP_WNDPROC, (LONG_PTR)pProc);
return pProc(hWnd, uMsg, wParam, lParam);
}
这是类的一个静态函数，因此能够做为窗口过程直接使用。咱们能够看到，他的参数正是窗口过程的四个参数。
函数首先拿到This指针，将传递进来的窗口句柄赋给this的成员变量m_hWnd。而后m_thunk.Init来从新初始化thunk，这个时候传递进去的再也不是两个NULL，而是类的一个成员函数和This指针。
这个初始化具体作什么咱们后面再具体分析。
初始化完成以后，咱们就能够拿到这个thunk的地址(m_thunk.GetWNDPROC就是获取thunk的地址)，而后调用SetWindowLongPtr将窗口过程设置成thunk的地址。下次窗口有消息来时就直接跑到thunk里面去了
最后直接调用thunk的地址，是为了将StartWindowProc正在处理的这个消息也传递给thunk处理，以避免丢失了窗口的第一个消息。
这段内存究竟是什么东西？
咱们下面来重点分析m_thunk.Init是完成什么功能。
CDynamicStdCallThunk.Init的代码以下：
BOOL Init(DWORD_PTR proc, void *pThis)
{
if (pThunk == NULL)
{
pThunk = new _stdcallthunk;
if (pThunk == NULL)
{
return FALSE;
}
}
return pThunk->Init(proc, pThis);
}
代码很简单，分配一段结构（_stdcallthunk），而后继续调用这个结构的init函数。（提早说一下的是，这里override了new这个operator，真正作的事情不是简单的从堆上分配内存，后面会详细介绍）
结构
struct _stdcallthunk
{
DWORD m_mov; // mov dword ptr [esp+0x4], pThis (esp+0x4 is hWnd)
DWORD m_this; //
BYTE m_jmp; // jmp WndProc
DWORD m_relproc; // relative jmp
BOOL Init(DWORD_PTR proc, void* pThis)
{
m_mov = 0x042444C7; //C7 44 24 0C
m_this = PtrToUlong(pThis);
m_jmp = 0xe9;
m_relproc = DWORD((INT_PTR)proc - ((INT_PTR)this+sizeof(_stdcallthunk)));
// write block from data cache and
// flush from instruction cache
FlushInstructionCache(GetCurrentProcess(), this, sizeof(_stdcallthunk));
return TRUE;
}
。。。。
｝
Thunk有四个成员，第一个成员是m_mov，被赋值为0x042444C7，第二个成员是m_this，被赋值为窗口对应类的地址。
这两个DWORD实际上组成了一条汇编语句：
mov dword ptr [esp+0x4], pThis
经过前面咱们知道，窗口过程已经被设置成这段内存的起始地址，也就是说窗口过程的第一行代码就是这行代码。
Esp是指向栈顶的指针，esp+0x4则是窗口过程的第一个参数hWnd，这段代码的意思就是说将this指针覆盖掉窗口过程的第一个参数hWnd。
咱们知道，类成员函数的第一个参数都是this指针，有了this指针，类成员函数就能够调用了。
下面的事情就是准备jump到成员函数中：m_jmp赋值为0xe9，一个相对跳转指令，m_relproc被赋值为相对成员函数相对thunk的地址，这两个成员变量也组成了一条汇编语句：
jmp WndProc
回到前面看看传递进来的成员函数的原型：
pThis->m_thunk.Init(pThis->GetWindowProc(), pThis);
GetWindowProc实际上就是返回成员函数WindowProc，原型以下：
template <class TBase, class TWinTraits>
LRESULT CALLBACK CWindowImplBaseT< TBase, TWinTraits >::WindowProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)；
能够看到，成员函数只有三个参数，窗口过程的第一个参数被修改为了this指针，因此达到了巧妙将窗口过程修改为类的成员函数的目的。
Thunk的基本原理到这里已经结束了，还剩下一个问题就是前面提到的对new的override，这就牵涉到关于ATL thunk的最后一个问题：
内存是怎么分配的，是一段堆上的内存吗？
为何要对new进行override？由于windows xp sp2以后，为了对付层出不穷的缓冲区溢出攻击，windows推出了一个新的feature叫Data execution prevention。若是这个feature被启用，那么堆上和栈上的数据是不能够执行的，若是thunk是位于new出来的代码，那么一执行就会crash。
为了解决这个问题，ATL override了new和delete运算符。
Override后的new最终会调用到函数__AllocStdCallThunk_cmn：
PVOID __AllocStdCallThunk_cmn ( VOID )
{
PATL_THUNK_ENTRY lastThunkEntry;
PATL_THUNK_ENTRY thunkEntry;
PVOID thunkPage;
if (__AtlThunkPool == NULL) {
if (__InitializeThunkPool() == FALSE) {
}
}
if (ATLTHUNK_USE_HEAP()) {
// On a non-NX capable platform, use the standard heap.
thunkEntry = (PATL_THUNK_ENTRY)HeapAlloc(GetProcessHeap(), 0, sizeof(ATL::_stdcallthunk));
return thunkEntry;
}
thunkPage = (PATL_THUNK_ENTRY)VirtualAlloc(NULL, PAGE_SIZE, MEM_COMMIT,PAGE_EXECUTE_READWRITE);
// Create an array of thunk structures on the page and insert all but
// the last into the free thunk list.
// The last is kept out of the list and represents the thunk allocation.
thunkEntry = (PATL_THUNK_ENTRY)thunkPage;
lastThunkEntry = thunkEntry + ATL_THUNKS_PER_PAGE - 1;
do {
__AtlInterlockedPushEntrySList(__AtlThunkPool,&thunkEntry->SListEntry);
thunkEntry += 1;
} while (thunkEntry < lastThunkEntry);
return thunkEntry;
}
函数首先判断是否是第一次被调用，若是第一次被调用，则调用__InitializeThunkPool来进行初始化（后面会详细介绍他）。初始化主要是用来判断Data execution prevention功能是否启用了。
若是没有启用，则简单多了，直接调用HeapAlloc来分配内存。
若是启用了则复杂多了。ATL会调用VirtualAlloc来分配一段PAGE_EXECUTE_READWRITE属性的内存，这段内存是能够被执行的，为了节省内存，将这段内存分红不少块，每一块大小就是一个thunk的大小。
而后将这些块压入到一个list当中，须要的时候则从中取出，释放的时候又将块压入到list中。
因为即便只建立一个窗口也须要分配一个页面的大小，若是这个进程中有多个dll，每一个dll都建立一个ATL的窗口，那么就会占用到不少页面空间，浪费内存。为了节省内存的使用，windows在进程的一个重要结构PEB偏移0x34的地方加入了一个域：
0:007> dt ntdll!_PEB
+0x000 InheritedAddressSpace : UChar
+0x001 ReadImageFileExecOptions : UChar
。。。。。
+0x030 SystemReserved : [1] Uint4B
+0x034 AtlThunkSListPtr32 : Uint4B
+0x038 ApiSetMap : Ptr32 Void
。。。。。。
在前面的初始化函数__InitializeThunkPool中，会尝试从这个位置获取Thunk的list的head，若是发现是空的，才会调用VirtualAlloc来建立新的页面：
BOOL static DECLSPEC_NOINLINE __InitializeThunkPool ( VOID )
{
#define PEB_POINTER_OFFSET 0x34
PSLIST_HEADER *atlThunkPoolPtr;
PSLIST_HEADER atlThunkPool;
result = IsProcessorFeaturePresent( 12 /*PF_NX_ENABLED*/ );
if (result == FALSE) {
// NX execution is not happening on this machine.
// Indicate that the regular heap should be used by setting
// __AtlThunkPool to a special value.
__AtlThunkPool = ATLTHUNK_USE_HEAP_VALUE;
return TRUE;
}
atlThunkPoolPtr = (PSLIST_HEADER *)((PCHAR)(Atl_NtCurrentTeb()->ProcessEnvironmentBlock) + PEB_POINTER_OFFSET);
atlThunkPool = *atlThunkPoolPtr;
__AtlThunkPool = atlThunkPool;
return TRUE;
}
https://www.cnblogs.com/georgepei/archive/2012/03/30/2425472.html
- 1. Thunk深刻解析
- 2. 深刻分析Java IO机制
- 3. MySQL Innodb日志机制深刻分析
- 4. 深刻Ambari Metrics 机制分析
- 5. 深刻分析_linux_spinlock_实现机制
- 6. 深刻分析 Java ClassLoader 工做机制
- 7. Java threadpool机制深刻分析
- 8. 深刻分析ClassLoader工做机制
- 9. 几句话归纳atl thunk技术
- 10. 深刻剖析Tomcat类加载机制
- 更多相关文章...
- • TCP滑动窗口机制深度剖析 - TCP/IP教程
- • ARP协议的工作机制详解 - TCP/IP教程
- • 漫谈MySQL的锁机制
- • 算法总结-深度优先算法
-
每一个你不满意的现在，都有一个你没有努力的曾经。