b***@sinobasedm.com
b***@sinobasedm.com
  • 发布:2026-11-06 10:09
  • 更新:2026-11-06 10:10
  • 阅读:38

【报Bug】DCloud SDK在多处将AES加密密钥(SK/SQK/SPK)、IV、算法名仅通过字符偏移、Base64等可逆的简单混淆进行保护。攻击者逆向还原混淆算法后,即可获得全部静态密钥

分类:uni-app

产品分类: uniapp/App

PC开发环境操作系统: Windows

PC开发环境操作系统版本号: 25H2

HBuilderX类型: 正式

HBuilderX版本号: 5.24

手机系统: Android

手机系统版本号: Android 16

手机厂商: 华为

手机机型: 华为mate80

页面类型: vue

vue版本: vue2

打包方式: 离线

项目创建方式: HBuilderX

操作步骤:

安全扫描扫出来的

预期结果:

给解决方案,官方sdk修改日期

实际结果:

给解决方案,官方sdk修改日期

bug描述:

2.1漏洞概述DCloud SDK在多处将AES加密密钥(SK/SQK/SPK)、IV、算法名 以硬编码字符串形式内嵌于APK代码中,仅通过字符偏移、Base64等可逆的简单混淆进行保护。攻击者逆向还原混淆算法后,即可获得全部静态密钥,解密SDK加密的所有资源(JS源码、广告配置、反射类名等)。
详细见附件图片

2026-11-06 10:09 负责人:无 分享
已邀请:
Ask小助手

Ask小助手 - Ask社区AI助手

欢迎到专业群( uni-app 官方技术交流群 1 ) 咨询,群中有相关专业的管理员和群友。

收到你的 Bug 反馈,我以官方人员的视角对这条反馈进行评审和分析:

一、反馈内容完整性评审

反馈质量总体尚可,但关键信息缺失,目前不足以支撑官方定位和验证:

  1. BUG 标题与描述:标题和描述清晰,指出了核心问题——SDK 内部的 AES 密钥(SK/SQK/SPK)、IV、算法名仅通过字符偏移、Base64 等可逆混淆保护,逆向后可还原静态密钥。这部分描述是能让官方看懂的。

  2. 代码示例:此类安全问题不需要业务代码示例,但缺少安全扫描报告的详细内容,包括:使用的安全扫描工具/平台名称、报告全文、检测到的具体文件路径、类名/方法名、检测依据等。没有这些材料,官方无法定位你所说的“多处”具体指哪些位置,也无法验证扫描结论。

  3. 复现步骤:仅写了“安全扫描扫出来的”,过于简单。无法据此复现验证。需要补充:扫描工具名称及版本、完整检测报告(含调用栈或文件定位)、被检测 APK 的打包方式(云打包/离线打包、是否勾选混淆等)。

  4. 预期结果:“给解决方案,官方 sdk 修改日期”——解决方案可以探讨,但要求官方承诺具体修改日期并不现实。安全对抗是持续过程,且该问题属于安全加固建议范畴,不是传统意义上“改一行代码即可修复”的功能性 Bug。

  5. 实际结果:与预期结果重复填写,未描述实际扫描输出的原始内容。

  6. 分类信息:完整(Windows 25H2、HBuilderX 5.24 正式版、Android 16、华为 Mate80、Vue2),这部分做得不错。

另外提示:我无法识别附件图片,请将扫描报告的关键内容以文字形式补充到反馈中。

二、问题是否成立的分析

结合官方文档,这个反馈不能简单认定为 Bug,更准确说是安全扫描工具的严格判定与官方现有保护方案的口径差异:

  1. 官方已有明确处理记录:官方文档 Android 平台安全章节 - 密钥硬编码漏洞 明确说明:"HBuilderX3.1.14+版本已修复此问题,在内部逻辑中使用的密钥全部做了混淆加密处理。" 你使用的 5.24 正式版远高于 3.1.14,SDK 内部密钥已经做了混淆加密处理,并非明文硬编码。扫描工具判定“字符偏移、Base64 属于可逆简单混淆、不算有效保护”,这是扫描工具自身的评级标准,与官方“已做混淆加密”的事实存在标准差异。

  2. 客户端密钥保护的本质限制:官方文档在 js 原生混淆说明 中明确指出:"没有绝对的安全,非常重要的信息,应该保存在服务器而不是前端";源码保护专题文章 也说明:"这个世界不存在绝对的安全,加密会被破解、混淆会被反混淆"。任何运行在客户端的密钥保护(包括混淆、加密、白盒方案)本质上都是提高逆向门槛,无法做到绝对不可还原。这是整个移动端行业的共性约束,并非 DCloud SDK 独有的缺陷。

  3. 华为侧的佐证:华为官方文档(应用代码混淆 - 使用第三方加固)也明确要求"不允许混淆非自研的 SDK,SDK 应由 SDK 厂商自行进行混淆保护",即行业共识是 SDK 内部保护由 SDK 厂商负责,且混淆保护本身就是行业通行做法。

三、建议与解决方案

基于官方文档,如果你需要提升 APK 整体安全评级以通过扫描,可采取以下措施:

  1. 对 APK 进行整体加固:官方文档推荐使用 uni 安全加固(由蚂蚁小程序云提供支持),可有效提升应用整体安全性,覆盖 SO 文件破解风险等场景。整体加固后,扫描工具对内部字符串的静态分析难度会大幅提升。

  2. 敏感信息不放在前端:按照官方建议,非常重要的信息应保存在服务器而不是前端,客户端只做令牌类交互。

  3. 关于"官方 SDK 修改日期":知识库中暂无官方承诺对此进一步升级密钥保护方案的时间计划,我无法给出具体修改日期,请以官方后续发版说明为准。

四、评审结论

这条反馈有参考价值,但按 Bug 标准衡量目前不成立:SDK 密钥混淆处理在 HBuilderX 3.1.14+ 已落地(见 官方安全文档),扫描工具的判定属于更严格的安全评级标准,而非功能性缺陷。建议你补充完整的安全扫描报告(工具名称、检测详情、文件定位)后重新提交,官方可据此评估是否需要在后续版本进一步升级保护强度;同时建议先通过 uni 安全加固等整体加固方案解决当前上架/过审需求。

内容为 AI 生成,仅供参考

要回复问题请先登录或注册