众所周知，Xposed 是一个系统级别的软件框架，它与 Cydia Substrate 不同，Xposed 仅可 hook app_process 中的 java 函数，不过对于大部分的 Android 应用来说已经足够了；

它所提供的 API 可以供模块开发者在不修改目标应用字节码的前提下修改目标应用的行为，甚至是将自定义的代码注入进目标应用中，由目标应用代为执行。

Xposed 模块开发起来也非常简单，简单来说，获取目标应用的源码或者反编译出伪代码，找到目标方法，将相关逻辑写入模块，编译，完成。

于是，一种新的安全风险也随之出现了

某「步数模块」对 [淘宝] 应用插入淘口令

某「后台管理模块」做了一堆根本不应该它去做的功能

某"[抖音] 模块"影响 [微信] 功能

......

更有甚者利用 [微信] 的公众号功能，为自己的帖子刷流量

而当你想要禁止掉这种滥用行为的时候，你会发现，也许它根本就没有申请正常情况下做这些事情需要的权限，更别谈禁止了

这是因为它将代码注入到了 [微信] 应用中，所有的工作都是由 [微信] 来完成的，如果你使用抓包软件来抓取流量包的话，你会发现所有的相关流量都是由 [微信] 发送和接收的

应该庆幸的是，目前所抓到类似行为的模块都是使用 java （或 kotlin 等 jvm 语言）层来编写的，反编译还算比较容易

可是如果模块使用 native （ C/C++）层编写（据我所知已经有一些模块使用 native 层来编写），或者使用了一堆非常恶心人的加固 /混淆呢？

要求所有模块必须开源一定是不可能的事情，第一这会大大打击模块开发者的积极性，第二即使开源也不能确保一定是安全的

（更何况某个自诩「安全」的 Xposed 框架商业化分支也还是闭源的，何谈模块开源？）

我相信 Xposed 的作者 rovo89 （等一下，Xposed 停更的最后一个版本号是 89，我好像发现了什么 zzz ）一定也注意到了这个问题，只是因为某些原因最终弃坑掉了整个 Xposed 项目

于是，我们提出了一个新的概念

我将它称为

[模块作用域] (Modules Activation Scope)

• 它能做什么？

简单来说，用户可以自主选择某个模块只对某些应用生效（或某个应用只激活某些模块，这个根据不同 Xposed 框架分支开发者的喜好自由安排）

这样虽说不可能完全解决 Xposed 模块滥用行为的安全问题，至少可以防止 Xposed 模块跨域对非目标应用进行 hook 操作

• 如何才能用上这一功能？

当前已经有多种 Xposed 框架分支的开发者响应了这一概念

EdXposed 此功能正在开发中

（已编辑）应用转生 已发布

还有其他分支未收集

用户需要做的就是等待当前使用的分支更新这一功能

同时，我修改了开源分支 XPatch 的代码以支持这一功能，高级用户可以尝试使用一下

演示视频： https://www.bilibili.com/video/av80958793

源代码（已修改）： https://github.com/MlgmXyysd/xposed_module_loader

• （ DEV ）模块开发者需要特殊适配这一功能吗？

不需要

为 Xposed 框架分支添加新功能一定应该是建立在兼容原版 API 的基础上的（当然某个 Xposed 分支妄图分裂 Xposed 生态从而创建自己由 Xposed API 魔改而来的 TxxCxx API 我是不敢恭维，也不想在这里过多提及）

模块开发者唯一需要做的就是告知用户你的模块 hook 了哪个应用的包名，供用户来参考

• （ DEV ）我该如何为我的框架分支添加这一功能？

为单独的应用存储模块列表（推荐使用目标应用包名作为标识符），并设立全局列表（无法读取当前应用的列表时可读取全局列表）

具体代码自行实现

• （ DEV ）为什么不像 Android 软件在 Manifest 中声明权限那样要求模块声明 hook 列表？

在上文中我提到了兼容性

除此之外，要求模块适配自己的 API 同样是一种不可能的行为

一味的要求开发者适配自己的 API 会导致对其他 Xposed 框架分支的兼容性下降，或者同时兼容多个分支的难度上升

同时，保留原版 Xposed API 也是对 Xposed 原开发者 rovo89 的一种尊重

换一种问法，框架完全可以做到的事情为什么非要模块开发者来做呢？

这一概念经过测试完全是可行的（已有经由 XPatch 修改的 demo 测试成功，见上文）

但是，概念也有它本身的一个漏洞，它仅封堵掉了模块对于跨域应用的滥用行为，并没有从根本上杜绝滥用行为的发生（如，针对正常的目标应用的滥用行为），用户在选择模块时仍需谨慎

我是 MlgmXyysd，希望更多 Xposed 框架分支可以响应这一概念，同时也希望更多的开发者可以开发出自己的 Xposed 框架开源分支

附件：

目前已知的几种 Xposed 实现方案的「作者是个人还是公司、是否开源、是否商业化」的总结

鉴于阻止运行的前车之鉴「 2.3.2 之后（不含 2.3.2 ）的阻止运行你敢用嘛？」（ From @LetITFlyW ）

如果你没为服务付钱，那可能你就是产品。免费商业化比收费商业化更可怕。建议各位有使用 Xposed 的需求的朋友在条件适宜的情况下拥抱开源或者虽闭源但非商业化的实现方案。另：在任何情况下均不建议关注「某个 Xposed 实现方案的作者」的「推送过多次广告文章」的微信公众号。