当 App 有了系统权限，真的可以为所欲为？

字数统计: 6.1k阅读时长: 23 min

 2023/05/14

2023 年，公开研究披露了某款 Android App 中的漏洞利用代码和动态下发的 DEX。我想看看这些代码尝试调用哪些系统能力，于是有了这篇文章。当时准备仓促，有些代码没有仔细看；下面保留分析过程，并修正能从截图和 AOSP 源码确认的问题。原始文章和代码链接如下：

我不是安全方面的专家。关于漏洞背景，可以参考 Android 反序列化漏洞攻防史话。本文不复现漏洞链，也不把某个接口调用直接等同于已获得 root。

历史案例，技术复核：2026-10-14。 本文分析的是 2023 年公开材料，不代表该 App 当前版本或所有厂商设备的行为。来源仓库以 6.49 为 APK 示例；各 DEX 的完整下发记录、执行身份、设备系统版本和安全补丁级别并未在本文中建立。截图能说明代码的调用意图，不能单独证明在用户设备上调用成功、收集了哪些数据或已经上传。文中的厂商接口按历史记录保留，当前适用性未验证。

“系统权限”也不是一个统一开关：预装 App、特权 App、平台签名、system UID 与 root 是不同条件。AOSP 中 system UID 为 1000、root UID 为 0；具体操作仍要看 Binder/Provider 权限检查、AppOps、文件访问控制和 SELinux。反射或 @SystemApi 不会自动授予调用权限。参见 AOSP Process（Android 13）、特权权限白名单、SELinux 和非 SDK 接口限制。

序列化和反序列化是指将内存数据结构转换为字节流，通过网络传输或者保存到磁盘，然后再将字节流恢复为内存对象的过程。在 Web 安全领域，出现过很多反序列化漏洞，比如 PHP 反序列化、Java 反序列化等。由于在反序列化的过程中触发了非预期的程序逻辑，从而被攻击者用精心构造的字节流触发并利用漏洞从而最终实现任意代码执行等目的。

这篇文章主要看公开仓库中 DEX 的反编译截图。按可见的调用和目标，大致可以分为下面几类；其中有的操作普通 App 经用户授权也能完成，有的依赖系统或厂商权限，不能一概称为“提权后已经做了这些事”。

自启动、关联启动相关的修改，偷偷打开或者默认打开：与手机厂商斗智斗勇。
开启通知权限。
监听通知内容。
查询使用事件、配置文件或标识字段；具体内容取决于接口、权限和输入参数。
修改系统设置。
整一些系统权限的工具方便自己使用。

另外也可以看到，这个 App 对于各个手机厂商的研究还是比较深入的，针对华为、Oppo、Vivo、Xiaomi 等终端厂商都有专门的处理，这个也是值得手机厂商去反向研究和防御的。

最后我还加上了这篇文章在微信公众号发出去之后的用户评论，以及知乎回答的评论区（问题已经被删了，但是我可以看到：如何评价拼多多疑似利用漏洞攻击用户手机，窃取竞争对手软件数据，防止自己被卸载？ - Gracker的回答 - 知乎 https://www.zhihu.com/question/587624599/answer/2927765317，2023 年写作时记录为 2471 个赞）可以说是脑洞大开（关于 App 如何作恶）。

0. Dex 文件信息

我当时从上述公开仓库里整理了 37 个 DEX 文件，不多，也不大，可以慢慢看。仓库作者描述了动态下发，并列出部分历史 CDN 地址；本文没有保存独立抓包记录，不能据此确认所有文件都在每次启动时下发或执行。Android 开源便于对照系统实现，但识别实际行为仍需要调用链和运行证据。

我当时使用 TTDeDroid 的 showjar 查看 DEX，下面保留原命令作为工具使用记录。本次复核没有执行这些样本。

showjar 95cd95ab4d694ad8bdf49f07e3599fb3.dex

TTDeDroid 默认使用 jadx 展示反编译结果。Executor 可以作为阅读入口，但还要追踪它调用的 helper 和系统服务。

反编译结果可能有重命名、缺失方法体或不准确的控制流。下面以截图中可见的逻辑为限；类名和成功回调的代码分支，都不是运行成功的证明。

1. 通知监听和通知权限相关

1.1 获取 Xiaomi 手机通知内容

文件： 95cd95ab4d694ad8bdf49f07e3599fb3.dex
功能：获取用户的 Active 通知
类名：com.google.android.sd.biz_dynamic_dex.xm_ntf_info.XMGetNtfInfoExecutor

1. 反射拿到 ServiceManager

截图通过反射访问 ServiceManager.getService，拿到 Binder 后再转换为服务接口代理。仅拿到代理，不代表服务端会接受后续调用。

2. 通过 NotificationManagerService 获取通知的详细内容

这里传入的是服务名 notification，转换得到 INotificationManager 接口代理，并非把 NotificationManagerService 类传进去。截图随后尝试调用隐藏接口 getActiveNotifications，按标题集合过滤结果，读取以下字段：

通知的 Title
发生通知的 App 的包名
通知发送时间
key
channelID ：the id of the channel this notification posts to.

可能有人不知道这玩意是啥，下面这个图里面就是一个典型的通知

其代码如下

需要区分同名接口。公开的 NotificationManager.getActiveNotifications() 从 API 23 起可读取调用 App 自己发布的活动通知（API 29 起也包括它以通知代理身份发布的通知）。截图中的跨 App 服务端接口则不同：Android 13 的实现检查 ACCESS_NOTIFICATIONS、AppOps 和用户范围。截图没有证明样本通过了这些检查。

另一条途径是经用户开启通知访问权限的 NotificationListenerService，它与辅助功能服务不是同一个机制。不能因为插件使用了某种系统 API，就断言它合规或不会泄露数据。防撤回功能也不意味着能恢复所有消息。Android 15（API 35）进一步限制不受信任的通知监听器读取检测到的一次性验证码原文，见 Android 15 行为变更；不能把旧截图外推到所有新系统。

1.2. 打开 Xiaomi 手机上的通知权限（Push）

文件：0fc0e98ac2e54bc29401efaddfc8ad7f.dex
功能：尝试为指定包启用通知，并查询包级开关状态。
类名：com.google.android.sd.biz_dynamic_dex.xm_permission.XMPermissionExecutor

这么看来这个应该还是蛮实用的，你个调皮的用户，我发通知都是为了你好，你怎么忍心把我关掉呢？让我帮你偷偷打开吧

代码尝试调用 setNotificationsEnabledForPackage。下面的服务端截图第一步就是检查调用身份；Android 13 源码使用 enforceSystemOrSystemUI，不能把反射调用本身解释为能强制开启。
frameworks/base/services/core/java/com/android/server/notification/NotificationManagerService.java

随后查询的是 areNotificationsEnabledForPackage，不是再次调用 setter。这个结果表示包级通知状态，不等于每个通知渠道都可见，也不证明已收到网络推送。
frameworks/base/services/core/java/com/android/server/notification/NotificationManagerService.java

另一个分支的名称是 lbe（原文误写为 leb），截图显示它访问 MIUI 权限管理 Provider。它的检查规则仍取决于具体厂商版本。连这个分支都单独处理了，细！

1.3. 打开 Vivo 机器上的通知权限（Push）

文件：2eb20dc580aaa5186ee4a4ceb2374669.dex
功能：尝试启用 Vivo 设备上指定 App 的通知。关闭通知展示，不等于 App 的网络推送连接必然断开。
类名：com.google.android.sd.biz_dynamic_dex.vivo_open_push.VivoOpenPushExecutor

截图与前一节一样尝试调用通知开关接口。Android 13（API 33）新增的 POST_NOTIFICATIONS 运行时权限管理非豁免通知的发布；它不是网络消息接收权限。旧厂商实现不能直接当作 Android 13 及以后版本的通用结论。

1.4 打开 Oppo 手机的通知权限

文件：67c9e686004f45158e94002e8e781192.dex
类名：com.google.android.sd.biz_dynamic_dex.oppo_notification_ut.OppoNotificationUTExecutor

方法体没有完整反编译出来。可见片段在查找 ColorOS/OPlus 通知管理 Provider；“打开通知权限”仍是对目标的推测，不能确认完整操作或结果。

1.5 Notification 监听

文件：ab8ed4c3482c42a1b8baef558ee79deb.dex
类名：com.google.android.sd.biz_dynamic_dex.ud_notification_listener.UdNotificationListenerExecutor

截图有 listen 和 collect 两个分支，后者发送收集广播并等待回传。实际监听哪些通知、统计哪些字段，还要看未展示的 helper。

下面是框架的 onNotificationPosted 回调声明，用来说明通知监听机制，不是样本完整的监听实现。

这个咱也不是很懂，是时候跟做了多年 SystemUI 和 Launcher 的老婆求助了....@史工

1.6 App Notification 监听

文件：4f260398-e9d1-4390-bbb9-eeb49c07bf3c.dex
类名：com.google.android.sd.biz_dynamic_dex.notification_listener.NotificationListenerExecutor

上面那个是 UdNotificationListenerExecutor ，这个是 NotificationListenerExecutor，UD 是啥？

这里尝试反射调用通知监听授权接口。@SystemApi 说明接口面向特定系统客户端，不是“调用即可获权”。Android 13 服务端的 checkNotificationListenerAccess() 会检查 system/phone 身份或 MANAGE_NOTIFICATION_LISTENERS；后续还处理用户选择和组件资格。样本截图中的双参数调用与下方框架截图的三参数接口也不相同，必须按目标版本匹配。

1.7 打开华为手机的通知监听权限

文件：a3937709-b9cc-48fd-8918-163c9cb7c2df.dex
类名：com.google.android.sd.biz_dynamic_dex.hw_notification_listener.HWNotificationListenerExecutor

截图尝试通过华为 Settings Provider 修改通知访问设置；没有该 Provider 对应版本的实现和运行结果，不能确认它接受了请求。

1.8 打开华为手机通知权限

文件：257682c986ab449ab9e7c8ae7682fa61.dex
类名：com.google.android.sd.biz_dynamic_dex.hw_permission.HwPermissionExecutor

截图尝试写入华为/荣耀通知管理 Provider 的配置。返回成功分支不等于已在设备上写入成功，仍需核对 Provider 权限和实际状态。

2. Backup 状态

2.1. 鸿蒙 OS 上 App Backup 状态相关，保活用？

文件：6932a923-9f13-4624-bfea-1249ddfd5505.dex
功能：Backup 相关

这段我当时看了半天。截图的顺序是先把 IBackupSessionCallback 传入 PackageManagerEx.startBackupSession，获得会话标识后再尝试执行备份任务，并不是先收到回调再启动会话。它涉及华为扩展接口，不能由此推断所有 HarmonyOS 版本都支持。

我当时查到的接口说明如下。“用于保活”没有足够证据；备份会话、文件操作和进程存活效果需要分别验证。

2.2. Vivo 手机 Backup 状态相关

文件：8c34f5dc-f04c-40ba-98d4-7aa7c364b65c.dex
功能：Backup 相关

这张图只显示 Vivo 备份/恢复观察器的 Binder 接口定义，没有备份调用或运行结果。

3. 文件相关

3.1 华为样本中的文件与 SharedPreferences 操作

文件： da03be2689cc463f901806b5b417c9f5.dex
类名：com.google.android.sd.biz_dynamic_dex.hw_get_input.HwGetInputExecutor

截图尝试复制输入参数指定的文件，随后按 SharedPreferences 读取键值并构造返回数据。目标路径来自输入，本文没有实际参数和读取结果，不能据此认定拿到了输入法内容或所有用户数据。跨 App 私有文件仍受应用沙箱等访问控制约束。拿这些内容做什么，数据分析？我看到这里也有这个疑问，但截图里没有答案。

获取 SharedPreferences

下面只是在 App 自己的文件目录下创建 .client_slog_cache/temp 临时目录。原文把它称作“获取 slog”不准确，截图没有读取系统日志的逻辑。

4. 用户数据

4.1 获取用户使用手机的数据

文件： 35604479f8854b5d90bc800e912034fc.dex
功能：查询一段时间内的使用事件，筛选并整理包名、类名、时间戳和事件类型。
类名：com.google.android.sd.biz_dynamic_dex.usage_event_all.UsageEventAllExecutor

服务名应为 usagestats，不是 usagestates。截图调用 UsageStatsManager.queryEvents，但这不是完整的安装列表或用户全部操作记录。普通 App 也可经用户在设置中授予使用情况访问权限后查询；Android 13 服务端会检查 AppOps，并在默认模式下检查 PACKAGE_USAGE_STATS。单看客户端 checkPermission 不能替代服务端判定。

系统定义了 Activity、前台服务、屏幕状态等事件，但样本还会筛选数据，不能因为枚举里有某一类型就认定全部采集。查询受时间范围和系统保留期限限制；API 文档说明事件只保留若干天，Android 11 起用户尚未解锁时可返回 null。

下面是 Android 13 android-13.0.0_r1 中 UserUsageStatsService.eventToString 的事件名称映射；原文错标为 UsageEvents.java。这是服务端调试辅助方法，包含内部事件，不是普通 App 可直接复制调用的 SDK 示例。

// AOSP android-13.0.0_r1
// frameworks/base/services/usage/java/com/android/server/usage/UserUsageStatsService.java
    private static String eventToString(int eventType) {
        switch (eventType) {
            case Event.NONE:
                return "NONE";
            case Event.ACTIVITY_PAUSED:
                return "ACTIVITY_PAUSED";
            case Event.ACTIVITY_RESUMED:
                return "ACTIVITY_RESUMED";
            case Event.FOREGROUND_SERVICE_START:
                return "FOREGROUND_SERVICE_START";
            case Event.FOREGROUND_SERVICE_STOP:
                return "FOREGROUND_SERVICE_STOP";
            case Event.ACTIVITY_STOPPED:
                return "ACTIVITY_STOPPED";
            case Event.END_OF_DAY:
                return "END_OF_DAY";
            case Event.ROLLOVER_FOREGROUND_SERVICE:
                return "ROLLOVER_FOREGROUND_SERVICE";
            case Event.CONTINUE_PREVIOUS_DAY:
                return "CONTINUE_PREVIOUS_DAY";
            case Event.CONTINUING_FOREGROUND_SERVICE:
                return "CONTINUING_FOREGROUND_SERVICE";
            case Event.CONFIGURATION_CHANGE:
                return "CONFIGURATION_CHANGE";
            case Event.SYSTEM_INTERACTION:
                return "SYSTEM_INTERACTION";
            case Event.USER_INTERACTION:
                return "USER_INTERACTION";
            case Event.SHORTCUT_INVOCATION:
                return "SHORTCUT_INVOCATION";
            case Event.CHOOSER_ACTION:
                return "CHOOSER_ACTION";
            case Event.NOTIFICATION_SEEN:
                return "NOTIFICATION_SEEN";
            case Event.STANDBY_BUCKET_CHANGED:
                return "STANDBY_BUCKET_CHANGED";
            case Event.NOTIFICATION_INTERRUPTION:
                return "NOTIFICATION_INTERRUPTION";
            case Event.SLICE_PINNED:
                return "SLICE_PINNED";
            case Event.SLICE_PINNED_PRIV:
                return "SLICE_PINNED_PRIV";
            case Event.SCREEN_INTERACTIVE:
                return "SCREEN_INTERACTIVE";
            case Event.SCREEN_NON_INTERACTIVE:
                return "SCREEN_NON_INTERACTIVE";
            case Event.KEYGUARD_SHOWN:
                return "KEYGUARD_SHOWN";
            case Event.KEYGUARD_HIDDEN:
                return "KEYGUARD_HIDDEN";
            case Event.DEVICE_SHUTDOWN:
                return "DEVICE_SHUTDOWN";
            case Event.DEVICE_STARTUP:
                return "DEVICE_STARTUP";
            case Event.USER_UNLOCKED:
                return "USER_UNLOCKED";
            case Event.USER_STOPPED:
                return "USER_STOPPED";
            case Event.LOCUS_ID_SET:
                return "LOCUS_ID_SET";
            case Event.APP_COMPONENT_USED:
                return "APP_COMPONENT_USED";
            default:
                return "UNKNOWN_TYPE_" + eventType;
        }
    }

4.2 获取用户使用数据

文件：b50477f70bd14479a50e6fa34e18b2a0.dex
类名：com.google.android.sd.biz_dynamic_dex.usage_event.UsageEventExecutor

这个 Executor 接受时间范围、包名、事件类型和数量限制，并整理查询结果。Activity resumed/paused 等事件不等于进程启动/退出；由事件估算使用时长还要处理缺失事件、时间窗口边界和多窗口情况。

4.3 获取用户使用数据

文件：1a68d982e02fc22b464693a06f528fac.dex
类名：com.google.android.sd.biz_dynamic_dex.app_usage_observer.AppUsageObserver

这里注册的是 App 使用时长观察器，不是在“注册权限”。截图尝试调用隐藏的 registerAppUsageObserver；Android 13 实现通过 hasObserverPermission() 检查 system、设备/资料所有者或 OBSERVE_APP_USAGE 等条件。客户端的 API 23 判断也不能证明隐藏方法在所有 API 23 设备上存在。

当时有读者提出一种猜测：把 Widget 做得像 App 图标，可能让用户混淆“移除桌面项目”和“卸载应用”。两者是不同操作；下面的截图没有展示完整的欺骗卸载流程，我也没有遇到过这个案例，因此不能把猜测写成已经发生的行为。

文件：f9b6b139-4516-4ac2-896d-8bc3eb1f2d03.dex
类名：com.google.android.sd.biz_dynamic_dex.vivo_widget.VivoAddWidgetExecutor

截图构造并尝试启动 Vivo Launcher 的添加 Widget Activity。组件是否可访问、是否需要用户确认，以及最终是否添加成功，图中没有结果。

5.2 获取 icon 相关的信息

文件：da60112a4b2848adba2ac11f412cccc7.dex
类名：com.google.android.sd.biz_dynamic_dex.get_icon_info.GetIconInfoExecutor

可见片段查询 Launcher Provider 中的记录来判断文件夹相关状态。截图右侧还有裁切，不能仅凭这一张图确认完整的行列位置查询，更不能确定收集它的最终用途。获取这些桌面信息到底想干嘛？我当时也没弄明白。

文件：75dcc8ea-d0f9-4222-b8dd-2a83444f9cd6.dex
类名：com.google.android.sd.biz_dynamic_dex.oppoaddwidget.OppoAddWidgetExecutor

这里只能看到按条件选择代理执行器或 Widget 执行器，具体添加流程没有展示。

5.4 Xiaomi 手机更新图标？

文件：5d372522-b6a4-4c1b-a0b4-8114d342e6c0.dex
类名：com.google.android.sd.biz_dynamic_dex.xm_akasha.XmAkashaExecutor

截图按请求类型分派到快捷方式权限、查询/更新图标和重启 Launcher 等 helper。这里能确认分支名称，不能确认各 helper 已成功执行。小米的同学可以来看看。

6. 自启动、关联启动、保活相关

6.1 打开 Oppo 手机自启动

文件：e723d560-c2ee-461e-b2a1-96f85b614f2b.dex
类名：com.google.android.sd.biz_dynamic_dex.oppo_boot_perm.OppoBootPermExecutor

截图涉及 ColorOS/OPlus 安全中心 Provider 和自启动相关参数。是否写入、是否生效，要看对应系统版本的 Provider 校验；这也不等于解除所有后台运行限制。

6.2 打开 Vivo 关联启动权限

文件：8b56d820-cac2-4ca0-8a3a-1083c5cca7ae.dex
类名：com.google.android.sd.biz_dynamic_dex.vivo_association_start.VivoAssociationStartExecutor

截图指向 Vivo 的关联启动白名单配置；这是厂商实现，不能当作 Android 通用权限接口。

下面构造 XML 节点。它说明拟修改的数据结构，不能单凭节点构造就确认文件已写入或系统已重新加载。

6.3 华为电量管理相关配置

文件：7c6e6702-e461-4315-8631-eee246aeba95.dex
类名：com.google.android.sd.biz_dynamic_dex.hw_hide_power_window.HidePowerWindowExecutor

截图显示了电量管理数据库、表名以及缓存文件清理。原题“关闭耗电精灵”下得过满：这些片段不足以证明整个电量管理功能被关闭，更不能推断温控策略失效。熟悉华为这部分实现的同学也可以来看看。

6.4 Vivo AMS 配置恢复相关

文件：7877ec6850344e7aad5fdd57f6abf238.dex
类名：com.google.android.sd.biz_dynamic_dex.vivo_get_loc.VivoGetLocExecutor

截图涉及 Vivo AMS 配置文件的恢复逻辑，以及向厂商 daemon 发起调用。我当时猜它是不是用来保活；没有完整调用链和执行结果，不能确认这一用途，也不能只凭类名里的 get_loc 认定获取了位置。Vivo 的同学可以来认领一下。

7. 安装卸载相关

7.1 VivoRollbackUninstallExecutor 与 Launcher 配置

文件：d643e0f9a68342bc8403a69e7ee877a7.dex
类名：com.google.android.sd.biz_dynamic_dex.vivo_rollback_uninstall.VivoRollbackUninstallExecutor

截图实际展示的是下载、替换 Launcher 配置文件并检查摘要的逻辑，没有展示卸载后安装旧 APK。“回滚到预置版本”是原文未经证实的推测，不能将它解释为普通的系统应用卸载更新。

7.2 Vivo 手机 App 卸载

文件：be7a2b643d7e8543f49994ffeb0ee0b6.dex
类名：com.google.android.sd.biz_dynamic_dex.vivo_official_uninstall.OfficialUntiUninstallV3

同样可见的是 Launcher 配置替换逻辑。类名含有 Uninstall，不足以确认如何影响卸载流程。

7.3 Vivo 手机 App 卸载相关

文件：183bb87aa7d744a195741ce524577dd0.dex
类名：com.google.android.sd.biz_dynamic_dex.vivo_official_uninstall.VivoOfficialUninstallExecutor

这里只展示按当前包名选择不同 helper 的分支；完整的卸载相关行为未展示。

其他

SyncExecutor

文件：f4247da0-6274-44eb-859a-b4c35ec0dd71.dex
类名：com.google.android.sd.biz_dynamic_dex.sync.SyncExecutor

这个我当时没看懂。截图从输入读取 sid，调用 CmdHandler.setSid 和 Utils.updateSid，随后构造版本、状态、进程号等返回字段。updateSid 实现没有展示，不能将这个 sid 直接解释为用户身份或系统 UID。

UdParseNotifyMessageExecutor

文件：f35735a5cbf445c785237797138d246a.dex
类名：com.google.android.sd.biz_dynamic_dex.ud_parse_nmessage.UdParseNotifyMessageExecutor

截图解析传入 Intent 的 extras，并处理其中的 Parcelable。Intent 来自何处、是否代表远端通知，要看调用方；单凭类名不能确定。

6.3 TDLogcatExecutor

文件
8aeb045fad9343acbbd1a26998b6485a.dex
2aa151e2cfa04acb8fb96e523807ca6b.dex
类名
com.google.android.sd.biz_dynamic_dex.td.logcat.TDLogcatExecutor
com.google.android.sd.biz_dynamic_dex.td.logcat.TDLogcatExecutor

这段我当时也没太看懂，像是保活又不像。可见片段主要检查初始化状态和目标包是否仍安装，然后调用后续方法。日志采集、保活或其他用途需要后续实现才能判断。

6.4 QueryLBSInfoExecutor

文件：74168acd-14b4-4ff8-842e-f92b794d7abf.dex
类名：com.google.android.sd.biz_dynamic_dex.query_lbs_info.QueryLBSInfoExecutor

截图读取当前 Wi-Fi 的 SSID 和 BSSID，没有展示 GPS 经纬度。此类字段可能辅助位置推断，但并非直接的位置结果；WifiInfo 文档也说明，位置敏感字段受权限限制，可能返回未知值或脱敏值。

6.5 WriteSettingsExecutor

文件：6afc90e406bf46e4a29956aabcdfe004.dex
类名：com.google.android.sd.biz_dynamic_dex.write_settings.WriteSettingsExecutor

截图按参数选择 Settings 命名空间及 putInt、putString 等方法，具体键值未展示。Settings.System 的写入能力与 Settings.Secure 的受限修改不是同一权限；不能把“找得到 put 方法”当作可写任意设置。参见 System.canWrite（API 23）和 Settings.Secure。