这种dll调用完就卸载的隐秘技术是如何得以实现的？
本帖最后由 冥界3大法王 于 2024-10-14 10:40 编辑https://bbs.kanxue.com/thread-283929-1.htm 参见我楼下的回贴和分析。
不得不佩服啊。
签名闪退+试用时间搞好了。就是注册信息呈现一半注册一半没注册的样子，不过无限使用了。
现在我反而更感兴趣的是
[*] “这种dll调用完就卸载的隐秘技术是如何得以实现的？”{:301_974:} 这字符串你搜索不到再正常也不过了。
[*]这种无限重启主程序挺有意思，和Microsoft Office简直是异曲同工啊。
freelibrary FreeLibraryAndExitThread 这种dll调用完就卸载的隐秘技术是如何得以实现的？
LoadLibrary 加载，完事后 FreeLibrary 释放。
参考 FreeLibrary 官方文档
系统为每个加载的模块维护每个进程引用计数。 由于加载时动态链接，在进程初始化时加载的模块的引用计数为 1。 每次调用 LoadLibrary 加载模块时，模块的引用计数都会递增。 引用计数也会通过对 LoadLibraryEx 的调用递增，除非模块是首次加载并且作为数据或图像文件加载的。
每次为模块调用 FreeLibrary 或 FreeLibraryAndExitThread 函数时，引用计数都会递减。 当模块的引用计数达到零或进程终止时，系统会从进程的地址空间中卸载模块。 在卸载库模块之前，系统允许模块通过调用模块的 DllMain 函数（如果有），并使用 DLL_PROCESS_DETACH 值从进程分离。 这样做使库模块有机会清理代表当前进程分配的资源。 在入口点函数返回之后，将从当前进程的地址空间移除库模板。 FreeLibrary，或者调用其他底层的函数。 自邀而来，不谢。人在52论坛刚下飞机。刚好有所涉及。
FreeLibrary是必须得但不是必须的。
它只是一哥标准方法而已，减少引用，归零卸载。如果多线程，有一个线程没有停止，则不会卸载。
解决：跟踪LoadLibrary调用。线程同步检测状态 再次调用。
自卸载：FreeLibraryAndExitThread，创建一个独立的线程调用FreeLibrary，并在DLL卸载后终止该线程调用 UnloadDLL 可以让DLL在不干扰进程主线程的情况下卸载自己。
问题：句柄泄露会造成卸载失败等问题。
解决：清理资源？？？？？？
我猜它使用 延迟技术 ，但是延迟还得回归到FreeLibrary。然后把所有上述能想到的都处理一遍？
盲猜：先到内存?（这TM不成手动了？）解析DOS头？搞PE结构？ 分配内存写入dll？处理表？修正指针？定位？
回头试试！
页:
[1]