- 综合排序
- 最热优先
- 最新优先
- 来自专栏方亮
DllMain中不当操作导致死锁问题的分析--进程对DllMain函数的调用规律的研究和分析
2 这个过程是为了验证创建新线程，对之前加载的Dll的DllMain调用情况。如果Dll1的DllMain输出了线程B TID记录，那么说明新线程创建会让之前加载Dll的DllMain。 该过程导致DllMain中输出的信息包括那些线程TID的记录，则说明存在影响（其他线程调用DllMain），否则说明不存在影响（其他线程不调用DllMain）。 7 8 9 验证对不同DLL的DllMain调用情况可能存在不同的线程，在退出时，是否会调用DllMain，以及它们对DllMain的调用规律。 DLLMain函数。 可以见得，在一个线程中对DLL产生了DllMain调用后，就不会因为Loadlibrary再发生DllMain的调用。
1.5K20发布于 2019-01-16 - 来自专栏方亮
DllMain中不当操作导致死锁问题的分析--导致DllMain中死锁的关键隐藏因子2
本文介绍使用Windbg去验证《DllMain中不当操作导致死锁问题的分析--导致DllMain中死锁的关键隐藏因子》中的结论，调试对象是文中刚开始那个例子。
91030发布于 2019-01-16 - 来自专栏方亮
DllMain中不当操作导致死锁问题的分析——DllMain中要谨慎写代码（完结篇）
之前几篇文章主要介绍和分析了为什么会在DllMain做出一些不当操作导致死锁的原因。本文将总结以前文章的结论，并介绍些DllMain中还有哪些操作会导致死锁等问题。 （转载请指明出于breaksoftware的csdn博客） DllMain的相关特性 首先列出《DllMain中不当操作导致死锁问题的分析--进程对DllMain函数的调用规律的研究和分析 但是注意不要想当然认为这个过程是A.dll的DllMain调用了B.dll的DllMain，B.dll的DllMain再调用了A.dll的DllMain这样的死循环。 F 与其他线程同步执行 由《DllMain中不当操作导致死锁问题的分析--加载卸载DLL与DllMain死锁的关系》、《DllMain中不当操作导致死锁问题的分析--导致DllMain中死锁的关键隐藏因子 如果或上了，就不调用DllMain。如果没或上，就调用DllMain。这说明DisableThreadLibraryCalls对创建线程时是否进入临界区无关。
1.8K20发布于 2019-01-16 - 来自专栏方亮
DllMain中不当操作导致死锁问题的分析--DisableThreadLibraryCalls对DllMain中死锁的影响
《windows核心编程》作者在讨论DllMain执行序列化的时候，曾说过一个他的故事：他试图通过调用DisableThreadLibraryCalls以使得新线程不在调用DllMain 思考作者的思路，他可能一开始认为：因为线程要调用DllMain而加锁，于是windows在发现DllMain不用调用时就不用加锁了。 本文将探讨DisableThreadLibraryCalls对DllMain死锁的影响。首先我们需要定位是什么函数调用了DllMain。 这步是为了让我们找出线程创建时是通过什么流程调用到DllMain函数的。 DLL的DllMain。
1.9K20发布于 2019-01-16 - 来自专栏方亮
DllMain中不当操作导致死锁问题的分析--导致DllMain中死锁的关键隐藏因子
有了前面两节的基础，我们现在切入正题：研究下DllMain为什么会因为不当操作导致死锁的问题。首先我们看一段比较经典的“DllMain中死锁”代码。 《windows核心编程》中有关于DllMain序列化执行的讲解，大致意思是：线程在调用DllMain之前，要先获取锁，等DllMain执行完再解开这个锁。这样不同线程加载DLL就可以实现序列化操作。 这样每个线程在执行初期，会先进入该临界区，从而实现在进程内DllMain的执行是序列化的。于是我们得出以下结论: 进程内所有线程共用了同一个临界区来序列化DllMain的执行。 结合《DllMain中不当操作导致死锁问题的分析--进程对DllMain函数的调用规律的研究和分析》中介绍的规律 二 线程创建后会调用已经加载了的DLL的DllMain，且调用原因是DLL_THREAD_ATTACH 时进入了临界区，而工作线程也要进入临界区去执行DllMain。
1.8K20发布于 2019-01-16 - 来自专栏方亮
DllMain中不当操作导致死锁问题的分析--加载卸载DLL与DllMain死锁的关系
前几篇文章一直没有在源码级证明：DllMain在收到DLL_PROCESS_ATTACH和DLL_PROCESS_DETACH时会进入临界区。 如果仔细看过《DllMain中不当操作导致死锁问题的分析--导致DllMain中死锁的关键隐藏因子2》，应该得知第14步就是进入临界区的点。 ? 以上两段从源码级证明了加载和卸载DLL导致的DllMain的调用（以及不调用）都是在临界区中完成的。
1.5K10发布于 2019-01-16 - 来自专栏方亮
DllMain中不当操作导致死锁问题的分析--死锁介绍
最近在网上看到一些关于在DllMain中不当操作导致死锁的问题，也没找到比较确切的解答，这极大吸引了我研究这个问题的兴趣。 我花了一点时间研究了下，正好也趁机研究了下进程对DllMain的调用规律。因为整个研究篇幅比较长，我觉得还是分开写比较能突出重点。本文先说说死锁。 就像我题目中描述的问题，很多人无法理解为什么就在DllMain中加了点代码就死锁了，甚至代码中不包括一点”等“性质的函数（其实是有，只是很隐蔽）。 请大家记住这两个例子，我们会在之后分析的DllMain中不当操作导致死锁的案例中再次看到它们的身影。
1.1K20发布于 2019-01-16 - 来自专栏方亮
DllMain中不当操作导致死锁问题的分析--线程退出时产生了死锁
然后wait到这个线程结束，我们在DllMain中继续做些操作。 是否想过，如果我们这儿创建一个线程去做事，然后去等待该线程结束。 这样就是同步操作了，如此操作不如将线程函数内容放在DllMain中直接执行，何必再去启动一个线程呢？ DllMain中SetEvent之后，工作线程从挂起状态复活，并执行完了return 0。那么另一个死锁因素是出现在线程退出的逻辑中。我们查看堆栈 ? RtlLeaveCriticalSection(&LoaderLock); } } 我们看第23行，发现该函数一开始便进入了临界区，也就是说不管该线程是否需要对某DLL调用DllMain 因为主线程正在调用DllMain，所以它先进入了临界区，并一直占用了它。而工作线程退出前也要进入这个临界区做点事，所以它一直进不去，并被系统挂起。
1.1K30发布于 2019-01-16 - 来自专栏10km的专栏
CC++:std::thread构造函数死锁问题:WIN32下不可以在DllMain中创建线程
根本的原因是Windows要求不可以在动态库的DllMain函数中创建线程，而我的代码结构恰好满足这个条件。 当在动态库执行时，这个a对象的初始化是在动态库入口点(DllMain entry point),也就是DllMain函数中完成的。 创建新线程时，在开始执行线程过程之前，会以DLL_THREAD_ATTACH方式调用动态库 的入口点(DllMain)1。为此，新线程必须获取加载程序锁。但是当前线程已经持有加载程序锁。 在stackoverflow上，找到了同款问题：2 文中给出的建议就是绝对不要在DllMain中创建线程. 这也是Microsoft官方文档3中给的要求: 参考资料 《DllMain entry point》 ↩︎ 《std::thread cause deadlock in DLLMain》 ↩︎
1.3K30编辑于 2022-04-13 - 来自专栏方亮
DllMain中不当操作导致死锁问题的分析——线程中调用GetModuleFileName、GetModuleHandle等导致死锁
之前的几篇文章已经讲解了在DllMain中创建并等待线程导致的死锁的原因。是否还记得，我们分析了半天汇编才知道在线程中的死锁位置。 可是该临界区被主线程占用着（在调用DllMain前进入临界区），主线程还要等待工作线程调用GetModuleFileName后激活事件才退出，于是就死锁了。 可是该临界区被主线程占用着（在调用DllMain前进入临界区），主线程还要等待工作线程调用GetModuleHandle后激活事件才退出，于是就死锁了。
1.3K30发布于 2019-01-16 - 来自专栏Ms08067安全实验室
利用DLL Proxying技术隐匿执行恶意代码
2.1 进程加载自动执行代码 这个相对来说比较简单，我们可以使用DllMain 这个函数，来让操作系统自己加载执行我们的代码，代码如下： BOOL WINAPI DllMain(HINSTANCE hinstDLL : DllMain 是Windows DLL中的一个特殊函数。 DLL_PROCESS_ATTACH: 当DLL 被加载到进程中时,操作系统会调用DllMain 函数,并传入此参数。 DLL_PROCESS_DETACH: 当DLL 即将从进程中卸载时,操作系统会调用DllMain 函数,并传入此参数。 这时，我们只需要编写自己的代码，放入DllMain 函数中执行，就可以隐匿实现执行自定义代码。
51100编辑于 2025-03-03 - 来自专栏锦鲤安全
白加黑免杀制作（详细）
文件 dllmain.cpp 文件包含程序的入口点，在 dllmain.cpp 中实现的在 pch.h 中定义函数，当然也可以在其他 cpp 文件中实现，如 pch.cpp 等。 入口函数（DllMain） DllMain是动态链接库的可选入口点。当系统启动或终止进程或线程时，它会使用进程的第一个线程为每个加载的 dll 调用入口点函数。 成功执行上线： （2）DllMain 上线 在导出函数上线一般需要所有安装 dll 同时存在，所以并不常用，常见的是直接在 DllMain 中上线。 DllMain 上线与在导出函数中上线有很大不同，在导出函数中上线直接使用普通的 shellcode 加载器就行了，但 DllMain 中上线则不同。 这里使用一段网上找的可以在 DllMain 中上线的加载器： // dllmain.cpp : 定义 DLL 应用程序的入口点。
12.7K92编辑于 2023-11-20 - 来自专栏红蓝对抗
白加黑保姆教程通杀主流杀软
DllMain 入口函数 这是动态链接库的可选入口点。系统启动或终止进程或线程的时候，它会使用进程的第一个线程为每个加载的DLL来调用入口点函数。 /* * hModule：DLL模块句柄 * ul_reason_for_call：调用函数的原因 * lpReserved：保留参数 */ BOOL APIENTRY DllMain(HMODULE DllMain函数名修饰-APIENTRY #define CALLBACK __stdcall // WIN32编程中的回调函数类型 #define WINAPI __stdcal #define ： dllmain里面不能创建进程这个问题是一个坑。 也就是说创建线程申请内存加载shellcode需要在导出函数里面操作，不能再dllmain里面直接操作，需要找到第一个执行的函数就能行，但是麻烦，我们可以可以新定义一个函数来申请内存，加载到内存中，在dllmain
1.6K10编辑于 2024-05-22 - 来自专栏FreeBuf
使用WFH搜索Windows可执行程序中的常见漏洞或功能
Frida against charmap.exe -------------------------------------------------- [+] Potential DllMain Sideloading: LoadLibraryW,LPCWSTR: MSFTEDIT.DLL [+] Potential DllMain Sideloading: LoadLibraryExW Frida against mspaint.exe -------------------------------------------------- [+] Potential DllMain Sideloading: LoadLibraryW,LPCWSTR: MSFTEDIT.DLL [+] Potential DllMain Sideloading: LoadLibraryExW Sideloading: LoadLibraryW,LPCWSTR: MSFTEDIT.DLL [+] Potential DllMain Sideloading: LoadLibraryExW
1.4K40发布于 2021-08-24 - 来自专栏安全的矛与盾
滥用具备RWX-S权限且有签名的dll进行无感知的shellcode注入
同时 DllMain 在被进程加载的那一刻就会执行，能够保证我们的shellcode在第一时间被执行。 patch DllMain为恶意代码 此时就有人说了，patch DllMain很简单啊，加载这个dll之后，获取 imagebase，然后解析PE头找到entrypoint，将 msfvenom 生成的 我们来看 DllMain的函数声明： BOOL WINAPI DllMain( HINSTANCE hinstDLL, // handle to DLL module DWORD fdwReason 这种情况下的DLL加载是在系统新开的一个线程中完成的，如果 DllMain 回调函数不返回，系统就会kill掉这个线程，以至于我们自己的恶意代码无法持续的执行，那解决办法就是要在 DllMain 中新开一个线程 仔细想一下，当 DllMain回调函数被执行的时候，难道真的任何地址信息都没有提供吗？其实不然。
1.3K20编辑于 2023-02-27 - 来自专栏一个程序员的修炼之路
Windows中Loader Lock引起的死锁问题
背景介绍 当主程序在启动的时候，隐式或者显示的加载动态链接库的时候，调用动态链接库的DllMain，或者当创建线程的时候，线程启动过程中隐式的调用动态链接库的DllMain。 然而为了多个线程顺序的调用DllMain，在微软内部在调用DllMain的时候使用了一个锁，叫做Loader Lock，这个锁作用于整个进程。 既然有个隐藏的Loader Lock锁，那么在编写DllMain的时候就需要格外小心了，举一个Winodws核心编程书中的20.2.5节的一个死锁例子： BOOL WINAPI DllMain(HINSTANCE Windbg分析问题 在背景介绍中，明白了Loader Lock中会产生一些隐藏的Bug，那就让谨慎编写DllMain吧。 那么通过这个指导我们，尽量在DllMain中不要实现太多逻辑，可以使用一个导出函数，在加载动态链接库之后，手动的调用导出的初始化函数。
1.6K10发布于 2021-08-06 C/C++ Inline Hook 钩子编写技巧
Transfer(){ __asm{ mov edi, edi push ebp mov ebp, esp mov ebx, jump jmp ebx } } bool APIENTRY DllMain LPCSTR lpString){ char * lpText = "LyShark 破解版"; return Transfer(hwnd, lpText); } bool APIENTRY DllMain MyMessageBoxW(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType) { return 1; } bool APIENTRY DllMain ); HookFunction64(L"user32.dll", "MessageBoxW", (PROC)MyMessageBoxW); return ret; } bool APIENTRY DllMain lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes,hTemplateFile); } bool APIENTRY DllMain
3.6K20编辑于 2022-12-28- 来自专栏学习之旅
【安全】记录钓鱼邮件中木马病毒的分析溯源
**DLL入口点函数**：`dllmain_dispatch`和`dllmain_raw`是dll文件的入口点函数，用于处理dll的加载、卸载等事件。 2. 代码结构解析 - **入口点函数**： - `dllmain_dispatch`：根据不同的事件类型调用相应的处理函数，如`dllmain_crt_process_attach`和`dllmain_crt_process_detach - `dllmain_raw`：处理dll的加载事件，返回1表示成功。 - `___scrt_dllmain_exception_filter`：过滤dllmain中的异常。 - `dllmain_crt_process_detach`：处理进程的清理，包括释放资源、清理异常处理等。
77810编辑于 2025-04-09 - 来自专栏Ms08067安全实验室
DLL 劫持提权：静默无痕拿下 Windows 最高权限
编写测试DLL 测试DLL劫持漏洞需要编写一个用于测试DLL劫持的测试DLL程序，为了保证一定的通用性，该程序使用DllMain作为触发点，程序代码如下。 #include "pch.h" BOOL APIENTRY DllMain(HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved){ MessageBoxA(0,"Thread detach",0,0); break; } return TRUE; } 将以上代码编译为DLL，当程序存在DLL劫持漏洞，调用DllMain 通过本次实验，介绍了如何手工挖掘一个入口点为DllMain的DLL劫持漏洞。实际上，除DllMain以外，DLL还有着很多其他的入口函数，通过更加深入的挖掘，可以找到更多的DLL劫持漏洞。
12810编辑于 2026-04-17 - 来自专栏码云1024
c++DLL编程详解
在前面的例子中，DLL并没有提供DllMain函数，应用工程也能成功引用DLL，这是因为Windows在找不到DllMain的时候，系统会从其它运行库中引入一个不做任何操作的缺省DllMain函数版本， 并不意味着DLL可以放弃DllMain函数。 这意味着不能直接在应用工程中引用DllMain函数，DllMain是自动被调用的。 看一个DllMain函数的例子： BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) 来仔细解读一下DllMain的函数头BOOL APIENTRY DllMain( HANDLE hModule, WORD ul_reason_for_call, LPVOID lpReserved )
2.9K60发布于 2018-05-10
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号