一次性脚本的痛点逆向工程师的电脑里都有一堆 test1.js、hook_final.js、hook_final_真的最终版.js——一次性脚本越攒越多，换个 App 又要重写 80%。Frida 脚本需要工程化：模块化、可配置、可复用。模块化：按功能拆分把常用能力拆成独立模块，用 require 组合：// lib/utils.js function bytesToHex(bytes) function bytesToStr(bytes) module.exports = ; // lib/okhttp.js —— OkHttp 抓包模块 var = require('./utils

为什么系统代理不够用安卓抓包的标准痛点：在 WiFi 设置里配了代理，但很多 App 根本不走系统代理——OkHttp 可以配 Proxy.NO_PROXY，native 层的网络库（Cronet、自研协议栈）直接无视系统设置。表现就是 Charles 里只能抓到部分请求，目标接口一个都看不到。解法：VPN 型全局接管。Postern 这类工具在手机上起一个本地 VPN，所有 TCP 流量强制走 VPN，再转发给 Charles——App 无论怎么配置都逃不掉。方案架构手机 App → Postern(VPN 接管) → Charles(电脑) → 目标服务器配置步骤第一步：Charles 端

越狱检测在检测什么iOS App（尤其是金融、政务类）启动时普遍做越狱检测，检测到就闪退或限制功能。检测点分四类：1. 文件系统特征越狱后多出来的文件是第一批路标：NSArray *paths = @[@"/Applications/Cydia.app", @"/usr/sbin/sshd", @"/usr/bin/ssh", @"/etc/apt", @"

B站扫码登录的接口设计B站的扫码登录是各家里最规整的——接口语义清晰、无复杂加密，是理解扫码登录协议的最佳样本。核心目标：拿到 SESSDATA cookie（B站登录态的灵魂）。全流程拆解第一步：申请二维码GET https://passport.bilibili.com/x/passport-login/web/qrcode/generate返回：{ "data": url 做成二维码展示（App 扫的就是它），qrcode_key 是后续轮询的凭证。第二步：轮询扫码状态GET https://passport.bilibili.com/x/passport-log

面对陌生 App 的标准作战流程新手逆向陌生 App 最容易犯的错是"上来就怼签名算法"——逆了三天算法，发现还要设备指纹；搞定指纹，发现还有行为风控。正确的流程是先侦察全貌，再决定主攻方向。这套流程我跑了几十个项目，稳定可靠。第一阶段：侦察（半天，不动手逆）1. 抓包看全貌挂上抓包工具（Charles/mitmproxy），把 App 的核心业务流程走一遍（登录、列表、详情、提交），回答三个问题：接口是 HTTP 还是私有协议？（决定分析工具）有没有签名参数？（sign/token/encrypt 字样）响应是明文还是密文？2. 静态看结构jadx 打开 APK（先不深入），看三样东西：加没