[{"data":1,"prerenderedAt":14},["ShallowReactive",2],{"case-why-we-built-devpeek-zh":3,"blog-list-zh":11},{"slug":4,"title":5,"summary":6,"date":7,"featured":8,"seoDescription":9,"html":10},"why-we-built-devpeek","我们为什么做 DevPeek（一）：HTTPS 解密了，Body 还是天书","版本日前那晚，TLS 早就解开了，改请求里一个字段却还要翻脚本加解密。于是萌生做一个把业务加解密收进代理的工具——DevPeek 从这儿开始。","2026-07-09",true,"DevPeek 起源系列第一篇：联调时请求体加解密的手工折腾，以及为什么先做一款把业务加解密收进代理的工具。","\u003Ch2>21:40，群里又 @ 我\u003C\u002Fh2>\n\u003Cp>版本日前最后一晚，测试丢过来一句：\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>「预发登录不了，线上也有用户反馈，帮忙看下？」\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>不是排期里的联调。群已经在催进度了。\u003C\u002Fp>\n\u003Cp>代理开着，HTTPS 也解得开。列表里那条 \u003Ccode>POST \u002Fapi\u002Fuser\u002Flogin\u003C\u002Fcode> 是 \u003Cstrong>200\u003C\u002Fstrong>——链路看着没问题。点开 Request，Body 却是这样：\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-json\">{\n  "payload": "U2FsdGVkX1+8K3v…（后面还有长长一串）",\n  "sign": "a8f3c2…"\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>TLS 没挂，\u003Ccode>payload\u003C\u002Fcode> 还是一截 Base64。这类接口我们项目里跑了好几年：网关包一层 body，字段再 AES，外面再拼个 sign。平时联调也会撞上，只是那晚特别赶，容不得慢慢磨。\u003C\u002Fp>\n\u003Ch2>平时能忍，一赶就崩\u003C\u002Fh2>\n\u003Cp>说白了，我的日常差不多是这样：\u003C\u002Fp>\n\u003Cp>复制密文，打开某个在线解密页——书签栏里这类页面我存了三个。贴进去，解出明文。后端说「把某个字段改成 X 试一下」，我就改完再加密回去，丢进 Postman 或脚本里重放。\u003C\u002Fp>\n\u003Cp>Charles 把 HTTPS 剥干净没问题，业务层加解密却还得换工具。平时不忙，切几个窗口也就算了；一赶时间，抓包、浏览器、终端来回跳，人很容易烦。\u003C\u002Fp>\n\u003Ch2>那一晚\u003C\u002Fh2>\n\u003Cp>Request 里的 \u003Ccode>payload\u003C\u002Fcode> 解不开，我根本看不出登录卡在哪。截了屏丢进后端群：「帮看下 body 明文？」\u003C\u002Fp>\n\u003Cp>消息发出去了，回复还没来，终端里的解密脚本已经跑起来了——干太多遍，几乎是手自己动的。\u003C\u002Fp>\n\u003Cp>同事回了一句：\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>「预发用的是 B 组 key，别按生产的解。」\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>接口其实没挂。时间先耗在密钥和环境对错了。明文都没对齐，后面没法往下查。\u003C\u002Fp>\n\u003Cp>然后后端提了个很小的验证：「把请求里的 \u003Ccode>userId\u003C\u002Fcode> 改成 0 再走一遍，看鉴权是不是误判。」\u003C\u002Fp>\n\u003Cp>这就要动 Login 发出去的那条 Request。Body 同样是密的，流程还是老样子：解出来，改字段，再加密，让 App 发出一条服务端能认的包。\u003C\u002Fp>\n\u003Cp>我在 Charles 里开了 Breakpoint，想拦下来改。打开一看，Body 全是乱码，根本动不了。只能去翻 \u003Ccode>scripts\u002Fdebug\u002F\u003C\u002Fcode> 下那份 Python，上次动还是三个月前。Postman 也能 Send 一版，可 Header、Cookie、签名顺序跟 App 真实链路对不齐，结论始终不踏实。\u003C\u002Fp>\n\u003Cp>测试还在群里催：「所以预发到底能不能登？」\u003C\u002Fp>\n\u003Cp>我在这套手工流程里磨了将近一小时。回过头想，要验证的无非一两个字段。\u003C\u002Fp>\n\u003Cp>早会前产品又丢过来：「注册流程也帮看下，加密规则和登录一样。」换个 URL，脚本复制改改——再来一轮。\u003C\u002Fp>\n\u003Cp>组里新来的后端问：「哪个接口用哪组 key？」文档在 Confluence 里。抓包工具的界面上，当然看不到。\u003C\u002Fp>\n\u003Ch2>卡住的从来不是 TLS\u003C\u002Fh2>\n\u003Cp>Charles、Fiddler 把 HTTPS 剥干净，这件事本身很有价值。真正耗人的是再往上一层：请求 Body 仍是密文，每一次改请求、每一次重放，都还得人手完成加解密。\u003C\u002Fp>\n\u003Cp>证书配好了，接口也是 200，群里还在催——可复制密文、对预发\u002F生产 key、解密改字段再加密重放，这些步骤一环都省不掉。\u003C\u002Fp>\n\u003Ch2>那晚之后\u003C\u002Fh2>\n\u003Cp>早会前我脑子还停在昨晚那条 login 请求上。\u003C\u002Fp>\n\u003Cp>代理已经坐在链路了，TLS 也剥干净了，可业务层加解密还在代理外面——站外工具、终端脚本、Postman，各干各的。改一个 \u003Ccode>userId\u003C\u002Fcode>，要验证的明明就一两个字段，却要整套手工流程再走一遍。\u003C\u002Fp>\n\u003Cp>那晚磨完，一个很直白的念头冒出来了：\u003Cstrong>能不能做一款工具，把抓包和业务加解密收进同一个地方？\u003C\u002Fstrong> 代理既然已经在链路上，解密脚本、环境密钥、改参重放，就别再让人在三四个窗口之间来回切了。\u003C\u002Fp>\n\u003Cp>大概就是这么个出发点，后来才有了 DevPeek。\u003C\u002Fp>\n\u003Cp>头一个想收进来的，就是那晚最绕不开的一截——\u003Cstrong>发出去的请求\u003C\u002Fstrong>。Charles 管 TLS，我们管业务层：在代理里看懂密文、改明文、再加密回去，而且只处理请求侧，先把联调里最耗时的那块啃下来。\u003C\u002Fp>\n\u003Cp>这就是现在的 \u003Cstrong>参数转换\u003C\u002Fstrong>。做法跟那晚的手工活一一对应，只是不用再离开抓包界面：\u003C\u002Fp>\n\u003Cp>\u003Cstrong>加解密配置\u003C\u002Fstrong> 管「怎么解、怎么再加密回去」。预发 B 组 key、生产 A 组 key，跟抓包上下文放在一起，不必再去 Confluence 翻表；\u003Ccode>scripts\u002Fdebug\u002F\u003C\u002Fcode> 里那套 Python 可以搬进脚本转换，常见 AES 也能用内置算法填密钥。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>参数转换规则\u003C\u002Fstrong> 管「哪条请求、哪个参数要转换」。对 \u003Ccode>POST \u002Fapi\u002Fuser\u002Flogin\u003C\u002Fcode> 右键拾取 URL 和 \u003Ccode>payload\u003C\u002Fcode>，绑上加解密配置，保存一次，后面同类请求自动命中。\u003C\u002Fp>\n\u003Cp>配好之后，日常就跟明文打交道了：详情里直接看解密后的字段；后端再说「把 \u003Ccode>userId\u003C\u002Fcode> 改成 0」，在 Mock 篡改或「调试 API」里改字、点发送，DevPeek 自动加密写回，Header、Cookie、签名顺序仍走 App 真实链路。注册接口？换条 URL 匹配，加解密配置复用就行。\u003C\u002Fp>\n\u003Cp>列表里记的仍是客户端发出的原始报文；明文单独展示在详情里，方便对照。Postman 和三个月没动过的 Python，可以退居二线。\u003C\u002Fp>\n\u003Cp>那晚一小时，其实就为改一两个字段。DevPeek 从这儿长出来，参数转换则是它落地的第一块——把这类验证从「手工流程」收成「改个字、点一下发送」。\u003C\u002Fp>\n\u003Ch2>下一篇预告\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>《我们为什么做 DevPeek（二）：App 里那页 H5，在电脑上也能对着查》\u003C\u002Fstrong>——手机经代理打开的内嵌网页，镜像到调试 Tab，用自研面板查 DOM、Console 和网络，不必只靠真机里硬啃。\u003C\u002Fp>\n\u003Chr>\n\u003Cp>若你也在联调里一遍遍手工处理请求体，欢迎 \u003Ca href=\"\u002F\">下载 DevPeek 试用\u003C\u002Fa>，或到 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FGYPengDev\u002Fdevpeek\u002Fdiscussions\">GitHub Discussions\u003C\u002Fa> 聊聊——参数转换教程见 \u003Ca href=\"\u002Fdocs\u002Fparam-transform\u002F\">官网\u003C\u002Fa>。\u003C\u002Fp>\n",{"items":12},[13],{"slug":4,"title":5,"summary":6,"date":7,"featured":8,"seoDescription":9},1783606046179]