前言

当前文章仅供读者学习 DeepSeek 网页版接口的加密与逆向技术，帮助开发者理解现代 AI 服务中常见的接口保护机制。

文章背景

DeepSeek 作为国内领先的大语言模型服务商，其网页版接口采用了多层加密与风控策略。无论是 Token 生成、请求签名还是环境校验，都体现了当前主流 AI 接口的安全设计思路。通过逆向分析这些机制，开发者可以：

• 理解现代 Web 接口的常见加密方案
• 掌握 JavaScript 逆向调试的基本方法
• 学习如何模拟浏览器环境进行接口调用
• 提升对接口安全设计的整体认知

阅读前提

本文适合有一定前端开发基础和网络协议知识的读者。阅读前建议了解：

• HTTP/HTTPS 请求与响应机制
• JavaScript 基础语法与调试工具使用
• 基本的加密算法概念（Base64、HMAC、AES 等）

免责声明

重要提示：本文所有内容仅供技术学习与安全研究使用。逆向分析他人接口可能违反相关服务条款，请读者在合法合规的前提下进行学习。请勿将本文技术用于任何非法用途，包括但不限于：恶意爬取数据、绕过付费限制、破坏服务正常运行等。因不当使用本文技术造成的法律后果，由使用者自行承担。

文章结构

本文将按以下顺序展开：

1. 环境准备：搭建逆向分析所需的工具链
2. 抓包分析：观察 DeepSeek 接口的请求与响应
3. Token 生成逆向：还原加密逻辑

实战开始

1.环境准备

一台有chrome的电脑足矣。

2.抓包分析

千篇一律第一步，先打开浏览器的调试模式（F12），进入聊天模式。为了方便研究其聊天接口，直接开启新对话。问一下deepseek知不知道自己是谁，结果直接把核心暴露了，如下图：

我们看一下该接口，貌似没什么加密，这怎么可能？使用python原封不动运行一遍发现，确实没什么加密。好吧，我承认我是小丑。
接着往下走api调用接口

不会又没什么加密吧？python原封不动再来一遍，等等！

不像没有加密的样子，试了一下，果然不行，ok，工作正式开始。
首先看到x-ds-pow-response参数格式很像base64，解密一下发现如下：
{
“algorithm”:“DeepSeekHashV1”,
“challenge”:“3af41dbb010c818253373b51f6a459d915e05a045a731a493370be7a54f3608f”,
“salt”:“5eae7176d8bf749cfa6f”,
“answer”:105240,
“signature”:“2fcfc25a64948a4584c30e50f3de7d1b53e59a5f2305ff322ea9cdf08927098b”,
“target_path”:“/api/v0/chat/completion”
}
除了answer外，其他参数都可以从create_pow_challenge 得出，接下来重点是获取到answer的来源。
在全部网络请求中搜索answer，有一个可疑来源

直接去资源中该处打断点，进入异步函数

下面有一个函数o，也是异步调用

这一步有一个33614，全局搜一下是什么样的存在

3.token生成逆向

打开该js，发现调用了一个wasm，好家伙，直接把wasm全部下载，js调用，ok，得出来answer。为什么我们选择直接调用wasm呢，因为wasm快啊！！！
简单来说整个流程就是使用wasm这个worker解一下power-challenge，许多参数传进去后，暴力计算，得出answer，deepseek接口回传answer参数，完成接口校验过程。