Android Verified Boot Recovery/OTA verify_package过程

最新推荐文章于 2024-10-30 15:09:02 发布

junwua

最新推荐文章于 2024-10-30 15:09:02 发布

阅读量1.3k

点赞数

CC 4.0 BY-SA版权

本文链接：https://blog.youkuaiyun.com/junwua/article/details/103488416

本文深入探讨Android OTA升级过程中的公钥验证机制，详细解析/res/keys文件的来源及其在Android Recovery下的作用。从编译Makefile入手，揭示RECOVERY_INSTALL_OTA_KEYS如何将默认系统开发证书拷贝至目标目录，确保OTA升级包的安全性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Android Recovery下升级，实际上OTA最终也是调用这个方法。

里面有个流程是需要验证verify_package，使用的是/res/keys，这个keys是从哪儿来的呢。

static constexpr const char* PUBLIC_KEYS_FILE = "/res/keys";
std::vector<Certificate> loadedKeys;
if (!load_keys(PUBLIC_KEYS_FILE, loadedKeys)) {
查看了recovery编译out目录，确实发现有这个文件呢，

recovery/root/res$ ls keys

刚开始以为是bootloader/recovery下，搜了没有。后面想了下，找下 RECOVERY文件的

编译Makefile。在目录build/make/core/Makefile，找到了RECOVERY_INSTALL_OTA_KEYS，

顺着代码看了下：

# substitute other keys for this one.
OTA_PUBLIC_KEYS := $(DEFAULT_SYSTEM_DEV_CERTIFICATE).x509.pem

$(RECOVERY_INSTALL_OTA_KEYS): PRIVATE_OTA_PUBLIC_KEYS := $(OTA_PUBLIC_KEYS)

$(hide) cp $(RECOVERY_INSTALL_OTA_KEYS) $(TARGET_RECOVERY_ROOT_OUT)/res/keys

编译log：

default_system_dev_certificate = (str) device/mediatek/common/security/releasekey

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

junwua

关注关注

0
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

Android系统之路(初识MTK) ------ OTA打包ROM安装系统img等到ZIP

Engineer-Jsp的专栏

03-16

5831

Android系统之路(初识MTK) ------ OTA打包ROM安装系统img等到ZIP

android 8.0 recovery模式,Android 8.0 OTA 分析——recovery

weixin_34983902的博客

06-01

942

这里是OTA分析的第一部分，主要是recovery模块，后面会对脚本进行分析如果有分析不到位的地方请指出，共同学习进步一、首先来看下升级的入口1.上层写入命令主动升级：这是最常见的方式，负责升级的APK会向command中写入升级的信息，比如”–update_package”参数和升级包的路径等[recovery.cpp]if (update_package != NULL) {// It's n...

参与评论您还未登录，请先登录后发表或查看评论

verify-package-version::folded_hands:GitHub动作，用于验证您的软件包版本是否满足某些条件

05-10

:folded_hands: 验证软件包版本验证您的软件包版本是否满足某些条件。当前仅支持PR触发，并且可以通过提出更多方案要求。预习如何使用？ name : Verify Package Version on : pull_request : types : [opened, edited, reopened, synchronize, ready_for_review] jobs : verify : runs-on : ubuntu-latest # Add conditions to trigger more effectively if : contains(github.event.pull_request.title, 'changelog') steps : - uses : actions/checkout@v2

验证软件包的正确性

软若石（I Will Get What I Want.）Asp.Net,Ajax,C#,Javascript

07-18

3499

2.1.4. 通过MD5校验和或GnuPG验证软件包的完整性 2.1.4.1. 验证MD5校验和 2.1.4.2. 通过GnuPG进行签名检查 2.1.4.3. 使用RPM进行签名检查下载了适合你的需求的MySQL安装软件包并在安装前，你应当确保它的完整性，没有被篡改。MySQL AB提供了

RecoverySystem.verifyPackage方法注释介绍

weixin_30335293的博客

07-04

3837

/** * Verify the cryptographic signature of a system update package before installing it. Note that the package is also verified separately by the installer once the device is rebooted into the reco...

android recovery框架,RecoverySystem

weixin_31467557的博客

05-31

531

verifyPackagepublic static void verifyPackage (File packageFile,RecoverySystem.ProgressListener listener,File deviceCertsZipFile)Verify the cryptographic signature of a system update packagebefore ins...

Android RecoverSystem 类

UPON的博客

09-30

636

昨天开会讨论IP网络升级时，需要一个后台服务做升级检测及下载数据，最后在定义下载的数据存放位置及如何做开机标志时，突然发现一个很好用的上层java类对象。 frameworks\base\core\java\android\os\RecoverySystem.java 那么这个类做了什么事情呢？又是如何做到的。 RecoverySystem类，可以帮助我们调用系统还原

android ota 版本校验,OTA升级签名校验简析

weixin_39518002的博客

05-26

1478

1. 概要如果进行过OTA升级的开发者，都或多或少有这样的疑问，如何确定该OTA升级包是可以信任的呢？这其中其实涉及到一个签名验证的流程。2. 签名生成在生成正规的固件时，一般会运行生成新key的脚本，并重新修改key中的信息。以网上常用的生成key的脚本为例:#!/bin/shAUTH='/C=CN/ST=xxxx/L=xxxxx/O=xxxxxx/OU=xxxxx/CN=China/email...

fota升级失败小结（recovery.cpp）

淡淡的宁静的博客

06-12

4870

1.查看升级成功和失败的recovery的log，在/cache/recovery/last_log 2.用sourceinsight导入/bootable/recovery，根据log，全局搜索。逐步分析 3.有些没有的方法可能存在/system或者/bionic下。 4.如果没有想要的，可以用串口去在recovery期间抓取完整的log，但是串口不是usb，需要拆开机器去焊接引出几根串口线，...

Android启动流程_Init阶段

Yang_Mao_Shan的博客

10-30

2930

本篇文章介绍了 Android 启动时 init 进程的功能，从 init 的启动阶段到 rc 文件的解析，服务的介绍等。

Recovery启动流程--recovery.cpp分析

weixin_30666401的博客

09-23

1056

这篇文章主要通过分析高通recovery目录下的recovery.cpp源码，对recovery启动流程有一个宏观的了解。当开机以后，在lk阶段，如果是recovery，会设置boot_into_recovery=1,然后读取recovery.img镜像，把recovery.img的地址和ramdisk等信息作为参数启动kernel，从而进入recovery模式，下面进行简单的分析。 ...

Android 的Recovery机制

热门推荐

fengying765的专栏

07-30

1万+

Android 的Recovery机制目录 1. 系统的启动模式 1 1.1 Android系统的启动模式 1 1.2 系统的启动模式 2 2. Recovery模式中的三个部分 3 3. Recovery模式中的两个通信接口 3 3.1 主系统和Recovery通过/cache下的文件通信 3 3.2 Bootloader与Recovery通过BCB（Bootload

Android OTA系统升级---原理三

darwinlong的博客

12-13

1188

最近公司的一个老的项目，现在客户在专网方面遇到一点问题，进行版本升级时，由于客户是公安，比较强硬，要求升级时不能擦除数据，这个可以简单的通过改下打包脚本下参数就能解决。还是花了很长时间来跟踪OTA打包的过程。 ### 相关变量 184 PRODUCT_OUT := $(TARGET_PRODUCT_OUT_ROOT)/$(TARGET_DEVICE) 187 188 HOS

Android OTA 升级之三：生成recovery.img

Lidong_Zhou的专栏

05-11

943

2011-03-08 08:206836人阅读评论(1)收藏举报 Android OTA 升级之三：生成recovery.img 作者：宋立新 Email：zjujoe@yahoo.com 前言得到了ota升级包后，我们就可以用它来升级系统了。Android 手机开机后，会先运行 bootloader。 Bootloader 会根据某些判定条件（比如按某个特殊键）决

idea中maven的几个操作按钮：clean、validate、compile...

m0_47743175的博客

05-05

4528

idea中maven的几个操作按钮：clean、validate、compile...

android 防刷机

lb5761311的专栏

05-28

8339

最近做的一款产品，由于前期失误使用的是官方的testkey 签名rom包。所以别人rom可以随意刷我们产品盒子，为了改正这个bug我们使用了新的签名刷自己产品。防止别人盗刷我们盒子。要用新签名rom包，先要理解android升级原理，第一步：当我们手动u盘升级或者ota升级下载好update.zip包后。当我们点击升级后，android framework的代码 .

recovery的一些开发点滴

weixin_34406796的博客

04-19

539

Android的recovery是我在公司做的最多的，应该也是我在Android中了解的较为深入的一个部分。recovery这部分其实Android本身都已经提供了很完善的一套机制，但是因为公司是做机顶盒的，所以在因为平台订制的关系，recovery这部分还是做了很多修改的。首先，修改的比较少的是OTT这种盒子，本次也主要讲这种，其实这种和手机区别...

Android recovery分析（二）---增量升级包的编译流程

mrcc_yy的博客

06-09

9091

Android recovery分析（二）---增量升级包的编译流程

android系统更新原理简介

搬砖的老牛

11-24

3874

简介： Android系统更新简而言之就是将升级包从服务器下载到本地然后对当前系统进行升级的过程，主要包括三大块：升级包、应用层、recovery层。主要功能流程如下如所示：升级包：版本编译完成后会生成target_file，这里的名称是：ota_target,升级包就是使用源版本的target_file跟目标版本的target_file通过imgdiff/bsdiff工具完成两个img文件的对比差分，做出升级所需的.new.dat、.patch.dat、.transfer.list文件，目

最新发布

03-28

<think>嗯，用户现在又提供了一段新的日志，需要我帮忙分析和解释。之前他们问了关于权限缺失的问题，现在看起来这次的问题可能与用户数据的准备和加密有关。首先，我需要仔细看一下用户提供的日志内容。日志中有几个关键部分：UserDataPreparer在准备用户数据，vold进程在处理存储相关的操作，还有之前的HealthPermIntentTracker警告，以及MediaGrants相关的操作。用户提到的UserHandle{11}，这在之前的对话中也出现过。可能用户正在处理多用户环境下的问题，比如新建用户账户时出现的问题。之前的回答已经涉及到了用户句柄缺失的警告，这次可能是在用户创建过程中出现的更多细节。接下来，日志中多次出现vold进程的操作，比如fscrypt_prepare_user_storage，准备各种目录如/data/system/users/11、/data/misc/profiles/cur/11等，并且验证了加密策略。这表明系统正在为新用户（用户ID 11）准备加密的存储空间。同时，MediaGrants部分提到了移除了0个媒体授权，可能是因为用户模式变化，比如权限变更。用户可能需要了解这些日志的含义，尤其是为什么在准备用户数据时会出现HealthPermIntentTracker的警告，以及整个过程的正常性。他们可能关心这是否意味着用户创建过程中存在错误，或者是否有安全隐患，特别是加密相关的部分。需要确认这些日志中的操作是否是正常流程的一部分。例如，当创建新用户时，系统需要为其准备数据目录并设置加密，vold负责这部分工作。而HealthPermIntentTracker的警告可能是在用户数据尚未完全初始化时，某些服务尝试访问用户句柄导致的，这可能是一个时序问题，但如果没有后续的错误，可能只是暂时的警告。另外，MediaGrants显示移除了0个授权，这可能是因为新用户还没有任何媒体权限，所以移除操作没有实际影响。这可能也是正常现象，不需要特别处理。用户可能还想知道这些日志中的加密策略验证是否成功，比如那些“Verified”的行是否表示一切正常。从日志看，vold成功验证了各个目录的加密策略，说明加密配置是正确的，没有错误。综合来看，用户的日志显示系统正在正常创建新用户（用户11），准备其数据目录并应用加密策略，而HealthPermIntentTracker的警告可能是在用户尚未完全就绪时触发的，但后续步骤显示用户数据准备成功。用户可能需要确认是否在创建新用户时遇到问题，或者只是看到这些日志想确认其正常性。此外，用户可能有更深层的需求，比如设备是否安全，或者多用户功能是否正常工作。需要建议他们检查用户创建后的状态，是否有功能异常，或者是否需要更新系统以修复潜在的兼容性问题。</think>以下是您提供的日志的逐层解析与解决方案： --- ### **日志核心流程** 该日志记录了Android系统为**新创建的用户（User 11）**准备数据存储空间的全过程，涉及**存储加密初始化**与**权限配置**，属于多用户设备（如平板、企业版手机）的典型操作。 --- ### **关键步骤分解** #### **1. 用户数据初始化** ```logcat 906 D UserDataPreparer: Preparing user data; volumeUuid=null, userId=11, flags=0x1, isNewUser=true ``` - **含义**：系统开始为用户11准备数据目录，`isNewUser=true`表明这是新用户首次创建。 - **关键参数**： - `flags=0x1`：对应`StorageManager.FLAG_STORAGE_DE`，表示准备**设备加密（Device Encryption）存储空间**。 - `volumeUuid=null`：操作主存储卷（通常是`/data`分区）。 --- #### **2. 存储加密准备（vold进程）** ```logcat D vold: fscrypt_prepare_user_storage for volume null, user 11, flags 1 D vold: Preparing: /data/system/users/11 ... I vold: Verified that /data/system_de/11 has the encryption policy 5db7e42a9b00a8f566d9ca1088d53bcb v2 modes 9/9 flags 0x6 ``` - **核心操作**： - **目录创建**：生成用户专属目录（如`/data/system/users/11`用于系统配置，`/data/user_de/11`用于加密应用数据）。 - **加密策略验证**：使用`fscrypt`（文件系统加密工具）确认目录加密策略一致，其中： - `v2 modes 9/9`：加密算法为AES-256-XTS（模式9）。 - `flags 0x6`：表示目录需要加密且允许递归加密子目录。 - **技术背景**：Android从7.0（API 24）起支持基于文件的加密（FBE），取代全盘加密（FDE）。 --- #### **3. 权限警告复现** ```logcat W HealthPermIntentTracker: Requested user handle: UserHandle{11} is not present in the state. ``` - **关联性**：此警告与[前次日志](链接)中的问题一致，表明**用户11的上下文尚未完全加载**。 - **时序解释**：由于用户数据仍在初始化中，部分服务可能提前尝试访问该用户导致警告，通常会在初始化完成后自动恢复。 --- #### **4. 媒体权限清理** ```logcat D MediaGrants: Removed 0 media_grants for 11 user... Reason: Mode changed: android:read_external_storage ``` - **含义**：系统清理用户11的媒体文件访问权限（如相册、音频），但因新用户无历史授权记录（移除数量为0），操作无实际影响。 - **触发条件**：用户存储加密状态变化（如首次创建或密钥轮换）。 --- ### **潜在问题排查** #### **场景1：用户创建失败** - **表现**：日志停留在`UserDataPreparer`或`vold`步骤，后续无成功记录。 - **解决方案**： 1. 检查存储空间是否充足：`adb shell df /data` 2. 确认文件系统无损坏：`adb shell e2fsck -f /dev/block/by-name/userdata` 3. 查看加密策略兼容性：`adb shell getprop ro.crypto.type` #### **场景2：加密策略验证失败** - **表现**：`vold`日志中出现`Failed to verify encryption policy`错误。 - **解决方案**： 1. 重启进入Recovery模式清除`/data`分区（**警告：导致数据丢失**）。 2. 更新系统版本修复加密驱动问题。 --- ### **技术总结** - **流程正常性**：此日志表明用户11已**成功创建**且存储加密正常，警告信息多为初始化时序问题，无需干预。 - **调试建议**： ```bash # 监控用户创建全流程 adb logcat -s UserDataPreparer:vold:I HealthPermIntentTracker:W # 查看用户11的加密状态 adb shell ls -lZ /data/user_de/11 ``` - **延伸阅读**：[Android多用户管理官方文档](https://source.android.com/docs/core/config/users) | [FBE加密实现细节](https://source.android.com/docs/security/features/encryption/file-based)