TEA 家族为什么在这些领域流行TEA（Tiny Encryption Algorithm）的设计目标是"用最少的代码实现分组加密"——核心加密循环不到 20 行 C 代码。这使它成为手游协议、IoT 固件、嵌入式设备的标配加密：代码量小、速度快、资源占用低。逆向这些领域时，TEA/XXTEA 的识别率是 AES 之外最高的。识别：黄金分割常量是路标TEA 的灵魂常量是 0x9E3779B9（2^32/φ，黄金分割比的无理数近似）：void tea_encrypt(uint32_t* v, uint32_t* k) { uint32_t v0 = v[0], v1 = v[1], su

什么时候该放弃纯协议协议模拟不是万能的。这些信号出现时，该考虑云手机/群控路线：签名算法在 VMP 级加固的 SO 里，还原成本以月计风控对设备环境的要求极高（协议模拟的环境总是"差点意思"）业务必须真实 UI 交互（人脸识别后的操作、复杂表单）协议随版本高频变更，维护成本失控云手机方案的本质：放弃"模拟设备"，直接"租用真实设备"——真实安卓系统、真实硬件指纹、真实传感器，上面跑自动化脚本。三种方案对比1. 公有云手机（红手指、雷电云、双子星等）形态：云端虚拟化安卓实例，按台/月租优点：开箱即用、弹性扩容、自带 IP 池（部分）缺点：云手机本身有虚拟化特征（风控能识别主流云手机平台）、成本随

WebSocket 逆向和 HTTP 有什么不同HTTP 协议模拟是"一次性请求"的复制，WebSocket 是长连接状态机的复刻：握手、鉴权、心跳、消息编解码、重连，每个环节都有坑。抓包工具对 WS 的支持也弱于 HTTP（Charles 能看但不直观），先建立正确的分析姿势。分析姿势：先看懂消息格式Chrome DevTools 的 Network → WS → Messages 标签页能看到所有帧。重点观察：消息格式：JSON？protobuf？自定义二进制？（JSON 最好办，protobuf 按前文方法还原，自定义二进制最麻烦）消息类型字段：一般有个 type/cmd/op 字段区分

TLS 指纹之后还有 H2 指纹过了 JA3 检测却被更隐蔽的指纹拦下——问题可能出在 HTTP/2 层。现代网站 90%+ 走 HTTP/2，而 H2 连接的建立过程同样暴露客户端实现：SETTINGS 帧：参数集合和值（HEADER_TABLE_SIZE、INITIAL_WINDOW_SIZE 等）WINDOW_UPDATE 帧：窗口增量的数值HEADERS 帧：伪头顺序（:method :path :authority :scheme 还是别的排列）优先级策略：PRIORITY 帧的使用模式这些全部由 HTTP/2 库的实现决定——Chrome 的 netstack、nghttp2（cu

为什么 Android 7 之后抓包变难了Android 7（API 24）改了网络安全模型：App 默认只信任系统证书，不再信任用户证书。你在设置里装的 Charles 证书进的是用户证书区，App 直接无视——这就是"证书装了但抓不到包"的原因。解决思路只有一个：把抓包证书塞进系统证书区 /system/etc/security/cacerts/。Android 10+ 的 system 分区是只读的（动态分区+dm-verity 校验），直接 remount 会失败，这就是本文要解决的完整链路。前置条件已 root（Magisk）Charles/mitmproxy 的 CA 证书（pem