1. 从一次“改日期”实验说起RSA 验签为什么会被绕过数字签名、Java、BigInteger.modPow、Java Agent、RSA 这几个词放在一起很多人第一反应是“密码学底层离业务很远”。但如果你做过 License 校验、插件授权、离线激活码这类功能就会知道它们离你非常近。我最近复现了一个很有意思的场景把许可证 JSON 里的有效期从 2026 年改到 2027 年签名完全没动程序却依然提示校验通过。这不是 RSA 被破解而是验签流程在 Java 字节码层面被“偷换”了结果。这篇文章面向三类人一是正在写 License 校验、权限验证的 Java 后端二是想理解 Java Agent 字节码增强到底能做什么的工程师三是需要在 AI 工具里安全接入模型通道、顺便验证这类底层陷阱的开发者。核心检索词就是数字签名、Java Agent、BigInteger.modPow 和 RSA 验签陷阱。我会先讲清楚验签的数学链路再给出可复制的 Java Agent 配置和复现步骤最后附上 TaoToken 的 settings.json 与 config.toml 骨架方便你在 AI 编码工具里统一管理 Key 和 API 通道。需要先说明一点本文所有实验仅用于技术研究与防御理解目的是让开发者知道“算法没破流程可能被绕”从而在设计校验逻辑时把执行环境可信度纳入考量。请勿将相关技术用于任何违反法律法规或侵犯他人权益的行为。2. 验签的“命门”为什么 modPow 返回值可以被替换2.1 RSA 验签在 Java 里的真实调用链以 SHA1withRSA 为例签名过程是原始数据 → SHA-1 → 20 字节哈希 → 加 OID 编码 → PKCS#1 v1.5 填充 → 用私钥做 modPow(d, n) → 得到签名值。验签过程则反过来签名值 → 用公钥做 modPow(e, n) → 去填充 → 解码取出 OID 和哈希 → 与本地计算的哈希比对。对应到 Java 底层最终都会落到BigInteger.modPow上// RSA 验签的核心数学运算sig^e mod n BigInteger result sig.modPow(e, n); // sig 签名值, e 公钥指数通常 65537, n 公钥模数验签程序最后一步的逻辑本质上就是// 这是验签程序里最核心的一行比对 return MessageDigest.isEqual(本地算出的哈希, 从签名中解出的哈希);关键洞察在这里如果能在modPow这一步把返回值替换成一个预设的、格式合法的 DigestInfo验签程序就会无条件通过。它只关心“解出来的哈希对不对”从不关心这个结果是不是真的由签名值算出来的。2.2 攻击模型里最反直觉的一点在正常认知里伪造签名需要私钥。但在这个模型里只有签名值 x 是可以被“伪造”的而公钥 (e, n) 和预设的 fakeResult 都是真实、合规的。也就是说攻击者不需要私钥只需要控制执行环境在modPow返回前把结果换掉。RSA 的数学基础没有被攻破被绕过的是“验签流程对执行环境的信任”。这也是为什么防御措施里“远程验证”和“硬件绑定”能有效——它们把关键运算放到了攻击者无法篡改的环境里。3. TaoToken 前置统一 Key 与 API 通道的准备在复现和验证这类底层陷阱时我习惯把实验代码、AI 辅助分析和模型调用放在同一套通道里管理避免 Key 散落在各个工具里。TaoToken 在这里的作用是提供一个统一的 API 入口让 AI 编码工具、对话工具和脚本都能走同一个 Key。你需要先拿到 API Key入口在控制台的 API Keys 页面https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite拿到 Key 之后模型对话入口可以用来快速验证通道是否通畅https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite如果你打算长期用 AI 辅助做 Java 字节码分析、Agent 规则生成这类编码任务Coding Plan 会更合适https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite接入文档和 API 基础地址分别是https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite https://taotoken.net/api注意 API 地址不带 UTM 参数直接使用即可。下面给出两个配置骨架分别对应支持 settings.json 和 config.toml 的工具。4. 可复制配置Java Agent 规则与 TaoToken 骨架4.1 Java Agent 拦截 BigInteger.modPow 的配置Java Agent 可以在 JVM 启动时动态修改字节码在BigInteger.oddModPowmodPow内部实际调用的方法上插入拦截逻辑。核心配置文件power.conf的规则格式是[Result] EQUAL,x,e,n-fakeResult当modPow(x, e, n)被调用时如果参数匹配规则就直接返回fakeResult跳过真实计算。构造规则分三步。第一步提取原始值。从合法许可证中取出签名值 x从证书中取出公钥 (e, n)// 提取签名值 x byte[] signatureBytes Base64.getDecoder().decode(signatureBase64); BigInteger x new BigInteger(1, signatureBytes); // 从证书中提取公钥 (e, n) CertificateFactory cf CertificateFactory.getInstance(X.509); X509Certificate cert (X509Certificate) cf.generateCertificate( new ByteArrayInputStream(certBytes)); RSAPublicKey rsaKey (RSAPublicKey) cert.getPublicKey(); BigInteger e rsaKey.getPublicExponent(); // 通常为 65537 BigInteger n rsaKey.getModulus();第二步计算修改后数据的 DigestInfo也就是 fakeResult。这一步必须严格遵循 PKCS#1 v1.5 填充规范实验用的是 SHA1withRSA// 1. 准备数据修改后的 license 部分不含签名和证书 byte[] data newlicensePartBase64.getBytes(StandardCharsets.UTF_8); // 2. 计算 SHA-1 哈希20 字节 MessageDigest md MessageDigest.getInstance(SHA-1); byte[] digest md.digest(data); // 3. SHA-1 的 OID1.3.14.3.2.26 的 DER 编码 byte[] sha1Oid {0x30, 0x0D, 0x06, 0x09, 0x60, (byte)0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x1A}; // 4. 构造 DigestInfoOID 哈希值 byte[] encoded new byte[sha1Oid.length digest.length]; System.arraycopy(sha1Oid, 0, encoded, 0, sha1Oid.length); System.arraycopy(digest, 0, encoded, sha1Oid.length, digest.length); // 5. PKCS#1 v1.5 填充长度 n 的字节长度 int keyLength n.bitLength() / 8; // 例如 2048 位 → 256 字节 byte[] padded padV15(encoded, keyLength); // 6. 转换为 BigInteger这就是 fakeResult BigInteger fakeResult new BigInteger(1, padded);padV15的实现private byte[] padV15(byte[] encoded, int keyLength) { int paddingLen keyLength - 3 - encoded.length; byte[] padded new byte[keyLength]; padded[0] 0x00; padded[1] 0x01; for (int i 2; i 2 paddingLen; i) { padded[i] (byte) 0xFF; } padded[2 paddingLen] 0x00; System.arraycopy(encoded, 0, padded, 2 paddingLen 1, encoded.length); return padded; }第三步组装规则。把 x、e、n、fakeResult 都用BigInteger.toString()输出的十进制字符串填入[Result] EQUAL,x的十进制字符串,e的十进制字符串,n的十进制字符串-fakeResult的十进制字符串这几串数字非常长复制时务必完整准确任何一位数字错误规则都不会生效。4.2 TaoToken settings.json 骨架适用于支持 settings.json 的 AI 编码工具{ apiProvider: taotoken, apiKey: sk-你的TaoTokenKey, baseUrl: https://taotoken.net/api, model: claude-sonnet-4-20250514, maxTokens: 8192, temperature: 0.2, timeout: 60000 }4.3 TaoToken config.toml 骨架适用于支持 config.toml 的工具[provider] name taotoken base_url https://taotoken.net/api api_key sk-你的TaoTokenKey timeout 60 [model] name claude-sonnet-4-20250514 max_tokens 8192 temperature 0.2 [agent] enabled true workspace ./java-agent-lab把 Key 统一放在这里实验代码、Agent 规则生成、模型对话都走同一个通道排查问题时不会因为 Key 来源混乱而误判。5. 验证请求复现拦截并确认校验通过5.1 加载规则并接入验签逻辑修改测试代码在静态块里加载power.confstatic { try { File configFile new File(src/test/resources/power.conf); MapString, ListFilterRule map ConfigParser.parse(configFile); ResultFilter.setRules(map.get(Result)); } catch (Exception e) { e.printStackTrace(); } }验签实现要绕过Signature封装直接走BigInteger.modPow这样插件才能拦截到private static boolean verifyWithBigInteger(byte[] data, byte[] signature, RSAPublicKey publicKey) { BigInteger e publicKey.getPublicExponent(); BigInteger n publicKey.getModulus(); BigInteger sig new BigInteger(1, signature); // 这一步会被 power 插件拦截 BigInteger result ResultFilter.testFilter(sig, e, n); if (result null) { result sig.modPow(e, n); // 规则没命中时走正常运算 } // 去填充 → 解码 → 比对哈希省略具体实现 // ... }5.2 运行验证public static void main(String[] args) throws IOException { Path path Path.of(src/test/resources/ActivationCode, newkey.txt); String key new String(Files.readAllBytes(path)); if (CheckLicense.isKeyValid(key)) { System.out.println(校验成功: key); } else { System.err.println(校验失败: key); } }预期输出校验成功: KG0U19U3MP-eyJsaWNlbnNlSWQiOiJLRzBVMTlVM01QIiwibGlj...到这里修改过日期的许可证在没有私钥的情况下通过了校验。整个过程里 RSA 算法本身没有被破解被替换的是modPow的返回值。6. 本篇常见错排查规则不生效的六个原因复现时最容易卡在“规则明明写了却不生效”。下面这张表是我踩过的坑按顺序排查基本能定位。排查项检查方法OID 是否正确SHA-1 是 1.3.14.3.2.26不要错用成 SHA-256 的 OID填充长度是否匹配padded 长度必须等于 n.bitLength() / 8数字是否为十进制BigInteger.toString() 输出的是十进制不要填十六进制规则参数是否一致任何一位数字不同匹配都会失败power.conf 是否加载检查日志是否有相关输出确认静态块执行成功是否绕过 Signature确认调用的是 ResultFilter.testFilter而不是 JDK 的 Signature.verify还有一个隐蔽问题如果验签代码走的是Signature.getInstance(SHA1withRSA)插件可能拦截不到因为 JDK 内部实现路径不同。必须让验签逻辑显式调用BigInteger.modPow规则才有机会命中。7. 语义一致 CTA把通道和排障入口固定下来这类底层实验的价值不在于“绕过”本身而在于让你意识到再强的密码算法在不可信的执行环境里都可能被绕过。防御方向也很明确——远程验证、硬件绑定、代码完整性校验都是把关键运算放到攻击者碰不到的地方。如果你在接入 AI 工具做 Java 字节码分析、Agent 规则生成时遇到 Key 或通道问题可以直接走这两个入口API Keys: https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 接入文档: https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite需要快速验证模型通道是否正常用模型对话https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite长期做编码和 Agent 任务Coding Plan 更省心https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite最后留一个实用习惯每次改完power.conf先用一个最小main方法单独打印ResultFilter.testFilter(sig, e, n)的返回值确认规则命中后再跑完整验签流程。这样能把“规则没生效”和“验签逻辑写错”两类问题彻底分开排查效率会高很多。
