内容摘要：付费小说网站的技术防护，说穿了就三层：前端混淆、接口鉴权、内容加密。大部分站点连第一层都做不扎实，右键查看源代码，章节内容直接躺在HTML里，连base64都没套。我见过一个日活几十万的站，VIP章节

付费小说网站的破解技术防护，说穿了就三层：前端混淆、付费方法接口鉴权、小说内容加密。网站大部分站点连第一层都做不扎实，破解右键查看源代码，付费方法章节内容直接躺在HTML里，小说连base64都没套。网站我见过一个日活几十万的破解站，VIP章节的付费方法正文就藏在<div id="content">里，只是小说用CSS把用户选中的功能禁掉了。选中、网站复制、破解右键，付费方法全被JavaScript拦着。小说打开开发者工具，输入document.getElementById('content').innerText，整章内容直接打印出来。前后不超过十秒。

这类站点的逻辑是：把内容完整发给浏览器，再用脚本阻止你拿走。可浏览器终究是用户的机器，脚本能拦住的只是普通操作。禁用JavaScript，或者用阅读模式，内容照样显示。有个叫“笔趣阁”的镜像站更离谱，付费章节的接口返回的是明文JSON，只是请求头里带了个token。token哪来的？登录后服务器发的。注册一个免费账号，抓包拿到token，把免费章节的chapter_id换成付费章节的，接口照样返回全文。连破解都算不上，只是改了个数字。

稍微像样点的站点会做接口鉴权。每次请求带签名，签名参数包括时间戳、章节ID、用户ID，用前端JS里的密钥做HMAC。问题在于，密钥在前端。打开JS文件，搜hmac或者sign，大概率能找到硬编码的字符串。把签名逻辑抄下来，用Python复现，就能伪造合法请求。我试过一个站，密钥是"secret_key_2023"，签名算法是md5(chapterId + timestamp + secret)。写个脚本批量请求，半小时下载了整本书。

内容加密是另一回事。有些站点把正文用AES加密，密钥通过另一个接口下发，且和用户绑定。这种确实麻烦些，但也不是无解。密钥下发接口的响应里，密钥本身往往没加密，只是做了混淆。比如把密钥拆成几段，分别放在不同的JSON字段里，前端再拼起来。你只要模拟前端逻辑，把拼装过程走一遍，密钥就到手了。更狠的站点用WebAssembly做解密，把核心逻辑编译成wasm。逆向wasm成本高，但可以用动态调试，在解密函数返回处下断点，直接拿明文。Chrome DevTools的Sources面板里，wasm也能断点。

真正难搞的是服务端渲染加图片化。正文不传文本，传的是图片，每个字都是单独渲染的。这种站我见过两三个，一般是比较小众的垂直领域。应对方式要么是OCR，要么是找接口拿原始文本——通常图片接口和文本接口是分开的，文本接口只是没在前端调用而已。抓包看看有没有多余的API端点，经常有惊喜。

法律上这事很灰色。破解付费小说，自己看，基本没人管。传播或者牟利，那就另说了。技术上能做的事，不代表应该做。我写这些，只是说明一个事实：前端没有任何秘密。所有依赖客户端隐藏的逻辑，最终都会暴露。区别只在于成本高低。大部分小说站的安全投入，连防住一个会按F12的人都做不到。

有个做安全的朋友说过一句话：把内容给用户看，又要防止用户拿走，这本身就是伪命题。你只能提高拿走的成本，没法杜绝。付费小说网站如此，视频网站如此，在线文档也如此。真正有效的防护不在前端，在服务端——比如每次请求都校验用户权限，且权限粒度足够细。但那样服务器压力大，大部分站不愿意做。所以破解方法一直有效，且会继续有效下去。