1. 首页
  2. 未分类
  3. 正文

BlueStacks Air 5.21.780.7504 Root + Proxyman HTTPS 抓包完整记录

  • 内容
  • 评论
  • 相关

BlueStacks Air 5.21.780.7504 Root 与 Proxyman 抓包记录

这次目标很明确：在 macOS 上把 BlueStacks Air 5.21.780.7504 做 root，然后安装 Proxyman 系统证书，最后把全局代理指到本机抓包环境。

参考项目是：

这个仓库 README 里公开测试到的最高版本是 5.21.745.7536，并没有直接写 5.21.780.7504。不过实测下来，5.21.780.7504 这一版仍然可以用它的方案成功 root，真正的问题不在 root 注入本身，而是在后续 Kitsune App 的收尾流程。

最终结论

BlueStacks Air 5.21.780.7504 可以 root 成功。

最终验证命令：

adb -s 127.0.0.1:5555 shell su -c id

返回：

uid=0(root) gid=0(root) groups=0(root)

说明 root 已经生效。

另外，Proxyman 证书也已经作为系统证书挂进 BlueStacks，代理也已设置为：

  • IP：192.168.0.113
  • 端口：9090

所以后续如果某个 App 还是抓不到 HTTPS，请优先怀疑：

  1. App 做了 certificate pinning
  2. App 没走系统代理
  3. App 使用了 QUIC 或自定义网络栈

这个项目的 root 原理

hanreev/root-bluestacks-air 的方案不是在 Android 系统起来之后再去“提权”，而是直接修改 BlueStacks Air 的启动 initrd，把 Magisk 提前塞进 Android 的早期启动链。

核心逻辑是：

  1. 解包 /Applications/BlueStacks.app/Contents/img/initrd_hvf.img
  2. 从 magisk.apk 里抽出 magisk64、magiskinit、magiskpolicy、stub.apk
  3. 把这些文件放进 ramdisk 的 boot/magisk/
  4. 把 magisk.rc 注入到启动流程
  5. 修改 boot/stage2.sh
  6. 重新打包 initrd_hvf.img

原本 boot/stage2.sh 最后是直接：

exec /init

脚本会把它改成“先安装 magisk.rc，再继续 exec /init”。这样 Magisk 就不是一个普通 App，而是进入了 Android 最早期、由 init 以 root 身份启动的链路。

这也是为什么最后 su 能真正拿到 uid=0。

实际操作流程

1. 准备仓库和 Magisk APK

先拉仓库：

git clone https://github.com/hanreev/root-bluestacks-air.git
cd root-bluestacks-air

然后下载 Kitsune Magisk v27.2-kitsune-4，放到仓库目录并重命名为：

magisk.apk

注意，这个 magisk.apk 不是仓库自带文件，而是你自己额外下载的 Kitsune 安装包。仓库只是约定脚本从这个文件里提取 Magisk 的二进制。

2. 检查当前 BlueStacks 版本是否还能套用脚本

虽然 README 没写支持 5.21.780.7504，但先做了静态检查。

解包系统里的 initrd_hvf.img 后，确认 boot/stage2.sh 末尾结构仍然是：

exec /init

这说明仓库脚本的补丁点没有变，仍然能对上。

3. 离线生成 patched initrd

为了避免直接原地写系统文件，先走 README 里的安全路径：

bash root.sh -o files/initrd_hvf.img -b files/backup

这个命令会做两件事：

  • 备份原始 initrd_hvf.img
  • 生成一个打好补丁的新 files/initrd_hvf.img

4. 替换 BlueStacks Air 的 initrd

把 patched 文件覆盖回应用目录：

sudo cp files/initrd_hvf.img /Applications/BlueStacks.app/Contents/img/initrd_hvf.img

然后启动 BlueStacks Air。

5. 打开 ADB 调试

在 BlueStacks 设置里打开 ADB，确认地址是：

127.0.0.1:5555

连接验证：

adb connect 127.0.0.1:5555
adb devices -l

6. 安装 Magisk App

可以直接用 ADB 安装：

adb -s 127.0.0.1:5555 install -r magisk.apk

过程中遇到的坑

坑一：首次打开 Kitsune 提示下载完整版，但点完就退出

第一次打开时，Kitsune 会提示需要下载完整版 Magisk。

理论上它会自己从网络拉完整包，把 stub 替换掉。但这一步在当前版本里直接失败，表现是：

  1. 点“确定”
  2. 转一圈
  3. App 直接退出

抓日志之后，原因很清楚：它访问的下载地址已经失效，返回了 404。

日志里的关键信息是：

FileNotFoundException: https://huskydg.github.io/download/magisk/v27.2-kitsune-4.apk

所以这一步不要来回重试，正确做法是直接用 ADB 把完整 APK 覆盖安装进去：

adb -s 127.0.0.1:5555 install -r magisk.apk

覆盖之后，Magisk 首页可以正常显示：

  • 当前 v27.2-kitsune-4
  • 包名 io.github.huskydg.magisk

坑二：Magisk 主页右上角“安装”里的 Direct Install 会闪退

进入：

  • Magisk
  • 安装
  • 直接安装（推荐）

点击“开始”后，App 会直接闪退。

这一步也不是操作错误，而是 Kitsune 在 BlueStacks Air 这条 Direct Install 路径里自己崩了。

日志里的实际报错是：

kotlin.UninitializedPropertyAccessException:
lateinit property installDir has not been initialized

所以结论很明确：

  • Direct Install 这一步在当前环境里不可靠
  • 它闪退不代表 root 失败
  • 不需要继续反复点这条路径

坑三：ADB 的 shell 默认没有 root，要在超级用户里手动放行

Magisk 的 超级用户 页面里会出现一条：

  • [SharedUID] Shell
  • com.android.shell

默认是关闭的。

必须把它打开，允许 com.android.shell 获取 root，否则这类命令会卡住、超时或者被拒绝：

adb -s 127.0.0.1:5555 shell su -c id

打开之后再验证，就能正常拿到：

uid=0(root) gid=0(root) groups=0(root)

安装 Proxyman 系统证书

如果 root 的目的是给 BlueStacks 里的 App 抓 HTTPS 包，那么只装“用户证书”通常不够，很多 App 只信任系统证书。

这次安装的证书文件是：

/Users/voidcat/Downloads/Proxyman CA (28 Sep 2025, voidcatdebijibendiannao.local).pem

Android 系统证书的命名规则

Android 的系统证书目录不是把 .pem 文件随便复制进去就行，文件名必须是 OpenSSL 旧 hash。

计算命令：

openssl x509 -inform PEM -subject_hash_old -in "Proxyman CA.pem" | head -1

这次算出来的文件名是：

7cd77f98.0

为什么不直接复制到 /system/etc/security/cacerts

这台 BlueStacks Air 是 Android 13，/system 是只读挂载：

/dev/vda1 on /system type ext4 (ro,...)

所以直接 cp 到：

/system/etc/security/cacerts/

即使临时可写，也不适合当成持久方案。

更稳的做法是：用 Magisk 模块把证书挂载到系统证书目录。

证书模块的结构

最小目录结构如下：

proxyman-ca-module/
  module.prop
  system/etc/security/cacerts/7cd77f98.0

module.prop 示例：

id=proxyman-ca-cert
name=Proxyman CA Cert
version=1.0
versionCode=1
author=Codex
description=Install Proxyman CA into system cacerts for BlueStacks Air

然后把这个模块放到：

/data/adb/modules/proxyman-ca-cert

重启 BlueStacks Air 后，证书就会作为系统证书挂进：

/system/etc/security/cacerts/7cd77f98.0

证书安装后的验证

重启后可以验证：

adb -s 127.0.0.1:5555 shell su -c 'ls -la /system/etc/security/cacerts/7cd77f98.0'

这次实际验证结果是文件存在，并且内容就是 Proxyman CA。

所以这一步已经成功。后面如果某个 App 还是无法抓 HTTPS，就不要再怀疑“系统证书没装上”，而应该优先去查 pinning。

设置 BlueStacks 全局代理

这次 BlueStacks 里设置的代理是：

  • IP：192.168.0.113
  • 端口：9090

直接用 ADB 设置全局代理：

adb -s 127.0.0.1:5555 shell settings put global http_proxy 192.168.0.113:9090

回读验证：

adb -s 127.0.0.1:5555 shell settings get global http_proxy

返回：

192.168.0.113:9090

如果还想分别验证 host 和 port：

adb -s 127.0.0.1:5555 shell settings get global global_http_proxy_host
adb -s 127.0.0.1:5555 shell settings get global global_http_proxy_port

取消代理：

adb -s 127.0.0.1:5555 shell settings put global http_proxy :0

隐藏 Root：Zygisk 与 Zygisk Assistant

在 BlueStacks Air 上拿到 root 之后，下一步常见需求就是“隐藏 root”，让一些会检测 Magisk、su、root 环境的 App 不那么容易发现当前设备已经被修改。

这里先说结论：

  • 只 root，不代表能过 root 检测
  • 很多隐藏 root 模块依赖 Zygisk
  • 在当前环境里，最适合先试的轻量方案是 Zygisk Assistant

Zygisk 是什么

可以把 Zygisk 理解成 Magisk 在 zygote 进程里的注入能力。

很多隐藏 root 模块本质上都依赖它，因为它们要在 App 进程很早期介入，拦截或改写部分检测行为。没有 Zygisk，这类模块通常根本不会生效。

所以顺序一定是：

  1. 先打开 Zygisk
  2. 重启 BlueStacks
  3. 确认 Magisk 首页里显示：
Zygisk = 是

Zygisk Assistant 是做什么的

Zygisk Assistant 是一个专门用于隐藏 root 的 Zygisk 模块。

项目地址：

它的定位很清楚：

  • 不是用来拿 root
  • 不是用来过 Play Integrity
  • 它的主要作用就是降低普通 App 对 root 环境的直接检测成功率

对 BlueStacks 这种场景来说，它很适合当成第一层处理方案：先装上，再去测目标 App 是否还报 root。

这次安装的版本

这次使用的是：

  • Zygisk Assistant v2.1.4

下载的是 release 包：

Zygisk-Assistant-v2.1.4-1013f8a-release.zip

安装方式

最常规的方式是在 Magisk 的“模块”页里选择本地 zip 安装。

这次为了省掉手工点击，直接把模块内容放进了 Magisk 模块目录：

/data/adb/modules/zygisk-assistant

模块的 module.prop 核心信息如下：

id=zygisk-assistant
name=Zygisk Assistant
version=v2.1.4 (1013f8a-release)
versionCode=214

无论你是从 App 里装，还是像这次一样直接落进模块目录，最终都要重启 BlueStacks，模块才会真正加载。

装完之后要不要配置

一般来说，不需要额外手动配置。

Zygisk Assistant 不是那种装完还要进很多页面打勾的模块。它更接近“装上即可参与 root hiding”的类型。

实际使用顺序就是：

  1. 开 Zygisk
  2. 安装 Zygisk Assistant
  3. 重启 BlueStacks
  4. 直接测试目标 App

它不是万能隐藏

这一点要提前讲清楚。

Zygisk Assistant 的作用是提高通过率，不是保证所有 App 都无法检测 root。

如果目标 App 仍然能识别环境，后续还可能需要继续补：

  • Shamiko
  • Hide My Applist
  • 单独处理 certificate pinning
  • 单独处理代理检测
  • 单独处理 Frida / 包名 / 文件路径检测

所以更稳的策略不是一开始堆很多模块，而是：

  1. 先装 Zygisk Assistant
  2. 测目标 App
  3. 真不够，再继续加别的隐藏方案

适合写在文末的一句话

如果只是想先做最小化的 root 隐藏，推荐顺序是：

打开 Zygisk，安装 Zygisk Assistant，重启后直接测试目标 App；先验证是否够用，再决定是否继续叠加 Shamiko、Hide My Applist 等更重的方案。

抓包链路最终状态

如果目标是让 BlueStacks 里的 App 能被 Proxyman 正常解密 HTTPS，那么这条链路要同时满足：

  1. BlueStacks 已 root
  2. Magisk 正常工作
  3. com.android.shell 已在超级用户里放行
  4. Proxyman 根证书已作为系统证书挂进 cacerts
  5. 全局代理已指向抓包机

这次的状态已经全部满足：

  • root 可用
  • 系统 CA 已装
  • 代理已设为 192.168.0.113:9090

所以现在如果某个 App 还是抓不到包，优先排查的是 App 自己，而不是 BlueStacks 的 root 或证书配置。

可复用的最短流程

如果以后再来一次，最短可以按下面这版记：

  1. 用 root.sh 生成 patched initrd_hvf.img
  2. 覆盖 /Applications/BlueStacks.app/Contents/img/initrd_hvf.img
  3. 启动 BlueStacks Air
  4. 打开 ADB 调试
  5. 用 ADB 直接安装完整 magisk.apk
  6. 不要纠结 Direct Install 闪退
  7. 进入 超级用户，把 com.android.shell 打开
  8. 用 adb shell su -c id 验证 root
  9. 把抓包证书做成 Magisk 模块挂到 /system/etc/security/cacerts
  10. 设置全局代理

常用验证命令

ADB 连接

adb connect 127.0.0.1:5555
adb devices -l

Root 验证

adb -s 127.0.0.1:5555 shell su -c id
adb -s 127.0.0.1:5555 shell su -c getenforce
adb -s 127.0.0.1:5555 shell su -c ls /data/adb

Magisk 版本验证

adb -s 127.0.0.1:5555 shell magisk -v
adb -s 127.0.0.1:5555 shell su -c magisk -v

系统证书验证

adb -s 127.0.0.1:5555 shell su -c 'ls -la /system/etc/security/cacerts/7cd77f98.0'

代理验证

adb -s 127.0.0.1:5555 shell settings get global http_proxy

一句话总结

BlueStacks Air 5.21.780.7504 虽然不在 root-bluestacks-air README 的已测版本列表里，但实测仍可 root；真正的坑不在 initrd 注入，而在 Kitsune 的 stub 下载地址失效、Direct Install 在 BlueStacks 环境下闪退，以及抓包时必须把证书作为系统证书挂进 cacerts。

相关文章

刷新

评论

0条评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注