浅谈 Xposed 新概念「模块作用域」

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

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

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

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

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

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

这是因为它将代码注入到了对应的应用中，所有的工作都是由被注入的应用来完成的。如果你使用抓包软件来抓取数据包的话，你会发现所有的相关数据都是由那个应用发送和接收的。

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

可如果模块使用了 Native 层（C/C++）编写，或者使用了一堆非常恶心人的加固、混淆呢？

要求所有模块必须开源一定是不可能的事情：①会大大打击模块开发者的积极性；②即使开源也不能确保一定是安全的。

（更何况某个自诩“安全”的 Xposed 框架商业化后也是闭源的，何谈模块开源？）

于是，一个新的概念应运而生。

我将它称为：

模块作用域 Modules Activation Scope

• 它能做什么？

它是一个应当默认关闭的高级功能，旨在将模块功能限制在一个用户许可的安全范围内。

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

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

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

当前已经有多种 Xposed 框架分支的开发者响应了这一概念（如 EdXposed、应用转生等）

用户只需要等待当前使用的框架更新这一功能。

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

演示视频：BiliBili/av80958793

源代码：GitHub@MlgmXyysd/xposed_module_loader

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

不需要

模块作用域是面向于用户层面的高级功能，模块开发者不需要也不应特殊适配或滥用这项功能。

为 Xposed 框架分支添加新功能一定应该是建立在兼容原版 API 的基础上的。

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

当然，EdXposed 提供了与原版兼容的 API，以供便捷声明模块的作用域，并展示给用户。您可以参考 开发文档 进行适配。

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

为单独的应用存储模块列表（使用目标应用包名作为标识符），并保留全局列表（用户未设置作用域列表时必须使用全局列表）

• 「DEV」为什么不像 Android 软件声明权限那样要求模块必须声明 hook 列表？

在上文中，我提到了兼容性考量；

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

一味的要求开发者适配自己的 API 会导致对其他 Xposed 框架分支的兼容性下降，同时兼容多个分支的难度上升。
同时，保留原版 Xposed API 也是对 Xposed 原开发者 rovo89 的一种尊重。

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

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

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