0.1先建立一张地图：数据到底怎么走

很多人学安全，卡在"知识点都会，但串不起来"。原因是没建立分层直觉。先看这张图：你点一下"登录"，数据从手指到服务器，再回来，中间穿了五层衣服。

0.2三条学习路线，按你的底子选

0.3全站地图

七个分组，36 页。每一页都是独立完整的，可以从任意一页开始；页尾的"上一页 / 下一页"会把线接回去。

0.4怎么用这套教程才有效

0.5快捷键与阅读功能

0.6内容边界：先把红线说清楚

这不是一句免责套话。真正做这行的人都明白：技术能力的边界，和授权文件的边界是重合的。第 25 章会把法律条款、授权范围怎么写、哪些行为绝对不要碰，一条条讲清楚。

零基础预备课：先搞懂这 8 个问题

如果你没学过网络、没写过代码，直接看后面的 TLS、逆向、风控会像看天书。这一页不涉及任何技术细节，只用寄快递、门牌号、身份证这些日常经验，把后面 35 页要用到的底层概念先铺一遍。看完这页，你就能看懂全站 80% 的图。

0.1问题一：点一下按钮，发生了什么

你在 App 里输入账号密码，点"登录"。这一瞬间发生了四件事，顺序固定：

把这四步想成寄快递：

• 请求：你写一张单子（账号密码），装进信封寄出去；
• 响应：对方收到后回一张单子（登录成功），还附了一张"取件卡"；
• 带凭证：以后每次取件都出示这张卡，对方就知道是你；
• 取数据：对方核对卡片，把包裹给你。

0.2问题二：手机怎么找到那台电脑

互联网上有几十亿台设备，你的手机怎么知道该把请求发给哪一台？靠三层地址，缺一不可。

0.3问题三：寄过去的那句话长什么样

这句话不是随便写的，它有固定格式。最常见的是 HTTP 报文，分成三块：

请求行：方法 + 路径 + 版本
POST /api/login HTTP/1.1

请求头：一堆"附件说明"
Host: shop.example.com
Content-Type: application/json
User-Agent: MyApp/8.2.1 (Android 14)

请求体：真正的业务内容
{"username":"demo","password":"******","ts":1729900000,"sign":"9f2c..."}

三块各管一件事：

• 起始行：我要干什么（GET 取数据 / POST 提交数据）；
• 头（Header）：附件说明，告诉对方"我是什么客户端、内容是什么格式、我带没带凭证"；
• 体（Body）：正文，通常是 JSON。

JSON 就是一种"用花括号和冒号写清单"的格式，你可以把它当成一张填写好的表格：

{
  "code": 0,                 // 0 表示成功
  "msg": "ok",
  "data": {
    "uid": 10086,
    "nickname": "小明",
    "token": "eyJhbGciOiJIUzI1NiIs..."
  }
}

0.4问题四：为什么这句话要加密

因为这句话一路上要经过很多台你不认识的机器：你家的路由器、运营商的基站、机房的交换机。任何一环都能偷看。看下面这张对比图：

但光加密还不够。攻击者虽然看不懂内容，却可以把整句话原样再寄一遍（重放），或者把信封上的名字换掉（冒充）。所以还需要：

• 加密：防偷看；
• 签名：防篡改、防冒充；
• 时间戳 + 随机数：防重放；
• 证书：证明"对面那台机器真的是它"。

0.5问题五：登录到底在干什么

登录不是"把密码发给服务器然后它记住你"。真实过程更像办一张临时门禁卡：

这也解释了一个常见疑问：为什么改密码之后，别的设备会被踢下线？因为服务器把旧 Token 作废了。Token 不是密码，它只是一张有期限的通行证。

0.6问题六：抓包到底在抓什么

"抓包"不是抓一个包裹，而是把手机和服务器之间来回的每一句话都录下来。录下来之后你能看到：

• 请求发到了哪个域名、哪个路径；
• 带了哪些头、哪些参数；
• 服务器回了什么状态码、什么内容；
• 一次操作背后其实发了好几个请求。

但抓包有个前提：你得能看懂它。如果流量是加密的，你只能看到一堆乱码和域名。于是就有了后面两条路：一条是让手机信任你的代理证书（第 10 章），另一条是直接分析 App 里的加密逻辑（第 12 到 15 章）。

0.7问题七：逆向到底在逆向什么

App 是一个打包好的程序。你手上没有它的源代码，只有安装包。逆向就是把打包好的东西拆开，还原出它的逻辑。拆的东西主要有三类：

三者是递进关系：先静态看结构，再动态看行为，最后用真实流量对拍验证。只做其中一步，很容易得出错误结论。

0.8问题八：我需要先会什么

不需要先成为程序员，但下面这些东西会反复用到，建议边学边补：

0.9接下来的学习顺序

网络分层：数据是怎么一层层穿上衣服的

你在抓包软件里点开一个包，会看到 Ethernet、IP、TCP、HTTP 一层套一层，像俄罗斯套娃。这一页用寄快递要套好几层包装讲清为什么要分层、每层加了什么，以及为什么改一个 HTTP 头根本不影响数据怎么走路。

2.1先看一次真实的寄快递

你给朋友寄一部手机。你不会把手机裸着塞进邮筒，而是分四步：

• 先用泡沫裹一层，防摔；
• 装进纸箱，保证装得下、不散架；
• 箱子上贴一张面单，写清收件人地址；
• 交给快递员，由他决定这一站送到哪个分拣中心。

这四步各管一件事。泡沫管"别摔坏"，纸箱管"装得下"，面单管"送到哪"，快递员管"这一站交给谁"。

关键在这里：分拣中心只看面单，不会拆开箱子研究你寄的是什么。它也不需要知道。

网络用的是同一套思路。你要发的一句话，也会被裹上好几层"包装"，每一层只写自己关心的信息。这套做法叫分层（Layering）。

2.2七层和四层：两套说法，说的是同一件事

教科书上最常见的是 OSI（Open Systems Interconnection，开放系统互连）七层模型，由国际标准化组织在 1980 年代提出。

但真实互联网跑的不是 OSI，而是 TCP/IP 四层模型。OSI 更像一张教学挂图：分得细，方便描述问题；TCP/IP 是施工图：能落地，大家都在用。

注意两个细节：

• 表示层和会话层在 TCP/IP 里被并进了应用层，所以"七层"和"四层"不矛盾，只是切法不同。
• 很多教材说"五层"，是把网络接口层再拆成数据链路层和物理层。三种说法都对，看你跟谁聊。

从下往上的记忆口诀：物、数、网、传、会、表、应。背下来，看任何协议文档都能对上号。

2.3每层到底在干什么

从上往下走一遍，每层一句话说清职责，再配一个真实例子。

• 应用层：你和程序打交道的地方。浏览器发出 GET /index.html HTTP/1.1，这就是应用层的内容。
• 传输层：负责"这一头到那一头"，用端口号区分程序。TCP 还会编号、确认、重传。头最少 20 字节。
• 网络层：负责"从这台机器到那台机器"，加源 IP 和目的 IP。头也是 20 字节起。
• 数据链路层：负责"这一跳到下一跳"，加以太网帧头，里面是目的 MAC、源 MAC 和类型，共 14 字节。
• 物理层：把 0 和 1 变成电压、光脉冲或无线电波。

2.4封装：一层层穿衣服

数据从应用层往下走的时候，每经过一层，就在前面加一个头。这个动作叫封装（Encapsulation）。

反过来，服务器收到电信号，从物理层往上走，每层检查并撕掉属于自己的头，把剩下的交给上一层。这叫解封装（Decapsulation）。

每一层的数据单位有专门的名字，看文档时经常遇到：

为什么要这么麻烦？因为每一层可以独立替换。Wi-Fi 换成 4G，只是链路层和物理层变了，上面的 HTTP 一行都不用改。

2.5四个头的真实样子

光说概念容易飘，直接看字节。下面是一个 HTTPS 请求在网线上被拆开后的样子，十六进制，空格只是为了好读。

以太网帧头（14 字节）
3c 22 fb 11 08 00   目的 MAC
a4 5e 60 9c 31 7d   源 MAC
08 00               类型 = IPv4

IP 头（20 字节，节选）
45 00 05 dc         版本 4、头长 5、总长 1500
40 06 ...           TTL 64、协议 6 表示 TCP
c0 a8 01 0a         源 IP 192.168.1.10

TCP 头（20 字节，节选）
1f 90 01 bb         源端口 8080、目的端口 443
00 00 00 00         序号
50 18 ...           头长 5、标志位 PSH + ACK

HTTP 请求（应用层，纯文本）
GET /api/user HTTP/1.1
Host: shop.example.com
User-Agent: MyApp/8.2.1

逐条解释，这些字段以后会反复出现：

• 帧头最后的 08 00 是类型字段，告诉接收方"里面装的是 IPv4"。如果是 86 dd，就是 IPv6。
• IP 头的第一个字节 45，高 4 位是版本号 4，低 4 位是头长度 5，单位是 4 字节，所以 5 乘 4 等于 20 字节。
• IP 头的 40 是 TTL（Time To Live，生存时间），每过一个路由器减 1，减到 0 就丢弃，防止包在网络里永远转圈。
• TCP 端口是 16 位，范围 0 到 65535。443 是 HTTPS 的默认端口，80 是 HTTP 的默认端口。
• HTTP 头是纯文本，一行一个字段。Host 告诉服务器你要访问哪个站点，一台服务器可以靠它区分很多网站。

2.6MTU 1500：超重必须拆包

网线不是想传多大就传多大。以太网一帧最多扛 1500 字节的 IP 数据，这个上限叫 MTU（Maximum Transmission Unit，最大传输单元）。

为什么是 1500？这是早期以太网定下的工程折中：太小，头部开销占比高；太大，一个包出错要重传的代价高，而且别的设备可能收不下。这个数字一直沿用至今。

超过 1500 怎么办？IP 层会把大包切成几片，每片都带自己的 IP 头，头里记着"我是第几片、从原始数据的第几个字节开始、后面还有没有"。这个过程叫分片（Fragmentation）。

用快递打比方：一件超重货物必须拆成三个箱子，每个箱子贴同一张运单的编号，收件方按编号拼回去。少一个箱子，整件货就不完整。

分片的代价很实在：

• 丢任何一片，整个原始包都得重传。IP 层自己不管重传，靠上层 TCP 补。
• 每片都要重复 20 字节 IP 头，开销变大。
• 中间设备重组策略不一致时会出现安全漏洞：攻击者用重叠分片，让防火墙看到无害内容，让目标主机拼出恶意内容。

所以现代做法是尽量避免分片：TCP 握手时会根据路径 MTU 算出 MSS（Maximum Segment Size，最大报文段长度），让每个 TCP 段正好装进一个帧。IPv6 更进一步，路由器不再分片，只允许发送方自己分。

2.7抓包软件里看到的是什么

用 Wireshark 抓一个 HTTPS 请求，点开其中一个包，会看到这样的层次，从上到下：

Frame 1: 1514 bytes on wire      物理层信息：帧长、到达时间
Ethernet II: 源 MAC 到 目的 MAC    链路层：类型 IPv4
Internet Protocol Version 4      网络层：源 IP 到 目的 IP，TTL 64
Transmission Control Protocol    传输层：51234 到 443，Seq / Ack
Transport Layer Security         表示层 / 会话层：TLS 记录
Hypertext Transfer Protocol      应用层：GET /api/user

注意顺序：抓包工具把"最外层"放在最上面，正好和发送时的封装顺序相反。你点开三角，就是在做一次解封装。

如果某一层显示"加密的应用数据"，说明 TLS 把上面几层的内容包住了。你只能看到 TLS 这一层，再往上要拿到密钥。

2.8常见误区：分层不是物理隔离

很多人以为七层是七个独立的程序，甚至以为是七段不同的网线。其实一台手机里，从浏览器到网卡驱动，所有层都在同一台设备上完成，只是代码分工不同。

分层是逻辑约定，核心只有一句话：每一层只使用下一层提供的服务，不关心下一层怎么实现。

• 所以底层换掉，上层不用改。Wi-Fi 换 4G、IPv4 换 IPv6，HTTP 依然照跑。
• 所以同一层可以有很多实现。TCP 在 Windows、Linux、手机里写法不同，但对上层的行为一致。

也别把分层当法律。现实里有大量"不守规矩"的用法：

• 隧道：把整个 IP 包装进另一个 IP 包里传，VPN 常这么做，等于套了两层网络层。
• QUIC：把可靠传输做在 UDP 之上，绕开了传统 TCP。
• TLS：横跨表示层和会话层，还顺手做了身份认证。

分层是描述工具，不是限制。判断一个协议属于哪层，看它解决的是哪类问题，而不是看它叫什么名字。

2.9回到那个问题：改 HTTP 头为什么不影响路由

现在可以回答了。路由器转发一个包时，只看 IP 头里的目的 IP 和路由表，然后决定从哪个口发出去。

HTTP 头在 IP 层眼里只是"数据"，被完整地包在 IP 包的载荷里。路由器不拆、不解析、也不关心。

快递分拣中心只看面单上的城市，不会拆开箱子读你写的信。同一个道理。

但这句话有个重要边界：不影响的只是"IP 路由"。下面这些设备会故意往上拆一层看。

所以"改 User-Agent 能骗过某些检测"和"改 User-Agent 能改变路由"是两件事。前者是应用层的事，后者根本不可能，除非中间有应用层设备插手。

顺带说清一个常见混淆：CDN 按 Host 头把请求分到不同源站，这叫应用层负载均衡，不是 IP 路由。它的决策依据是 HTTP 头，不是路由表。

字节、编码与字节序：所有协议的底层语言

抓包看到一串 48 54 54 50，逆向看到 0x12345678，网页里看到 %E4%B8%AD。这些不是天书，是同一种东西的不同写法。这一页把"0 和 1 怎么变成人能读的字"讲透，让你以后看到字节先能判断它是什么，而不是直接喊加密。

3.1为什么安全人要懂字节

你在抓包工具里看到的是十六进制，在逆向工具里看到的是汇编和内存，在网页源码里看到的是百分号编码。它们说的是同一件事：一段字节。

不懂字节，会出现三种典型误判：

• 把 Base64 当成加密，以为解不开，直接放弃。
• 把 UTF-8 的中文当成乱码，以为数据坏了。
• 把大端当小端读，长度算错一位，整个包解析全错。

这一页不要求你会写代码，只要求你能"看懂并手算"。手算过一次，比看十遍定义都管用。

3.2位、字节、十六进制

计算机最小的单位是位（Bit），只有 0 和 1 两种状态，像一盏灯的开关。

8 个位组成一个字节（Byte）。一个字节能表示 0 到 255，共 256 种值。

写二进制太长，于是用十六进制（Hexadecimal）：每 4 位合成一个十六进制数字，一个字节正好写成两位。比如 0100 0001 写成 41。

十六进制用 0 到 9 和 A 到 F 共 16 个符号。A 代表 10，F 代表 15。前面加 0x 表示"这是十六进制"。

所以 0x41 等于十进制 65，等于二进制 0100 0001，等于 ASCII 字符 A。这四个写法完全等价。

手算方法：把十六进制每一位乘 16 的幂。

0x41  = 4 乘 16 + 1  = 65
0xFF  = 15 乘 16 + 15 = 255
0x100 = 1 乘 256      = 256

反过来，十进制转十六进制就是不断除以 16 取余数。初学阶段记住几个锚点就够：

• 0x20 是空格，0x30 是字符 0，0x39 是字符 9。
• 0x41 是大写 A，0x61 是小写 a，两者差 32。
• 0x7F 是 ASCII 的上限，超过它就是非 ASCII 内容。

3.3大端与小端：一个数字，两种排法

一个整数如果超过 1 个字节，就要决定"高位字节先放还是低位字节先放"。这就是字节序（Endianness）。

以 0x12345678 为例，它占 4 个字节：12、34、56、78。

• 大端序（Big-endian）：高位在前，内存里是 12 34 56 78，符合人的阅读习惯。
• 小端序（Little-endian）：低位在前，内存里是 78 56 34 12。x86 和 ARM 默认用这种。

网络传输统一用大端，这叫网络字节序（Network Byte Order）。所以写代码时经常要调用"主机序转网络序"的函数，就是在做这个转换。

为什么这事和安全有关？因为协议解析错误经常出在这里。你把小端的长度字段按大端读，可能把 1000 读成 3891200，然后按这个长度去读缓冲区，就是经典的越界漏洞。

判断方法：看到 00 00 03 e8，按大端读是 1000；看到 e8 03 00 00，按小端读也是 1000。真实协议里长度字段通常是 2 或 4 字节，先确认字节序，再算长度。

3.4整数编码：无符号、有符号、补码

同样 1 个字节，可以表示 0 到 255（无符号，Unsigned），也可以表示 -128 到 127（有符号，Signed）。区别在于最高位是不是被当成符号位。

有符号数用补码（Two's Complement）表示。规则很简单：正数不变，负数等于取反再加 1。

 5 = 0000 0101
-5 = 1111 1010 + 1 = 1111 1011 = 0xFB

用温度计理解最直观：0 度在中间，往上是正数，往下是负数。走到最底下再往下走一格，就绕回最上面，因为一个字节只有 256 个格子，溢出会"绕圈"。

这个"绕圈"是很多漏洞的来源：

• 一个无符号长度减去一个更大的数，不会变成负数，而是变成一个巨大的正数。
• 用这个巨大数字去分配缓冲区，要么分配失败，要么后续拷贝直接越界。

反过来，有符号数溢出在 C 语言里是未定义行为，编译器可以做任何事。所以安全代码里做长度计算，一律用无符号并检查上界。

3.5变长整数 varint：省空间的艺术

固定 4 字节存一个小数字很浪费。比如用户 ID 是 300，也要占 4 字节。Protobuf（Protocol Buffers）用变长整数（varint）解决这个问题。

规则：每个字节只用低 7 位存数据，最高位是"还有没有下一个字节"的标志。1 表示后面还有，0 表示这是最后一个。

300 = 0000 0001 0010 1100
按 7 位一组，从低位开始切：010 1100、000 0010
每组补上继续位：1010 1100、0000 0010
写成十六进制：ac 02

所以 300 只占 2 字节，而不是 4 字节。数字越小占得越少，超过 127 才需要第二个字节。

代价是解析要循环：一直读到最高位为 0 为止。这也给了攻击者空间，构造一个超长的 varint，让解析器一直读下去，就是拒绝服务。所以实现里必须限制最大字节数，常见上限是 10 字节。

3.6Base64：3 个字节变 4 个字符

有些通道只能传文本，不能传二进制，比如老式邮件、URL 参数、JSON 字段。Base64 把任意字节换成 64 个安全字符：A 到 Z、a 到 z、0 到 9，再加 + 和 /。

原理只有一步：把 3 个字节共 24 位，重新切成 4 组，每组 6 位。6 位能表示 0 到 63，正好对应 64 个字符。

以 "Man" 为例，完整过程是：

M = 01001101    a = 01100001    n = 01101110
连起来：010011 010110 000101 101110
查表：   T      W      F      u
结果：TWFu

3 字节变 4 字符，体积涨约 33%。如果原文不是 3 的倍数，用 = 补齐，所以你会看到结尾有 = 或 ==。

重点：Base64 不是加密。它没有密钥，任何人拿到都能还原。它只是换了一种写法，作用是让二进制能安全穿过文本通道。

3.7UTF-8：一个汉字通常 3 字节

计算机只认字节，要把"字"变成字节，需要字符编码（Character Encoding）。

UTF-8 是目前最通用的编码。它的规则是变长：

所以"中"这个字在 UTF-8 里是 e4 b8 ad 三个字节。你在抓包里看到这三个字节，不是乱码，是正常的中文。

判断技巧：UTF-8 的多字节序列，第一个字节高位有几个 1，就表示总共几个字节。e4 是 1110 0100，开头三个 1，所以是三字节字符。后面两个字节都以 10 开头，是续字节。

GBK 是另一套中文编码，一个汉字 2 字节。同一段中文用 UTF-8 和 GBK 编码，字节完全不同。看到"锟斤拷"这种乱码，通常是编码用错了，不是数据损坏。

3.8URL 编码：%E4%B8%AD 是怎么来的

URL 里有一批字符不能直接出现，比如空格、中文、&、=、#。解决办法是把每个字节写成百分号加两位十六进制。

"中"的 UTF-8 是 e4 b8 ad，所以 URL 编码后就是 %E4%B8%AD。大小写都合法，习惯上写大写。

常见对照：

• 空格变成 %20，在查询参数里也可能写成 +。
• / 变成 %2F，. 变成 %2E。
• 一个中文变成三个 %XX。

这里有个经典安全问题：如果服务器只解码一次，而中间某层解码了两次，攻击者就能用 %252e%252e%252f 绕过路径检查，解码两次后变成 ../。这叫双重编码（Double Encoding）。防御方法是对输入只解码一次，然后做规范化再校验。

3.9文件头：看前几个字节就认出文件

很多文件格式在开头放了固定字节，叫魔数（Magic Number）。改扩展名骗不了它。

用法：拿到一个可疑文件，先看前 16 字节，比看扩展名可靠得多。攻击者也常用"改文件头"来绕过检测，所以只看魔数也不够，要结合结构解析。

3.10工具：两条命令看字节

Linux 和 macOS 自带 xxd 和 hexdump，Windows 可以用 Git Bash，或者 PowerShell 的 Format-Hex。

# 看前 64 字节：左边偏移，中间十六进制，右边字符
xxd -l 64 sample.bin

# 经典十六进制视图，-C 表示同时显示字符
hexdump -C sample.bin | head

# 看一个汉字在 UTF-8 下的字节
printf '中' | xxd

输出长这样：

00000000: 8950 4e47 0d0a 1a0a 0000 000d 4948 4452  .PNG........IHDR

左边 00000000 是偏移，也就是第几个字节。中间每 2 个十六进制数字是 1 个字节。右边是能打印的字符，不能打印的显示为点。

3.11误区：看到十六进制就以为加密

这是初学者最常见的误判。判断顺序应该是：

1. 先看是不是文本编码。能按 UTF-8 正常读出中文英文，就是编码问题。
2. 再看是不是 Base64。全是 A 到 Z、a 到 z、0 到 9、加号、斜杠，长度是 4 的倍数，结尾可能有等号，大概率是 Base64。
3. 再看是不是压缩。开头 1F 8B 是 gzip，50 4B 是 zip。
4. 最后才考虑加密。加密后的字节应该接近随机：每个值出现频率差不多，没有明显的重复结构。

一个实用判据：把字节画成直方图。文本和 Base64 的分布很不均匀，压缩和加密的分布接近均匀。这就是"熵"的直观含义，下一章会讲。

另一条：如果一段数据你能用 Base64 解开，得到可读内容，那它从一开始就不是加密。

密码学基础：四把锁和一台榨汁机

加密、哈希、签名、证书，这四个词经常被混着用。这一页用四把锁和一台榨汁机，把它们各自解决什么问题、不能解决什么问题分清楚。看完你会明白：为什么 TLS 不直接用非对称加密传数据，为什么同一个 IV 用两次会出大事。

4.1先分清四个需求

在选工具之前，先问自己要解决哪个问题。这四个词以后会反复出现，必须一次分清。

逐个说清：

• 机密性（Confidentiality）：内容不能让中间人看懂。工具是加密。
• 完整性（Integrity）：内容不能被悄悄改动。工具是哈希、消息认证码。
• 认证（Authentication）：确认对方真的是它。工具是证书、签名。
• 不可否认（Non-repudiation）：事后不能否认自己做过。工具是数字签名。

现实系统通常四个都要。TLS 就是把这四件事打包：用非对称加密协商密钥并认证服务器，用对称加密传数据，用认证标签保证没被改。

4.2对称加密：一把钥匙开一把锁

对称加密（Symmetric Encryption）只有一把钥匙，加密和解密用同一个。像家里的门锁，同一把钥匙进和出。

优点是快。AES（Advanced Encryption Standard，高级加密标准）在普通笔记本上能跑到每秒几个 GB，加密一整块硬盘也不费劲。

缺点是钥匙怎么给对方。你们没见过面，怎么安全地把钥匙送过去？这就是后面非对称加密要解决的问题。

AES 是分组密码（Block Cipher）：把数据切成固定大小的块，每块 16 字节，逐块加密。密钥长度有 128、192、256 位三种，目前常用 128 或 256。

但分组密码只解决了"一块怎么加密"，还需要一个工作模式（Mode of Operation）来决定"多块怎么串起来"。

4.3四种常见模式：ECB、CBC、CTR、GCM

重点说 ECB。它把每一块单独加密，完全不管上下文。结果就是：明文里相同的块，密文里也相同。

最著名的演示是"ECB 企鹅"：一张图片用 ECB 加密后，企鹅的轮廓依然清晰可见，因为大面积的同色区域产生了相同的密文块。

所以 ECB 不该用于任何真实数据。它只适合加密单个随机块，或者当教学例子。

CBC 的做法是：先让明文块和"上一块密文"异或，再加密。第一块没有上一块，就用一个初始向量（Initialization Vector，IV）顶上。这样相同的明文块，位置不同，密文就不同。

CTR 换了个思路：不加密数据，而是用"密钥加计数器"生成一串密钥流，再和数据异或。加密解密是同一个操作，可以并行，也可以随机读某一块。

GCM 在 CTR 基础上加了一个认证标签（Authentication Tag），解密时先校验标签，不对就拒绝。这类"加密加认证"一体的模式叫 AEAD（Authenticated Encryption with Associated Data，带关联数据的认证加密）。

4.4IV 和 nonce：一次性，绝不能重复

IV 和 nonce（Number used once，一次性数字）的作用是让同样的明文每次加密出来不一样。

为什么必须不一样？以 CTR 和 GCM 为例：密钥流等于加密后的计数器。如果同一个密钥配同一个计数器，生成的密钥流就完全一样。

后果很严重：

• 两段密文异或，密钥流会互相抵消，直接得到两段明文的异或。英文文本的异或很容易被统计分析还原。
• GCM 下重复 nonce 更糟，攻击者可以伪造认证标签，等于完整性保护失效。

规则很简单：

• CBC 的 IV 要随机，且不可预测；不需要保密，但要每次不同。
• CTR 和 GCM 的 nonce 绝对不能在同一密钥下重复。常用做法是随机 96 位，或者用递增计数器。

现实中出过很多事故，根源都是"随机数生成器坏了"或"计数器重启归零"。这类 bug 从外部看不出来，但加密等于没做。

4.5非对称加密：两把钥匙

非对称加密（Asymmetric Encryption）有一对钥匙：公钥（Public Key）和私钥（Private Key）。

公钥可以公开给任何人，私钥只有自己知道。用公钥加密，只有私钥能解；用私钥签名，任何人都能用公钥验证。

像邮箱：投信口是公钥，谁都能往里塞信；取信口的钥匙是私钥，只有你能打开。

两种主流算法：

• RSA：安全性建立在大整数分解难题上。把两个大素数乘起来容易，反过来分解极难。
• ECC（Elliptic Curve Cryptography，椭圆曲线密码）：建立在椭圆曲线离散对数难题上。同样安全强度下，密钥短得多。

所以你会看到"RSA 2048 约等于 ECC 256"。密钥短的好处是握手快、证书小、手机省电。

非对称加密的代价是慢。RSA 加密比 AES 慢几个数量级，所以它不用来加密大量数据。

4.6混合加密：真正干活的是对称密钥

现实中的做法是混合加密（Hybrid Encryption）：用非对称加密只传一把临时对称密钥，之后所有数据都用对称加密。

步骤拆开看：

1. 客户端连上服务器，服务器出示证书，证书里含公钥。
2. 客户端验证证书，确认公钥真的是这家网站的。
3. 客户端生成一个随机的对称密钥，叫会话密钥。
4. 客户端用服务器公钥加密这个会话密钥，发过去。
5. 服务器用私钥解开，拿到会话密钥。
6. 之后双方用会话密钥做 AES-GCM 加密通信。

为什么这么设计？因为非对称加密慢，只用来传 32 字节的密钥很划算；对称加密快，用来传几 MB 的网页刚好。

这也是为什么"破解 TLS"实际上不是破解 AES，而是想办法拿到会话密钥：要么拿到服务器私钥，要么在客户端装证书，要么直接读进程内存。

4.7哈希：一台不可逆的榨汁机

哈希（Hash）把任意长度的输入，压成固定长度的输出。SHA-256 的输出永远是 256 位，也就是 32 字节。

最好的类比是榨汁机：苹果进去，果汁出来。你没法从果汁还原出苹果。

哈希有三个关键性质：

• 单向：给定输出，反推输入在计算上不可行。
• 抗碰撞：很难找到两个不同输入产生相同输出。
• 雪崩：输入改 1 个比特，输出大约一半的比特会变。

echo -n "hello" | sha256sum
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

echo -n "hellp" | sha256sum
输出完全不同，哪怕只改了一个字母

常见算法现状：

"已破解"的意思是能找到碰撞，不是能反推原文。但对签名、证书来说，能碰撞就足够伪造，所以必须换掉。

4.8HMAC：带密钥的哈希

哈希有个问题：谁都能算。攻击者改了数据，自己算一个新哈希附上，接收方照样验证通过。

解决办法是 HMAC（Hash-based Message Authentication Code，基于哈希的消息认证码）：把密钥混进哈希计算里。

HMAC(K, M) = Hash((K 异或 opad) 拼接 Hash((K 异或 ipad) 拼接 M))

不用记公式，只要知道：没有密钥就算不出正确的 HMAC。所以它同时提供完整性和认证。

和哈希的区别一句话：哈希防"意外损坏"，HMAC 防"有人故意改"。

注意：不要把加密和 MAC 混用同一个密钥，也不要用"哈希(密钥加消息)"这种土办法，长度扩展攻击可以绕过它。用标准 HMAC。

4.9KDF：为什么存密码不能只做一次 SHA-256

如果数据库存的是"密码的 SHA-256"，攻击者拿到库之后，可以每秒试几十亿个候选密码。因为 SHA-256 的设计目标就是快。

正确做法是用密钥派生函数（Key Derivation Function，KDF），故意把计算变慢、变占内存：

除了慢，还要加盐（Salt）：每个用户一个随机值，和密码一起哈希。这样同样的密码，存下来也不同，攻击者不能预先算一张大表。

参数选择的原则：让一次验证在你服务器上耗时约 100 毫秒，攻击者要试十亿次就得花几年。

4.10随机数：最容易被忽视的地基

所有密钥都来自随机数。随机数一旦可预测，密钥就等于公开。

两种随机数要分清：

• 普通伪随机：比如 C 语言的 rand()，种子固定就序列固定，只适合游戏和模拟，绝不能用来生成密钥。
• 密码学安全伪随机（Cryptographically Secure Pseudo-Random Number Generator，CSPRNG）：输出不可预测，即使知道前面的输出也推不出下一个。

历史教训很多：路由器用开机时间当种子，导致密钥可枚举；虚拟机克隆后随机数状态相同，两台机器生成同一对密钥；物联网设备第一次开机没有足够熵，密钥几乎是固定的。

实践规则：密钥、IV、盐、Token，一律用操作系统提供的 CSPRNG，比如 /dev/urandom、getrandom()、secrets 模块。不要自己写随机算法，不要用时间戳。

4.11国密算法：一句话认识

国内有一套自己的密码标准，统称国密（ShangMi，SM 系列）：

• SM2：非对称算法，基于椭圆曲线，用于签名和密钥交换，对标 ECDSA 和 ECDH。
• SM3：哈希算法，输出 256 位，对标 SHA-256。
• SM4：分组密码，块长和密钥都是 128 位，对标 AES-128。

在金融、政务、部分国内 App 里会见到。分析流量时如果看到 32 字节的摘要、128 位的分组，别默认是 SHA-256 和 AES，也可能是 SM3 和 SM4。

4.12三个必须记住的误区

第一个：Base64 不是加密。它没有密钥，只是编码，任何人可还原。上一章已经讲过原理。

第二个：加密不等于签名。加密只保证别人看不懂，不保证是谁发的，也不保证没被改。攻击者可以整段替换你的密文，接收方照样能解开，只是内容变了。

第三个：哈希不等于加密。哈希不可逆，加密可逆。用哈希存密码是对的，用哈希"加密"需要还原的数据是错的。

4.13一张表收尾

记住这张表，遇到"这个场景该用什么"的问题，先想它属于哪一行。

数字签名与证书：谁在证明这句话是你说的

加密能挡住偷看，却挡不住"改一个字"和"对面是假货"。这一页用蜡封、印模、身份证把签名、证书、证书链、吊销一路讲通，最后说清为什么"地址栏有锁"不等于"这个网站可信"。

5.1先分清：加密、哈希、签名是三件事

初学者最容易把这三个词混着用。它们解决的是完全不同的问题，用错地方就会得出完全错误的结论。

打个比方：加密是把信锁进保险箱，只有拿钥匙的人能打开；哈希是给信算一个指纹，指纹不能还原出信；签名是在指纹上盖一个只有你能盖的章。

一句话记住分工：加密管"看不懂"，哈希管"变了没有"，签名管"谁说的"。这三件事经常一起出现，但不能互相替代。

5.2蜡封：把签名的动作拆开看

中世纪的信封会用火漆封口，再盖上家族印章。收信人看到蜡封完整、印章对得上，就能得出两个结论：信没被拆过，而且确实出自那个家族。

数字签名就是把这件事搬到电脑上。私钥是你的印章，只有你有；公钥是印在名片上的印模，谁都能拿到。用私钥盖一次，全世界都能用公钥验，但没人能伪造。

注意图里两行：上面那行是签名方做的事，下面那行是任何拿到数据的人都能做的事。签名本身是一串字节，通常和原文一起发出去，或者单独放在请求头里。

长度要有概念：RSA-2048 的签名是 256 字节；Ed25519 只有 64 字节；ECDSA P-256 大约 70 到 72 字节。签名会明显增加报文体积，抓包时看到一段很长的 base64，往往就是它。

5.3为什么必须先哈希再签名

直接拿整份文件去做非对称运算，有两个硬伤。

• 太慢：非对称运算比哈希慢好几个数量级，签一个 1GB 的安装包要等到天荒地老。
• 装不下：RSA 一次能处理的数据长度受密钥长度限制，2048 位密钥只能处理几百字节以内的内容。

所以标准做法是：先对原文算一个哈希（比如 SHA-256，固定输出 32 字节），再对这 32 字节的摘要签名。验证时，对方也对原文算一次哈希，再和"用公钥解出来的摘要"比对。

哈希还有一个好处：把任意长度的内容压成固定长度，签名算法就不用关心原文有多长，实现起来简单，验证也快。

这也解释了为什么哈希算法必须选强的。MD5 和 SHA-1 已经被证明能人为制造碰撞（两份不同内容算出同一个值），现在做签名普遍要求 SHA-256 及以上。

5.4四种常见签名算法

你不需要懂数学，只要记住它们的取舍。四种算法的共同点只有一句：私钥签，公钥验。

"确定性"是指同样的原文和私钥，每次算出来的签名一模一样；"随机化"是指每次都不同，但都能验证通过。两者都安全，只是用途和兼容性不同。

选哪个？一般不用你选。协议和平台会规定好，比如 TLS 1.3 里 RSA 证书要求用 PSS，很多新系统默认 Ed25519。

5.5证书：把公钥和身份钉在一起

光有公钥还不够。攻击者完全可以把自己的公钥发给你，说"我是银行"。你怎么知道这把公钥真的属于银行？

答案是找一个大家都信的第三方，给你的公钥签个字。这张"签过字的纸"就是证书（Certificate），格式标准叫 X.509。

这里有个过时知识要纠正：很多老教程说"看 CN 字段里的域名"。现在浏览器只认 SAN（Subject Alternative Name，主体备用名）扩展里的域名列表，CN 早就不参与域名匹配了。抓包看证书时，重点看 SAN。

5.6证书链：浏览器一级一级往上验

证书不是凭空签出来的，它本身也是被上一级 CA 签的，于是一条接一条，形成证书链（Certificate Chain）。

浏览器从服务器证书开始，逐级用上一级的公钥验证签名，一直验到本机信任库里的根证书。根证书是自签名的，靠操作系统和浏览器预装来"无条件信任"。这也解释了为什么根证书数量很少：它是整个体系的锚点。

完整验证清单，缺一不可：

• 每一级签名都对得上，用上一级的公钥验下一级；
• 当前时间在有效期内，没有过期也没到生效时间；
• 访问的域名出现在 SAN 里，通配符范围匹配；
• 用途正确，服务器证书不能拿来签代码；
• 没有被吊销，这一步经常是"尽力而为"；
• 根证书在本机信任库里，并且没有被用户手动移除。

5.7吊销、私有 CA 与"合法中间人"

证书有有效期，但私钥可能提前泄露，需要"提前作废"。业界有三种做法。

CRL 是 CA 定期发布一张"作废名单"，客户端把整张表下载下来自己比对。证书多了以后，这张表会非常大。

OCSP 是拿着证书序列号实时问 CA"这张还有效吗"。快，但多一次网络往返，而且等于告诉 CA"我正在访问这个网站"，隐私上有代价。

OCSP Stapling 是服务器替你去问，把 CA 的答复（带时间戳）在 TLS 握手时一起发给你。省一次请求，也不泄露你的访问记录。代价是服务器要自己维护这份答复。

5.7.1 自签名、企业私有 CA 和抓包代理

这三种场景经常被混为一谈，其实动机完全不同：

• 自签名：自己给自己签，测试环境常见，浏览器会红，但开发时够用。
• 企业私有 CA：公司自建根证书，装进员工电脑和手机，用于内部系统，方便统一管理。
• 抓包代理：Charles、Fiddler、mitmproxy 这类工具会生成自己的 CA。你把它装进手机并设为信任，它就能给任何网站现场签一张证书。

原理不复杂：手机以为自己在和服务器说话，其实是在和代理说话；代理再用真实身份去连服务器。中间人之所以能看懂内容，是因为你把信任交给了它。

平台差异很关键：Android 7 以后，App 默认不信任用户自己安装的证书；iOS 需要在"关于本机"里找到"证书信任设置"，手动打开完全信任。这就是为什么"证书装了，包还是抓不到"。

反过来，App 也会用证书固定（pinning）来防这一手：只认自己写死的那张证书或那把公钥，换了就不连。攻防就在这一层反复拉锯。

5.8代码签名：安装包也要盖章

你下载的 APK、IPA、EXE 本质上都是"代码"，同样需要证明"没被改过、是谁发的"。否则任何人往里塞一段恶意代码，用户根本看不出来。

Android 的 v1 方案只签每个文件的摘要，安装时逐个校验，历史上出过漏洞；v2 改成对整个安装包做一次签名，校验快、覆盖全；v3 增加了换密钥的能力，方便密钥泄露后平滑过渡。

iOS 更严格：证书由苹果签发，还要配描述文件，绑定 Bundle ID、权限和设备列表。所以"重签名"在 iOS 上是个专门的技术活，不是改个文件就行。

Windows 的 Authenticode 会给签名加一个时间戳。这样即使证书过期，之前签过的程序仍然有效，不会因为证书到期就全部失效。

5.9四个常见误区

• 以为签名能保密：签名不隐藏内容，明文照样能读。要保密得另外加密。
• 以为有证书就可信：钓鱼站也能申请到合法证书。证书只证明域名归属，不证明内容善意。
• 以为签名能防重放：签名不绑定时间，原样再发一次照样验通过。要配合时间戳、随机数和服务端去重。
• 以为哈希就是签名：哈希谁都能算，没有身份含义，谁都能伪造一个"看起来对"的哈希。

把这四点想清楚，你在抓包里看到签名、证书、指纹时，就不会再把它们当成同一件事。

TCP 与 UDP：可靠到底是怎么做到的

很多人背过"TCP 可靠、UDP 不可靠"，但说不出可靠是靠什么换来的。这一页用打电话、寄明信片、编号回执、路口限流，把握手、挥手、重传、粘包、NAT 一次讲透，最后告诉你为什么抓包里会出现 RST 和零窗口。

6.1打电话和寄明信片

传输层要解决的是"两台机器上的两个程序怎么对话"。最常用的两套方案，思路完全相反。

TCP 像打电话：先拨号，等对方接起来，确认双方都能听见，再开始说；说的时候对方会"嗯"一声表示收到；没听清就让他重复。挂电话也要互相确认。

UDP 像寄明信片：写好地址投进邮筒，不确认对方收没收到，也不保证顺序。便宜、快，但可能丢、可能后发的先到。

注意最后一行：QUIC 跑在 UDP 上，但它自己在应用层把可靠性做回来了。所以"UDP 不可靠"说的是协议本身不负责，不是说用了它就一定丢数据。

6.2三次握手：为什么不能是两次

建立连接要交换三句话。核心目标只有一个：双方都要确认"我发的能到、你发的能到"。

为什么两次不行？服务器发完 SYN-ACK 就单方面认为连接建立了，但它并不知道这个包有没有送到客户端。如果客户端根本没收到，服务器就白建了一条连接，还占着内存。

更麻烦的是旧包。网络里可能残留很久以前发出的重复 SYN，如果只握两次，服务器会被这些过期请求骗出一堆无效连接。三次握手能让这种老包自然失效。

还有一个细节：起始序号（ISN）是随机选的，不是从 0 开始。这样攻击者更难猜到下一个序号，也更难伪造报文。

抓包里看到 SYN、SYN-ACK、ACK 三行，就是一次成功的握手；只看到 SYN 后面跟着 RST，通常是端口没开，或者被防火墙直接拒绝。

6.3四次挥手与 TIME_WAIT

关闭连接要四句话，因为 TCP 是全双工的：两个方向要各自关一次。你说"我不发了"，不代表对方也发完了。

主动关闭的一方最后要进入 TIME_WAIT，等 2 倍报文最大生存时间。这个等待不是浪费，它有两个明确作用：

• 万一最后那个 ACK 丢了，对方重发 FIN 时，还能再回一次，不至于让对方一直卡着；
• 让这条连接的旧报文在网络里彻底消失，避免污染下一条恰好用了相同端口的新连接。

服务器上出现大量 TIME_WAIT 是正常现象，不是"连接泄漏"。真正需要担心的是本地端口被占满，导致新连接建不起来。

6.4编号、回执和窗口

TCP 把数据看成一条很长的字节流，每个字节都有编号。发送方说"我从 1001 号开始给你 500 字节"，接收方回"1001 到 1500 收到，下一条我要 1501"。

这个"下一条我要第几号"就是确认号（ACK）。它是累积的：确认了 1501，就代表 1501 之前的全部收到，不用一条条确认。

窗口（Window）是接收方的缓冲区还剩多少空间。窗口变成 0，发送方就必须停下来等，这就是抓包里的"零窗口"。

这三样合起来就是可靠传输的骨架：编号让接收方能排序和去重，确认让发送方知道哪些到了，窗口让发送方别把接收方撑爆。丢包、乱序、重复，都靠这套机制兜住。

6.5重传与拥塞控制

丢包了怎么办？等。等多久？根据往返时间动态估算，这个等待时间叫 RTO。超时还没收到确认就重传，而且每次超时等待时间翻倍，避免把已经堵死的链路砸得更烂。

还有一种更快的办法：如果连续收到三个重复的确认，说明中间缺了一段，不用等超时，立刻重传缺的那段。这叫快重传，能让恢复从"秒级"降到"毫秒级"。

拥塞控制像路口限流。发送方维护一个"拥塞窗口"，开始时很小，每收到确认就涨一点（慢启动阶段实际是每轮翻倍），摸到上限后改成缓慢增长（拥塞避免）；一旦检测到丢包，就把窗口砍半，退回去重新试探。

现代系统常用 CUBIC 或 BBR 这类算法。你不需要记公式，只要记住一句话：TCP 会主动试探带宽上限，一丢包就退让。

6.6粘包与拆包：TCP 是字节流，不是消息流

这是初学者最容易被坑的地方。你调了两次发送，对方不一定读两次；你发了一条完整消息，对方可能只读到一半。

你写了两次，可能被合成一次读到（粘包）；也可能一次写入被拆成两半（拆包）。这跟"TCP 可靠"不矛盾：字节一个没少，只是边界没了。

解决办法都在应用层，常见三种：

• 定长：每条消息固定长度，不够就补齐，简单但浪费；
• 分隔符：用换行或特殊字符分隔，HTTP 头就是用空行结束的；
• 长度前缀：先发 4 字节表示后面有多长，再发内容，最通用，很多私有协议都这么干。

6.7选项、UDP 与 QUIC

TCP 头里有一块"选项"区域，用来协商一些增强能力。抓包时展开它，经常能看到问题所在。

UDP 的头只有 8 字节，没有握手、没有确认、没有重传。它把"要不要可靠"的决定权交给应用。DNS 查询、视频通话、游戏同步都用它，因为丢一帧比卡一秒更能接受。

QUIC 是把可靠性做进用户态的一次重做：它跑在 UDP 上，自己实现重传、流控、加密（内置 TLS 1.3）和多路复用。好处是升级不用等操作系统和中间设备，坏处是很多网络设备看到的就是一堆 UDP 包，可能被限速或拦截。

QUIC 还顺手解决了 TCP 的一个老毛病：一条连接里所有数据共享同一个字节流，丢一个包会卡住后面所有数据（队头阻塞）。QUIC 的每条流独立，丢包只影响自己那条。

6.8五元组、NAT 与抓包排错

一条 TCP 连接由五元组唯一确定：源 IP、源端口、目的 IP、目的端口、协议。抓包工具就是靠这五项，把杂乱的包归到不同连接里。

你家所有设备共用一个公网 IP，靠 NAT 区分：路由器改写源端口，维护一张"内网地址端口"到"公网端口"的对照表。表项有超时，太久没流量就被回收，回收后再来包就对不上了。

抓包时三种信号最值得看：

把这句话记牢，你在排查"用户说没收到"这类问题时，就不会只盯着网络层了。

DNS 与 HTTP 家族：从域名到页面的每一跳

你在地址栏敲下域名到看见页面，中间至少经过一次域名查询、一次 TCP 握手、一次 HTTP 请求、若干次缓存判断。这一页把这条链路上的每一跳拆开，告诉你 301 和 302 差在哪、304 为什么没有正文、HTTP/2 到底解决了什么又没解决什么。

7.1第一跳：把域名换成 IP

你在地址栏输入 example.com 回车。第一件事不是发 HTTP，而是问"这个域名对应哪个 IP"。因为网络只认 IP，不认名字。

查询顺序是逐级往上的：浏览器缓存、系统缓存（含 hosts 文件）、递归解析器、根服务器、顶级域服务器、权威服务器。任何一级命中就直接返回，后面的都不用问。

递归解析器通常是运营商或公共 DNS 提供的。它替你把整条链路跑完，然后把结果缓存一段时间，这个时间就是 TTL。所以同一个域名第二次访问，往往一个包都不用发。

7.2记录类型、TTL 与 DNS 安全

DNS 不是只有"域名换 IP"一种记录。不同类型的记录，管的是不同的事。

TTL 是"这条记录能缓存多少秒"。TTL 设得很长，改 IP 后要等很久才全网生效；设得很短，解析压力大。常见做法是切换前先把 TTL 调短，切完再调回去。

DNS 天生是明文的，早期也没有验证机制，所以能被污染：中间人抢先返回一个假 IP，你的请求就去了别人的服务器。DNSSEC 用签名保证"这条记录确实来自权威服务器"，但它不加密，别人仍然能看到你在查什么。

DoH（DNS over HTTPS）和 DoT（DNS over TLS）把查询塞进加密通道，解决"被偷看、被篡改"的问题。代价是：企业内网的 DNS 审计会失效，所以很多公司会主动禁用它。

7.3第二跳：HTTP 报文长什么样

拿到 IP、建好连接之后，才轮到 HTTP 出场。HTTP 是"一问一答"的文本协议，请求分三块：起始行、头、空行、体。

起始行：方法 + 路径 + 版本
GET /index.html HTTP/1.1

请求头：一堆说明
Host: example.com
User-Agent: MyApp/8.2.1 (Android 14)
Accept: text/html
Cookie: session=abc123

空行之后是请求体，GET 一般没有体

响应也一样：状态行、头、空行、体。

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 132
Cache-Control: max-age=600
ETag: "a1b2c3"

空行之后是正文，这里是 132 字节的 HTML

那个空行不是装饰，它是"头结束、体开始"的分界。少了它，对方会一直等更多的头，最后超时。

Content-Length 和 Transfer-Encoding 是二选一的关系。分块传输适合"边生成边发"的场景，比如大文件下载、流式输出，因为发送前根本不知道总长度。

7.4状态码：三位数里的信息

状态码的第一位决定大类。记住大类，再看具体数字，就不会慌。

重点记这几个，够用八成场景：

• 200：成功，响应体里有业务数据；
• 301：永久重定向，会被缓存，搜索引擎会更新地址；302 是临时重定向，不缓存；
• 304：内容没改过，用你本地的缓存，响应没有体；
• 400：请求格式错了；401 没认证或凭证失效；403 认证了但没权限；404 找不到；
• 429：请求太频繁，通常带 Retry-After 告诉你等多久；
• 500：服务端代码出错；502 网关拿到上游的坏响应；503 服务暂时不可用；504 网关等上游超时。

7.5Cookie 和 Session 到底谁存什么

HTTP 本身是无状态的：服务器不记得上一次是谁来过。要让"登录状态"延续，需要额外的东西。

Cookie 是存在浏览器里的一小段文本，每次请求自动带上。Session 是存在服务器上的一份数据，浏览器只保存一个编号（Session ID）。

Cookie 有几个关键属性要认识：

• HttpOnly：脚本读不到，降低被注入脚本窃取的风险；
• Secure：只在 HTTPS 下发送，防止明文链路泄露；
• SameSite：限制跨站携带，防跨站请求伪造，常见值 Lax 和 Strict；
• Domain 和 Path：决定哪些请求会带上它。

7.6HTTP/2：一条连接跑多个请求

HTTP/1.1 最大的问题是：一条连接同一时刻只能处理一个请求。浏览器只能开六条左右的连接来并行，开太多又浪费资源。

HTTP/2 把报文改成二进制分帧：把每个请求和响应切成小帧，打上"流编号"，然后在一条连接上交错发送。接收方按流编号重组。这就是多路复用。

它还做了两件事：HPACK 压缩头部（把重复的头字段放进表里，只发索引），以及服务器推送（服务端主动推资源，实际用得很少，主流浏览器已经移除）。

但 HTTP/2 仍然跑在 TCP 上。TCP 丢一个包，后面所有流的数据都要等它重传，这叫 TCP 层队头阻塞。HTTP/2 只解决了 HTTP 层的排队问题。

7.7HTTP/3 与缓存控制

HTTP/3 直接换成 QUIC（跑在 UDP 上）。它把 TLS 1.3 内置进握手，首次连接一个往返，恢复连接可以做到 0-RTT：客户端拿着上次的票据，第一个包就能带数据。

0-RTT 有代价：这些早期数据可能被重放。所以只应该用于幂等请求，比如读取，不能用于"转账"这种操作。

QUIC 用连接 ID 而不是四元组标识连接。你从 Wi-Fi 切到移动网络，IP 变了，连接还能继续，这叫连接迁移。

缓存这块，重点是三个响应头：

浏览器再次请求时会带 If-None-Match（对应 ETag）或 If-Modified-Since。服务器发现内容没变，就回 304，不传正文，省流量也省时间。

no-store 是完全不缓存；no-cache 是"可以存，但每次必须回源确认"。这两个词经常被搞反，配置错会导致该更新的不更新、该省流量的不省。

7.8代理、CDN 与三个误区

正向代理代表客户端，反向代理代表服务器。CDN 是部署在各地机房的反向代理集群，把静态资源放在离用户最近的地方。

用了代理和 CDN 之后，源站看到的 IP 往往是代理的。所以会有 X-Forwarded-For 这类头来传递真实客户端 IP。这个头由客户端和代理逐跳追加，可以被伪造，做风控时不能单独信它。

最后是三个必须纠正的误区：

• HTTP/2 一定比 1.1 快：不一定，见上一节，丢包严重时反而更糟；
• 200 就代表业务成功：很多系统把错误放在响应体里，HTTP 照样回 200，判断业务要看体里的 code 字段；
• HTTPS 就安全：HTTPS 只保证传输这一段，服务端漏洞、越权、注入它一概不管。

TLS 深入：握手、密钥与加密记录

浏览器地址栏那把小锁，背后是一套跑了三十年的协议。这一页把它拆成四件事：怎么谈、怎么算钥匙、怎么装信封、怎么证明身份。看懂之后，抓包里那些看不懂的握手包就有了名字。

8.1它到底在防谁

先想一个场景：你在咖啡店连公共 WiFi，打开网页输入账号密码。这条链路上有多少人能复制你的数据？

至少五六个：你的手机、店里的路由器、运营商、中间经过的机房。任何一环都能录一份。

TLS（Transport Layer Security，传输层安全）做的事，就是在这条路上临时修一条管道。管道外面的人只能看到"有数据在流"，看不到里面是什么。

它只解决三个问题，不多不少：

• 机密（Confidentiality）：别人看不懂。靠加密。
• 完整（Integrity）：别人改不了。改一个字节，接收方就会发现。
• 身份（Authentication）：对面真的是它。靠证书。

拿寄合同打比方：

• 不加密，等于寄明信片，路上谁都能读；
• 加密，等于装进保险箱；
• 完整性，等于保险箱贴封条，被撬过就有痕迹；
• 身份，等于对方出示营业执照，确认不是隔壁老王冒充。

8.2TLS 1.2 握手：两个来回

握手（Handshake）就是开场谈判。双方要在这几步里完成四件事：交换随机数、确认算法、验证身份、算出钥匙。

RTT（Round Trip Time，往返时延）指"一句话发出去再收到回复"要多久。手机 4G 下通常 30 到 80 毫秒，跨洋可能 200 毫秒以上。

TLS 1.2 的完整握手需要 2 个 RTT。也就是说，在你看到网页之前，光握手就多花了两个来回。

逐条看这十条消息在说什么：

• ① ClientHello：客户端说"我支持这些算法，这是我的随机数 A，我要访问 example.com"。
• ② ServerHello：服务器从清单里挑一个双方都支持的算法，给出随机数 B。
• ③ Certificate：服务器把证书链发过来，证明"我是 example.com"。
• ④ ServerKeyExchange：用 ECDHE 时，服务器给出一个临时公钥，并用证书私钥签名。
• ⑤ ServerHelloDone：服务器表示"我这边说完了，轮到你"。
• ⑥ ClientKeyExchange：客户端给出自己的临时公钥。双方各自算出同一个共享秘密。
• ⑦⑧：客户端发 ChangeCipherSpec 和 Finished，表示"接下来我加密，这是校验值"。
• ⑨⑩：服务器同样回两条，握手结束，开始传业务数据。

Finished 里装的是"前面所有握手消息的摘要"。任何一条被改过，摘要就对不上，握手立刻失败。这是防篡改的最后一道闸。

8.3三个随机数与密钥派生

很多人以为 TLS 只用一把钥匙。实际上，握手阶段产生了三份关键材料：

为什么需要两个随机数，而不是一个？

因为随机数的作用是"加盐"。假如只有预主密钥，同一对客户端和服务器每次算出来的会话密钥都一样。攻击者录下今天的密文，明天偷到钥匙，就能解开昨天的全部记录。

加入两个随机数之后，每一次连接算出来的钥匙都不同。昨天的密文，今天解不开。

那为什么还要预主密钥？因为随机数是公开传的，光有它没有秘密。预主密钥才是只有双方知道的那部分。

协商预主密钥有两种方式，差别很大：

• RSA 密钥交换（老）：客户端生成预主密钥，用服务器证书里的公钥加密后发过去。缺点是谁录下了流量，将来只要拿到服务器私钥，就能解开全部历史记录。这叫没有前向保密。
• ECDHE（椭圆曲线临时迪菲-赫尔曼）：双方各生成一对临时密钥，交换公钥，各自算出同一个共享秘密。临时私钥用完就扔。即使服务器私钥泄露，也解不开过去的流量。这就是前向保密（Forward Secrecy）。

现在几乎所有正规站点都用 ECDHE。看到"没有前向保密"这个词，基本等于"这套配置已经过时"。

PRF（Pseudo-Random Function，伪随机函数）像一个搅拌机：把秘密、标签、随机数一起打碎，输出指定长度的字节。它单向、不可预测，同样的输入永远得到同样的输出。

为什么要分"客户端一份、服务器一份"？

因为如果两个方向用同一把钥匙，攻击者可以把客户端发出去的密文原样发回给客户端，让它自己解密自己。这叫反射攻击。分开之后，方向不对就解不开。

8.4TLS 1.3 改了什么

TLS 1.3 不是小修小补，是一次大扫除。它做了四件事：

0-RTT 是 1.3 最诱人也最危险的功能。客户端如果之前连过，可以拿着上次的票据（ticket），在第一个包里就带上"早期数据"（Early Data）。省掉一整个往返，代价是：这些早期数据可以被攻击者原样重放。

所以规范要求：0-RTT 只能用于幂等请求，比如 GET 查询。不能用于转账、下单、改密码。

8.5记录层：AEAD、nonce 与重放

握手只是开场。真正传数据的是记录层（Record Layer）。它把上层的数据切成一块块，每块加上头和认证标签。

TLS 1.3 的记录结构非常简单：

AEAD（Authenticated Encryption with Associated Data，带关联数据的认证加密）是一类算法，一次调用同时完成"加密"和"防篡改"。常见的有 AES-GCM 和 ChaCha20-Poly1305。

它需要三样输入：明文、密钥、nonce。nonce 是"一次性数字"，同一把钥匙下绝不能重复。

TLS 1.3 的 nonce 怎么来？把静态 IV 和序列号做异或。

• 静态 IV 是握手时派生出来的 12 字节，双方都知道；
• 序列号从 0 开始，每发一条记录加一，不放在网络上，双方各自维护；
• 异或之后得到本次使用的 nonce。

为什么这样能防重放？

因为同一条连接里序列号只增不减。攻击者把第 5 条记录再发一次，接收方按第 8 条去解，nonce 对不上，认证标签校验失败，直接丢弃。跨连接呢？每条连接的钥匙都是新算的，旧密文在新连接里根本解不开。

8.6证书怎么验、SNI、ALPN、ECH 与会话恢复

拿到证书不等于信任。客户端至少要做四道检查：

还有两件常被忽略的事：

• 用途：证书要标着"可用于服务器认证"（EKU serverAuth），否则不能拿来当网站证书。
• 吊销：证书可能被提前作废。检查方式有 CRL（下载黑名单）和 OCSP（在线问一句）。现实中很多客户端采用"软失败"，查不到就放行，所以吊销并不总是可靠。

接下来三个缩写，各自解决一个具体麻烦。

SNI（Server Name Indication，服务器名称指示）解决"一个 IP 上放很多网站"的问题。客户端在 ClientHello 里明说"我要访问 example.com"，服务器据此挑对应的证书。代价是：SNI 是明文，旁观者能看出你访问了哪个站点。

ALPN（Application-Layer Protocol Negotiation，应用层协议协商）解决"谈完 TLS 之后说什么协议"。浏览器列出 h2、http/1.1，服务器挑一个。没有它，双方只能退回 HTTP/1.1。

ECH（Encrypted Client Hello，加密客户端问候）解决 SNI 泄露。做法是把真正的 ClientHello 包在一个外层 ClientHello 里加密，公钥从 DNS 的 HTTPS 记录里取。中间人只能看到外层那个假域名。

会话恢复是为了省掉重复的握手。老办法有两种：

• Session ID：服务器记住会话状态，给客户端一个编号。缺点是服务器要存东西，机器一多就难同步。
• Session Ticket：服务器把状态加密后交给客户端保管，下次带回来。服务器不用存，但票据本身要保护好。

TLS 1.3 统一用 PSK 票据，0-RTT 就是建立在它之上的。

8.7攻击面与抓包可见性

下面只讲原理，不讲操作。

中间人攻击（Man-in-the-Middle）稍微不同：攻击者站在中间，两边各建一条 TLS。它能成功的前提只有一个——客户端信任了攻击者的证书。

那抓包到底能看到什么？

如果拿到会话密钥，比如浏览器导出的 keylog 文件，Wireshark 就能解密。这就是第 10 章要讲的事。

8.8三个常见误区

误区一：HTTPS 就一定安全。

小锁只代表"这条连接是加密的、证书链是通的"。钓鱼站、诈骗站一样能用免费证书。安全与否要看对面是谁、你输出了什么。

误区二：TLS 1.3 的 0-RTT 没有风险。

0-RTT 数据可以被重放。同一个"下单"请求被重放十次，可能就下十单。所以服务端必须只对幂等操作开放 0-RTT。

误区三：证书有效就代表网站正规。

域名验证型（DV）证书几分钟就能自动签发，只证明"你控制了这个域名"，不证明公司真实存在。要判断主体，得看组织验证（OV）或扩展验证（EV）证书，而这两类现在也很少被浏览器特殊展示。

序列化格式：JSON 之外的二进制世界

同样一句"张三二十岁"，可以写成一张表、一封信，也可以写成一段只有约定好的人才能读的密码。这三种写法就是序列化的三个流派。看懂它们的取舍，你才能在抓包里认出那堆字节到底是什么。

9.1序列化：把一张表变成一串字节

先做一个思想实验。你要把"张三，20 岁，VIP"这条信息发给另一台电脑，有几种写法？

• 写成表格：一行三列，谁都看得懂，但占地方。
• 写成一封信：有称呼、有格式、有落款，啰嗦但清楚。
• 写成一段密码：最短，但只有事先约好暗号的人能读。

这三种写法，分别对应今天要讲的三个流派：文本格式、标记语言格式、二进制格式。

为什么不能直接把内存里的东西发过去？两个原因：

• 不同机器存同一个数字的字节顺序可能相反，这叫字节序（Endianness）。
• 内存里有"指针"这种东西，它记录的是本机地址，换台机器就完全失效。

所以必须先翻译成一套双方都认的中间形式，这个过程就叫序列化（Serialization），反过来叫反序列化（Deserialization）。

评价一种格式，看四个指标：可读性、体积、解析速度、跨语言支持。它们没法同时最优。

9.2JSON：最好读，也最容易踩坑

JSON（JavaScript Object Notation）只有六种值：对象 {}、数组 []、字符串 ""、数字、true / false、null。就这么点，所以谁都能在十分钟内学会。

{
  "user": {
    "name": "张三",
    "age": 20,
    "tags": ["vip", "new"]
  },
  "ok": true
}

好读是优点，但下面四个坑，几乎每个新手都会踩一次。

坑一：数字精度

JSON 规范没有规定数字用几位存。绝大多数语言的解析器把它读成 IEEE 754 双精度浮点数。这种格式能精确表示的整数上限是 2 的 53 次方，也就是 9007199254740992。

超过这个范围，末尾就开始丢。比如 9007199254740993 读进来会变成 9007199254740992。

小数更明显。0.1 加 0.2，在 JSON 里序列化出来是 0.30000000000000004。这不是 JSON 的错，是浮点数的错，但 JSON 把它暴露在你面前。

坑二：重复键

{"a":1,"a":2} 是合法 JSON。不同解析器的行为不一样：多数保留最后一个，有的保留第一个，有的直接报错。

这个差异可以被利用。安全设备看到的是第一个值，后端业务代码用的是最后一个值，两边判断不一致，这叫参数污染。写接口时，遇到重复键应该直接拒绝，而不是默默取一个。

坑三：注释和尾逗号

标准 JSON 不允许注释，也不允许最后一项后面多一个逗号。JSON5、JSONC 是扩展语法，配置文件里常见，但接口里别混用。

坑四：看起来像数字的字符串

"1e3" 带引号是字符串，1e3 不带引号是数字 1000。很多解析器对科学计数法的处理还有细微差别。跨语言传数据时，能写清楚就别用简写。

9.3XML 与 XXE

XML（Extensible Markup Language，可扩展标记语言）用标签嵌套表达结构。它比 JSON 啰嗦，但多出三样东西：属性、命名空间、DTD。

<order id="1001">
  <item sku="A-01">键盘</item>
  <price currency="CNY">199</price>
</order>

命名空间（Namespace）解决"两个不同的 title 打架"的问题。用 xmlns 声明前缀，前缀不同的标签就是不同东西。这在拼接多个系统时非常必要。

DTD（Document Type Definition，文档类型定义）是更老的一套约束语法，可以声明元素、属性，也可以声明实体。问题就出在实体上。

XXE（XML External Entity，XML 外部实体）的原理只有一句话：DTD 里的实体可以指向外部资源，解析器会主动去取。

<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<foo>&xxe;</foo>

解析器读到 &xxe; 时，会去读那个文件，把内容填进来。如果解析结果被回显，攻击者就读到了服务器文件。把 file 换成 http 地址，还能让服务器替你发请求，也就是 SSRF。

防护很直接：解析时禁用 DTD、禁用外部实体、禁用外部 DTD；用带安全默认值的解析库；不要用 XML 承载不可信输入。三条里做到第一条，绝大多数 XXE 就没了。

9.4Protobuf：字段编号才是身份

Protobuf（Protocol Buffers）是 Google 的二进制格式。核心思想：双方先约定一份 .proto 文件，写清字段名和编号，编译成代码。传输时只传编号和值，不传字段名。

message Login {
  string username = 1;
  int32  age      = 2;
  bool   vip      = 3;
}

编码规则一：varint。每个字节用低 7 位存数据，最高位表示"后面还有没有"。

• 150 的二进制是 10010110，拆成 7 位一组：0010110 和 0000001。
• 低位组在前，每个字节补上延续位：0x96 0x01。
• 所以 150 只占 2 字节，而不是 4 字节。小数字特别省。

编码规则二：tag。每个字段前面有一个 tag 字节，算法是：tag = 字段编号 左移 3 位，再或上线类型（wire type）。

拿 username="abc"、age=150 举例：

• 字段 1 是字符串，tag = (1 左移 3) 或 2 = 0x0A；长度 0x03；内容是 61 62 63。
• 字段 2 是 int32，tag = (2 左移 3) 或 0 = 0x10；值是 96 01。
• 完整字节：0A 03 61 62 63 10 96 01，一共 8 字节。

向后兼容规则，这几条必须背下来：

• 字段编号一旦发布就不能改，也不能复用。删掉的编号要写进 reserved，防止后人误用。
• 可以新增字段，老程序会忽略不认识的编号，不会报错。
• 不能把 int32 改成 string，线类型变了就解不出来。
• 1 到 15 号字段的 tag 只占 1 字节，留给最常用的字段。

9.5MessagePack 与 CBOR

这两个可以理解为"二进制版 JSON"：不需要 .proto，自己带类型信息，所以拿到字节就能解，但体积比 Protobuf 大一点。

CBOR（Concise Binary Object Representation）是 IETF 的标准，物联网和 COSE 体系里常见。MessagePack 在缓存、消息队列、游戏后端里用得多。

9.6Thrift、Avro 与两种表单编码

Thrift：Facebook 出身，自带 RPC 框架，用 IDL 定义服务和数据结构，一次生成多语言代码。定位是"协议加远程调用一整套"。

Avro：Hadoop 生态出身，特点是 schema 随数据一起存，读的时候用写入方的 schema 解释。适合大数据批处理和历史数据兼容。

再说网页表单。它有两种编码，很多人只知道第一种。

• application/x-www-form-urlencoded：拼成 a=1&b=2，特殊字符做百分号编码，空格变成加号。只能传文本。
• multipart/form-data：用一段 boundary 分隔多个部分，每部分有自己的头，可以传二进制。文件上传必须用它。

抓包时看到 Content-Type 是哪一个，就知道该用哪种方式去解析请求体。

9.7自定义二进制协议怎么设计

很多 App 不用现成格式，自己定一套。典型结构长这样：

每个字段都有理由：

• magic：固定几个字节，用来一眼判断"这是不是我的包"。抓错端口时能立刻发现。
• 版本：以后改协议时，老客户端还能被识别出来。
• 标志位：一位表示是否压缩，一位表示是否加密，省得再加字段。
• 类型：这条消息是登录、心跳还是拉数据。
• 长度：告诉对方 payload 有多少字节。
• 序列号：对应答、防重放、排查丢包。
• 校验和：CRC32 之类，快速发现传输错误。

9.8怎么认出一个未知格式

拿到一段来路不明的字节，按这四步走，通常十分钟内能定性。

还有两个小技巧：看有没有规律重复的字节（可能是分隔符），看末尾是不是固定长度的一段（可能是校验值）。多个包一起看，比盯着一个包有效得多。

9.9两个必须记住的误区

误区一：JSON 字段顺序不重要，所以签名时也不用管顺序。

JSON 对象在语义上确实无序，但签名是对字节做的。序列化时字段顺序一变，字节就变，签名就对不上。所以签名前必须约定规范化规则：键按字典序排、去掉多余空格、数字格式统一、Unicode 转义统一。这类约定通常叫规范化（Canonicalization）。

误区二：Protobuf 字段名改了没关系，反正传的是编号。

前半句对，后半句对，但结论危险。字段名确实不上线，改名不影响兼容。可是字段编号绝对不能改、不能复用。改了编号，老客户端会把新字段当成另一个字段解析，数据直接错位，而且不会报错，只会静默出错。

抓包与工具链：先看得见，才谈得上分析

分析协议的第一步不是读代码，是先把流量完整地看见。这一页讲清楚抓包发生在哪三个位置、每件工具适合干什么、为什么装了证书还是抓不到，以及一条从"打不开网页"到"证书固定"的排查路线。

10.1抓包的三个位置

流量从手机到服务器，一路上有很多个"可以下手"的点。按距离远近，分成三类。

10.2tcpdump：最基础的命令行抓包

tcpdump 几乎每台 Linux 都自带。它没有界面，输出是一行行文本，但正因为轻，服务器上排查问题首选它。

过滤表达式用的是 BPF 语法，写在命令最后，用单引号包住：

# 只抓和某台服务器有关的 443 流量，存成文件
tcpdump -i any -nn -s 0 -w cap.pcap 'tcp port 443 and host 203.0.113.10'

# 排除噪音：不要 SSH，不要 DNS
tcpdump -i any -nn 'not port 22 and not port 53'

# 只看带数据的包，过滤掉纯 ACK
tcpdump -i any -nn -A 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

最后那条看着吓人，其实只做一件事：算出这个包里实际有多少字节的应用数据，大于 0 才显示。纯确认包不带数据，就被过滤掉了。

10.3Wireshark：把包拆开看

Wireshark 是图形化的协议分析器。它的核心不是"抓"，而是"拆"和"筛"。

先分清两套过滤器：抓包过滤器（Capture Filter）在抓之前生效，语法和 tcpdump 一样；显示过滤器（Display Filter）在抓之后生效，功能强得多，能按协议字段筛。

三个必须会用的操作：

• Follow TCP Stream：右键任意一个包，选它，就能把这条连接的双向数据按顺序拼起来。看 HTTP 请求响应最快的方法。
• Statistics 里的 Conversations：一眼看出谁和谁通信最多、各传了多少字节。找"可疑外连"从这里开始。
• Expert Information：自动标出重传、乱序、握手失败。很多"网络慢"的问题，答案在这里。

Wireshark 还能解密 TLS，前提是你有会话密钥。浏览器和部分程序支持把密钥写进一个环境变量指定的文件（常叫 SSLKEYLOGFILE），在 Wireshark 的 TLS 协议设置里填上这个文件路径，就能看到明文。

10.4代理为什么能解密

代理（Proxy）的本质是中间人：客户端以为在跟服务器说话，其实在跟代理说话；服务器以为在跟客户端说话，其实也在跟代理说话。

把过程拆成六步：

• 客户端配置了代理地址，比如 127.0.0.1:8080。
• 访问 HTTPS 前，客户端先发一条 CONNECT example.com:443，请求开一条隧道。
• 代理回 200，隧道建立。此时还只是裸 TCP。
• 客户端在隧道里发起 TLS 握手，它以为对面是 example.com。
• 代理当场生成一张 example.com 的证书，用自己 CA 的私钥签，发给客户端。
• 客户端验证签发者：如果用户装过代理的 CA，就通过。握手完成，代理拿到明文。

代理再和真服务器建一条独立的 TLS。于是链路上有两段加密，而代理手里同时握着两把钥匙。

关键点只有一句：客户端必须信任代理的 CA。否则第 5 步就会报证书错误，连接直接断开。

10.5mitmproxy、Charles、Fiddler 怎么选

选型不用纠结：手工看几个请求，Charles 最快；要写脚本批量处理、做自动化，mitmproxy 更合适；只在 Windows 上临时用，Fiddler 够。

10.6Android 的两套证书，以及 Android 7 的分水岭

Android 里有两个证书库，地位完全不同：

• 系统证书：预装在系统分区里，出厂就有，普通应用改不了。
• 用户证书：用户自己安装的，存在用户数据区。

Android 7（API 24）之前，应用默认两者都信任。所以那个年代，装上代理的 CA 就能抓包。

Android 7 之后，规则变了：应用默认只信任系统证书，用户证书被忽略。除非应用在自己的网络安全配置里显式声明信任用户证书，或者这个应用是可调试的。

10.7抓不到包，按这个顺序查

不要一上来就怀疑工具。按下面的顺序，一步一停，能省掉大量时间。

再补两句容易忽略的：

• QUIC：HTTP/3 走 UDP 443，普通 HTTP 代理不接管 UDP，所以流量直接绕过去了。表现是"网页能开，但代理里一条记录都没有"。
• 非 HTTP 协议：WebSocket、gRPC、自定义 TCP，代理不一定认得。得回到链路抓包，或者直接看代码。

10.8无线抓包与 USB 抓包

无线抓包：网卡要支持监听模式（Monitor Mode），才能收到空口上所有帧，而不只是发给自己的。WPA2 加密的网络，需要抓到四次握手并且知道密码，才能解出内容。只能用于自己拥有或获授权的网络。

USB 抓包：用 USBPcap 之类的工具，看手机和电脑之间的 USB 通信。主要用于分析 iOS 的备份、同步协议，以及某些走 USB 的外设通信。

10.9合法性：这一节比技术更重要

技术能力不等于许可。同样的工具，用在自家 App 上是调试，用在别人系统上就是入侵。这条线不因为"我只是看看"而移动。

10.10一个最大的误区

装上证书就能抓到所有包。

证书只解决"信任"这一环。它管不了下面这些：

• 应用自己做了证书固定，只认特定证书，代理的证书直接被拒；
• 应用走 QUIC，代理根本不接管；
• 应用用的是非 HTTP 协议，代理不认识；
• 应用在应用层又加了一层自己的加密，解开 TLS 之后还是密文。

所以"抓不到"是个多层问题，得按 10.7 的顺序一层层排。

协议逆向方法论：从黑盒到可复现

你抓到一条登录请求，里面有二十多个字段，sign 是一串看不懂的十六进制，ts 每次都变。凭感觉试了三天，偶尔能通一次，但说不清为什么。问题不在技术，在于没有方法。这一页给一套可以照着做的实验流程：怎么拆、怎么比、怎么验证、怎么记。

11.1三种盒子：你手上有什么，决定你从哪下手

同样一个 App，三个人手里的东西可能完全不同：一个人只有一段抓包，一个人有安装包，一个人有源码。这三种起点，做法差得很远。用透明度打个比方，就是黑盒、灰盒、白盒。

• 黑盒（Black Box）：只有一个输入口和一个输出口，里面完全看不见。你只能发请求、看响应，靠对比猜规律。
• 灰盒（Grey Box）：外壳是半透明的。你有安装包，能反编译看到类名、字符串、调用关系，但看不到完整源码，也看不懂所有细节。
• 白盒（White Box）：全透明。你有源码，或者有带完整符号表的二进制，逻辑直接摆在眼前。

真实项目里，九成情况是灰盒：有安装包，但代码被混淆过，关键算法还塞进了 .so。所以这一页的方法默认按灰盒写，黑盒和白盒都能套用。

11.2八步工作流：顺序错了，全是返工

下面这八步是一条固定流水线。它的核心不是"步骤多"，而是前四步只观察、不动手。绝大多数人失败，是因为第一步还没定清楚，就直接跳到第五步去脱壳了。

每一步的产出物写清楚，你就知道自己在哪：

后四步是另一套节奏：定位算法靠静态看结构、动态看入参；复现是自己写代码算一遍；对拍是拿真机结果逐字节比对；固化是把结论写成脚本和文档，让别人也能跑。

11.3输入输出清单法：把请求变成一张可实验的表

把一次请求想成一排开关。你要做的是：先数清有多少个开关，然后一次只拉一个，看灯怎么变。一次拉三个，灯变了你也不知道是谁干的。

先把所有字段抄成表。抄的时候不要漏：路径、方法、每个头、每个体字段，一个都不能少。

列完之后做四件事：

1. 给每个字段标上"固定 / 时间 / 随机 / 依赖别人"四类之一；
2. 挑一个字段，只改它，其他一个字节都不动，发出去；
3. 记录响应的状态码、错误码、提示语；
4. 把这次实验写进记录表（模板在 11.8）。

发出去之后，失败通常有三种，必须分清，否则你会把"签名错"当成"参数错"：

• 签名失败：服务端先说签名不对。说明这个字段参与了签名计算，你改它等于改了原文。
• 业务失败：签名过了，但业务规则不满足，比如余额不足、验证码过期。
• 风控失败：签名和业务都过，但请求被判定为异常行为而拒绝。

三者的错误码通常不同，提示语也不同。第一次遇到时就把它们记下来，后面能省大量时间。

11.4差异对比法：让两次请求自己说出关系

人眼找规律很不可靠，但机器做 diff 很可靠。方法很简单：抓两次请求，让它们只差一个参数，然后把两份文本逐行对齐。

举个具体例子。同一个账号连续登录两次，除了 ts 之外完全一样。diff 的结果是：

第一次
ts=1729900000  sign=9f2c1a...
第二次（8 秒后）
ts=1729900008  sign=4b81ee...
只有 ts 和 sign 两行不同

这条 diff 直接告诉你两件事：sign 依赖 ts；sign 不是固定值。如果两次之间你还改了 uid，那就分不清是 ts 还是 uid 影响了 sign，这次实验就废了。

把这种关系一条条记下来，最后会得到一张依赖清单，长这样：

• sign 依赖 ts（改 ts，sign 变）；
• sign 依赖 uid（改 uid，sign 变）；
• sign 不依赖 nonce（改 nonce，sign 不变）；
• 改 nonce 服务端也不报错，说明它可能只是日志用途。

这张清单就是算法的骨架。剩下的问题只是"用什么函数把这些字段拼起来"。

11.5时间戳与随机数剥离：先把"必然会变"的拿掉

很多人对拍永远对不上，不是算法错了，而是把一个时间戳当成常量算了。所以第三步就要把"每次都会变"的字段挑出来，单独处理。

常见的四种"会变"的字段，判断方法各不相同：

时间戳的判定最实用，记住两个数字就够：

• 10 位十进制，大致是"秒"级时间戳。2026 年前后，这个值在 17 亿左右（1.7 乘 10 的 9 次方）。
• 13 位十进制，是"毫秒"级时间戳，就是秒级乘 1000。

把它除以 1000 再转成日期，如果落在这几天，基本可以确认。反过来，一个 10 位数字如果不落在合理时间范围，那它可能只是流水号。

"剥离"的意思是：对拍时把这些字段固定成同一个值。比如你在脚本里写死 ts=1729900000，然后用真机在同一秒抓到的请求做对比。两边输入完全一致，输出才有可比性。

11.6从字段倒推算法：长度、字符集、分组边界都是线索

字段本身就是一张名片。看一眼长度和字符集，就能把候选算法从几十种缩到三五种。

字符集还能再细分一层：

• 只出现 0-9 和 a-f，是小写十六进制；出现 A-F 就是大写十六进制，说明代码里做了 toUpperCase。
• 出现 + 和 /，是标准 Base64；出现 - 和 _，是 URL 安全变体（URL-safe Base64）。
• 固定前缀如 v1_、sig:，说明是自定义拼接格式，前缀通常不参与计算。

长度还能暴露"分组加密"：如果一个字段的长度总是 16 的整数倍，而且明文长度不同、密文长度会跳变，那多半是 AES 这类分组密码（Block Cipher），块大小 16 字节。反过来，哈希的输出长度是固定的，无论输入多长都一样长。

最后一个关键实验是"雪崩"：把输入改动一个字符，看输出变化多少。

• 输出整段都变，约一半的位翻转：这是哈希或加密的特征。
• 输出只有一小段变：更像编码、拼接或简单替换，比如 Base64、异或。
• 输出完全不变：这个字段根本没进计算，或者被服务端忽略了。

11.7对拍方法学：把服务器当成你的判卷老师

"对拍"这个词来自算法竞赛：写完程序，用一个肯定正确的慢程序跑同一组输入，比输出是否一致。在协议分析里，那个"肯定正确的慢程序"就是真实客户端加真实服务器。

对拍的核心概念叫 Oracle（预言机，这里指判定器）：一个你能反复问"这个答案对不对"的东西。服务器就是最好的 Oracle，因为它会明确告诉你签名通过还是失败。

对拍有三种做法，解决的问题不一样：

这三种方法要配合"假设-验证"循环用。假设必须写成可以被证伪的句子，不能写成"应该是某种加密"这种模糊判断。

一个合格的假设长这样：

不好的假设
sign 应该是 MD5 之类的东西
好的假设
sign = MD5(uid + ts + key) 的小写十六进制
可证伪的预测：改 uid，sign 整段变化；改 nonce，sign 不变

写完预测，再去做实验。如果结果和预测一致，假设暂时成立；连续三次不一致，说明假设错了，回到起点重新提，不要在错的假设上继续加条件。

11.8实验记录、常见死胡同与最大的误区

方法论里最不起眼、但最能救命的是记录。人的短期记忆只能装三四个变量，第五个开始就全靠猜。一张表就能解决：

四列就够。写的时候注意两点：一是"预期"必须写，不写预期的实验等于没做；二是"实际"要抄原文错误码，不要写"失败了"。

下面这些死胡同，几乎每个人都会掉进去一次：

• 一上来就脱壳。还不知道要找什么，就先花两天脱壳，脱完发现关键逻辑根本不在被脱的那一层。
• 只看静态。反编译出来的代码可能被混淆、可能走不到、可能线上根本不执行。静态给结构，动态给事实。
• 把巧合当规律。改了 A 之后成功了一次，就认定 A 是关键。一次成功可能只是缓存、可能只是重试。
• 同时改多个变量。这是最浪费时间的做法，实验做完什么也证明不了。
• 不做记录。三天后回来，连自己改过什么都想不起来。
• 用"环境问题"解释对不上。对不上就是没懂，先把差异定位到字节，再谈环境。

最后说这一页最重要的误区：很多人以为"能复现一次"就等于"搞懂了"。

能复现一次，可能只是照抄了一次成功请求，或者运气好碰上了。真正的标准有三个：

1. 给你一个没见过的输入，你能算出正确输出；
2. 你能解释每个字段为什么这么算，包括顺序、编码、大小写；
3. 别人拿着你的记录，不用问你也能重跑一遍。

三条都满足，才叫可复现。差一条，都还停在"试出来了"的阶段。

Android 逆向基础：APK、DEX 与 Frida

你下载了一个 APK，双击解压，看到一堆不认识的文件夹；用工具反编译，出来几千个文件，不知道从哪看起。这一页把 Android 拆成四层：安装包、字节码、原生库、运行时，每一层告诉你它是什么、用什么工具看、能看到什么。

12.1APK 的本质：一个改了后缀的 zip

APK（Android Package，安卓安装包）不是什么神秘格式。把 app.apk 改名成 app.zip，用任何解压工具都能打开。它就是一个压缩包，里面按固定目录放了几类文件。

这一点很重要：你不需要特殊工具就能看到它的骨架。解压出来先看一眼目录，比直接上反编译工具更快建立整体印象。

每个位置对应一个问题：

• AndroidManifest.xml：这个 App 叫什么、能干什么、从哪个界面启动、申请了哪些权限。
• classes.dex：Java 和 Kotlin 代码编译后的字节码，业务逻辑主要在这里。
• lib/：C 和 C++ 编译出来的原生库，加密、签名、反调试常藏在这里。
• res/ 与 assets/：界面、图片、字符串、配置文件。
• META-INF/：签名信息，用来证明这个包没被人改过。

12.2DEX 与 smali：为什么必须反编译

你写的 Java 代码，编译器不会把它原样放进 APK。它先被编译成字节码（Bytecode），再打包成 DEX（Dalvik Executable，安卓可执行格式）。

打个比方：源码是"人话"，字节码是"电报码"。电报码也是信息，但没人能直接读。反编译就是把这封电报翻译回人话。

DEX 有两个绕不开的限制，直接影响了它的样子：

• 方法数上限：单个 DEX 最多引用约 65536 个方法。超过就要拆成 classes2.dex、classes3.dex，这叫多 DEX（MultiDex）。
• 寄存器架构：DEX 用的是寄存器指令，不是栈指令。所以反编译出来的中间表示和源码不完全一样，会有很多临时变量。

于是有两个层次的"可读版本"：

smali 之所以重要，是因为它一一对应字节码，改起来不会失真。你想把"签名不对就退出"改成"签名不对也继续"，改 Java 是没用的（改完要重新编译整个工程），改 smali 只需要动一两行，再重新打包签名。

一段典型的 smali 长这样，含义是"如果 v0 等于 0，就跳转到标签"：

# 比较 v0 和 0
if-eqz v0, :cond_1
# 相等时执行的代码
const-string v1, "ok"
return-object v1
:cond_1
# 不相等时走到这里
const/4 v0, 0x0
return-object v0

看不懂没关系。你现在只需要记住：smali 是"可以精确修改"的那一层，Java 是"方便阅读"的那一层。读用 Java，改用 smali。

12.3Manifest 与四大组件：先找到入口

反编译之后不要急着搜 sign。先看 Manifest，它相当于这个 App 的身份证加目录：谁开发的、能做什么、从哪个界面启动、能被谁调用。

Android 有四种基本组件，合称四大组件：

• Activity：一个界面。你看到的每一屏都是一个 Activity。
• Service：后台干活的，没有界面，比如上传、播放音乐。
• Broadcast Receiver：接收系统或别的应用发来的广播消息。
• Content Provider：对外提供数据，比如通讯录、相册。

Manifest 里最该看的几个字段：

其中 android:exported 值得单独说。它决定"别的 App 能不能直接唤起这个组件"。为 true 时，任何应用都能发一个意图（Intent）把它叫起来，并带上参数。这既是功能，也是风险：参数没校验就可能被注入。

找入口的顺序建议是：先在 Manifest 里找带 MAIN 和 LAUNCHER 的 Activity（那就是桌面图标的入口），再从它的代码里看它启动了哪些界面、调用了哪些网络类。

12.4工具分工：jadx、apktool、IDA 各管一段

新手最容易犯的错，是拿一个工具硬啃所有问题。这三个工具的分工其实很清楚：

实际流程通常是：jadx 读逻辑，apktool 改代码，IDA 看 native。

• 先用 jadx 打开 APK，全局搜关键字（比如 sign、encrypt、接口路径），快速定位到可疑类。
• 如果发现关键方法是 native 声明，就转去 lib/ 找对应的 .so，用 IDA 打开。
• 如果确认要改行为，用 apktool 解包，改 smali，再 apktool b 回编译、重新签名。

回编译之后必须重新签名，否则装不上。这一步用的是你自己的调试证书，只对你自己测试的设备有意义。

12.5native 库与 JNI：Java 怎么落到 .so

Java 代码跑在虚拟机里，碰不到硬件，也做不了高性能计算。需要时，它会调用 C 或 C++ 写的函数，这些函数编译成 .so（Shared Object，共享库）放在 lib/ 下。

连接两边的桥叫 JNI（Java Native Interface，Java 原生接口）。可以把它想成翻译：Java 说"我要调用 sign"，JNI 负责把这句话翻译成 C 函数能听懂的参数格式。

名字绑定有两种方式，这决定了你在 .so 里怎么找函数：

• 静态注册：函数名按 Java_包名_类名_方法名 拼出来。在 IDA 的导出表里直接搜方法名就能找到。
• 动态注册：在 JNI_OnLoad 里用 RegisterNatives 把名字和函数地址绑起来。导出表里看不到业务函数名，只能从 JNI_OnLoad 顺藤摸瓜。

看到动态注册不用慌。它只是"把电话本换成了另一张纸"，函数本体还在，只是名字不写在导出表上。顺着 JNI_OnLoad 里的那张表，一个个对过去就行。

12.6Frida 原理：在运行时看真实入参

静态分析有个天生的短板：代码可以加密、可以混淆、可以动态加载。但程序要运行，就必须把真实的参数交给真实的函数。Frida 就是在这个时刻插一脚。

它的原理分三步：

1. 往目标进程里注入一个 agent（代理模块），让目标进程多出一段外来代码；
2. 这段代码里带一个 JavaScript 运行时，你用 JS 写逻辑；
3. 用 Interceptor 把目标函数的开头改成跳转，先跳到你的回调，再跳回原函数。

下面两个脚本都只做观察，不改任何逻辑。第一个挂在 Java 层，打印方法入参和返回值：

// 只读观察：打印 sign 方法的入参与返回
Java.perform(function () {
  var cls = Java.use("com.example.app.SignUtil");
  cls.sign.implementation = function (a, b) {
    console.log("[入参] a=" + a + " b=" + b);
    var r = this.sign(a, b);
    console.log("[返回] " + r);
    return r;
  };
});

第二个挂在原生函数上，只打印参数和返回值，不读内存内容，避免踩到指针：

// 只读观察：打印 .so 里某个导出函数的调用
var addr = Module.findExportByName("libsign.so", "sign_init");
Interceptor.attach(addr, {
  onEnter: function (args) {
    console.log("[调用] 第 1 个参数: " + args[0]);
  },
  onLeave: function (retval) {
    console.log("[返回] " + retval);
  }
});

这两段代码的价值不在语法，而在思路：与其猜算法，不如让程序自己告诉你它收到了什么、算出了什么。拿到真实入参之后，再回到静态代码里对照，比纯看汇编快得多。

12.7adb：连接手机的那根线

adb（Android Debug Bridge，安卓调试桥）是电脑和手机之间的命令行通道。它做的事情很朴素：把命令送进手机，把文件取出来。

最常用的几条命令，建议背下来：

# 看设备有没有连上
adb devices
# 安装（-r 表示覆盖安装，保留数据）
adb install -r app.apk
# 看指定应用的日志
adb logcat -s MyApp
# 列出所有包名，找目标应用
adb shell pm list packages
# 启动某个界面
adb shell am start -n com.example.app/.MainActivity
# 端口转发：把手机的 27042 映射到电脑
adb forward tcp:27042 tcp:27042
# 从手机取文件出来
adb pull /data/local/tmp/trace.txt

其中端口转发是 Frida 的关键一步：frida-server 在手机上监听一个端口，电脑通过转发连上去，看起来就像连本机一样。

看日志也有技巧。logcat 默认输出所有应用的日志，噪音极大。用 -s 标签 只留你关心的那一个，或者用 --pid 只留某个进程的日志，效率会高很多。

12.8root、Magisk 与 App 的检测点

root 的本质是拿到系统的最高权限。用大楼打比方：普通用户只有自己房间的钥匙，root 有整栋楼的总钥匙，能进任何房间、改任何门锁。

Magisk 是目前最常见的 root 方案。它的特点是"系统分区不改动"，通过启动时挂载的方式把修改叠加上去，所以能比较容易地撤销。它还提供模块机制，可以往系统里加东西而不碰原始分区。

代价也很直接：

• 系统完整性被破坏，部分银行、支付、企业应用会拒绝运行；
• 系统更新可能失败，或者更新后 root 失效；
• 安全边界降低，任何拿到 root 的恶意程序都能读全部数据。

App 检测 root，靠的是一组"痕迹"。这些痕迹的原理值得了解，因为它们是移动端风控的基础知识：

从防守方角度看，这些检测都有同一个弱点：它们依赖"环境看起来正常"，而环境是可以被伪装的。所以现代风控不会只靠单一检测，而是把 root 痕迹、设备指纹、行为特征放在一起打分。

从学习角度看，你要记住的是结论：root 不是目的，只是让你能观察系统的一种手段。绝大多数协议分析，用一台普通测试机加抓包就够了，不一定需要 root。

12.9动态调试 smali、加固脱壳与两个误区

改 smali 之后怎么验证？最直接的办法是让程序停在你想看的那一行。思路是：在 smali 里插入一条调试指令（本质是一条特殊的指令，会让调试器接管），然后用调试器附加到进程，单步执行，看寄存器的值。

这条路的门槛在于：你得先让应用以可调试的方式运行，而正式包默认是不可调试的。所以实践中更多用 Frida 做观察，用 smali 打补丁做验证，两者配合。

再往上就是加固。加固厂商做的事情，本质是三层：

• 藏：把真正的 DEX 加密后放进 assets 或 .so，启动时在内存里解密，磁盘上永远没有明文 DEX。
• 骗：改 Manifest、加壳入口，让静态工具看到的类列表是空的或假的。
• 防：检测调试器、检测注入、校验自身完整性，发现异常就退出。

对应的脱壳思路，原理上只有一句话：DEX 要在内存里变成可执行的形式，就一定有一个时刻是明文。所以方向是在那个时刻把内存里的 DEX 抓出来，再修复头部。具体工具和步骤不在本页展开，因为不同壳差异极大，且容易踩到授权边界。

最后说两个流传很广的误区。

误区一：反编译出来就是源代码。不是。反编译是"根据字节码推测源码"，变量名、注释、部分语法结构都丢了。混淆之后，类名会变成 a、b，方法名变成 a()、b()，可读性接近零。你看到的是"能编译回去的近似版本"，不是作者写的那份。

误区二：混淆等于加密。也不是。混淆只改变名字和结构，逻辑完全没变，运行时该怎么做还是怎么做。加密是让内容在没钥匙时不可读。混淆挡的是"人眼",加密挡的是"没有钥匙的人"。所以混淆过的代码照样能被 Frida 挂钩，只是读起来更费劲。

iOS 逆向基础：Mach-O、签名与运行时

iOS 的安装包不像 APK 那样一眼能看穿：它没有 DEX，代码是编译好的机器码；它还有一整套签名与授权机制，让"装不上"和"跑不起来"成为常态。这一页讲清四件事：IPA 里有什么、Mach-O 怎么读、签名在防谁、运行时怎么观察。

13.1IPA 的结构：也是一个 zip

IPA（iOS App Store Package，iOS 应用包）和 APK 一样，本质是 zip。把它改名成 .zip 就能解压。但它的目录结构只有一个固定入口：Payload/。

用寄快递打比方：Payload 是外箱，MyApp.app 是里面那个贴着标签的包裹，包裹里才是真正的东西。

四样关键东西，各管一件事：

• 可执行文件：和 .app 同名的那个文件（没有后缀），就是 Mach-O 格式的程序本体。
• Info.plist：应用的身份证，写着包名（Bundle ID）、版本、支持的设备、启动配置。
• embedded.mobileprovision：描述文件，写着"哪个证书签的、允许哪些设备装、能用哪些能力"。
• Frameworks/：内嵌的动态库，第三方 SDK 通常以这种形式存在，每个都是独立的 Mach-O。

13.2Mach-O：iOS 程序的真实形状

Mach-O（Mach Object，Mach 目标文件格式）是苹果系统的可执行文件格式。它的结构像一本印刷书：先有封面和目录，再有正文，正文按章节分块。

三大部分，从前往后：

• Header（头部）：开头一小段，说明"我是什么架构、有多少条目录项"。头 4 个字节是魔数，用来确认这是 Mach-O。
• Load Commands（加载命令）：一串目录项，每一项说"某一段在文件的哪个位置、多大、加载到内存哪里"。
• Segments 与 Sections（段与节）：真正的数据。段是大块（代码段、数据段），节是段里的细分（代码段里的指令、常量字符串）。

实际分析时，最常打交道的不是头部，而是两个地方：

• __TEXT 段里的 __text 节：所有机器指令都在这里。反汇编工具默认打开的就是它。
• __cstring 节：常量字符串。接口路径、错误提示、密钥片段、加密算法名，常常在这里露出来。

还有一类文件叫胖二进制（Fat Binary）或通用二进制：一个文件里同时包含 arm64 和 x86_64 等多份代码，方便在不同设备上运行。分析前要先用工具"瘦身"，只留你关心的架构，否则地址会对不上。

13.3签名机制：不是加密，是封条

很多人把 iOS 签名理解成"给应用加密"。不是。签名更像火漆印：它不隐藏内容，只证明"这封信是谁写的、路上有没有被拆过"。

一套完整的签名，涉及四样东西：

这解释了一个常见现象：你改了一个字节想验证猜想，结果应用直接闪退。不是你的改动逻辑错了，是签名对不上了。要验证改动，必须重新签名，而重签需要证书和描述文件。

也解释了一个常见误解：签名不加密。任何人拿到 IPA 都能解压、都能看到资源文件、都能读字符串。签名防的是"篡改"和"冒充"，不是"偷看"。真正防止偷看代码的是 App Store 下发时的加密（对应 13.1 提到的"砸壳"）。

13.4越狱：作用与代价

越狱（Jailbreak）就是绕过系统的签名与沙盒限制，拿到最高权限。用大楼打比方：正常应用各自住在自己的房间里，越狱相当于拿到总钥匙，能进配电房、能改门禁。

它能带来三件事：

• 安装未经 App Store 签名的应用；
• 读写系统目录和其他应用的数据；
• 往其他进程注入代码，这是动态分析的前提之一。

代价同样明确：

• 安全性下降：沙盒失效，恶意程序拿到权限后能做更多事；
• 应用拒绝运行：银行、支付、部分游戏会检测越狱并直接退出；
• 系统不稳定：越狱依赖系统漏洞，更新后经常失效，甚至无法开机；
• 保修与支持：官方通常不对此类设备提供支持。

需要澄清一点：越狱不是分析的必要条件。很多工作可以在未越狱设备上完成，比如用开发者证书自签一个测试应用、用官方提供的调试通道、或者直接分析已经解密好的 IPA。越狱只是让"注入其他进程"这件事变简单。

13.5工具分工：谁看结构，谁看代码

iOS 这边工具不多，但分工比 Android 更细。核心区别是：有的工具只读结构，有的工具读指令。

实际顺序通常是：class-dump 看有哪些类和方法，Hopper 或 Ghidra 定位到具体函数，IDA 做深度确认。

class-dump 的价值常被低估。它不能给你实现，但能给你地图：类名、方法名、继承关系。有了地图，你才知道该在哪个函数上下断点。方法名往往还很直白，比如 signWithParameters:、encryptData:，一眼就能看出用途。

13.6Objective-C 运行时：消息发送与替换

Objective-C（简称 ObjC）是 iOS 的主力语言之一。它和 Java 最大的不同在于：方法调用不是"直接跳过去"，而是"发一条消息"。

打个比方：Java 是"我知道你工位在哪，直接走过去找你"；ObjC 是"我打总机，报一个名字，总机帮我转接"。这个"总机"就是运行时（Runtime）。

由此产生三个关键概念：

• 类对象（Class）：运行时里真实存在的一个结构，里面有一张方法表，记录"名字到函数地址"的映射。
• 选择器（Selector）：方法的名字，编译后变成一个唯一的标识。发消息时传的就是它。
• 消息发送（objc_msgSend）：所有方法调用的统一入口。它拿到对象和选择器，去方法表里查地址，再跳过去。

因为是"查表再跳"，方法表在运行时是可以被改的。这就带来了 method swizzling（方法交换）：把两个方法的实现地址互换，调用 A 的时候实际执行 B。

它的用途很广：统计埋点、功能开关、热修复，都是这个原理。对分析者来说，它的意义是一个天然的观察点：交换前后，你可以在自己的实现里打印参数，再调用原实现。

这也解释了为什么 ObjC 应用比 Swift 应用更容易做动态分析：类名、方法名、参数类型都还在运行时结构里，工具能直接读出来。

13.7Swift 符号与 mangling：名字里藏着类型

Swift 为了让"同名方法但参数类型不同"能共存，把类型信息编码进了符号名。这个编码规则叫 mangling（名称修饰）。

结果就是：你在符号表里看到的不是 sign(ts:)，而是一串以 $s 开头、中间夹着数字和字母的东西。比如模块名、类型名、参数类型，全被压进了这一串。

这串东西不是加密，只是编码，可以还原。苹果工具链自带还原命令（swift-demangle），很多反汇编工具也会自动还原。

需要记住的只有三点：

• Swift 符号可还原，不是乱码；
• 还原后能看到模块名、类型名、参数类型，对定位很有帮助；
• Swift 的类信息不在 ObjC 运行时里，所以 class-dump 看不到，得靠符号或反汇编。

13.8Frida 在 iOS 上：同样的思路，不同的入口

Frida 在 iOS 上的原理和在 Android 上一致：注入进程、跑 JS、挂钩函数。差别在挂钩的写法，因为 iOS 的方法是用选择器（Selector）标识的。

下面这段只做观察：打印入参对象，然后照常调用原实现，不改任何返回值。

// 只读观察：打印某个 ObjC 类方法的入参
var method = ObjC.classes.SignUtil["+ signWith:ts:"];
Interceptor.attach(method.implementation, {
  onEnter: function (args) {
    var first = new ObjC.Object(args[2]);
    var second = new ObjC.Object(args[3]);
    console.log("[入参] " + first + " / " + second);
  },
  onLeave: function (retval) {
    console.log("[返回] " + new ObjC.Object(retval));
  }
});

这里 args[0] 是对象自身，args[1] 是选择器，真正的参数从 args[2] 开始。这个偏移是 ObjC 消息调用约定决定的，记错就会读到一个奇怪的指针。

在 iOS 上用 Frida，通常需要满足一个前提：设备越狱并装了 frida-server，或者应用本身以可调试方式运行并加载了对应的动态库。这不是"绕过"，而是调试通道是否打开的问题。

13.9Keychain、数据保护与抓包的前提

iOS 把敏感数据放在 Keychain（钥匙串）里。它不是一个普通文件，而是系统管理的一个加密数据库，应用只能通过接口存取，拿不到原始文件。

钥匙串的条目可以设置"可访问条件"，决定它在什么状态下能被读：

这些级别的实现依赖硬件里的安全区域（Secure Enclave）和设备的锁屏密码。所以"拿到手机就能读出所有密钥"是不成立的：锁屏状态下，高保护级别的条目根本解不开。

再说抓包。iOS 对证书的信任分两层：

1. 把代理工具的根证书装进设备（作为描述文件安装）；
2. 到"证书信任设置"里手动打开完全信任。

只做第一步是不够的，这是 iOS 和很多 Android 设备最大的操作差异。很多人卡在"证书装了但还是抓不到"，原因就是第二步没开。

即使两步都做了，仍可能看不到明文。因为应用可以做证书固定（Certificate Pinning）：不信任系统证书库，只认自己内置的那张证书或公钥。这时握手会失败，流量依然加密。

从防守方角度，证书固定是有效手段；从分析角度，它是一个明确的信号：看到握手失败而不是乱码，就该怀疑固定，而不是怀疑抓包工具坏了。

13.10两个必须纠正的误区

误区一：不越狱就没法分析 iOS 应用。

不对。越狱解决的是"往别人的进程里注入代码"这一件事。而下面这些工作都不需要越狱：

• 解压 IPA、读 Info.plist、看资源文件；
• 对已解密的 Mach-O 做静态反汇编、搜字符串、看依赖库；
• 用开发者证书给自己编译的测试应用做动态调试；
• 在信任了证书的前提下抓自己应用的流量。

越狱只是让"动态注入"这一步更省事。把越狱当成前置条件，会让很多人还没开始就放弃。

误区二：iOS 一定比 Android 安全。

这句话混淆了"恶意软件少"和"不可被分析"。iOS 的封闭生态确实降低了普通用户中招的概率：应用必须经过审核、不能随意侧载、沙盒更严格。但这不等于系统不可分析，也不等于没有漏洞。

更准确的说法是：两者的威胁模型不同。

对做安全的人来说，结论是：没有"更安全的平台"，只有"不同的攻击面"。iOS 把门槛放在了签名和加密上，Android 把门槛放在了混淆和加固上，两边都要学。

加固、混淆与反调试：对抗的成本

很多人第一次拆一个商业 App，打开反编译工具会愣住：类名全是 a.b.c，字符串全是乱码，调试器一附加程序就退出。这不是工具坏了，而是对方花钱买了对抗。这一页讲清楚加固到底做了什么、为什么有效、边界在哪里。

14.1先给结论：加固是把成本抬高

把一个 App 装进保险柜，和把它装进纸箱，区别不在"能不能打开"，而在"打开要多久、要什么工具、要懂多少东西"。加固（Hardening）做的正是这件事。

它抬高三类成本，缺一不可：

• 时间成本：原来十分钟能读完的逻辑，现在要三天。
• 工具成本：原来一个免费反编译器就够，现在要会写脚本、会看汇编、会搭动态环境。
• 知识成本：原来会 Java 就行，现在要懂链接器、内存布局、进程状态。

对防守方来说，这是一笔很划算的买卖：一次投入，长期生效。对分析方来说，这是一笔持续支出：每出一个新版本，之前的经验要重来一遍。

所以评估一个 App 的加固，不要问"能不能破"，要问"破它值不值"。这句话是整章的主线。

14.2混淆：让代码能跑但读不懂

混淆（Obfuscation）的生活比喻是：把一篇文章里所有人名换成"甲、乙、丙"，再把段落顺序打乱。文章照样能读通，但你已经不知道谁是谁。

它在编译阶段完成，代码的行为完全不变，变的只是"名字"和"结构"。常见四种手法：

关键判断：混淆完全不改变程序语义。所以它只对"静态阅读"有效，对"动态观察"几乎无效。程序运行时该调用的函数照样调用，该传的参数照样传。

14.3加壳：外面套一层，运行时才解开

加壳（Packing）的比喻是快递里的泡沫箱：你收到的是一个箱子，拆开泡沫才见货。App 也一样，磁盘上那份文件里装的是"壳"，不是真正的代码。

常见三层，保护强度递增：

14.3.1 DEX 壳

Android 的可执行代码叫 DEX（Dalvik Executable）。壳的做法是：把真实 DEX 加密后藏进安装包的资源里，安装包里只留一个很小的"启动器"。

App 启动时，启动器把真实 DEX 解到内存，再交给系统加载。所以你在磁盘上翻来翻去，只能翻到壳。

14.3.2 VMP：把指令翻译成方言

虚拟机保护（Virtual Machine Protection，VMP）更狠：它把原始指令翻译成一套自定义字节码，再配一个解释器循环执行。

比喻：把中文合同翻译成只有某个翻译官懂的手语。你拿到了手语录像，但没有词典。

代价也很明显：解释执行比原生执行慢，耗电高。所以 VMP 通常只用在最核心的一两个函数上，不会全量使用。

14.3.3 OLLVM：在编译期就把代码搅乱

OLLVM 是一套编译期插件，在生成机器码之前做三件事：控制流平坦化、虚假控制流、指令替换。

它和前面混淆的区别是：混淆作用在"名字"层面，OLLVM 作用在"指令"层面。即使你拿到汇编，也要花很大力气才能还原。

14.4完整性校验：改了就要被发现

完整性校验（Integrity Check）的比喻是门上的封条：内容不重要，重要的是"有没有被撕开过"。

它有四种常见强度，从弱到强：

签名校验值得单独说。Android 安装包必须签名，重打包必然换证书。客户端只要读出自己的签名摘要，和内置的期望值比一下，就知道有没有被改过。

分段校验是"分散投资"：不在一处检查全部，而是把校验点撒在启动、登录、下单、支付前。改一处只能过一关，下一关还会拦。

14.5反调试：让你连不上

反调试（Anti-Debugging）的目标不是"让你看不懂"，而是"让你没法停下来看"。调试的核心动作是"暂停程序、检查状态"，反调试就围绕这一点做文章。

14.5.1 ptrace 占坑

Linux 里一个进程同一时刻只能被一个调试器跟踪。App 可以在启动时自己调用 ptrace 附加自己，把"名额"占掉。调试器再来就附加失败。

比喻：自己先把车位停了，别人就没地方停。

14.5.2 读进程状态

系统会给每个进程维护一份状态文件，里面有一个 TracerPid 字段，表示"谁在跟踪我"。正常情况是 0，被调试就不是 0。App 读一下就知道有没有人挂在上面。

14.5.3 时间差检测

在代码里埋两处时间戳，正常执行可能只隔几微秒。如果中间被下了断点，人会停下来看，时间差就会变成几百毫秒甚至几秒。

比喻：掐表看一段路走了多久，走得太慢说明有人停下来看风景了。

14.5.4 端口与标志检测

调试器通常会在本机监听一个端口。App 试探性地连一下这些常见端口，能连上就说明环境可疑。另外，安装包里如果声明了"可调试"，也是明显信号。

14.6反 Hook：找注入框架的痕迹

Hook 是动态分析的主力手段：把一个函数"劫持"掉，看它的入参和返回值。反 Hook 的思路是：不管你用什么框架，它都要在进程里留下痕迹。

痕迹主要有四类：

这四类检测的共同点是：它们观察的是"环境"，不是"代码"。所以加固厂商会把它们打包成一个"环境体检"模块，在启动、登录、支付前各跑一次。

但反过来，环境检测也有代价：扫描内存映射、遍历线程都要时间，做得太频繁会拖慢启动，做得太粗会误伤正常用户（比如某些安全软件、无障碍服务、输入法也会注入进程）。

14.7多进程与双进程保护

单进程的保护有个天然弱点：所有判断都在一个进程里，只要控制了这个进程，判断就全废了。于是有了多进程方案。

比喻：两个保安互相盯着，一个被放倒，另一个立刻报警。

常见做法有三种：

• 守护进程：主进程和一个轻量守护进程互相心跳，一方消失另一方重启它。
• 校验分工：把签名校验、环境检测放到独立进程，主进程只接收结论。
• 数据分散：密钥分片存放在不同进程，单独一个进程拿不到完整密钥。

但这条路在近年的 Android 上越来越难走。系统对后台进程限制很严，守护进程被杀后不一定能拉起来，反而导致崩溃率上升、耗电变差。所以现在的产品更倾向于"多进程分工"，而不是"互相拉活"。

14.8怎么评估一个 App 的加固强度

不要凭"打开反编译器看到什么"下结论。用四个维度打分，才比较靠谱。

第三项最容易被忽略。一个只在启动时校验一次的 App，和分别在启动、登录、下单、支付前校验四次的 App，防护强度差一个数量级。

第四项是"诚实度测试"：故意改一个无关紧要的字节，看它有没有反应。反应越干脆（立刻退出、功能不可用），说明校验越硬；毫无反应，说明基本没做完整性保护。

14.9攻防的经济学：谁更划算

把加固看成一场成本竞赛，很多现象就解释得通了。

关键洞察：防守方一次投入长期有效，攻击方每个版本都要重来。所以加固真正的价值不在"挡住一次"，而在"让每次都要重新付出"。

反过来说，如果一个 App 一年只发一个版本，加固的边际收益就低；如果两周发一版，加固的收益会成倍放大。这也解释了为什么大厂更愿意在加固上花钱。

14.10两个最常见的误区

误区一：混淆等于加密。很多人看到乱码字符串，就以为内容被加密了、拿不到了。其实混淆后的代码必须能正常运行，而运行就必须解密。解密函数就在同一个文件里，只是名字难看。加密保护的是"传输和存储"，混淆保护的是"阅读体验"，两件事。

误区二：加壳等于安全。壳只保护磁盘上的文件，程序跑起来之后内存里一定是明文。而且壳本身是一个复杂的加载器，历史上不少壳自己就有漏洞，反而扩大了攻击面。

还有一个变体误区：以为加固能防住"有授权的人"。加固防的是批量和自动化，防不住一个愿意投入几周时间、并且有合法授权做安全评估的团队。这是设计目标决定的，不是实现缺陷。

14.11合规提醒

加固分析在合法场景里非常常见：安全公司做渗透评估、厂商做兼容性排查、研究机构分析恶意样本、开发者检查自家 App 有没有被二次打包。

这些场景有一个共同点：要么是自己的 App，要么有书面授权。

• 只分析自己开发的、或客户书面授权的 App。
• 分析他人 App 的付费、授权、会员逻辑并加以利用，可能构成侵权甚至犯罪。
• 不要把分析结果、密钥、绕过方法公开传播。
• 涉及用户数据时，遵守最小必要原则，能不留存就不留存。

SSL Pinning 与中间人：证书信任的边界

很多人第一次抓包会遇到同一种挫败：代理装好了，证书也装好了，浏览器能抓，偏偏这个 App 一点流量都没有，或者干脆报错退出。原因几乎总是同一个：这个 App 不信任"系统里所有受信任的证书"，它只信任自己认定的那一张。

15.1中间人是怎么成立的

先说清楚一件事：中间人（Man-in-the-Middle，MITM）不是"破解"了 TLS，而是把一条 TLS 拆成了两条。

生活比喻：你以为在跟房东打电话，其实中间有个中介。中介一边跟你说"我是房东"，一边跟真房东说"我是租客"。两边都以为在跟对方说话。

技术上，抓包代理干的就是中介的活：

所以问题变成：客户端为什么会接受"代理的证书"？因为代理的证书也是某个受信任的机构签的——只要你在手机上装了代理的根证书，系统就认为它是合法的。

这正是抓包工具的标准流程：生成一张自己的根证书，让你装进系统信任库。从系统角度看，它和正规证书颁发机构没有区别。

15.2证书校验的三个层次

客户端验证一张证书，通常分三步，像机场安检的三道关：

第一层，系统信任库。手机里预装了一百多个受信任机构的根证书，操作系统和浏览器都认这份名单。你在设置里装的证书，也会进这份名单。

第二层，主机名校验。证书上写着"这个证书属于哪些域名"。如果证书是给 api.example.com 的，你却拿它去访问 pay.example.com，就要报错。

第三层，证书固定。客户端不看"谁签的"，只看"是不是那一张"。这一层是应用自己实现的，不是 TLS 协议强制的。

15.3证书固定的三种类型

"固定"（Pinning）的意思是：把某个值提前写进客户端，运行时比对。固定的对象不同，严格程度和可维护性也不同。

15.3.1 整证书固定

把整张证书的字节做一次哈希，客户端存这个哈希。服务器换证书（哪怕只是续期），哈希就变了，客户端立刻连不上。

比喻：门卫手里拿着你的整张身份证复印件，你换了张新身份证（号码没变），他也不认。

所以这种方式几乎只用在极少数场景，比如固定硬件的物联网设备。

15.3.2 公钥固定

只比对证书里的公钥。证书可以换，只要公钥不变就能通过。

但公钥是一段很长的二进制，要在客户端里解析证书、取出公钥再比对，实现成本高，也容易因为解析差异出问题。

15.3.3 SPKI 哈希固定

SPKI（Subject Public Key Info）是证书里"公钥加算法标识"那一段。把它单独取出来做 SHA-256，得到一串 32 字节的值，编码成 Base64 就是一串短文本。

客户端只需要算一次哈希，和存好的字符串比一下。简单、稳定、体积小，所以 OkHttp、AFNetworking 这类库默认都走这条路。

15.4Android 上怎么实现

Android 有两条路：系统级配置和代码级实现。

15.4.1 网络安全配置

从 Android 7 开始，应用可以用一份 XML 声明"我信任哪些证书"。这份文件叫网络安全配置（Network Security Configuration）。

# network_security_config.xml 片段（示意）
<domain-config>
  <domain>api.example.com</domain>
  <pin-set expiration="2027-01-01">
    <pin digest="SHA-256">AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA</pin>
    <pin digest="SHA-256">BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB</pin>
  </pin-set>
</domain-config>

几个要点：

• domain 指定对哪个域名生效，可以写多个。
• pin 写的是 SPKI 哈希的 Base64，一条当前、一条备用。
• expiration 是保险丝：到期后固定自动失效，避免把自己锁死。
• 还可以用 debug-overrides 只在调试包里放开限制，正式包保持严格。

15.4.2 代码级固定

OkHttp 提供了 CertificatePinner，在构造客户端时挂上去，写法大致是"域名 + sha256/哈希值"。

它的好处是粒度细：可以只对支付相关域名严格固定，对日志上报域名放宽。坏处是绕过了系统配置，排查问题时不容易一眼看出来。

15.5iOS 上怎么实现

iOS 的思路类似，但实现位置不同。

• AFSecurityPolicy：AFNetworking 提供的策略对象，可以设置"只接受指定证书"或"只接受指定公钥"，并可选是否校验域名。
• URLSession 代理校验：实现挑战回调，在服务器要求客户端验证证书时，自己读取证书链、算哈希、和内置值比对，然后决定接受还是拒绝。
• 系统级固定：把证书放进应用的配置描述里，由系统在建立连接时强制校验。

要注意的是，iOS 的信任评估比 Android 更集中，一旦应用自己接管了校验回调，就必须自己处理证书链、有效期、域名匹配等全部细节。写得粗糙反而会引入漏洞，比如只比对了域名却没验证签名。

15.6为什么抓包会失败：错误码对照

失败信息本身就是最好的线索。不同错误对应不同的关卡。

最后一行最容易被误判。应用不会告诉你"pin 校验失败"，它只会默默关掉连接，或者返回一个笼统的网络错误。所以你看到"请求超时""网络异常"时，也可能是被固定挡了。

判断方法：同一台设备、同一个代理，用浏览器访问同一个域名。浏览器能通、App 不通，基本可以确定是应用层做了额外校验。

15.7企业场景下的合法中间人

中间人不等于攻击。很多正规场景必须做中间人：

• 企业设备管理（Mobile Device Management，MDM）：公司发的手机，公司需要检查有没有恶意流量。
• 私有证书颁发机构（私有 CA）：企业内网服务用自己的 CA 签发证书，员工设备预装根证书。
• 安全网关：办公网出口做流量审计、防数据外泄。
• 开发调试：开发阶段用代理查看自己 App 的请求。

这些场景能成立，靠的不是技术，而是知情与授权：设备是公司的、员工被明确告知、证书由公司统一管理、离职时收回。

15.8检测思路：双方各自怎么看

这一节讲"怎么发现问题"，不讲"怎么绕过"。两者方向相反，但原理是同一套。

15.8.1 服务端能看出什么

• 客户端证书指纹异常：如果业务用了双向认证，客户端证书就是身份，代理拿不到。
• TLS 指纹异常：不同客户端库的握手参数有固定组合，代理转发的握手往往和真实客户端不一致。
• 请求特征突变：同一个账号，平时用移动网络，突然所有请求都来自一个机房 IP，且头部顺序变了。
• 时间与顺序异常：代理会引入额外延迟，某些强时序校验会对不上。

15.8.2 客户端能自检什么

• 证书链是否来自预期签发者：不只看"是否受信任"，还看"是谁签的"。
• 是否存在多余的根证书：检查用户证书库里有没有不该有的条目。
• 连接是否被转发：检查系统代理设置、检查网络接口是否异常。
• 自身完整性：包名、签名、代码段是否被改动。

注意最后一条：客户端的自检代码本身也在被保护的范围内，所以这是一个不断加码的循环。检测越细，误报越多；误报越多，越需要"降级"而不是"直接拒绝"。

15.9两个常见误区

误区一：pinning 能防住所有分析。固定只能保证"客户端只和持有特定私钥的服务器通信"，它管不了内存里的明文。请求发出去之前，参数一定是明文；响应回来之后，也一定是明文。所以动态分析依然能看到业务数据，只是看不到"线上那一份原始报文"。

误区二：关掉校验就万事大吉。很多应用不只在一处校验。关掉网络库的固定，可能还有 Native 层的校验、还有服务端的证书指纹检查、还有请求签名里绑定的通道信息。改一处往往只是让错误换了个样子。

还有一个更隐蔽的误区：以为"能抓到包"就等于"看懂了协议"。抓包只给你原料，字段含义、签名算法、加密参数，仍然要靠分析和验证。

15.10合规提醒

证书固定是保护用户的技术，不是攻击工具。使用它的场景应该是：保护自己的 App 不被中间人劫持，尤其是在公共 Wi-Fi、恶意热点环境下。

• 只对自己开发的 App 或书面授权的目标做抓包分析。
• 不要在他人设备上安装根证书。
• 抓到的流量里可能包含个人信息，按最小必要原则处理，用完即删。
• 企业内部审计必须告知员工，并限定范围与保存期限。

设备指纹与风控：八类参数与一致性

你有没有想过：为什么换了个手机号注册，平台还是知道"又是你"？为什么刚注册的新号，第一次下单就被要求人脸验证？答案通常不是某个神秘的"唯一编号"，而是一堆普通参数拼出来的画像，再加上它们之间的一致性。

16.1什么是指纹：稳定和唯一的拉扯

设备指纹（Device Fingerprint）的定义很朴素：从一台设备上采集一组参数，用来在多次访问之间认出"这是同一台"。

它有两个目标，而这两个目标天然冲突：

• 稳定性：同一个用户下次来，这些值最好别变。
• 唯一性：不同用户之间，这些值最好别撞。

比喻：用"身高"当指纹，很稳定（成年后基本不变），但一点都不唯一（一米七的人太多了）；用"今天穿的衣服"当指纹，很唯一，但明天就失效了。

一个好的指纹要同时满足四个条件：稳定、唯一、难伪造、可采集。现实中没有任何一项能全占，所以工程上用的是"多项加权"：单个值只贡献一点分数，组合起来才有判断力。

16.2八类参数：从"机器是什么"问到"它和谁有关系"

把常见参数归归类，一共八类。前四类描述设备本身，后四类描述"这台设备在做什么、和谁有关"。

注意最后两类。很多初学者以为指纹就是"设备参数"，其实行为和环境才是最难伪造的部分。设备参数可以改，但一个人的操作习惯、作息时间、常驻地点，改起来成本高得多。

16.3Android 标识的变迁：为什么一直在换

Android 的设备标识换过好几代，每一次都是隐私压力和商业需求拉扯的结果。

IMEI 是硬件串号，最稳定也最敏感。从 Android 10 起，普通应用已经拿不到它，只有系统级应用或设备所有者才有权限。

Android ID（也叫 SSAID）改成按"应用签名 + 用户 + 设备"派生。这意味着同一台手机上的两个不同 App，读到的值是不一样的，横向串联被切断了。

GAID（Google 广告 ID）是给广告场景用的，用户可以随时重置，也可以关闭个性化广告。关闭后返回的是一串全零，等于"我不给你"。

OAID 是国内厂商联合推出的匿名设备标识，思路一样：可重置、可关闭，用匿名性换可用性。

16.4iOS：IDFV、IDFA 和钥匙串

iOS 的思路和 Android 类似，但更早收紧。

• IDFV（Identifier for Vendor）：同一个开发商的所有 App 共享一个值。删掉该开发商全部 App 后重置。
• IDFA（Identifier for Advertisers）：广告标识。iOS 14.5 之后必须用户明确授权才能读取，未授权返回全零。
• 钥匙串（Keychain）：系统级的加密存储。删除 App 后数据可能仍然保留，所以常被用来存"持久标识"。

钥匙串这一点值得多说一句。它的设计初衷是"让同一开发商的 App 安全共享密码"，但被拿来当持久标识之后，就变成了一个隐私争议点：用户以为卸载干净了，实际上痕迹还在。

16.5浏览器指纹：不用任何 ID 也能认出你

浏览器没有 IMEI，也没有 GAID，但依然能被认出来。方法是采集一堆"渲染细节"。

原理是：同样的代码，在不同的显卡、驱动、字体、操作系统上，渲染出来的像素会有微小但稳定的差异。这个差异就是签名。

比喻：同一句话让不同的人手写，字迹不同；同一段代码让不同的机器渲染，像素也不同。

再叠加时区、语言、屏幕分辨率、是否装了某些插件，几十个维度组合起来，碰撞概率就非常低。有研究指出，仅 Canvas 一项在普通用户群体里的区分度就相当高，加上其他维度后接近唯一。

16.6TLS 指纹：握手姿势也会暴露你

就算你把浏览器指纹全改了，还有一个地方很难改：TLS 握手时发送的那一堆参数。

TLS 客户端第一次说话时，会发一个"你好"消息（ClientHello），里面包含：支持的版本、一串密码套件、一串扩展、支持的椭圆曲线、曲线点格式。

不同的客户端库（不同版本的浏览器、不同语言的网络库）会给出不同的组合。把这些字段按固定顺序拼成一个字符串，再做哈希，就得到一个短标识。

它的价值在于识别"客户端类型"。比如服务端发现：同一个接口，九成请求的 TLS 指纹都属于某 App 的官方库，只有一小撮请求的指纹属于某个脚本库——这一小撮就值得重点看。

但它不能单独用来认人。同一个版本的 App，几百万用户共享同一个指纹。把它当"唯一 ID"用，是典型误用。

16.7HTTP 头的顺序和大小写

还有一个更细的层面：HTTP 请求头的顺序、大小写、有没有多余空格。

正规的网络库通常按固定顺序输出头，大小写也统一。而用脚本手工拼出来的请求，顺序往往和官方库不一致，甚至会出现不该有的头。

比喻：伪造一封信，内容可以抄得一字不差，但信封的折法、邮票贴的位置、笔迹的力度，往往会露馅。

服务端把"头顺序 + 头名大小写 + 头集合"作为一个整体特征，和账号、设备、IP 一起看，就能发现"这个请求不是这个 App 发的"。

16.8一致性校验：矛盾才是信号

前面讲的都是"采集"。真正决定风控效果的，是参数之间对不对得上。

单点异常很常见（用户换了网络、装了新输入法），所以不会直接判定。但多个维度同时矛盾，就很难解释了。

常见的矛盾类型有四组：

• 性能与行为：参数显示是低端机，行为却是高频并发。
• 时间与地点：时区、语言、IP 归属地三者互相打架。
• 新与重：设备是全新的，但操作路径像老手，直接找到最深的功能。
• 账号与设备：一个新设备，登录了一堆注册时间接近、行为相似的账号。

这些矛盾单看都不致命，组合起来就有说服力。风控的本质是概率判断，不是事实认定，所以它给出的通常是"分数"和"动作"，而不是"结论"。

16.9关系图谱：从单点走向网络

单台设备的信息再多，也有上限。真正的识别能力来自关系。

把账号、设备、IP、支付方式、收货地址都当成"点"，把它们之间的使用关系当成"线"，就得到一张图。风控在这张图上找"团伙"：

• 多个账号共用同一台设备；
• 多个设备共用同一个支付账号；
• 一批账号在短时间内从同一批 IP 登录；
• 多个账号填写的收货地址高度重合。

比喻：单看一个人可能毫无问题，但一看他的人际关系图，全是同一伙人，那就值得注意了。

图谱的价值在于抗伪造：你可以改设备参数，但改不了"你的支付账号和另外二十个账号绑在一起"这个事实。

16.10隐私合规：能哈希就不存明文

指纹技术天然涉及个人信息，所以合规不是可选项。

• 告知同意：采集哪些参数、用来做什么、保存多久，要说清楚。
• 最小必要：能不用 IMEI 就不用，能用匿名标识就不用硬件号。
• 能哈希不存明文：设备号、手机号这类值，存哈希比存原文安全得多。
• 可撤回、可删除：用户要求删除时，要能真正删掉。

哈希也有讲究。手机号只有十一位，直接做一次 SHA-256 是可以被穷举的——攻击者把所有可能的号码都算一遍，就能反查。所以正规做法是加盐（在原文里混入一段随机值）或用带密钥的哈希。

16.11两个最常见的误区

误区一：改一个参数就能换身份。很多人以为改掉设备号就"变成新设备"了。但风控看的是组合：设备号变了，硬件参数没变、行为习惯没变、IP 没变、支付方式没变，几十个维度里只有一个变了，反而更可疑——正常用户换手机，是整机参数一起换。

误区二：指纹等于唯一 ID。指纹是一组概率性的特征，不是数据库主键。它会有碰撞（两台设备算出一样的组合），也会有漂移（系统升级后特征变了）。所以工程上用的是"置信度"，不是"是或否"。

还有一个相关误区：以为指纹只在客户端采集。实际上服务端能看到的东西同样多，甚至更多——TLS 指纹、请求头顺序、时序特征，这些客户端根本改不了。

纯协议登录：一个完整案例的全链路

不启动 App，只用代码把登录过程重做一遍，到底要发几个请求、带哪些字段、在哪一步判断成败？这一页用一个脱敏的电商类 App 做样本，把六个请求串成一条可以逐步验证的链路，并告诉你什么才算真正跑通。

17.1什么叫"纯协议"

"纯协议"这三个字，指的是不启动 App、不点界面，直接用代码构造 HTTP 请求，把 App 在背后做的事情在命令行里重做一遍。它不需要手机，也不需要模拟器，只需要一台能联网的电脑。

你可以把它想成不去柜台排队，而是照着柜台的表单格式，把材料直接寄过去。表单的栏目、顺序、盖章位置都必须对，错一项就被退回。

要跑通它，至少需要三样东西：

• 看得懂请求：知道每一步发到哪个路径、带哪些字段，这来自抓包；
• 算得出签名：请求里通常有一个随时间变化的签名字段，这来自逆向或算法还原；
• 保得住会话：登录成功后拿到的 Token 要能存下来、带上去、及时换。

17.2案例背景：一条被拆成六步的登录链

样本是一个电商类 App 的账号密码登录。为了避免指向任何真实系统，下文域名统一写成 api.example.com，路径和字段名都做了替换，数值只作示例。

这个 App 的登录不是"一个请求搞定"，而是六个请求前后依赖，像一条流水线：

1. 设备注册：先告诉服务端"我是一台什么设备"，换回一个设备编号；
2. 预登录：领取本次登录专用的盐值和挑战码；
3. 登录：提交账号、密码派生值、挑战答案和签名；
4. 换取 Token：用登录结果换访问凭证；
5. 拉用户信息：验证这张凭证是不是真的能用；
6. 业务接口：取购物车、订单等真实数据，确认整条链真的通了。

依赖关系很清楚：第 1 步的 deviceId 是后面每个请求的必需参数；第 2 步的盐值和挑战码决定第 3 步的签名内容；第 4 步的 Token 决定第 5、6 步能不能过。

这条链有个很坑的特点：任何一步失败，后面都会以"参数缺失"或"未授权"结束，而不是告诉你真正的原因。所以排错必须从第一步开始，不能从报错的那一步猜。

17.3全链路时序：六个请求的先后关系

为什么第一步必须是设备注册？因为服务端需要给你发一个稳定的编号，用来关联后续的登录、风控和行为记录。没有这个编号，登录请求会被当成"来路不明"，很多系统会直接返回一个含糊的错误。

为什么要有预登录？如果每次登录都用同一个固定签名，别人抓一次就能无限重放。预登录下发一次性的盐值和挑战码，让每次的签名都不一样。这就像考试前先领一张带编号的答题卡，抄上次的答案没有用。

17.4每一跳的请求结构

下面这张表只列决定成败的字段。真实请求还会有一些通用头，例如内容类型、客户端标识，它们不参与核心判断，但缺失时同样可能被拒。

17.5签名参数从哪来

签名的本质，是给这一堆参数按一个只有双方知道的规则算一个"指纹"。服务端收到后按同样规则再算一遍，两边一致才认。所以签名的输入必须双方都能独立算出来。

这个案例里，签名用到四类输入：

• 时间戳 ts：10 位秒级数字。服务端只接受与服务器时间相差 300 秒以内的请求，过期直接拒，用来压缩重放的窗口；
• 随机数 nonce：每次请求重新生成。服务端短期缓存用过的值，重复即拒，用来防止同一时间窗内的重复提交；
• 设备标识 did：注册时拿到。它把签名和具体设备绑在一起，换设备后旧签名就失效；
• 请求体哈希 bodyHash：把请求体按固定规则序列化后做 SHA-256。任何一个参数被改，哈希就变，签名随之失效。

用伪代码写出来大概是这样，注意这里只是示意，真实项目里参数名和规则都不一样：

# 伪代码：算一次签名
params = {
    "account": user,
    "deviceId": did,
    "nonce": rand_hex(16),
    "ts": now_seconds(),
    "bodyHash": sha256(canonical_json(body)),
}
raw = "&".join(k + "=" + params[k] for k in sorted(params))
sign = hmac_sha256(secret, raw).hex()

# 结果放进请求，body 原样发送
headers["X-Sign"] = sign
headers["X-Ts"] = params["ts"]

密钥从哪来？三种常见情况：编译在本地库文件里、由服务端在预登录时下发、或者设备注册时协商。算法版本号也会随 App 升级变化，所以签名逻辑通常需要持续维护，而不是一次写好就永久有效。

17.6会话保持：Token 放哪里，什么时候刷新

登录成功后拿到的 Token，就是后面所有请求的通行证。它通常放在请求头里，最常见的形式是 Authorization: Bearer 一串字符，也有放在自定义头或 Cookie 里的。

有效期各家不同，常见是 2 小时到 7 天。系统一般还会给一个有效期更长的刷新凭证，用来在不重新输密码的情况下换新 Token。

• 主动刷新：在到期前 5 分钟换一次，避免请求打到一半过期；
• 被动刷新：收到 401 时先刷新一次，刷新也失败才重新登录；
• 单会话限制：很多系统同一账号只允许一个有效 Token，重复登录会把旧的顶掉。

17.7端到端判据：不是 HTTP 200

初学者最容易在这里误判：看到状态码 200、看到返回里有一个 code: 0，就认为登录成功。其实网关只要把请求转给后端就会回 200，业务失败也常常包在 200 里，用响应体里的业务码表示。

为什么"有 Token"也还不算？因为 Token 可能是空串、可能是过期占位符、也可能权限不足。真正的判据是：调一个必须登录才能访问的业务接口，返回的数据字段非空且结构符合预期。

把判据写成断言，程序才能自己判断成败，而不是靠人看日志：

• 状态码等于 200，且响应体能正常解析；
• Token 字段存在，长度大于 20，字符集符合预期；
• 用户信息里 uid 非空，昵称或手机号后四位存在；
• 购物车列表能解析成数组，且元素数量与账号状态相符。

17.8失败分支与错误码

排错的第一步不是改代码，而是把失败分类。同样是"登录失败"，原因可能完全不同，处理方式也相反。

这张表的价值在于：它把"重试"和"不重试"分开了。401 值得刷新一次，429 值得等一会儿，403 和 1002 继续重试只会让情况更糟。

17.9和"自动化点界面"比，差在哪

两种方式都能完成登录，但适用的场景完全不同。纯协议不是"更高级"，它只是把变量换了一个位置。

纯协议的优势是快、可观测、省资源；代价是你必须完全理解签名和会话，任何一个字段算错都跑不通。界面自动化相反：不用懂协议，但慢、脆、难排查。

17.10合规边界：这条链路只能用在哪里

这一页讲的是原理和工程方法，落到实践必须满足三个前提：

• 目标自有或书面授权：自己的系统、客户明确授权的系统、公开教学靶场；
• 遵守平台规则与法律：不碰他人账号，不采集超出范围的数据，不做影响服务稳定的事；
• 数据最小必要：日志里不存明文密码，手机号、地址等个人信息脱敏或哈希后再保存。

签名与风控包：构造原理与一致性

服务端看不见你的手机，它凭什么判断一个请求"像人发的"？答案藏在客户端随请求附带的那一包字段里。这一页讲清风控包的分层结构、签名链路，以及为什么单点伪装没有用。

18.1风控包是什么：一份客户端自报的体检报告

你打开 App，服务端其实什么也看不见。它不知道你的手机是什么型号、屏幕多大、在哪个时区、刚才点得快不快。这些信息只能由客户端自己报上去。

客户端上报的这组信息，通常塞在请求头的一个 JSON 字段里，或者放在请求体的固定位置。业内叫法不统一，有叫设备信息、有叫风险参数、有叫指纹包，这一页统称"风控包"。

它不是 HTTP 标准的一部分。每个公司自己定义字段名、编码方式和加密方式，所以你在不同 App 上看到的形态完全不一样。这也意味着没有通用模板，只能一个目标一个目标地看。

为什么要有这个东西？因为"自报"天然不可信。服务端能做的，是让自报的细节足够多、彼此足够自洽，从而提高伪造的代价。它不追求"证明你是好人"，只追求"让造假变得不划算"。

18.2风控包一般包含哪几类字段

虽然字段名千差万别，但按用途归类，基本逃不出六类。理解分类比记住字段名有用，因为字段会变，分类不会。

18.3为什么字段这么多：细节密度就是成本

一个字段很好编，十个字段就难了，几十个彼此关联的字段几乎编不圆。这就是风控包设计的核心逻辑：用细节密度换伪造成本。

举个具体例子。一台真实手机上报的字段是相互约束的：

• 机型决定了屏幕分辨率的合理范围；
• 分辨率决定了像素密度和屏幕尺寸；
• 系统版本决定了可用的接口和字体集合；
• 时区决定了语言习惯和当前时间；
• 传感器数量和型号决定了这台设备能不能"感知"移动。

如果你只改机型，分辨率却还是五年前小屏机的值，传感器数量是 0，系统版本又是最新的，这三条放在一起就互相打架。服务端不需要知道哪一条是假的，只要发现"这个组合在真实设备里不存在"，就可以打低分。

18.4签名与加密：六个层次别混在一起

很多人把编码、哈希、加密、签名混成一件事。它们在链路里各占一层，作用完全不同。先看一条完整的处理链：

三件事必须分清：

• 编码（如 Base64）：只是换一种写法，任何人可还原，不提供任何安全性；
• 哈希（如 SHA-256）：单向，改一个字节结果全变，用来防篡改；
• 加密（如 AES）：可逆，需要密钥，用来防偷看。

常见组合是：参数排序拼接后做 HMAC 得到 sign，请求体整体加密，最外层再走 TLS。签名本身是公开传输的，这没问题——它只需要服务端能验证，不需要保密，只要密钥不泄露。

18.5时间戳、nonce、序列号，各自防什么

这三个字段经常一起出现，初学者容易觉得重复。其实它们防的是三种不同的攻击。

打个比方：时间戳是门票上的日期，过期作废；nonce 是每张票的座位号，同一座位不能坐两次；序列号是排队号，叫过号的不能再插队。三者叠加，重放的窗口被压到极小。

反过来说，如果你只带时间戳不带 nonce，那么在 300 秒的窗口内，同一个请求可以被重复使用成百上千次。这就是为什么很多系统宁可多传一个字段，也要把窗口堵死。

18.6三条构造路径：录制、参数化、纯算法

想让程序自动发出"看起来合法"的请求，历史上只有三条路。它们的稳定性差了一个数量级。

第一条路只能验证"请求长什么样"，不能用于持续运行。第二条路听起来聪明，但有个陷阱：只要改了参与签名的字段，签名就必须重算。所以"参数化"最终还是会撞上算法。

第三条路才是工程上可用的方案，代价是要把算法、密钥、拼接规则全部还原出来，并且随着 App 升级持续跟进。这也是为什么协议分析里，最花时间的往往不是抓包，而是搞清签名。

18.7一致性：字段之间会互相"打脸"

假设你要编一份体检报告。身高写 190，体重写 45，肺活量写 2000，医生一眼就知道有问题。风控包也一样，单看每个字段都正常，放在一起就露馅。

常见的矛盾组合：

• 分辨率是 1080×2400，机型却是五年前的小屏机；
• 时区是东八区，IP 归属地却在另一个大洲；
• 系统语言是简体中文，字体列表却全是英文；
• 应用版本写 8.2，客户端标识里却是 7.9；
• 首次安装时间晚于账号注册时间；
• 机型是真实手机，传感器数量却是 0。

这些矛盾不需要每一条都被检测到。服务端只要发现其中一两条，就足以把这次请求标记为"可疑"，然后降级处理：加验证码、限流、要求二次验证，而不是直接拒绝。

18.8服务端可能怎么校验

服务端的校验通常不是一道门，而是五层筛子。任何一层不过，结果不一定是拒绝，更常见的是"降级"。

把五层拆开看：

• 验签：重算签名，不一致说明参数被改过或密钥不对；
• 时间窗：时间戳偏差过大，说明请求是旧的或时钟被改过；
• 频率：同一设备或同一地址在短时间内请求过多；
• 画像：字段组合与历史记录、机型约束是否匹配；
• 序列：请求顺序是否像正常业务，例如没浏览商品就直接下单。

这五层不是每次都全跑。低风险请求可能只过前两层，高风险请求才会走完整流程。所以你在外部看到的现象经常是"有时成功有时失败"，而不是稳定的通过或拒绝。

18.9检测与防护视角：为什么单点伪装没用

安全上有个木桶效应：水位由最短的那块板决定。风控包也是，整体可信度由最不自洽的那个字段决定。你把机型改得天衣无缝，只要时区和地址对不上，前面的努力全部作废。

从防守方角度看，一套好的校验体系要满足四点：

• 多维度：不依赖单一字段，任何单点被攻破都不致命；
• 可解释：每个低分要能说清是哪条规则触发的，方便运营复核；
• 可运营：阈值能调、规则能灰度、误伤能回滚；
• 可对抗：定期看新型伪造手法，更新约束关系。

反过来，从分析者角度看，这也解释了为什么"找一个能过检的字段"是伪命题：系统看的不是某个字段的值，而是整份报告的内部逻辑。这一页只讲原理，不针对任何具体平台提供操作步骤。

18.10合规提醒

风控包里大量字段与个人信息相关：设备标识、位置、网络、行为轨迹。处理这些数据必须守住几条线：

• 授权范围：只对自有系统或书面授权的目标做分析；
• 最小必要：只采集完成目标所需的最少字段，不扩大范围；
• 告知与同意：涉及真实用户数据时，必须有明确的告知与同意基础；
• 脱敏存储：能哈希就不存明文，日志里的手机号、地址要打码；
• 可删除：任务结束后按约定清理原始数据。

自动化工程：从能跑到跑得稳

手动跑通一次，和每天稳定跑几千次，中间隔着一整套工程。这一页讲状态机、重试、限速、断点、日志和密钥管理——它们不产生"新功能"，但决定了系统能不能长期活下去。

19.1单次成功，和规模化之间隔着什么

第一次跑通脚本的时候，人很容易产生错觉：接口通了、数据拿到了，事情就完成了。但这只是"一次成功"，离"稳定运行"还有很远。

算一笔账。假设单次成功率是 95%，看起来很高。连续跑 1000 次，全部成功的概率是 0.95 的 1000 次方，大约是十的负二十三次方——比连续中几次彩票还难。也就是说，在规模化场景里，"不出错"才是小概率事件。

19.2状态机：让程序知道自己走到哪一步

最朴素的脚本是一条直线：初始化、登录、取数据、结束。中间任何一步失败，整个进程就退出，下次只能从头再来。规模化之后，这种做法会浪费大量已经完成的步骤。

更稳的做法是把流程写成状态机：程序随时知道自己处在哪个状态，以及什么条件能进入下一个状态。

状态机有三个直接好处：

• 可恢复：进程重启后读一下任务表，就知道该从"登录"还是"业务"继续；
• 可测试：每个状态可以单独测，不用每次跑完整条链；
• 可观测：日志按状态归类，一眼看出卡在哪一步。

可以把它想成电梯：待机、上行、下行、开门、故障，每个状态都有明确的进入条件和退出条件。电梯不会"大概在动"，程序也不该"大概在跑"。

19.3重试与退避：只重试值得重试的错误

重试不是"失败就再来一次"。错误的分类比重试次数重要得多。网络抖动值得重试，参数写错重试一万次也没用。

先分清两类：

• 可重试：连接超时、读超时、服务端 5xx、限流 429；
• 不可重试：400 参数错误、403 拒绝、业务码明确表示失败、以及 401（应先刷新 Token，而不是原样重试）。

可重试的错误也不能立刻重试，否则会在服务端最脆弱的时候继续加压。标准做法是指数退避：第一次等 1 秒，第二次 2 秒，第三次 4 秒，第四次 8 秒，设一个上限比如 30 秒，最多重试 4 次。

为什么要加抖动？假设 1000 个任务在同一秒全部失败，如果都按固定 4 秒重试，第 4 秒会再来一次 1000 个请求的尖峰，服务端可能直接崩掉。加随机抖动后，重试被摊平到一个区间里。

还有一个容易被忽略的前提：幂等。重试之前要问自己，这个操作重复执行会不会产生副作用。查询接口天然幂等，重复调用没问题；下单、支付这类写操作，必须有幂等键，否则重试等于重复提交。

19.4限速与并发：快不等于猛

新手最容易犯的错，是把并发开到最大。并发不是免费的：服务端有连接数和限流，网络有带宽，风控有频率阈值，任何一个先到顶，结果都是更慢、更容易失败。

控制节奏最常用的工具是令牌桶：桶里最多放 20 个令牌，每秒补充 5 个，每个请求执行前先取一个，取不到就等。这样既允许短时突发，又把长期速率压在 5 次每秒。

并发数可以用一个粗略公式估算：

• 并发数约等于目标每秒请求数乘以单次平均耗时；
• 例如目标每秒 20 次、单次 200 毫秒，理论并发是 4；
• 实际取 3，留出余量给网络抖动、重试和服务端抖动。

更进一步的做法是自适应：监控最近一分钟的错误率，超过 5% 就把并发减半；低于 1% 且持续 5 分钟，再缓慢加回来。这样系统能自己找到当前环境下的合理速度，而不是靠人拍脑袋。

19.5断点续跑：进程死了也能接着干

批量任务最怕"跑到一半崩了，全部重来"。解决办法是把进度写进一张任务表，而不是只存在内存里。

任务表至少要有这些字段：

• task_id：任务唯一编号；
• dedup_key：业务唯一标识的哈希，用来去重，防止重复入队；
• status：pending、running、done、failed、skipped；
• attempts：已尝试次数，配合最大重试次数；
• next_run_at：下次允许执行的时间，退避就写在这里；
• last_error：最后一次错误摘要，方便复盘。

启动时先做一次"自愈"：把所有状态是 running、但超过 10 分钟没有更新的任务重置为 pending。这对应"进程崩溃时来不及改状态"的情况。

这就像下载器的断点续传：文件下到 60% 断了，下次从 60% 接着下，而不是从 0 开始。

19.6日志与可观测性：出事了能查

"跑得稳"不只是不出错，还包括出错时能快速定位。这依赖结构化日志，而不是满屏的打印。

结构化日志的意思是：一行一条 JSON，字段固定，机器能检索、人能看懂。每条至少包含：

• 时间、日志级别；
• request_id：一次任务的所有请求共用同一个编号，方便串起来看；
• task_id、当前状态或阶段；
• 耗时（毫秒）、状态码、错误分类。

除了日志，还要看几个指标：成功率、95 分位耗时、重试率、限流命中次数、风控命中次数。这几个数字一旦异常，往往比单条报错更早发现问题。

日志里不能出现明文密码、完整 Token、完整手机号。Token 只留前六位，手机号中间四位打码，这是底线。

19.7配置与密钥管理：别把钥匙贴在门上

把密钥写进代码，是最常见也最危险的省事做法。代码一旦进仓库、被复制、被截图，密钥就等于公开了。

• 不写死：密钥放环境变量或专门的密钥管理服务，代码里只读不存；
• 分环境：开发、测试、生产各用各的配置，不要一套密钥走天下；
• 定期轮换：旧密钥保留一段过渡期，确认无调用后再停用；
• 最小权限：每个任务只拿它真正需要的权限，不做"万能账号"。

配置文件也要能区分环境，并且把敏感项单独抽出来。提交代码前跑一次检查，确认没有密钥、没有真实用户数据。

19.8失败分类：不同病，不同药

把所有失败都叫"报错"，是排查效率低下的根源。下面这张表是工程上最实用的分类方式。

这张表的关键不在"重试几次"，而在"哪一类不该重试"。把不可重试的错误反复重试，轻则浪费配额，重则触发更严格的限制。

19.9数据存储：留证据，也留退路

一个成熟的自动化系统，数据通常分三层存：

• 原始报文：请求和响应的原文，压缩后保留 7 到 30 天，用于复现和举证；
• 解析结果：清洗后的结构化数据，带 request_id，供后续分析；
• 失败样本：按错误类型分目录保存，保留更久，用于复盘和回归测试。

三层各有用途：原始报文回答"当时到底发了什么"，解析结果回答"业务上得到了什么"，失败样本回答"为什么没成"。只存其中一层，出问题时就只能猜。

存储时同样要脱敏。个人信息能哈希就哈希，能删就删，保留期限写进配置，到期自动清理。

19.10两个误区与合规边界

误区一：并发越高越快。实际上服务端限流、带宽争抢、风控频率阈值都会让高并发变得更慢。真正决定吞吐的是"服务端愿意接受的速度"，不是"你能发多快"。

误区二：重试能解决所有失败。401、403、400 重试只会浪费配额，甚至让账号被限制。重试只对"临时性故障"有效，对"确定性拒绝"无效。

最后是边界。自动化系统跑起来之后，影响的是真实服务，必须守住四条：

• 只对自有或书面授权的目标运行；
• 遵守约定的频率，不做压力测试式的高并发；
• 不采集超出范围的数据，个人信息最小必要；
• 随时可停，有总开关，异常时能立刻降速或停止。

排错手册：症状、原因与定位顺序

同一个"登录失败"，可能是手机没网，可能是代理证书没装，也可能只是签名里少了一个字段。这一页给你一套固定顺序：先分层定位，再二分缩小，最后最小复现。照着走，不靠猜。

20.1三条铁律：顺序比经验重要

老手排错看起来很快，不是因为他记得更多报错，而是因为他从不跳步。三条铁律，顺序不能换：

为什么顺序不能换？因为分层决定"往哪看"，二分决定"看多细"，复现决定"结论算不算数"。跳过第一步，你会在一堆无关的代码里翻半天；跳过第三步，你改完一次以为好了，明天又坏。

20.2分层定位：从上往下走七级台阶

一次请求从手机到服务器，要经过七道关。任何一道关了，你看到的都是"失败"，但失败的原因完全不同。按下面这张图的顺序走，每一层只问一个问题：这一层通了吗？

每一层的验证动作都很便宜，一句话就能做完：

20.3症状对照表：把现象翻译成原因

下面这张表是本页最该收藏的部分。左边是你看到的现象，中间是最可能的原因，右边是验证动作和下一步。查到对应行，就按那一行的顺序做，不要跳到别的行。