0. 先导言#

自3年前我在高二开发出平板看视频的功能后，我始终没有把破解大业向前推动一步，在高考毕业后，也是如愿收到官方所谓的原生安卓推送，在我拿到后始终感觉这个原生安卓并不原生，依旧是ifly的魔改版。

今天（已经大二了）正好借助Claude Code对这个系统进行一次改造，如果还有同辈手里有这台闲置设备又想让权限更上一层楼，或者为了隐私安全，可以一看。

1. 先把「所有权」拆成四层#

这是我一开始就想清楚的事，也是整篇文章的骨架。笼统地问「能不能刷成一个干净的系统」没有意义，因为不同层的答案完全不同：

后来证明这个划分是对的：前两层可以全部拿下，后两层受限于个人能力和胆量一步没动。如果你像在其他安卓设备上一样，尝试多次点击版本号的话，会弹出一个需要输入暗码的窗口，这个后面会涉及。

先给结论，免得你抱错期望：

• 展锐（Unisoc）教育机型的 bootloader 基本锁死，没有 TWRP、没有机型适配 ROM
• ro.build.type=user + release-keys 意味着 adb root 直接拒绝，没有任何提权空间
• 网上流传的「C6 刷机包」来源不明，踩到投毒固件的概率比原厂后门还高

所以这场改造的目标不是「换系统」，是「在现有系统上把被拿走的操作权限要回来」。

2. 第一关：设置里什么都没有#

现象很典型：

• 设置不是原生 Android 设置，是深度定制的
• 没有「开发者选项」
• 没有 USB 调试开关
• 拨号盘被删，所以 *#*#83781#*#* 这类工程码也敲不了
• 有一个关不掉的「系统更新」通知

但有个有利条件：APK 可以随便装。

这就够了。第一步不是找漏洞，是找入口。

3. 三种报错，三种含义（这张表很值钱）#

在 279 项里乱点的时候，会遇到三种结果。学会分辨它们，能省掉大量瞎试：

我第一次点 Settings$DevelopmentSettingsDashboardActivity，报的是 ActivityNotFoundException。 如果按这张表，结论应该是「类被删了」。但这个结论后来被推翻了 —— 原因在下面。

4. 意外之门：EngineerMode#

拨号被砍，工程码敲不了。那就换个思路：工程码最终只是跳转到一个 Activity，和拨号盘没有本质关系。

在 Activity Launcher 的包列表里翻，展锐平台通常有这个包：

1
com.sprd.engineermode

这是产线测试用的工具，厂商一般不敢删。展开它的 Activity，进去翻，找到了 USB Debug 开关。

1
Settings.Global.ADB_ENABLED

1
adb devices
2
# Q102112224614763   device  product:AIPad model:CB_C6_STU

5. ADB 到手后，先读指纹#

连上第一件事不是急着改东西，是摸清底细。构建属性决定了一切可能性的边界：

1
for p in ro.build.type ro.build.tags ro.debuggable ro.secure \
2
         ro.board.platform ro.build.version.release ro.build.fingerprint; do
3
  printf "%-28s %s\n" "$p" "$(adb shell getprop $p)"
4
done

输出：

1
ro.build.type                user
2
ro.build.tags                release-keys
3
ro.debuggable                0
4
ro.secure                    1
5
ro.board.platform            ud710
6
ro.build.version.release     9
7
ro.build.fingerprint         SPRD/ud710_2h10_native_noorca/ud710_2h10:9/...:user/release-keys

翻译一下：

• user + release-keys → 正式发布构建。adb root 会被直接拒绝（实测：adbd cannot run as root in production builds）
• ro.debuggable=0 → 没有调试后门
• ud710 → 展锐 UD710 平台

结论很干脆：root 无望，不过 ADB 已经够用了。

顺手确认一下有没有 MDM 锁：

1
adb shell dumpsys device_policy

结果是空的 —— 没有启用的 Device Admin，没有 Device Owner。这意味着 pm disable-user 可以自由使用。这是一个好消息。

6. 逆向第一步：把 Settings.apk 拉下来#

有了 ADB，就能读 /system（shell 用户对它可读，不需要 root）：

1
adb shell pm path com.android.settings
2
adb pull /system/priv-app/Settings/Settings.apk .
3
# 54 MB

现在目标很明确：在这个 APK 里找到那个「暗码」。

因为现象里有一条关键线索：连点设置内的版本号好几次后，ifly弹窗要求输入暗码。这说明：

1. 存在一个硬编码或可推导的校验值
2. 它就在这个 APK 里（或者它请求的某个服务里）

先赌在 APK 里。

7. 在 54MB 里找一个中文词#

1
unzip -o Settings.apk -d settings_x
2
grep -al "暗码" settings_x/*.dex settings_x/resources.arsc

1
settings_x/resources.arsc          ← 命中
2
（dex 里没有）

1
import glob, os
2
for f in glob.glob('settings_x/**/*', recursive=True):
3
    if not os.path.isfile(f): continue
4
    data = open(f, 'rb').read()
5
    b = '暗码'.encode('utf-8')
6
    i = data.find(b)
7
    if i != -1:
8
        print(f, data[max(0,i-160):i+240].decode('utf-8', 'replace'))

1
启用开发者选项

8. 可疑的wind_ 前缀#

strings.xml 里找到资源名：

1
<string name="wind_delelopment_password_hint">请输入暗码</string>
2
<string name="wind_delelopment_title">开启开发者模式</string>

wind_ 是讯飞的定制前缀（顺带一提，delelopment 是他们的拼写错误，这种瑕疵反而好认）。

于是问题变成：谁用了这个字符串？

这时候装反编译器：

1
brew install jadx
2
jadx -d settings_java Settings.apk

然后搜：

1
grep -rn "wind_delelopment" settings_java/sources/

直接指到一个文件：

1
com/android/settings/WindDeviceInfo.java:119

9. 柳暗花明：WindDeviceInfo.java#

打开一看，密码就明明白白写在第 111 行，不能更扎眼了：

1
if (developDilaog.getPassword() != null
2
    && developDilaog.getPassword().equals("IFlyCBaistudy5121")) {
3
    toDevelopmentMode();
4
}

暗码 = IFlyCBaistudy5121。

而且同一个方法里还藏着完整的触发条件：

1
if (CLICK_COUNT >= 6 && CLICK_COUNT > 0) {
2
    // 从第 6 次开始显示倒数
3
    Toast.makeText(..., plurals.show_dev_countdown, 12 - CLICK_COUNT, ...);
4
}
5
if (CLICK_COUNT >= 12) {
6
    // 第 12 次才弹暗码框
7
    developDilaog.showDialog(...);
8
}

所以这里不是原生 Android 的连点 7 次，而是连点 12 次。

再看 toDevelopmentMode()：

1
DevelopmentSettingsEnabler.setDevelopmentSettingsEnabled(mContext, true);
2
ComponentName componentName = new ComponentName(
3
    "com.android.settings",
4
    "com.android.settings.Settings$DevelopmentSettingsDashboardActivity");
5
setTileEnabled(componentName, true);   // ← 关键
6
mContext.startActivity(intent);

10. 解开 enabled="false" 的谜#

回到第三节那个矛盾：Activity Launcher 说 ActivityNotFoundException，但代码里明明在跳转它。

答案在 AndroidManifest.xml 里：

1
<activity
2
    android:name="Settings$DevelopmentSettingsDashboardActivity"
3
    android:enabled="false"          ← 就是这里
4
    ...>

组件被声明成禁用状态。

在 Android 里，启动一个 enabled=false 的组件，抛出的正是 ActivityNotFoundException —— 和「类不存在」的报错一模一样。这就是为什么那张分诊表也会骗人：这个报错有两种成因，但大不相同。

厂商的设计是：先用 DevelopmentSettingsEnabler 打开全局开关，再由 Settings 自己的 uid 调 setComponentEnabledSetting 把组件启用。两步都对，才能进去。

1
adb shell pm enable 'com.android.settings/...Settings$DevelopmentSettingsDashboardActivity'

1
SecurityException: Shell cannot change component state for ... to 1

1
adb shell "am start -n 'com.android.settings/com.android.settings.Settings\$DevelopmentSettingsDashboardActivity'"

1
mResumedActivity: ActivityRecord{... com.android.settings/.Settings$DevelopmentSettingsDashboardActivity}

11. 顺手解剖 OTA 包#

开发者选项搞定后，还剩那个关不掉的更新通知。

先定位：

1
adb shell pm list packages -s | grep -iE "ota|update|fota"
2
# com.iflytek.study.ota
3
# com.sprd.systemupdate

第一个是讯飞的教育机 OTA，第二个是展锐原生的更新器。两个要区别对待。

把讯飞那个拉下来：

1
adb shell pm path com.iflytek.study.ota
2
adb pull /system/app/IFlyOTA/IFlyOTA.apk .

1
LC_ALL=C grep -aoh 'https\?://[A-Za-z0-9._~:/?#@!$&()*+,;=%-]\{6,200\}' classes*.dex \
2
  | LC_ALL=C sort -u

1
https://hsmp.changyan.com/     ← 自己家的
2
https://byod.xunfeixxj.com/byod/
3
https://k12-api.openspeech.cn/
4
https://aiapi.changyan.com/coep-rest/
5
http://coop.voicecloud.cn/activity/ms/uploadSnapshot   ← 这个名字一言难尽
6
https://android.bugly.qq.com/rqd/async       ← 腾讯 Bugly 崩溃上报
7
https://astat.bugly.qcloud.com/rqd/async
8
https://h.trace.qq.com/kv

1
adb shell pm disable-user --user 0 com.iflytek.study.ota

12. 哪些做成了，哪些没做#

关于在这台机器上装 GMS 补一句：Android 9 上把 GSF/GMS 当普通 APK 装是能装上的，但账号登录必然失败 —— GSF 需要 /system/priv-app 位置和签名权限。没有 root，这条路是死胡同。要 GMS 体验，换一台能解锁 bootloader 的机器（Pixel、部分小米/红米）比在这台上耗着划算得多。

除此之外，我还把默认浏览器换成了Via（原版CVE太多了），用小企鹅替换了原版输入法等等，剩下的都是应用问题了。

13. 方法论#

回头看，真正起作用的是这几个思路：

1. 先分层，再谈可行性。 「能不能刷干净」是伪问题，「哪一层能拿到、卡在哪」才是真问题。
2. 厂商删入口不删实现。 菜单项删了，Activity 还在；设置项藏了，底层 Settings.Global 还在。找另一个入口，比找漏洞容易得多。
3. 报错信息要分级。 NotFound / SecurityException 是两个完全不同的世界。而且要警惕同一个报错有多种成因 —— enabled=false 也能伪装成「类不存在」。
4. 资源文件和代码要分开搜。 中文文案在 resources.arsc，逻辑在 dex。搜错了地方会得出「这里什么都没有」的错误结论。
5. 壳可以伪装，常量不行。 一个应用可以声称自己是「系统更新」，但它的 dex 里躺着 Bugly 和 uploadSnapshot。URL 不会撒谎。
6. 变化要可逆。 每一步都问一句「怎么退回去」。禁用而不是删除，留着 com.sprd.systemupdate，都是这个原则。

这次能成，一半靠技术，一半靠厂商的帮衬。 工程模式没删、暗码硬编码在客户端、组件只是禁用没有移除，不过这个平板本身就是学校发的学生机。一毕业，客户残值也就没了。

附录：完整命令清单#

1
# ---------- 连接 ----------
2
adb devices -l
3

4
# ---------- 摸清底细 ----------
5
for p in ro.build.type ro.build.tags ro.debuggable ro.secure \
6
         ro.board.platform ro.build.version.release ro.build.fingerprint; do
7
  printf "%-28s %s\n" "$p" "$(adb shell getprop $p)"
8
done
9
adb shell dumpsys device_policy
10

11
# ---------- 拉包 ----------
12
adb shell pm path com.android.settings
13
adb pull /system/priv-app/Settings/Settings.apk .
14
adb shell pm path com.iflytek.study.ota
15
adb pull /system/app/IFlyOTA/IFlyOTA.apk .
16

17
# ---------- 静态分析 ----------
18
unzip -o Settings.apk -d settings_x
19
grep -al "暗码" settings_x/*.dex settings_x/resources.arsc
20
brew install jadx
21
jadx -d settings_java Settings.apk
22
grep -rn "wind_delelopment" settings_java/sources/
23

24
# ---------- 启动被禁用的组件 ----------
25
adb shell "am start -n 'com.android.settings/com.android.settings.Settings\$DevelopmentSettingsDashboardActivity'"
26

27
# ---------- 停掉 OTA ----------
28
adb shell pm disable-user --user 0 com.iflytek.study.ota
29
adb shell pm list packages -d          # 查看已禁用的包
30

31
# ---------- 榨 URL ----------
32
LC_ALL=C grep -aoh 'https\?://[A-Za-z0-9._~:/?#@!$&()*+,;=%-]\{6,200\}' classes*.dex \
33
  | LC_ALL=C sort -u

这篇结束的时候，开发者选项已经能正常打开了。距离第一次在设置里翻不到任何东西的高中毕业季，过去了一年多。