传统的API挂钩导致崩溃 [英] Traditional API hooking causes crash

问题描述

我正在使用此示例中建议的API挂钩：



API /函数挂钩/拦截使用JMP指令即拼接



我挂钩的一个功能是BitBlt（）功能。在钩子函数中，我使用CreateThread（）创建一个新线程。

I am using API Hooking as suggested in this example:

API/Function Hooking/Interception Using JMP Instruction aka splicing

One of the functions which I am hooking is the BitBlt() function. In the hooked function, I am creating a new thread using CreateThread().

BOOL WINAPI MY_BitBlt(HDC hdcDest, int xDest, int yDest, int width, int height, HDC hdcSrc, int xSrc, int ySrc, DWORD dwRop)
{
    VirtualProtect((LPVOID)pOrig_BitBlt_Address, SIZE_6, my_BitBlt_Protect, NULL);
    memcpy(pOrig_BitBlt_Address, old_BitBlt_Bytes, SIZE_6);
    BOOL rv = Real_BitBlt(hdcDest, xDest, yDest, width, height, hdcSrc, xSrc, ySrc, dwRop); // Calls the actual function
    memcpy(pOrig_BitBlt_Address, JMP_BitBlt, SIZE_6);
    VirtualProtect((LPVOID)pOrig_BitBlt_Address, SIZE_6, old_BitBlt_Protect, NULL);
    CreateThread(NULL, 0, _SampleProc, NULL , 0, 0);
    ...
    return rv;
}

有时，即使在卸载DLL之后，BitBlt（）内部创建的线程仍然在内存中并导致访问冲突异常，从而导致应用程序崩溃。崩溃是不一致的。



然后我尝试用空线程proc创建一个线程，这也导致崩溃。



如果我没有创建新线程，则不会发生崩溃。



在钩子函数内创建线程是不安全的？



注意：我使用SetWindowsHookEx（）进行DLL注入。



我的总体想法是获取从目标应用程序到我的应用程序的一些信息。为此，我首先将我的dll加载到我的应用程序中，然后使用SetWindowsHookEx（）来应用特定于线程的钩子。当我的dll被加载到目标进程中时，我执行如上所述的API挂钩。



我尝试了什么：



我可以通过使用共享内存而不是创建线程来解决问题。此外，我听到有人说我应该在这种情况下使用Trampoline，但我无法得到一个例子，即使我有一个基本的想法，它的工作原理。有人可以帮我解决这个问题吗？

Sometimes, even after unloading the DLL, the thread created inside of BitBlt() remains in memory and causes an Access Violation exception, which in turn leads to application crash. The crash is inconsistent.

Then I tried creating a thread with an empty thread proc, this too led to a crash.

If I don't create a new thread, the crash does not occur.

Is it not safe to create threads inside of a hooked function?

Note : I use SetWindowsHookEx() for DLL injection.

My overall idea is to get some information from a target application to my application. To achieve this, I first load my dll into my application and then use SetWindowsHookEx() to apply a thread specific hook. When my dll gets loaded into target process I perform API hooking as mentioned above.

What I have tried:

I have a way around by using shared memory instead of creating threads . Also I have heard people saying I should be using Trampoline in this scenario but I could not get an example on this even though I have a basic idea of it works. Can someone help me with this problem?

推荐答案

维基百科上的代码质量很差...它甚至不使用 FlushInstructionCache函数 [ ^ ]以避免崩溃或暂停其他进程内线程。是的，该代码是为1核处理器和单线程应用程序设计的。否则代码将导致间歇性崩溃。



在具有多个内核的计算机上...... BitBlt周围的指令可能位于L1，L2或L3 cpu缓存中。 。



另外......为了避免竞争条件，大多数钩子库暂停除了自身之外的所有其他线程......然后写下蹦床说明。





祝福，

-David Delaune

Hi,

That code on wikipedia is poor quality... it doesn't even use the FlushInstructionCache function[^] to avoid a crash or suspend other in-process threads. Yep, that code is designed for a 1 core processor and a single-threaded application. Otherwise the code will cause intermittent crashes.

On a computer with multiple cores... the instructions surrounding BitBlt may be in the L1,L2 or L3 cpu cache...

Also... to avoid race conditions most hook libraries suspend all other threads except itself... then write the trampoline instructions.


Best Wishes,
-David Delaune

这篇关于传统的API挂钩导致崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！