🔖逆向

抓包分析的本质是"提问-验证"循环面对一条陌生的加密流量，新手盯着 hex 发呆，老手在做假设-验证的循环：猜一个结构，找证据，错了换下一个假设。本文把这套心法拆成可执行的步骤。第一步：建立流量的"地图"抓到包先别急着看单条，先看全貌：会话结构：这次操作产生了几个请求？顺序是什么？（Charles 的 Sequence 视图）域名分布：api 域名、cdn 域名、埋点域名各是什么？（分清业务流量和噪音）协议类型：HTTP/1.1 还是 H2？明文 json 还是加密体？全貌看完，心里要有张图：哪个请求是核心（业务数据），哪些是配套（鉴权、埋点、心跳）。第二步：找"锚点"——已知信息分析加密流量

IP 是协议模拟的半壁江山签名算法逆得再完美，单 IP 高频请求照样被封。代理池是规模化的基础设施，但代理类型选错，钱花了一倍效果打对折。先把三种主流代理的本质搞清楚。三种代理的本质差异1. 数据中心代理（机房 IP）来源：阿里云/AWS 等机房 IP 段特点：便宜（几毛钱/个）、快、稳定致命伤：IP 段公开可查，风控直接按 ASN/段封——电商、社交类站点基本秒识别适用：防护弱的站点、对 IP 质量不敏感的业务2. 短效代理（动态转发）模式：给你一个固定入口，后端 IP 池自动轮换（每分钟/每请求换 IP）特点：IP 量大（百万级池子），按量计费坑：IP 质量混杂（机房+住宅混合），且每次请

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 放行 # 一条命令自

Mach-O：iOS 二进制的解剖图iOS/macOS 的可执行文件是 Mach-O 格式，结构分三段：Mach Header（头部：架构、加载命令数量） ↓ Load Commands（加载命令：告诉系统怎么加载） ↓ Segments/Sections（数据段：代码、数据、符号）逆向必知的几个 Load Command：LC_SEGMENT_64：定义内存段（__TEXT 代码段、__DATA 数据段）LC_ENCRYPTION_INFO_64：FairPlay 加密信息，cryptid=1 表示加密，砸壳就是把它清 0 并替换明文段LC_CODE_SIGNATURE：代码

Canvas 指纹的原理：渲染差异即身份Canvas 指纹利用一个朴素的事实：同一段绘图代码，在不同硬件/系统/浏览器上渲染出的像素有微小差异。差异来自 GPU 渲染管线、字体渲染引擎、抗锯齿算法、色彩管理——这些因素组合起来，几乎能唯一标识一台设备。风控 JS 的标准做法：function getCanvasFingerprint() 同型号同系统的两台手机，这个 hash 大概率相同；不同显卡的两台电脑，几乎必然不同。逆向视角：先确认它采没采、采了什么分析一个风控 SDK 是否采集 canvas 指纹，hook 两个 API：// hook toDataURL const origToDa