Showing Posts From
Android
Frida + frida-tools + Objection 版本对照：frida==16.7.19 最稳组合及 64 位进程错误
版本对照表组件 最新版 最稳版 说明frida 17.5.x 16.7.19 17 仍有 iOS/Objection 兼容问题frida-tools 13.x（最新） 13.7.1 随 frida 走，一般不用指定objection 最新版 最新版 两套 frida 都支持frida-server 与 frida 客户端相同版本 16.7.19 设备端必须与 PC 端版本一致安装命令 最稳定组合（推荐） pip install frida==16.7.19 frida-tools==13.7.1 objection适合：Android 逆向、SSL Pinning、Objection Explore、大多数中文教程。 使用最新版 Frida 17 pip install frida==17.5.1 frida-tools objection适合：需要最新特性，iOS 逆向可能遇到问题时再降级。 常见错误：unable to handle 64-bit processes frida-ps -U Failed to enumerate processes: unable to handle 64-bit processes due to build configuration原因：安装了 32 位 Python，而 Android frida-server 是 64 位的。 检查 Python 位数： python -c "import struct; print(struct.calcsize('P')*8)"如果输出 32，说明是 32 位 Python。 解决方法：从 python.org 下载并安装 64 位 Python（安装时勾选"Add to PATH"） 重新创建虚拟环境：python -m venv frida_env .\frida_env\Scripts\activate pip install frida==16.7.19 frida-tools objection验证：frida-ps -Ufrida-server 版本必须匹配 设备端 frida-server 版本必须与 PC 端 pip install frida 安装的版本完全一致。 例如 PC 端安装了 frida==16.7.19，则设备端 frida-server 也必须是 16.7.19。 从 GitHub releases 下载对应版本： # Android arm64 frida-server-16.7.19-android-arm64# 推送到设备 adb push frida-server-16.7.19-android-arm64 /data/local/tmp/frida-server adb shell "chmod 755 /data/local/tmp/frida-server" adb shell "/data/local/tmp/frida-server &"版本混用报错 如果 PC 端 frida 版本和 frida-server 版本不一致，会看到： unable to communicate with remote frida-server Failed to spawn: unable to find process with name 'xxx'解决方法：保持两端版本一致，不要跨大版本（如 PC 16.x + server 14.x）。
Frida / frida-tools / Objection 版本对齐 + 32 位 Python 的坑
CTF / 授权渗透 / 自己应用的安全测试里 Frida 是常用工具。装的时候版本三个（frida、frida-tools、objection）加设备端 frida-server 要对得上，不然经常 unable to communicate with remote frida-server。 目前最稳的组合 写在最前面——如果你不追新，直接抄这套： pip install frida==16.7.19 frida-tools==13.7.1 objection设备端 frida-server-16.7.19（对应 Android 架构）。这套是当前社区教程覆盖最广、踩坑最少的组合。 用最新 Frida 17 呢 装最新版： pip install frida frida-tools objectionfrida-tools 会跟着 Frida 版本自动装匹配的（一般是 13.x）。Objection 最新版也已经跟上了 Frida 17，但 iOS 场景仍有已知问题，比如：ObjC is not defined 部分 explore 命令异常 SSL Pinning 相关脚本行为变化Android 场景 Frida 17 已经比较稳。iOS 建议留在 16.7.x。 frida-ps -U 报"unable to handle 64-bit" 一装完想连手机测： frida-ps -U崩： Failed to enumerate processes: unable to handle 64-bit processes due to build configuration几乎 100% 是你装了 32 位 Python，而设备上 frida-server 是 64 位。Frida 的 Python 绑定的位数必须和目标进程匹配。 先确认 Python 位数： python -c "import struct;print(struct.calcsize('P')*8)"输出 32 就是罪魁祸首。 解法：从 python.org 下 64-bit 安装包（找 "Windows installer (64-bit)" 或者 "Windows embeddable package (64-bit)"） 卸载 32 位 Python 新建虚拟环境：python -m venv frida_env frida_env\Scripts\activate pip install frida==16.7.19 frida-tools==13.7.1 objection主机 Frida vs 设备 frida-server 必须版本一致 主机 Python 侧和手机上的 frida-server 必须严格同版本号，包括小版本。混版本症状： frida.core.RPCException: unable to communicate with remote frida-server对齐流程： # 1. 主机装什么版本 frida --version # 假设 16.7.19# 2. 下对应设备端 # github.com/frida/frida/releases → frida-server-16.7.19-android-arm64.xz# 3. 手机架构 adb shell getprop ro.product.cpu.abi # arm64-v8a → 用 android-arm64 # armeabi-v7a → 用 android-arm# 4. 推送 + 启动 adb push frida-server-16.7.19-android-arm64 /data/local/tmp/frida-server adb shell "chmod +x /data/local/tmp/frida-server" adb shell "/data/local/tmp/frida-server &"# 5. 主机验证 frida-ps -U | head环境里有多个 frida.exe pip show frida 显示当前 venv 装了，但 frida-ps -U 还是老版本行为——大概率是 PATH 上另一个 Python 里也有 frida.exe： where frida where frida-ps看到两条以上路径，把不想用的从 PATH 里挪走，或者用 venv 里的绝对路径调： D:\project\frida_env\Scripts\frida-ps.exe -U一张速查表症状 常见原因unable to handle 64-bit 32 位 Pythonunable to communicate with remote frida-server 版本不一致 / server 没起 / SELinuxObjC is not defined（iOS） Objection + Frida 17 兼容问题Failed to attach: process not found root 权限 / SELinux / SEAndroidfrida-server 起来立刻退出 架构下错、缺可执行权限一句话总结 64 位 Python + frida==16.7.19 frida-tools==13.7.1 + 同版本 frida-server 是当前最稳的组合。Frida 17 追新可以，iOS 用户等它再稳一稳。
TrickyStore 替代方案：2026 年 Android Root 通过 Play Integrity 的主流组合
背景 TrickyStore 的核心功能是：劫持 Android KeyStore，注入 Keybox，伪造 TEE 硬件证明（Hardware Attestation），让 Play Integrity 拿到 MEETS_STRONG_INTEGRITY。 2026 年 Google 大规模推进 RKP（Remote Key Provisioning），设备 Keybox 越来越多通过远程下发，公开泄露的 Keybox 被大量封禁，TrickyStore 的有效性明显下降。 主流替代方案对比方案 用途 推荐度Play Integrity Fork Device / Basic Integrity 修复 ⭐⭐⭐⭐⭐ReZygisk 替代原生 Zygisk ⭐⭐⭐⭐Shamiko Root 痕迹隐藏 ⭐⭐⭐⭐HMA-OSS（Hide My Applist） 隐藏 Root、LSPosed、模块列表 ⭐⭐⭐⭐KernelSU Next + SUSFS Kernel 级隐藏，最难检测 ⭐⭐⭐⭐⭐TrickyStore Strong Integrity / TEE 硬件证明 ⭐⭐⭐（RKP 影响下效果变弱）各场景推荐组合 银行 App（不要求 Strong Integrity） Play Integrity Fork + HMA-OSS + ReZygisk很多银行只要求 DEVICE_INTEGRITY，更多是检测：Root 文件、Bootloader 状态、Magisk/LSPosed 痕迹、可疑 App 列表。HMA-OSS 可以对指定 App 隐藏已安装列表，避免被扫描到 Root 工具。 Google Wallet Google Wallet 目前仍需要 STRONG_INTEGRITY，TrickyStore 仍然是成功率最高的方案，没有更好的替代： TrickyStore + Play Integrity ForkKeybox 失效后需要更换有效的私有 Keybox，公开 Keybox 已不可靠。 游戏（Pokemon GO、吃鸡等） 游戏越来越少单纯依赖 Play Integrity，更多依赖自己的反作弊检测： KernelSU Next + SUSFS + HMA-OSSSUSFS 在内核层隐藏 /proc、/sys 特征，比用户空间隐藏更彻底，是目前社区反作弊对抗的主流选择。 完全放弃 TrickyStore 的通用方案 KernelSU Next + SUSFS + ReZygisk + Play Integrity Fork对绝大部分银行 App 和普通应用可以通过 BASIC + DEVICE Integrity，已经够用。 Magisk 体系 vs KernelSU 体系维度 Magisk 体系 KernelSU 体系方式 修改 boot.img 内核模块隐藏难度 中（用户空间检测较容易发现） 高（内核层操作更底层）兼容性 广（绝大多数设备） 需要设备支持 KMI 或自编译内核Zygisk 原生支持 需 ReZygiskSUSFS 支持 有 susfs4magisk，但效果弱于 KernelSU 原生支持，效果最好重要说明 银行 App 实际检测逻辑通常不只看 Play Integrity，还包括：/proc/mounts 是否有可疑挂载 系统分区是否有异常文件 可疑进程名（magiskd、zygote64d 等） 已安装 App 列表（通过 PackageManager）即使 Play Integrity 全部通过，Root 痕迹未隐藏干净仍可能被识别。HMA-OSS 对目标 App 可以精确控制可见的应用列表，是隐藏 Root 工具的关键一步。