Post #135

通知版「豆瓣·电影日历」复活（顺便之前好像更新了自定义跳转），感谢 @Neurogram 大佬 JSBox 小组件脚本 Dougets 提供绕过加密验证的思路。 最初练习写脚本时接到群成员需求觉得有意思就研究了一下，通过重放发现其为“抽查”的形式来验证加密，故删除了相关接口中的加密验证信息（_sig），通过不断重试的方式绕过加密。脚本发出使用一段时间后豆瓣对此接口开始全面验证加密，查找一些信息（Douya _sig、Douya FRODO_SECRET）后发现需要在非 nodejs 的环境中实现一个 js 处理这个加密比较麻烦（Quantumult X 1.0.19 (480) 的测试版好像可以有办法处理了？），后因个人时间精力问题搁置了该脚本。近期狗哥发布了模拟豆瓣官方小组件的 JSBox 小组件 Dougets，学习后发现可以写死一组通过验证的加密信息 _sig（签名验证） 和 _ts（时间戳）来绕过加密，其实在对 Douya 项目的学习中就发现只验证了时间戳，但是由于相关接口中还含有 yyyy-MM-dd 形的日期信息，本能以为会通过日期信息同步验证时间戳，没想到当初他们堵住“抽查”验证时依旧没有完成强加密验证。 比较有意思的是，在这一年多学习写脚本的过程中，发现了许多公司在加密验证这个事上的「迷惑行为」，非常常见的有有完整的几套加密体系，却在一些接口不进行验证。这种行为可能有某些解释，但是还有一种是有加密体系，并进行了验证，但这些加密实际上并没有起到作用，如此次的「豆瓣·电影日历」的相关接口。再比如滴滴出行中的「滴滴橙心果园」，抓包分析后可以很容易发现请求体中的信息几乎都被加密了，比较容易从形式上看出其中的 params 参数是 Base64 后的结果，故通过解码可以得到正常信息，但 sign 参数可能为 MD5 加密后的信息，几乎不可通过解密得到正常信息，只能通过一些别的手段去得到如何计算这个 MD5 值。但有意思的是，其中 ts 参数并不是时间戳这种恒变的参数，而是类似于“操作次数”的记录，而“操作次数”在请求了进入这个游戏的初始化接口后会重置。所以很容易可以产生一个思路，在相同的“操作次数”进行相同的操作，是否可以直接利用之前的 sign 参数呢？重放验证后答案是肯定的，这样也就绕过了这个加密。其中迷惑行为一在某些情况写可以理解，而迷惑行为二我个人认为只是他们单纯的没能理解加密或如何加密。 依旧是个人时间精力问题，还是会做一只随缘更新的🐦，最近比较想🐦一期这一年多折腾这些的经验讨论。 附： Quantumult X 1.0.19 (480) 测试内容： - Script 类型 HTTP rewrite 支持二进制数据修改，增加类型为 ArrayBuffer 的传入参数 $response.bodyBytes 与 $request.bodyBytes（需 iOS 14.0 及以上） - 同时 $task.fetch 响应体亦支持类型为 ArrayBuffer 的参数 bodyBytes（需 iOS 14.0 及以上） - 示例参见 https://raw.githubusercontent.com/crossutility/Quantumult-X/master/sample-bytes-rewrite.js - 部分界面调整 附 2: 此豆瓣接口签名缺失会返回错误代码 997，签名错误则会返回 996。