PG移动端安全实验室：安全性与签名检查

读者为何搜索安全性与签名检查

读者通常想知道文件是否来自预期发布者、下载后是否被改动、更新是否延续同一身份，或网页是否会加载未知脚本。这些问题相关但不相同。安装包签名可以建立文件完整性与证书标识线索，却不审查代码是否无漏洞；HTTPS保护传输过程，却不判断站点经营主体；CSP限制部分网页资源行为，却不覆盖原生后台权限。把它们分层，才能避免一个绿色图标承担全部安全结论。

签名检查还常被版本更新触发。系统拒绝用新文件覆盖旧版，可能因为软件包或签名不一致；这是一条重要供应链信号。正常的证书轮换或迁移需要可追溯的一手说明和平台支持，不能由第三方一句“换签正常”解释。若旧样本来源可信，应保存其证书指纹作为基线；没有基线时，只能描述当前签名，不能断言它长期属于某主体。

“安全性”一词范围很大。除签名外，还包括权限、通信、数据存储、依赖、更新机制、输入处理和退出清理。本页不会因为签名有效就写“安全”，也不会因为网页使用CSP就认可安装文件。检查目标应具体到“签名是否连续”“资源来源是否受限”“错误提示是否清楚”，每个结论列出没有覆盖的层面。

签名检查适合用连续更新场景理解。一台设备已有软件包标识相同的旧版本，新文件版本代码更高，却无法覆盖安装；查看后发现证书指纹不同。此时“文件更新”与“来源延续”发生冲突，优先级应给签名和正式迁移说明，而不是版本号。若发布主体确有密钥轮换，说明应能交代时间、受影响构建与验证方式；仅由下载页声称换证不足以闭合证据链。对于首次见到的包，签名只能稳定标识这个发布序列，不能凭证书自签名称建立品牌关系。比较时应使用完整指纹和签名方案信息，避免只抄证书显示名或末尾几位。

把宣传说法拆成可查命题

“官方签名”应拆成证书标识是什么、由哪份一手资料将其与责任主体关联、适用哪些版本，以及历史样本是否连续。“银行级加密”要改为传输使用什么协议、哪些数据在何处加密、密钥由谁管理；如果没有技术说明，就只保留为未经证实的宣传用语。“网站有锁所以下载安全”则要拆成当前网页连接、重定向链和最终文件三项。

“通过安全检测”需要检测主体、样本摘要、检测日期、方法和覆盖范围。一张没有摘要的报告无法确认检测的是当前文件；多个扫描结果也可能只覆盖已知恶意特征。较中性的写法是“某机构在某日对某摘要执行所列检查，其他行为未覆盖”。若报告来源与文件来自同一未知页面，仍缺少独立性。

“页面防篡改”也不能仅凭CSP断言。MDN指出CSP通过控制允许加载的资源形成纵深防御，但同时明确它不是输入净化的替代；策略可能缺失、过宽或只处于报告模式。^来源3 因此要查看实际响应、指令范围与是否允许危险内联执行，仍不把网页层结论延伸到移动包签名。

“界面提示清楚所以可信”同样需要限制。WCAG要求可感知、可操作、可理解与健壮等方面，可以帮助发现错误提示、焦点和标签问题；恶意页面也可能做得易用。可访问性是减少非自愿选择的重要质量维度，不是主体认证。

安全判断表可分为四种组合：摘要相同且签名相同，表示两个文件字节一致；摘要不同但签名连续，可能是正常新构建，仍需版本说明；软件包相同而签名不同，需暂停并寻找轮换依据；软件包与签名都不同，则应作为独立应用重新核验。扫描结果、文件名和图标只能放在辅助列，不能覆盖这四种身份关系。若样本由拆分安装包组成，应确认所有片段属于同一会话和签名集合，不能只检查基础包。表中还要写明取得时间与渠道，因为相同签名并不能证明每个分发页面都可信，未知页面仍可能重新分发未经修改的真实文件。

使用一手资料交叉验证

文件层先从系统或可信分析环境读取软件包标识、版本、签名算法、证书指纹与有效期信息，再与来源明确的旧版本对照。证书中的名称只是证书字段，必须由责任主体公开资料或受控分发记录建立关系。自签名不等于恶意，公共证书也不等于被声称品牌；关键是身份关联和版本连续性。

网页层从起始地址逐跳记录注册域和证书错误，查看最终响应是否有CSP及其资源限制。策略允许的域名很多、允许任意内联脚本或发生跨域下载时，记录具体配置，不用“有CSP”作二元判断。对H5外壳，还要把外壳签名与远端网页域名分别核对，因为其中一层可信不为另一层背书。

界面层按WCAG相关原则检查下载说明、风险提示、取消入口和状态消息是否可读、可聚焦且不只靠颜色表达。若键盘或屏幕阅读器无法到达拒绝选项，读者可能在并非自愿的情况下继续。记录具体控件和步骤，不宣称整个页面符合标准；完整一致性评估需要更广范围与人工判断。

交叉验证的最终表应显示三层是否闭合：文件证书能否关联主体，网页域名能否关联分发，页面入口能否无误导地把读者带到同一文件。任一层断裂，结论就不能写成“安全下载”。即使三层一致，仍需列出未审计的代码、服务器、隐私处理和地区规则。

工具输出不一致时，先确认比较的是同一种文件和同一摘要。有的界面展示证书摘要，有的展示文件摘要，两者长度相似却含义不同；复制时应在字段名旁保留算法名称。若一个工具报告多个签署者，检查它是在显示历史签署链、不同签名方案还是多个证书，不要截取第一行。签名校验失败可能来自文件损坏、非完整分包或工具不支持，需用第二种可信方法复查，但不执行样本。若网页只公布一串指纹而没有说明对应版本和包名，匹配也只能支持有限命题。出现要求关闭系统完整性检查才能安装时，诊断应立即结束并标为安全边界冲突。

高风险措辞的中性改写

把“签名无误，完全无风险”改为“所查样本的签名与基线一致，未评估全部代码和运行后资源”。把“官网加密链接”改为“本次连接使用HTTPS，注册域与一手来源关系另行核对”。把“无病毒”改为“在给定日期与工具覆盖范围内未触发所列检测，样本摘要如下”。这些句子把观察、时间和限制放在同一位置。

把“适合所有用户”改为“已检查的界面任务与辅助功能条件如下，未覆盖项保持未知”。把“完全防注入”改为“观察到CSP限制了所列资源来源，输入净化和其他防护未审计”。涉及PG名称时，写“文件使用该名称”而不是“PG官方文件”，除非存在直接一手关联；本页没有提供这样的具体文件证据。

遇到证书过期、签名突变或系统不受信任提示，不用“暂时故障”淡化。应写明系统原文、证书字段、版本与来源，并说明未找到迁移依据。相反，签名验证成功也不写“已认证所有者”，除非证书身份与主体关系已经独立确认。准确的中性表达会保留不确定性，而不会把不确定性变成模糊安慰。

密钥轮换需要比普通版本更新更严格的证据。理想情况下，旧签名序列能够授权新签名或发布主体在旧受控渠道提前说明轮换日期、适用包名和验证指纹。若只有新下载页声称“证书升级”，它既是样本提供者又是解释者，尚未形成独立连续性。复核者应查看旧设备是否能通过正常更新路径接受新包、系统是否显示签署历史，以及不同工具对历史链的呈现是否一致。无法更新而要求卸载重装会切断系统对连续性的检查，也可能造成数据损失，因此应列为重大迁移而非便捷步骤。若真正发生主体或产品迁移，还需区分品牌关系与技术签名关系。报告中保留旧新完整指纹、首次观察时间和说明出处，使后来复核者能够判断这是一条被验证的轮换链，还是两个独立签署序列共享了相似名称。

• 签名一致不等于代码无漏洞。
• HTTPS有效不等于页面主体真实。
• CSP存在不等于策略严格或安装包可信。
• 界面易用不等于内容诚实。
• 检测未报警不等于未来行为有保证。

行动摘要与来源目录

行动顺序是：保存起始来源；展开重定向；记录网页证书与CSP；在不执行文件的情况下读取摘要、软件包和签名；与可信历史样本及一手说明对照；最后检查页面提示和退出路径。若签名变化没有迁移说明、网页域名无法关联主体或拒绝入口不可用，停止流程并撤销已授予的站点权限。

本页于2026年7月12日查阅MDN CSP指南与WCAG 2.2。MDN来源支持网页资源控制与纵深防御的说明，W3C来源支持可访问界面与一致性边界。两份资料都未对任何PG移动文件、证书或下载页面作检测，也未提供PG签名基线；因此本文不会公布猜测的证书信息。

修订记录应把签名基线、样本摘要、版本、来源和查阅日绑定。若证书轮换后来获得一手说明，追加新证据与适用版本，不删除先前的未核实状态。网页策略变化也按响应日期保存，避免用今天较严格的CSP追溯证明旧页面当时同样受保护。

签名证据清单包括文件摘要、软件包标识、版本名称与代码、证书完整指纹、签名方案、取得渠道和旧版对照。路线常见问题是“哈希一致还需签名吗”；哈希只确认字节一致，签名用于观察发布序列，两者回答不同问题。另一个问题是“证书名称含公司字样是否可信”；自填名称可以被模仿，仍需从受控来源建立对应关系。报告应把工具名称与版本写入方法栏，并保存原始输出中不含私人路径的部分。若后来找到轮换说明，追加它如何解释旧新指纹，而不是把原先的不一致记录删除。完整历史能帮助区分合法迁移、重签名镜像和名称相似的另一应用。

人工核对指纹时可按固定长度分组并进行第二人复读，减少复制缺位；机器比较仍使用完整无空格值。截图若只显示首尾字符，不能作为最终对照。证据文件还应注明算法，避免把不同算法输出的长度差异误认为证书已经改变。

签名连续性只有与受控来源基线相连时才支持发布关系。

• 文件、网页、界面三层分别下结论。
• 每个样本以摘要绑定版本与签名观察。
• 证书身份需要一手主体关系，不靠名称相似。
• 策略和提示按实际响应与设备版本记录。
• 任何安全结论都列出未覆盖范围。