分享日常工作生活中的所思所想，拒绝碎片化信息，通过阅读和博客沉淀深度思考。
","icon":"https://cdn.madeai.eu.org/blog-madeai-eu-org/production/images/channel-b4ee93e4522a2b7a4690f12bf5d4960a.png","favicon":"https://cdn.madeai.eu.org/blog-madeai-eu-org/production/images/favicon-6920fee38a77ad3a22da59b4571d4660.png","authors":[{"name":"DylanYang"}],"language":"zh-cn","items":[{"id":"BJndgcYhWBB","title":"逆向小米运动健康：从抓包到生成 FIT 文件","content_html":"我用小米手环记录运动已经快两年了。某天想把骑行数据导进 Strava 做路线分析，才发现问题：官方 App 的导出能力相当有限，而云端其实存着远比界面展示更丰富的原始数据——逐秒心率、速度、踏频、GPS 轨迹、甚至游泳每一趟的配速和划水次数，全都躺在服务器上，只是没有出口。
\n于是我决定自己做这个出口。最终成果是一个本地 Web 应用 ~/mifit-web（Flask + 离线自包含前端），能直接对接小米运动健康后端，拉取 → 解密 → 解析 → 生成标准 .fit 文件，也能在网页上看完整的数据分析和轨迹地图。
这篇文章记录整个逆向过程——包括那些让我卡了好几个小时的坑。如果你也在做类似的 App 数据自救，希望这些经验能省你一些时间。
\n先说结论：这套流程目前跑通了 416 条运动记录，覆盖 2024-10 到 2026-09 共 23 个月、18 种运动类型，解析出的时长、心率、卡路里与官方报表零条不匹配。
\n目标 App com.xiaomi.miwatch.pro，后端 hlth.io.mi.com。iOS 上我用 HTTP Catcher 抓包，产物是 .hcf 文件。
解析 .hcf 时第一个意外是：HTTP 头在一条记录里，加密参数的表单却在紧随其后的另一个分片里。记录头格式是：
00 00 0c 05 (请求) / 00 00 0c 08 (响应)\n+ reqseq(4) + ts(8, 毫秒) + paylen(4)要把请求行和它的参数表单配对。我一开始按时间顺序配对，签名校验率只有 47%——因为相邻请求的表单会互相串位。
\n改成按文件位置划窗口，再用「哪个候选的 data 能解出合法 JSON」来定绑，校验率立刻升到 79%。
还有个很隐蔽的坑：提取 _nonce 的正则如果写成 _nonce=([^\\x00\\r\\n ]+)，会贪婪地吞掉后面整个查询串——实测 nonce 变成了 287 个字符。结果是所有候选都不满足「nonce 长 12/16」而被丢弃，表现为「表单 0 个、请求 0 条」，可正则明明匹配到 21 处。正确写法必须排除 &：
_nonce=([^\\x00\\r\\n &]+)另外 token 有域的概念：抓包里会同时出现两个 serviceToken——hlth 域的约 172 字符，api.io.mi.com 的约 216 字符。取错就一直是 auth err。
小米这套接口的每个请求都带三个加密参数：data（业务数据密文）、rc4_hash__、signature。要自己构造请求，必须完全复现它的算法。反编译 APK 后我一点点把逻辑拼了出来，其中最要命的一条是这个：
看 esj 类的构造函数结尾有一句 b(f17415b)，而 f17415b 是一个 new byte[1024] 的全零数组——等于用 1024 个 0x00 去预热 RC4 状态机。
所以实际 keystream 是从第 1024 字节开始的。如果按标准 RC4 从 0 开始取，得到的是高熵垃圾，还会误判成「security 不对」，一路往错误方向排查。这是整件事里最大的时间黑洞。
\nt12.i() 是标准 Base64，不是 hexdigest。判据：signature 密文 28 字符（= 20 字节 SHA1），rc4_hash__ 密文 40 字符（= 28 字节）。如果你算出 40 字符的十六进制串，说明用错了 hexdigest()。y54.c 只 new esj(strB) 一次，然后按 TreeMap 顺序切分：data 占 K[0:n]，rc4_hash__ 接着 K[n:]。只单独解 data 看不出问题，校验第二个参数时才会暴露。rc4_hash__ 用明文 kv 算，signature 用密文 kv 算。两者都不包含 _nonce / signature / rc4_hash__；而 data 自身不在签名 kv 里，是以字面量 data=<值> 的形式拼进签名串的。raw32 = SHA256( b64decode(security) || b64decode(_nonce) ) # 32 字节\nstrB = base64encode(raw32)\n\n# y54.c —— GET/POST 通用（注意：不是 y54.d）\nrc4_hash__ = b64(SHA1( METHOD & path & \"k=v\"按key排序 & strB )) # 明文 kv\nrc4 = RC4(raw32, skip=1024) # 整条请求只建一次！\nfor k in sorted(treeMap):\n out[k] = b64( rc4.xor(utf8(treeMap[k])) )\nsignature = b64(SHA1( METHOD & path & \"k=v\"按key排序 & strB )) # 密文 out\nout[\"_nonce\"] = nonce_nonce 的构造是 base64( 8字节随机 + int32_be((now+timeDiff)//60000) )，共 16 字符——末 4 字节是大端分钟数，正好可以用来核对抓包时间。
还有个必须知道的事实：security 会随登录变化，必须用与目标请求同时段的那个。来源是响应头 extension-pragma 里的 ssecurity，或登录响应 JSON 的 data.ssecurity。
算法复现对了（重新加密能和抓包原值逐字符比对一致），但请求发出去仍然是 401。又踩了三个坑才通：
\n# ✓ 对\nkv = {\"data\": '{\"watermark\":0,\"limit\":30}'}\n# ✗ 错（会一直 401！）—— 把 JSON 字段拆成独立参数\nkv = {\"watermark\": 0, \"limit\": 30}拆开算签名，服务端一律返回 auth err。验证方法：用已知明文重新加密，和抓包原值逐字符比对，三个字段必须全对。
@Secret(pathPrefix=\"healthapp/\") → 签名要用裁剪后的 subpath规则在 CloudInterceptor.subpath：如果 pathPrefix 非空，就取 URL 中该子串出现位置之后的部分；为空则从第一个 / 起取。
URL /healthapp/service/gen_download_url\n签名 /service/gen_download_url ← 用这个算 signature / rc4_hash__同理 /healthapp/home/profiles → /home/profiles。而 /app/v1/*、/ops/v1/* 的 pathPrefix 为空，用完整路径。这一条解开后，401 立刻变 200。
要按顺序试：① 明文 JSON（不加密的端点）；② gzip 包着的 base64 密文（chunked 响应）；③ 直接就是 base64 密文（非 chunked 响应，实时 API 常见）。
\n拿到接口还不够——真正的原始数据（逐秒心率、GPS 轨迹）是通过一个文件下载接口拿的，返回的是加密文件。我一度以为解不开，后来发现密钥就明晃晃地放在 gen_download_url 的响应里：
{\"result\": {\"<suffix>_<ts>\": {\n \"url\": \"https://cnbj1.fds.api.xiaomi.com/...\",\n \"obj_key\": \"[REDACTED]\", ← AES 密钥在这里\n \"method\": \"GET\"}}}反编译确认了 AESCoder(String aesKey) { this(Base64.decode(aesKey, 8)); }，于是：
key = base64.urlsafe_b64decode(obj_key + '=' * (-len(obj_key) % 4)) # 16 字节\nIV = b'1234567887654321' # AESCoder.getInitialVector() 硬编码\nalgo = AES/CBC/PKCS5Padding\n\nct = base64.urlsafe_b64decode(txt + '=' * (-len(txt) % 4))\nraw = AES_CBC_decrypt(key, IV, ct) 然后 PKCS5 unpad每份文件的 obj_key 各不相同（GPS 文件和打点文件的密钥不一样），必须各自取用，不能复用。
① 裸 base64url，'=' padding 被剥掉 b'iLgArCVs8Jn...c'\n② JSON 字符串（带双引号），同样无 padding b'\"4feFfXCJLHKw...q\"'只 .strip() 去不掉引号。而更阴的是——引号恰好让长度凑成了 4 的倍数，于是代码跳过了补 padding 的逻辑，解码时长度又少 2 → 抛 Incorrect padding。
症状很有意思：一部分活动（乒乓球、腰部训练、钓鱼……）详情页直接报错，另一部分完全正常。原因是这两类活动走的分支不同。修法是先剥引号、再按真实长度补 =。
解密后得到的是 schema 驱动的二进制。解析器在 APK 里是 com/xiaomi/fit/fitness/parser/schema/ 那一套。以 GPS 文件为例，头部 9 字节：
[0:4] timestamp u32LE [4] timezone u8 [5] version u8\n[6] fileType bitField: normalDataFlag(7) dataType(6..2) fileType(1..0)\n[7] encComp bitField: encryptionMode(7..4) compressionMode(3..0)\n[8] validity bitField: time(7) lon(6) lat(5) acc(4) speed(3) src(2) alt(1) hdop(0)点字段必须按 schema 的固定偏移，不能顺次臆测：
\n[0:4] time u32LE\n[4:8] longitude f32LE\n[8:12] latitude f32LE\n[12:16] locationHorizontalAccuracy f32LE ← 水平精度，不是海拔！\n[16:18] locationSpeedAndGpsSource u16LE speed=(v>>4)/10 m/s, src=v&0x0F\n[18:22] altitude f32LE\n[22:26] hdop f32LE我一开始把 [12:16] 当海拔，结果拿到的是水平精度——平坦路恒为 4.75m，定位野值点跳到 1448，看着像条曲线，其实毫无物理意义。这类「看着合理但完全错误」的 bug 最难发现。
同一个 App 导出的文件，因为 validityFlags 决定哪些字段被写入，布局逐个活动都不同：
| 骑行 | 徒步 | |
|---|---|---|
| GPS 点长 | 18 B | 18 B |
| record 头部 | 11 B | 13 B |
| record 点长 | 7 B | 13 B |
| 速度在哪 | record 里 (u16LE@4, ×0.1) | record 里没有，只有 GPS 有 |
| 里程单位 | 米 (÷1) | 0.1 米 (÷10) |
所以解析器只能自适应探测，而关键是——用什么当校验信号？答案是官方报表。报表里的 distance / duration / avg_hrm / max_hrm / calories 就是标准答案：
body % P == 0，且时间戳单调不减、坐标聚在一小片区域、速度物理合理。(头部长度, 段头长度, 段头内偏移, 点长)，要求段链恰好走到 EOF，再加「里程合计 ≈ 报表 distance」「点数 ≈ 报表 duration」「心率列均值/最大 ≈ 报表」三重打分。record 文件是多个段拼接的，结构是「段头 + N 个点」循环直到 EOF。段头里 resumeTimestamp 是段的起始时间。
如果从 offset 0 开始扫「第一个像时间戳的 u32」，会命中段头里由掩码/里程高位拼出的伪值（实测 0x739e0000），于是把 814 秒的骑行算成 65011721 秒。
阴险的地方在于：段链本身没坏，段数/点数/里程全对，只有时长崩了，极易漏掉。正确判据要三个同时成立：
\nvals = [u32le(head, off) for each seg head]\nall(MIN_UNIX < v < MAX_UNIX for v in vals) # 全部落在合理 unix 区间\nall(b >= a for a, b in zip(vals, vals[1:])) # 跨段非递减\nall(vals[i+1]-vals[i] >= rcs[i]*0.95) # 后段起点 ≥ 前段起点 + 前段点数骑行与徒步实测都落在 offset 8。
\n| 指标 | 含义 | 实测对齐 |
|---|---|---|
报表 duration | 实际运动秒数（不含暂停）= 文件点数 | 徒步 12745 = 12745 ✓ |
end_time - start_time | 墙钟跨度（含暂停） | 骑行 1607 s ✓ |
拿 end_time - start_time 去校验 duration 会误判成 bug（骑行 1001 vs 814，看着差 23%），其实两个都对。FIT 里分别对应 total_timer_time 和 total_elapsed_time。
这是最近才攻下的部分，也是最花时间的一块。
\n小米 App 在游泳详情里会画出「分段配速」「分段划频」「分段 SWOLF」三张图。我想知道这些是本地算的还是服务端给的。反编译定位到 SportRecordConverter.java，它构造 SwimmingPassage 对象时读的是 oneSportRecord.getPace() / getSwolf()——来自服务端下发的 record 字段，不是本地计算的。wire 级字段名是 sectionPace / sectionSwolf / sectionStrokeFrequency。
但把 get_sport_records_by_time 的完整响应翻遍，value 里只有汇总字段：avg_pace、max_pace、avg_swolf、best_swolf、stroke_count、turn_count……没有任何 section 数组。
关键线索来自 schema 文件 swimming_record_v3.json——它的 dataPoint 里明确声明了 sectionPace / sectionSwolf / sectionStrokeFrequency，而且字节大小是写明的。
APK 里那个 schema 声明的是 version 8.0，dataPoint 约 35 字节。而实际文件是 version 2、每小节 26 字节——字段增删过。按 schema 硬套只会一路错位，表现为 sectionDistance 读出 65280 这种荒谬值。
实测出来的 26 字节布局：
\n+0 endTime u32 本节结束时间\n+4 dataType u8 0=小节 / 1、2=段落汇总\n+5 sectionPace u16 秒/百米 ★ 分段配速\n+7 sectionSwolf u16 SWOLF ★ 分段 SWOLF\n+9 sectionDistance u16 本小节距离(米，=池长)\n+11 activeCalories u16\n+13 totalArmPull u16 本小节划水次数\n+15 turnCount u16 本小节转身次数\n+17 sectionStrokeFrequency u8 本小节划频 ★ 分段划频\n+18 unknownStrokeFreq u8\n+19 breastStrokeFreq u8\n+20 freeStrokeFreq u8\n+21 backStrokeFreq u8\n+22 butterflyStrokeFreq u8\n+23 totalCalories u16\n+25 标志位 u8真正的障碍是：每约 4 个小节后跟一条变长的段落汇总记录（字段布局不同）。直接按固定 26 字节往前走，到那里就错位了。
\n解法是：扫描「4 字节时间戳（落在合理 unix 区间）+ 1 字节 dataType ≤ 8」的候选起点（并去除重叠），再用值域筛出真正的小节：1 ≤ 距离 ≤ 100 且 30 ≤ swolf ≤ 400 且 40 ≤ pace ≤ 1200。
单趟用时(秒) = sectionPace × 池长 / 100\nSWOLF = round(单趟用时) + 划水次数逐字节验证：id=14 第 0 趟，pace=216 × 25/100 = 54.0 秒，划水 14 次 → 54 + 14 = 68，正好等于文件里存的 swolf。
id=14 44 小节 距离 1100/1100 转身 44/44 划水 602/602\n swolf 均 66.4/66 最佳 51/51\n pace 均 211/210 最快 158/158 最慢 316/316 划频 max 24/24\nid=5 44 小节 距离 1100/1100 转身 44/44 划水 617/617\n swolf 均 71.1/71 最佳 54/54\n pace 均 228/228 最快 164/164 最慢 452/452池长从 sectionDistance 的众数推出来——因为官方报表里 pool_width 是 0，表示用户没设置过。
逆向数据最容易犯的错，是「猜一个看起来合理的值填进去」。我给自己定了两条硬规则：
\n而不是填 0。因为 0 在运动数据里是有意义的真实值（静止时速度就是 0），拿它表示「缺失」会让下游无法区分。
\n具体到 UI：缺失的卡片直接隐藏，FIT 里不写零，页面明确标注「文件里没有此字段」。
\n心率列和卡路里列在不同运动类型里位置不同：
\n骑行 P=7 ：心率 b1 | 距离 b3÷1 | 速度 b4(u16×0.1 km/h)\n室内跑步 P=12：心率 b1 | 距离 b2÷10 | 步幅 b3(cm) | 步频 b9\n徒步 P=13：心率 b1 | 距离 b3÷10 | 步幅 b4(cm) | 步频 b10\n室内健身 P=4 ：心率 b0 | 卡路里 b1 整字节\n爬楼机 P=4 ：心率 b0 | 卡路里 b1 整字节\n椭圆机 P=3 ：心率 b1 | 卡路里 b0 高 4 位这里踩过一个很典型的坑：hr_col = detect(...) or 1。列号 0 是合法值，但 0 or 1 == 1，结果室内健身和爬楼机的心率被解成 1/1。
另一个：卡路里探测写成「只有点长 ≥ 6 才读」，而爬楼机 P=4、椭圆机 P=3，结果是这些类型的卡路里永远是 0。改成用官方 calories 反查（逐点求和 ≈ 官方值 ±3%，优先取值多样的列），命中率：爬楼机 254/254、室内健身 7/7、椭圆机 242/242、室内跑步 323/323、徒步 1335/1335、骑行 95/96。
有些官方值是滤波/派生过的，和原始文件算出来的天然不同。比如「最大速度」：徒步原始 GPS 最大 17.64 km/h，官方只报 6.91；而骑行两者几乎一致（37.80/37.76、41.04/41.01、57.60/56.94，差 <1.5%）。
\n所以对照表里这类差异标蓝色「说明」而非红色叉号——对不上不代表解错了。
\n一份完整的 FIT = GPS 文件 + record 文件，按时间戳合并。
\ngps_by_t.setdefault(t, []).append(g) 全部保留，否则会丢掉约 69 个点（746 → 677）。distance 必须按时间轴单次累加：先把 newDistance 按时间累加成 dict，GPS 独有的秒沿用上一个累计值。分段累加会算成 4201m（超过报表的 4088m）。speed 单位是 m/s；record 里是 km/h × 10，GPS 里是 m/s（÷10 后）——别混。所有 timestamp 必须减 631065600（FIT 纪元是 1989-12-31 UTC），否则解出来是 2046 年。这是最容易漏的一步。
产出校验（883 records，CRC 全部无错）：
\n含GPS=746 含心率=866 距离末值=4088.0m 单调递增=True\n心率 均126.1/最大171 速度最大37.80 km/h\nsession: cycling | 4088.0m | 1001.0s | 95kcal | HR 127/171小米的 GPS 文件里不含海拔字段（实测导出都是 18 字节变体，只写到 speedAndSource），小米也没有「查任意坐标海拔」的接口。所以只能用第三方 DEM 按坐标补。
\n这里有个值得记的教训：数据集选错会让累计爬升虚高好几倍。
\n我最初用 ASTER GDEM，一条 250km 的骑行算出累计爬升 2989m。但对比别人相似路线的 800m 左右，差距太大。查下来原因是：ASTER 在珠三角冲积平原会把 8m 的城区读成 43m（+35m 伪影），250km 里被累加了 537 次。
\n换成 SRTM 后同一条路线是 1260m。地标真值也支持这个结论：顺德大良城区实际约 8m，ASTER 读 43m，SRTM/mapzen 读 14m；而皂幕山 805m，三套数据都给 796~798。
\n算法上也做了修正：累计爬升用滞回阈值 + 按距离 100m 等间隔重采样，而不是直接把所有正增益加起来（DEM 的整米阶梯噪声会被全算成坡）。并且报告一个不确定度区间（T=5/T=12 两端）而非单一数字——250km 骑行的区间是 983~1744m。
\ndays = int(x) or 90 是个陷阱。前端「全部」按钮传 days=0，被当成 falsy 静默变成 90 天。要显式判 None，再把 <=0 映射成上限。duration 等于文件里的点数，但 end_time - start_time 包含暂停。1000 / step_m）；且全程配速要用全部秒数（即官方 duration 的语义），用「有位移的秒数」会偏快（6'01\" vs 官方 6'29\"）。回头看，整个逆向过程里最有价值的不是某个具体发现，而是这套验证习惯：
\nsignature 当试金石。它对已知密文做哈希，所以只要猜中 security 就能立刻验证，不必等明文解对。比盲试解密快得多。data 不代表算法完整，只有同时校验 rc4_hash__ 才会暴露「共享 keystream」这类坑。Incorrect padding、sectionDistance=65280 这类异常，背后往往都是一个真实的结构性发现。现在这套东西是一个本地 Web 应用（Flask + 离线自包含前端，图表和地图都不依赖外网 CDN）：
\n整个解析链路的核心设计原则是自适应 + 用官方值校验，而不是写死任何字节数——因为同一个 App 导出的文件，布局本来就逐个活动不同。
\n如果你也在做类似的事，希望这篇能帮你绕过那几个最深的坑。尤其是那个 RC4 跳过 1024 字节——它真的浪费了我很多时间。
\n本文所述均为对自有账号数据的个人备份与分析，未涉及任何服务端的未授权访问。文中所有凭证类字段均已隐去。
\n","content_text":"起因\n\n我用小米手环记录运动已经快两年了。某天想把骑行数据导进 Strava 做路线分析，才发现问题：官方 App\n的导出能力相当有限，而云端其实存着远比界面展示更丰富的原始数据——逐秒心率、速度、踏频、GPS\n轨迹、甚至游泳每一趟的配速和划水次数，全都躺在服务器上，只是没有出口。\n\n于是我决定自己做这个出口。最终成果是一个本地 Web 应用 ~/mifit-web（Flask + 离线自包含前端），能直接对接小米运动健康后端，拉取 → 解密\n→ 解析 → 生成标准 .fit 文件，也能在网页上看完整的数据分析和轨迹地图。\n\n这篇文章记录整个逆向过程——包括那些让我卡了好几个小时的坑。如果你也在做类似的 App 数据自救，希望这些经验能省你一些时间。\n\n先说结论：这套流程目前跑通了 416 条运动记录，覆盖 2024-10 到 2026-09 共 23 个月、18\n种运动类型，解析出的时长、心率、卡路里与官方报表零条不匹配。\n\n\n第一层：抓包\n\n目标 App com.xiaomi.miwatch.pro，后端 hlth.io.mi.com。iOS 上我用 HTTP Catcher 抓包，产物是 .hcf\n文件。\n\n\n坑：一条请求被拆成多条记录\n\n解析 .hcf 时第一个意外是：HTTP 头在一条记录里，加密参数的表单却在紧随其后的另一个分片里。记录头格式是：\n\n00 00 0c 05 (请求) / 00 00 0c 08 (响应)\n+ reqseq(4) + ts(8, 毫秒) + paylen(4)\n\n\n坑：绑定顺序必须按「文件位置」，不能按「时间序」\n\n要把请求行和它的参数表单配对。我一开始按时间顺序配对，签名校验率只有 47%——因为相邻请求的表单会互相串位。\n\n改成按文件位置划窗口，再用「哪个候选的 data 能解出合法 JSON」来定绑，校验率立刻升到 79%。\n\n还有个很隐蔽的坑：提取 _nonce 的正则如果写成 _nonce=([^\\x00\\r\\n ]+)，会贪婪地吞掉后面整个查询串——实测 nonce 变成了\n287 个字符。结果是所有候选都不满足「nonce 长 12/16」而被丢弃，表现为「表单 0 个、请求 0 条」，可正则明明匹配到 21 处。正确写法必须排除\n&：\n\n_nonce=([^\\x00\\r\\n &]+)\n\n另外 token 有域的概念：抓包里会同时出现两个 serviceToken——hlth 域的约 172 字符，api.io.mi.com 的约 216\n字符。取错就一直是 auth err。\n\n\n第二层：签名算法\n\n小米这套接口的每个请求都带三个加密参数：data（业务数据密文）、rc4_hash__、signature。要自己构造请求，必须完全复现它的算法。反编译 APK\n后我一点点把逻辑拼了出来，其中最要命的一条是这个：\n\n\n致命坑：RC4 必须跳过前 1024 字节 KEYSTREAM\n\n看 esj 类的构造函数结尾有一句 b(f17415b)，而 f17415b 是一个 new byte[1024] 的全零数组——等于用 1024 个 0x00\n去预热 RC4 状态机。\n\n所以实际 keystream 是从第 1024 字节开始的。如果按标准 RC4 从 0 开始取，得到的是高熵垃圾，还会误判成「security\n不对」，一路往错误方向排查。这是整件事里最大的时间黑洞。\n\n\n另外三个容易搞错的点\n\n * t12.i() 是标准 Base64，不是 hexdigest。判据：signature 密文 28 字符（= 20 字节\n SHA1），rc4_hash__ 密文 40 字符（= 28 字节）。如果你算出 40 字符的十六进制串，说明用错了 hexdigest()。\n * 一条请求内多个参数共享同一条 RC4 keystream（连续累加）。y54.c 只 new esj(strB) 一次，然后按 TreeMap\n 顺序切分：data 占 K[0:n]，rc4_hash__ 接着 K[n:]。只单独解 data 看不出问题，校验第二个参数时才会暴露。\n * rc4_hash__ 用明文 kv 算，signature 用密文 kv 算。两者都不包含 _nonce / signature /\n rc4_hash__；而 data 自身不在签名 kv 里，是以字面量 data=<值> 的形式拼进签名串的。\n\n\n完整算法\n\nraw32 = SHA256( b64decode(security) || b64decode(_nonce) ) # 32 字节\nstrB = base64encode(raw32)\n\n# y54.c —— GET/POST 通用（注意：不是 y54.d）\nrc4_hash__ = b64(SHA1( METHOD & path & \"k=v\"按key排序 & strB )) # 明文 kv\nrc4 = RC4(raw32, skip=1024) # 整条请求只建一次！\nfor k in sorted(treeMap):\n out[k] = b64( rc4.xor(utf8(treeMap[k])) )\nsignature = b64(SHA1( METHOD & path & \"k=v\"按key排序 & strB )) # 密文 out\nout[\"_nonce\"] = nonce\n\n_nonce 的构造是 base64( 8字节随机 + int32_be((now+timeDiff)//60000) )，共 16 字符——末 4\n字节是大端分钟数，正好可以用来核对抓包时间。\n\n还有个必须知道的事实：security 会随登录变化，必须用与目标请求同时段的那个。来源是响应头 extension-pragma 里的\nssecurity，或登录响应 JSON 的 data.ssecurity。\n\n\n第三层：三个把 401 变 200 的关键\n\n算法复现对了（重新加密能和抓包原值逐字符比对一致），但请求发出去仍然是 401。又踩了三个坑才通：\n\n\nA. 请求参数是「单个 DATA 字段」，值是整段 JSON 字符串\n\n# ✓ 对\nkv = {\"data\": '{\"watermark\":0,\"limit\":30}'}\n# ✗ 错（会一直 401！）—— 把 JSON 字段拆成独立参数\nkv = {\"watermark\": 0, \"limit\": 30}\n\n拆开算签名，服务端一律返回 auth err。验证方法：用已知明文重新加密，和抓包原值逐字符比对，三个字段必须全对。\n\n\nB. @SECRET(PATHPREFIX=\"HEALTHAPP/\") → 签名要用裁剪后的 SUBPATH\n\n规则在 CloudInterceptor.subpath：如果 pathPrefix 非空，就取 URL 中该子串出现位置之后的部分；为空则从第一个 / 起取。\n\nURL /healthapp/service/gen_download_url\n签名 /service/gen_download_url ← 用这个算 signature / rc4_hash__\n\n同理 /healthapp/home/profiles → /home/profiles。而 /app/v1/*、/ops/v1/* 的 pathPrefix\n为空，用完整路径。这一条解开后，401 立刻变 200。\n\n\nC. 响应解密用「请求同一个 NONCE」，且有三种形态\n\n要按顺序试：① 明文 JSON（不加密的端点）；② gzip 包着的 base64 密文（chunked 响应）；③ 直接就是 base64 密文（非\nchunked 响应，实时 API 常见）。\n\n\n第四层：原始文件的加密\n\n拿到接口还不够——真正的原始数据（逐秒心率、GPS 轨迹）是通过一个文件下载接口拿的，返回的是加密文件。我一度以为解不开，后来发现密钥就明晃晃地放在\ngen_download_url 的响应里：\n\n{\"result\": {\"