换一换 
原帖地址： 侵删 内容（由Gemini翻译）： 正文： 嘿，你！你担心恶意模组吗？？读读这个！ 我总看到人们在这两种观点之间摇摆不定： “所有模组都是安全的” “所有模组都是恶意软件” 这两种说法都不准确。针对 Unity + DLL 注入式模组（包括鸭科夫），真正的威胁模型如下。这也解释了为什么平台的“筛查”基本上解决不了问题，以及如果我们严谨一点的话，“安全”到底意味着什么。 1) 核心事实：Unity DLL 模组以你的身份运行 大多数实质性的 Unity 模组都是通过注入/添加 .dll 程序集到游戏进程中工作的（例如通过 BepInEx / MelonLoader / ModLoaders，鸭科夫的模组就是这样工作的）。这意味着： 模组实际上是在游戏内部执行的代码。 它以启动该游戏的账户相同的权限级别运行（实际上通常是管理员权限）。 它可以做任何你能做的事：读写文件、启动进程、运行命令、触碰目录等等。 所以，是的：任何 DLL 模组都有能力进行恶意行为。这并不是说“Unity 特别不安全”，而仅仅是“在进程内运行未签名的第三方代码”所意味着的必然结果。 2) 为什么“预先筛查模组”大多是幻想 人们会问：“为什么开发者 / Steam / 模组网站不直接扫描它们呢？” A) 静态扫描无法可靠地捕捉恶意 DLL 恶意软件作者可以混淆代码或分阶段通过 Payload，导致像 Defender 这样的扫描软件无法确信地标记它们。DLL 之所以成为常见的传播格式，正是因为它们灵活且可以隐藏意图。 B) “只在沙盒里运行一下”无法规模化，也没多大证明力 要正确做到这一点，你需要： 扫描每个模组中的每一个文件（VirusTotal 有帮助，但它不能捕捉所有东西，而且会产生误报）。 在安装了实际游戏的沙盒中执行模组。 在足够多的条件下观察其行为，以捕捉延时触发或条件触发的情况。 并且要足够了解恶意软件的工作原理（静默运行、条件触发等），才能看出是否有奇怪的事情发生。 而且，每次模组更新时，你都得重新做一遍这些工作。 C) “更新”才是真正的绕过手段 即使你在首次上传时进行了筛查，恶意作者也可以： 上传一个可以通过检查的干净版本。 稍后推送一个恶意更新（创意工坊甚至可以自动静默更新）。 在任何人注意到之前，危害就已经造成了。 D) 账户被盗让“受信任的作者”变得脆弱 即使作者是合法的，攻击者也可以通过网络钓鱼或重用泄露的密码来劫持他们的 Steam/GitHub/托管账户，并发布恶意更新。（多人联机co-op模组当时就是这个问题）大多数模组制作者并不是 IT 安全专家，他们和普通人一样容易遭受凭证诈骗。 底线： 对于社区 DLL 模组，除非你进入一个拥有严格发布流程的签名构建/可复现构建的生态系统（几乎没有游戏模组社区能做到这一点），否则不存在现实的、永久的“模组安全认证”渠道。 底线： 对于社区 DLL 模组，除非你进入一个拥有严格发布流程的签名构建/可复现构建的生态系统（几乎没有游戏模组社区能做到这一点），否则不存在现实的、永久的“模组安全认证”渠道。 3) 为什么我们通常还是没事？ 大多数 Unity 模组生态系统依靠以下几点运作： 社会激励（获得认可 > 被人憎恨，人们不想被列入黑名单）。 社区审计压力（热门模组会有很多人盯着，有错误报告，有人反编译，有审查）。 攻击者的经济学（与网络钓鱼、浏览器恶意软件、广告网络等相比，模组社区通常不是最容易或最有利可图的目标）。 所以常态是：理论上破坏力很大，但实际上滥用情况很少。（这一次不算常态） 4) 为什么这次事件会特别引爆舆论（激励机制 + 生态系统形态） 这里的区别不在于 Unity 本身特别危险。而是某些生态系统使得滥用更有可能发生，或者更显眼： 小圈子模组制作： 独立的眼睛更少，规范更弱，更少有人会注意到问题。 社会激励： 紧密的圈子互相包庇，缺乏有意义的问责制。 语言/平台割裂： 如果大部分社区讨论都发生在 Steam 之外且处于不同的语言空间中，反噬和审核信号就无法清晰地传达。 被绑架的生态系统： 如果少数模组制作者控制了“必备”模组，且没有好的替代品，即使用户信任崩塌，他们也依然不得不依赖这些模组。 此外：一些坏人很快被抓到，不是因为恶意软件很明显，而是因为他们做了一些琐碎的、用户可见的蠢事（启动崩溃、弹窗、搞破坏）。真正恶意的行为通常被设计为有条件触发且悄无声息的。
