检测MT管理器的一个小方法

type

Post

status

Published

date

Jun 24, 2026

slug

MT-Manager-Detector

summary

MT Manager 作为 Android 端常见的文件管理、APK 编辑与逆向辅助工具，在部分高风险场景中会与 Root、Hook、重打包、动态调试等行为组合出现。仅依赖包名、安装记录或文件路径进行识别，容易受到隐藏包名、卸载后残留清理、应用分身和包管理接口 Hook 的影响。本文提出一种利用 Android 抽象 Unix Socket 命名规律进行活跃检测的方法。该方法不依赖 Java 层包管理接口，不读取 MT Manager 私有目录，通过 native 层直接系统调用，对由分秒时间种子派生的抽象 socket 名称进行高频连接探测, 实现对短暂可连接窗口的捕获。

1. 引言

MT Manager 本身不是 Root 框架，但它具备 APK 编辑、资源修改、Dex 查看、签名与文件系统操作等能力，常被用于分析、篡改或验证移动应用包。因此，在安全风控、反篡改、反作弊和环境完整性检查中，识别 MT Manager 的活跃迹象具有工程价值。

本文采用的思路是’判断“是否存在 MT Manager 运行时暴露出的抽象 Unix socket 特征”’

2. 背景

2.1 Android 抽象 Unix Socket

Linux/Android 的 Unix domain socket 支持抽象命名空间。与普通文件系统路径不同，抽象 socket 的 sun_path[0] 为 \0，后续字节作为 socket 名称。它不会在文件系统中形成可见节点，因此无法通过常规路径扫描直接观察。

检测端可以通过 socket(AF_UNIX, SOCK_STREAM, 0) 创建本地 socket，再对目标抽象名称执行 connect()。如果连接成功，说明目标 socket 上存在可连接监听端；如果返回 EACCES 或 EPERM，也可能说明目标对象存在但因权限或 SELinux 策略被拒绝。

2.2 MT Manager 的命名规律

MT Manager 暴露的抽象 socket 命名模式：

其中 @ 表示抽象 Unix socket 的首字节 \0，实际传入 sockaddr_un.sun_path 时并不包含字符 @。后缀来自以分秒为粒度的时间种子，并截断到 24 bit。

3. 检测原理

3.1 名称候选生成

检测端首先读取当前 wall clock 时间，并换算为分秒：

随后回溯最近一段时间窗口，对每个 offset 生成：

完整扫描窗口为 60 分钟，即：

每个分秒后缀检查两个名称，因此一次完整扫描最多尝试 72000 个候选名称。

3.2 抽象 socket 连接探测

对每个候选名称，检测端构造 sockaddr_un：

随后直接执行 arm64 syscall：

不建议通过 libc 的 socket() / connect() 符号，选择内联 svc #0 发起系统调用，降低动态链接符号依赖，也减少 Java 层或常规 libc hook 对探测路径的影响。

3.3 命中条件

检测将以下结果视为命中：

connect() 返回 0：目标 socket 可连接；

connect() 返回 EACCES；

connect() 返回 EPERM。

后两者的意义是：连接被权限或策略拒绝，但目标抽象 socket 名称可能已经被解析到实际对象。该策略可以提高在不同 SELinux 或权限环境下的检出率，但也要求后续风控不要把单一命中解释为绝对恶意。