🔖Frida

检测方的完整武器库把商业 App/安全 SDK 的反 Frida 手段按层汇总，这是一份"对手视角"的清单。逆向时对照排查，比盲目试错高效得多。应用层检测（Java/Kotlin）1. 端口扫描// 连接本机 27042 端口，通了就说明 frida-server 在跑 Socket socket = new Socket("127.0.0.1", 27042);绕过：换端口（-l 127.0.0.1:8888）。2. 进程枚举// 读 /proc 下所有 cmdline 找 frida-server // 或 Runtime.exec("ps") 解析

JNI 层是 Java 与 SO 的边境检查站分析带 native 签名的 App 时，最有价值的信息都发生在 JNI 边界：Java 层把什么参数传进了 SO，SO 又把什么结果还了回来。jnitrace 这个 Frida 工具就是干这个的——自动 hook 所有 JNI 函数调用，打印参数和返回值。pip install jnitrace jnitrace -l libtarget.so com.target.app-l 指定要跟踪的 SO。跑起来后，目标 SO 的每一次 JNI 调用（FindClass、GetMethodID、CallObjectMethod、NewStringUTF…

Frida 的默认特征有多明显Frida 是逆向神器，但它的默认部署在检测方面前几乎是裸奔：进程名：frida-server 写在进程列表里端口：默认监听 27042内存特征：注入的 agent 带 frida 字样的内存页、特有的线程名（gum-js-loop 等）库特征：frida-agent.so 出现在 maps 里商业 App 的反 Frida 检测就是按这个清单逐项扫的。对抗思路：逐项消除特征。第一层：改名换端口（5 分钟搞定）# 1. 二进制改名 adb push frida-server /data/local/tmp/.fs64 # 隐藏文件名 # 2. 换端口 + 只

attach 模式的致命短板frida -U com.target.app（attach 模式）的问题是时机：进程已经跑起来了，启动期的代码——反调试初始化、密钥加载、设备指纹采集——全都执行完了。你 hook 上去时，该发生的都发生了，该检测的也检测完了。spawn 模式（frida -f）让 Frida 创建进程并在 main 之前挂起，你的脚本先执行，App 的代码后运行——攻守之势逆转。基本用法# spawn 启动并挂起，加载脚本后手动放行 frida -U -f com.target.app -l script.js # 进入 REPL 后输入 %resume 放行 # 一条命令自

为什么抓包工具失效时要 hook libsslApp 做了 SSL Pinning 后，Charles/mitmproxy 这类中间人抓包全部失效——证书校验在客户端代码里写死，代理证书不被信任。但有一个地方永远是明文：加密前和解密后的数据。所有 HTTPS 流量最终都要经过 SSL 库的 SSL_write（加密前）和 SSL_read（解密后），在这里 hook，Pinning 形同虚设。Android 上绝大多数 App 用 BoringSSL（Google 的 OpenSSL 分支），SO 名字是 libssl.so，或静态链接进自己的 SO（比如抖音的 libttboringssl）