标题: 分析基于宝塔面板自签证书API的一条可行钓鱼攻击链
作者: #耗子
板块: #开发调优
编号: 1588833
帖子: https://linux.do/t/topic/1588833
时间: 2026-02-10 02:12:18
摘要:

前两天有人跟我提起宝塔这个自签证书的设计，只需要安装一次根证书到电脑之后所有浏览器访问面板都不会提醒不安全，说这个设计好，太方便了，让我给 AcePanel 也加上。作为半个网络安全研究人员，我当时就怀疑宝塔这样验证搞不好有被钓鱼攻击的可能，后面实测发现钓鱼攻击确实可行，宝塔压根没做任何验证。
这个问题前两天反馈之后以“危害较小”理由打回，我倒也不在意，既然打回了那就来公开聊聊吧，正好普及一下这方面的安全知识。

首先需要知道宝塔的自签证书是如何生成的，在公开代码 BaoTa/tools.py at main · aaPanel/BaoTa · GitHub 中可以看到有 CreateSSL 函数。

该函数首先获取了面板的用户信息，如果信息不存在则使用 uid 0 和 32 个 B 作为 access_key，再通过前面 get_host_all 函数获取了当前所有网络接口的地址，然后请求 https://api.bt.cn/bt_cert 接口获取证书。
问题就出在这，bt_cert 接口没有任何验证逻辑，传入啥域名就返回啥域名的证书，例如我可以轻松通过以下命令获取一张 CA 为宝塔面板的 qq.com 证书。
curl -X POST 'https://api.bt.cn/bt_cert' \
  -H 'User-Agent: BT-Panel' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'data={"action":"get_domain_cert","company":"宝塔面板","domain":"qq.com","uid":0,"access_key":"BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB","panel":1}'


这时候你可能会说不就一个自签证书，能有啥问题？我自己用 openssl 随便签 10000 个出来。确实光是自签证书的话没有任何问题，正常直接使用这个自签证书你的系统和浏览器会识别并弹出红色警告，

标题: 【开源自荐】魔因漫创 🎬 AI 影视生产级工具 · 支持 Seedance 2.0 · 剧本到成片全流程批量化
作者: #simon wan
板块: #开发调优
编号: 1588837
帖子: https://linux.do/t/topic/1588837
时间: 2026-02-10 02:15:53
摘要:

自己先砸饭碗了！！！！ 
 S级板块 — Seedance 2.0 多模态创作

多镜头合并叙事视频生成：将多个分镜分组合并生成连贯叙事视频
支持 @Image / @Video / @Audio 多模态引用（角色参考图、场景图、首帧图自动收集）
智能提示词构建：自动三层融合（动作 + 镜头语言 + 对白唇形同步）
首帧图网格拼接（N×N 策略）
Seedance 2.0 参数约束自动校验（≤9图 + ≤3视频 + ≤3音频，prompt≤5000字符）

 剧本解析引擎

智能拆解剧本为场景、分镜、对白
自动识别角色、场景、情绪、镜头语言
支持多集/多幕剧本结构

 角色一致性系统

6层身份锚点：确保同一角色在不同分镜中外观一致
角色圣经 (Character Bible) 管理
支持角色参考图绑定

 场景生成

多视角联合图生成
场景描述到视觉提示词的自动转换

 专业分镜系统

电影级摄影参数（景别、机位、运动方式）
自动排版和导出
视觉风格一键切换（2D/3D/写实/定格等）

 批量化生产工作流

一键全流程：剧本解析 → 角色/场景生成 → 分镜切割 → 批量生图 → 批量生视频
多任务并行队列，自动重试失败任务
适合短剧/动漫番剧批量生产
GitHub - MemeCalculate/moyin-creator: AI 影视生产级工具 | 支持 Seedance 2.0 | 剧本到成片全流程批量化 | AI-powered film production tool with Seedance 2.0 support

标题: 单日 5E Tokens 调用 + 首次单对话破百万 Tokens 纪念（Opus 4.6 200K 模型）
作者: #91kevinshi
板块: #开发调优
编号: 1588841
帖子: https://linux.do/t/topic/1588841
时间: 2026-02-10 02:19:50
摘要:

随着 Opus 4.6 发布
原先受限的工作效率已经完全解放了
这里要感谢风大的 CCG 工作流
  
    
    
    
      【开源】CCG v1.7.58 : Claude Code 编排三 CLI 协作 | Codex + Gemini + Claude（新帖，旧帖子没办法编辑了） 
  

开发调优
    
  
  
    GitHub: GitHub - fengshao1227/ccg-workflow: 多模型协作开发工具集 - 基于 Claude Code CLI，整合 Codex/Gemini 后端能力，提供智能路由、代码审查、Git 工具等 17+ 个命令 
觉得好用请留下你的  Star 

[npm version] [License: MIT] [Claude Code] 
v1.7.…
  


感谢 A 社团队
新的 Agent Teams 功能让我可以一个 200k 的单对话，能够调用过百万的 Agent Teammates

这在之前就算通过 subagents 也是难以实现的开发效率、深度的提升
今天从起床到睡觉前，用了 5 个 E 的 Tokens（下午的时候中转站降速BUG，晚上才恢复，不不然还能多0.5-1 个 E 的 Tokens）
仅在此做个人纪念，同时也是一个时代的开始
以后个人每日使用 5E、1B、10B 甚至 100B 都将指日可待！！

标题: 分享一个能够让你在阅读APP中使用豆包去朗读小说的项目
作者: #夜雨扰心弦
板块: #资源荟萃
编号: 1588853
帖子: https://linux.do/t/topic/1588853
时间: 2026-02-10 02:42:41
摘要:

想问问广大使用开源阅读的书友，有没有想使用豆包的声音听小说的？ 

我就想听，所以这就是我花了好长时间捣鼓出来的，专用于阅读APP的豆包朗读小说的TTS逆向项目

项目介绍
一个专为开源阅读APP / 二改开源阅读定制的豆包语音朗读TTS逆向调用项目，用于支持阅读高质量的小说听书，适配阅读APP朗读引擎调用逻辑。
项目用途

用于在阅读APP中调用豆包TTS实现使用豆包去朗读小说


核心功能与支持

完整发音人支持，完美覆盖豆包官方全部音色
拥有可视化 WebUI 界面，支持多参数图形化调节
基础文字转语音，支持语音文件生成与下载
拥有多 Cookie 轮询请求机制，缓解听小说的高频调用导致Cookie封禁
强兼容性：完美适配原版阅读APP及各类基于阅读二改的客户端
双平台快速部署：支持 Windows 10/11、Android Termux

阅读TTS说明

实时模式（可用，逻辑待优化，暂不推荐）

当前逻辑：逐句发送、逐句返回合成语音




优点：随听随做、可调节朗读进度、支持实时语速调节
缺点：请求频繁，Cookie不多极其容易触发封禁，大量需要Cookie数量去弥补；
后续优化方向：改为一次性批量请求多段文本，再返回，减少Cookie使用频率
优点：稳定性提升
缺点：朗读进度与文本可能错位，不支持朗读进度的调节


预制书模式

运行逻辑：提前对整本书进行批量预处理，生成完整语音集后本地调用




优点：不需要高频使用Cookie，大幅降低封禁风险、能够调节朗读进度
缺点：做了才能听、无法实时调节语速、书籍内容产生改变可能导致已有预制内容无法正常匹配到(例如中途换书源、改变阅读原有布局等改变文本原有内容或结构的操作)

注意事项：不可开启按页朗读功能可能导致无法正常匹配缓存
预制书模式用法参考

5个Cookie：使用低请求延迟15，预制够几章后就可开始听，基本不会出现预制速度跟不上朗读速度的情况
1个Cookie：建议高请求延迟25防止频繁，没有多余Cookie去进行轮询只能非常的慢，所以建议就在晚上睡觉等时间去慢慢的制作第二