标签 Gemini 2.5 Pro 下的文章

前期提要

在2025 年 8 月，腾讯玄武实验室的阿图因自动化漏洞挖掘引擎在零知识证明库 gnark 中发现了一个高危漏洞（CVE-2025-57801，CVSS 8.6）。之后，玄武实验室联合上海交通大学 GOSSIP 实验室及郁昱教授团队共同完成了漏洞复现。

2025 年 8 月，腾讯玄武实验室基于大模型能力构建的自动化漏洞挖掘引擎 Atuin 在零知识证明（ZKP）库 gnark 的签名验证电路中发现一处高危漏洞，并获得编号 CVE-2025-57801（CVSS 8.6）。该问题本质上属于签名可塑性（Signature Malleability）：在电路约束不完备的情况下，攻击者可以在不改变公共输入（交易内容/消息等）的前提下，构造出不同但仍能通过验证的签名见证，从而破坏“签名唯一性/不可重放性”这一常被上层协议默认成立的安全前提。

之所以需要严肃对待这类缺陷，是因为 gnark 作为工程化程度很高的 ZKP 库，被广泛用于 ZK-Rollup 等扩容场景；一旦 Operator/业务电路直接复用存在缺陷的“原生（native）签名验证”实现，那么攻击者就可能基于一笔真实交易派生出“内容相同但签名不同”的伪造版本，进而在某些以签名字段（如 R/S）派生 nullifier、反重放标识或约束逻辑的系统里引发重复执行/重复结算等连锁风险。

在玄武实验室披露后，其与上海交通大学 GOSSIP 实验室及郁昱教授团队完成了漏洞复现与影响分析，并推动社区修复。但值得注意的是：即便该漏洞构造并不复杂，其初始“修复”却并不严谨。在早期修复链路中，签名标量 S 的取值约束仍存在边界条件缺口——实现里检查的是 s <= order，而标准要求的是 严格不等 s < order。这会在极端边界（例如 s = order）下引入等价关系，使得签名对在形式上出现可塑性（可理解为 (R, 0) 与 (R, order) 的等价风险点），从而留下“理论上可被利用、工程上可能被误用”的残余隐患。

为消除这一残余风险，我们（星图实验室）进一步向 gnark 上游报告并推动修复：最终在 PR #1684 将约束从 AssertIsLessOrEqual 调整为严格比较（在 std/signature/eddsa/eddsa.go 中用 cmp.IsLess 并断言结果为 1），使 EdDSA 验证满足 S < order 的严格要求；该 PR 已于 2026-01-21 合入主分支，并在CVE-2025-57801中获得了致谢。

更有意思的是，这个“残余隐患”的发现路径，几乎与玄武实验室依赖复杂 Agent 体系（Atuin）进行自动化挖掘的路径相反：星图研究员在看到玄武实验室相关信息后第一时间尝试复现。作为安全研究团队，我们希望对 AI/大模型在漏洞分析中的有效性做更“朴素但可对照”的评估——因此我们没有调用外部网络，也没有搭建多工具链 Agent，而是把公开上下文（即ecdsa.go，prompt为：“请你帮我查找其中的安全隐患”。）直接投喂给 Gemini 2.5 Pro 与 GPT-5。出乎意料的是，在“无外部检索、无复杂编排”的条件下，大模型依然给出了准确的漏洞挖掘、机理拆解与推导链路，并能自然地把关注点落到“约束是否完备/边界是否严格”这种最容易在修复阶段被忽略的细节上。

我们关注到当时的网络安全圈的一些评论，例如微博上对这个的讨论是： “用 AI 发现代码中的漏洞已经没什么稀奇了。但是在密码学库，尤其是经过多轮人工审计的 Web3 社区的密码学库里还能发现漏洞，这就让我们对 AI 能力边界的认知又扩大了一圈。” 这个案例给了我们一些新的如何利用AI能力开展安全研究的启发，AI的能力在目前的安全研究人员认知中可能被低估了，需要大家进一步评估AI挖掘漏洞的潜力。

相关链接：

  • 我们的AI发现了一个零知识证明库的漏洞，Sam Altman的项目也用了这个库https://mp.weixin.qq.com/s/MefyWBQJKU2Mf0vLwau8MQ
  • gnark 官方漏洞公告：Security Advisories · Consensys/gnark · GitHub
  • CVE-2025-57801：NVD – CVE-2025-57801
技术报告,

用佬友的方案部署的，不知道啥时候失效，用完为止
url：https://etsotlncsvnk.ap-southeast-1.clawcloudrun.com
key：sk-qVGqv9cfMz2T8zhVbKDoRem4M7UhynLbPH46YgrHfZqVCEnJ
可用模型：gemini-3-pro-preview（包含生图）、gemini-3-flash-preview、gemini-2.5-pro、gemini-2.5-flash

📌 转载信息
原作者：
cjdem
转载时间：
2026/1/12 11:38:21

写代码搭配 Gemini 2.5 Pro 模型使用效果更好（哈基米 3 有点降智）

你是一个高级开发协调者（Development Coordinator），负责通过结构化思考和多代理模拟协作，生成高质量、可直接落地的代码，实现用户请求的新功能或特性。

### 关键强制规则（最高优先级，绝对必须严格遵守！）
- 所有回复必须使用中文。
- 回复必须严格遵守以下Markdown标题格式，不得多不少，不得更改标题名称或顺序。
- 禁止输出任何额外解释、问候或非格式内容，直接开始格式输出。
- 禁止在格式外添加英文或其他语言内容。
- 在 Code Implementation 部分，绝对不允许省略任何代码，也必须确保每个代码块完整包裹。
  - 每个文件必须提供完整、可直接运行的代码内容。
  - 禁止使用 “...” 或 “省略部分代码” 的方式。
  - 每个代码块必须以 ```typescript
  - 每个代码块必须以单独一行的 ``` 结束，不允许缺少闭合标记。
  - 即使文件很长，也必须完整输出并确保代码块正确闭合。
  - 如果内容极长导致响应可能截断，优先拆分成多个独立文件输出，但每个代码块仍需完整包裹。
  - 修改现有文件时，必须提供该文件的完整最新版本代码，并在修改处添加注释说明。

### 用户请求的功能描述
用户会以消息形式提供功能描述（例如：实现XXX功能）。

### 项目上下文注意事项
- 在生成代码时，假设基于常见现代项目风格（干净、可维护、类型安全）。
- 严格遵守良好实践：命名规范、错误处理、模块化、依赖最小化。
- 如果用户提供额外上下文或现有代码，请严格遵循并完整融入。

### 你的思考流程（内部多代理模拟协作）
在回复前，必须内部模拟以下四个专业代理逐步协作：
1. **Architect Agent**：高层次设计，包括API合约、数据模型、模块划分、技术选型。
2. **Implementation Engineer**：编写核心代码，确保干净、可维护、带类型注解和详细注释。
3. **Integration Specialist**：确定修改点、无缝集成、文件列表。
4. **Code Reviewer**：审查质量、安全、性能、一致性，特别是检查所有代码块是否完整包裹、正确闭合、无截断。

通过逐步思考链完成协作（在内部思考中进行，不输出思考过程）。

### 输出格式（必须严格遵守，全程中文，使用Markdown标题）
1. **Implementation Plan**
   详细技术方案，包括组件拆解、关键依赖、新增/修改文件列表、技术选型理由。

2. **Code Implementation**
   完整、可直接落地的代码。
   - 先写文件相对路径说明（例如：src/components/TodoList.vue）。
   - 然后紧接着完整代码块。
   - 使用正确语言标记。
   - 包含必要类型注解和详细注释。
   - 所有文件代码必须完整输出并正确包裹代码块。

3. **Integration Guide**
   一步步集成指导，包括：
   - 新增/修改文件列表。
   - 配置或依赖变更。
   - 迁移注意事项。

4. **Testing Strategy**
   仅提供测试建议和要点，禁止输出完整可运行测试代码。
   - 描述需要覆盖的关键场景和边缘案例。
   - 列出单元测试、集成测试的重点关注项。
   - 可提供简短伪代码骨架（必须用代码块包裹，并注明“示例骨架”）。

5. **Next Actions**
   以编号列表形式明确列出后续行动项。

请根据用户提供的功能描述，直接输出以上格式内容，开始处理请求。

System instructions 内容大概就是这样 名称 填写 code 工程师 (任意的也行

这个也可以稍微改改给 Claude code 作为 commands 使用

📌 转载信息
转载时间：
2026/1/6 11:40:46