IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

标签:签名

共 2 篇相关文章

IT 累计浏览 2,741

Android APK 签名文件MANIFEST.MF、CERT.SF、CERT.RSA分析

这篇讲的是Android APK签名中三个关键文件:MANIFEST.MF、CERT.SF和CERT.RSA的内部结构和作用。作者从一个已签名的APK入手,逐步解剖了这三个文件如何构成一个层层校验的“信任链”。 核心机制是“三明治”式的校验:MANIFEST.MF首先记录了APK内所有文件的SHA-1哈希值,确保每个资源文件的完整性;接着,CERT.SF文件不仅保存了MANIFEST.MF本身的哈希值,还对MANIFEST.MF中的每一项描述再次进行SHA-1计算并存储,这相当于对“清单的清单”进行了二次确认。最后,CERT.RSA文件则包含了用于验证上述所有哈希值的公钥和签名者证书信息,完成了整个数字签名的闭环。 文章不仅展示了每个文件的具体内容,还通过手动计算和使用OpenSSL工具生成密钥、提取证书等方式进行了实战验证,并引用了Android源码佐证。整个分析过程清晰地揭示了Android签名机制如何通过这种“文件哈希 -> 清单哈希 -> 对清单的签名”的三重保障,来确保应用的完整性与来源可信度。

IT 累计浏览 3,298

一个想当然造成的错误(函数引用参数的一个问题)

开发者对函数参数传递方式的理解,有时会停留在“理所当然”的层面,而这往往正是错误的起点。这篇分享的就是这样一个典型案例:作者从一个由函数引用参数引发的实际 Bug 出发,剖析了错误背后隐蔽的思维定式。 问题的核心在于,许多人下意识地认为,当将一个变量作为“引用参数”传递给函数后,在函数内对它进行的任何修改都会直接反映到外部原始变量上。然而,在某些语言或特定编译器优化下,情况并非如此简单。作者发现,代码逻辑完全按此预期编写,但函数外部的变量值却未被改变,导致了功能异常。 经过排查,根因被定位到编译器对参数传递的具体实现上。在某些情况下,编译器可能为了优化,将“引用”参数以一种“值传递”的副本形式传入函数,导致函数内的修改仅作用于副本,而非原始数据。这个由“想当然”导致的错误,揭示了编程中一个常见陷阱:语言特性和底层实现之间可能存在细微但关键的差异。 文章最终提醒我们,对于关键的参数传递操作,尤其是涉及性能或内存敏感的场景,不能仅凭直觉。通过调试输出或查阅语言规范来验证实际行为,是避免此类隐蔽错误的有效方法。