某夕夕anti_content算法分析
- 代码中大量报错 , 按照顺序处理
403错误 , 未授权
- 调整至fiddler工具中
- 采集真实小程序中产生的token信息 , 并中转拦截处理
- 拦截授权请求后 , 业务接口可以正常访问
- 余下报错为初始化过程中 , wss初始化链接数过多 , 堆栈定位一下
- 寻找
r.MaxWebsocketConnect
参数初始化时引用的对象 , 并修改 - 在
app.js
中修改调试器的全局参数__devtoolsConfig.setting.MaxWebsocketConnect = 5
- 此时已成功没有错误 , 429状态码为风控引起的返回状态码 , 忽略即可
anti_content算法
- 随便定位一条带有anti_content的请求
https://xcxapp.pinduoduo.com/backend/conf/startup_v2
- 放眼望去 , 只有这么几条参数值得关注
- 两条token大概率由授权请求返回的 , 不是我们关注的重心
- xcx_hash看上去大概率为签名 , 最后一步看即可 , 接下来分析anti_content
- 查看堆栈
- 直接忽略asdebug与waservice的堆栈 , 这是工具自身的引用栈 , 与业务代码无关 , 直接从
41.js
分析即可
- 确认引用了anti_content后 , 往上追溯至没有异步的地方或生成的地方
- 业务代码并没有严重的混淆 , 所以很轻松定位到了生成的位置 , 不过参数传入为boolean , 难道不应该为对象吗
- 进入此函数 , 并打印传入参数
- 调试信息都不是想像中的亚子 , 那是不是找错链接了呢 , 尝试寻找其他较长的anti_content
- 尝试调试了其他链接的anti_content后 ,长度不一致 , 问题不在外部函数 , 那么就需要深入anticontent函数了
1 | function g(t) { |
- 稍微深入后 , 即可发现anti_content的生成位置
- 最后一句encode的函数 , 粗略看上去像是类似base64的编码算法 , 直接调用即可
- 看看encode前调用了哪些参数
1 | [ |
- 到此为止 , 调用了哪些环境信息就可以知道了
- 关于wss中请求的内容 , 有时间再讲一期 , 难度都不高
侵权说明
此分析仅供学习参考 , 并不提供源码以及代码指导 , 如有侵权 , 联系邮箱admin@tisoz.com
删除
This blog is under a CC BY-NC-SA 3.0 Unported License
本文链接:http://www.tisoz.com/2022/08/22/%E6%9F%90%E5%A4%95%E5%A4%95anti_content%E7%AE%97%E6%B3%95%E5%88%86%E6%9E%90/