[OTA] 系统加密后Recovery是如何读取OTA升级包的

目前很多Android手机采用的FUSE方案，也就是内部SD卡不单独占用一个文件系统而实际上占用的是userdata的空间。当系统加密后，解密需要VOLD的参于。而在Recovery模式下，是没有VOLD的启动的。因此，若是OTA升级包保存在了usrdata或内部存储器中时，Recovery是没有法子直接读取的。

那么，Android 5.0上，是怎么处理这个问题的呢？我来从头一一分析起来：

首先，安装升级包一般是调用

frameworks/base/core/java/android/os/RecoverySystem.java 中的installPackage来触发的。

    public static void installPackage(Context context, File packageFile)

        throws IOException {

        String filename = packageFile.getCanonicalPath();

        Log.w(TAG, "!!! REBOOTING TO INSTALL " + filename + " !!!");

        final String filenameArg = "--update_package=" + filename;

        final String localeArg = "--locale=" + Locale.getDefault().toString();

        bootCommand(context, filenameArg, localeArg);

    }

最终调用到了bootCommand中，在/cache/recovery/command写入 “--update_package=升级包的文件路径”。然后调用PowerManager, 触发REBOOT_RECOVERY

    /**

     * Reboot into the recovery system with the supplied argument.

     * @param args to pass to the recovery utility.

     * @throws IOException if something goes wrong.

     */

    private static void bootCommand(Context context, String... args) throws IOException {

        RECOVERY_DIR.mkdirs();  // In case we need it

        COMMAND_FILE.delete();  // In case it's not writable

        LOG_FILE.delete();

        FileWriter command = new FileWriter(COMMAND_FILE);

        try {

            for (String arg : args) {

                if (!TextUtils.isEmpty(arg)) {

                    command.write(arg);

                    command.write("\n");

                }

            }

        } finally {

            command.close();

        }

        // Having written the command file, go ahead and reboot

        PowerManager pm = (PowerManager) context.getSystemService(Context.POWER_SERVICE);

        pm.reboot(PowerManager.REBOOT_RECOVERY);

        throw new IOException("Reboot failed (no permissions?)");

    }

至于pm.reboot, 最后会调用到PowerManagerService的lowLevelReboot：

    /**

     * Low-level function to reboot the device. On success, this

     * function doesn't return. If more than 20 seconds passes from

     * the time a reboot is requested (120 seconds for reboot to

     * recovery), this method returns.

     *

     * @param reason code to pass to the kernel (e.g. "recovery"), or null.

     */

    public static void lowLevelReboot(String reason) {

        if (reason == null) {

            reason = "";

        }

        long duration;

        if (reason.equals(PowerManager.REBOOT_RECOVERY)) {

            // If we are rebooting to go into recovery, instead of

            // setting sys.powerctl directly we'll start the

            // pre-recovery service which will do some preparation for

            // recovery and then reboot for us.

            //

            // This preparation can take more than 20 seconds if

            // there's a very large update package, so lengthen the

            // timeout.  We have seen 750MB packages take 3-4 minutes

            SystemProperties.set("ctl.start", "pre-recovery");

            duration = 300 * 1000L;

        } else {

            SystemProperties.set("sys.powerctl", "reboot," + reason);

            duration = 20 * 1000L;

        }

        try {

            Thread.sleep(duration);

        } catch (InterruptedException e) {

            Thread.currentThread().interrupt();

        }

    }

当重启原因是REBOOT_RECOVERY是，居然不是直接重启，而是启动了pre-recovery这个服务。好吧，还要继续追踪，这个pre-recovery是啥东西？

在init.rc里有定义：

service pre-recovery /system/bin/uncrypt

    class main

    disabled

    oneshot

继续找 uncrypt，路漫漫啊。

uncrypt在这里 “bootable/recovery/uncrypt/”，看到Recovery了吧，开心了吧，快到头了。

int main(int argc, char** argv)

{

    const char* input_path;

    const char* map_file;

    int do_reboot = 1;

    if (argc != 1 && argc != 3) {

        fprintf(stderr, "usage: %s [<transform_path> <map_file>]\n", argv[0]);

        return 2;

    }

    if (argc == 3) {

        // when command-line args are given this binary is being used

        // for debugging; don't reboot to recovery at the end.

        input_path = argv[1];

        map_file = argv[2];

        do_reboot = 0;

    } else {

        input_path = parse_recovery_command_file();

        if (input_path == NULL) {

            // if we're rebooting to recovery without a package (say,

            // to wipe data), then we don't need to do anything before

            // going to recovery.

            ALOGI("no recovery command file or no update package arg");

            reboot_to_recovery();

            return 1;

        }

        map_file = CACHE_BLOCK_MAP;

    }

    ALOGI("update package is %s", input_path);

    // Turn the name of the file we're supposed to convert into an

    // absolute path, so we can find what filesystem it's on.

    char path[PATH_MAX+1];

    if (realpath(input_path, path) == NULL) {

        ALOGE("failed to convert %s to absolute path: %s", input_path, strerror(errno));

        return 1;

    }

    int encryptable;

    int encrypted;

    if (read_fstab() == NULL) {

        return 1;

    }

    const char* blk_dev = find_block_device(path, &encryptable, &encrypted);

    if (blk_dev == NULL) {

        ALOGE("failed to find block device for %s", path);

        return 1;

    }

    // If the filesystem it's on isn't encrypted, we only produce the

    // block map, we don't rewrite the file contents (it would be

    // pointless to do so).

    ALOGI("encryptable: %s\n", encryptable ? "yes" : "no");

    ALOGI("  encrypted: %s\n", encrypted ? "yes" : "no");

    // Recovery supports installing packages from 3 paths: /cache,

    // /data, and /sdcard.  (On a particular device, other locations

    // may work, but those are three we actually expect.)

    //

    // On /data we want to convert the file to a block map so that we

    // can read the package without mounting the partition.  On /cache

    // and /sdcard we leave the file alone.

    if (strncmp(path, "/data/", 6) != 0) {

        // path does not start with "/data/"; leave it alone.

        unlink(RECOVERY_COMMAND_FILE_TMP);

    } else {

        ALOGI("writing block map %s", map_file);

        if (produce_block_map(path, map_file, blk_dev, encrypted) != 0) {

            return 1;

        }

    }

    wipe_misc();

    rename(RECOVERY_COMMAND_FILE_TMP, RECOVERY_COMMAND_FILE);

    if (do_reboot) reboot_to_recovery();

    return 0;

}

看看uncrypt干吗了：

1.）看下是不是有额外参数，如果有，就以为是debug模式。。嗯，这个不管它。只看正常模式

2.）调用 parse_recovery_command_file()，就是读一下/cache/recovery/command了是的update-package。这个是RecoverySystem.java写入的

3.）读不到update-package，重启到recovery，如果是Factory Data Reset触发的wipe-data就走到这里。

4.）看看系统是不是加密的，我是感觉原生代码上这里少了块逻辑，如果系统没有加密，真接重启进recovery就是了，为什么还要继续转换？

5.) 看看 update-pacakge是不是以"/data"开始的。如果是的话，就调用produce_block_map

6.）删除中间文件，然后重启。

至于 produce_block_map干什么了，也是一目了然的。

1.）生成了一个block map，把/cache/recovery/command中的update_package的值改成 @/cache/recovery/block.map

2.）如果系统是加密的，就解密，嗯，uncrypt.c 注释里写的很详细，我就不瞎扯了（其实是我也没细看这逻辑）

// If the filesystem is using an encrypted block device, it will also

// read the file and rewrite it to the same blocks of the underlying

// (unencrypted) block device, so the file contents can be read

// without the need for the decryption key.

不过，看这注释讲，如果加密了，这个文件等升级完系统重启后，己经是被废掉了。

先说到这吧。其实还有块，Recovery下面是怎么能识别 @/cache/recovery/block.map这样的update_package的。

必须提一下有个作死的BUG。

当uncrypt的selinux权限不够读原升级包文件时，会出错并退出，退出就退出吧，偏偏不重启进Recovery，此时会造成用户点系统升级后，能看到关机动画，然后就是黑屏卡住不动了。当升级包是内置sd卡时，无论是不是加密，几乎是必出现的。

此时，会有selinux 的 denied的log.

04-14 09:32:50.094W/uncrypt ( 5524): type=1400 audit(0.0:25): avc: denied { getattr } forpath="/data/media" dev="mmcblk0p31" ino=567841scontext=u:r:uncrypt:s0 tcontext=u:object_r:media_rw_data_file:s0 tclass=dirpermissive=0

要怪就怪原生uncrypt没有media_rw的权限吧！（莫非google的OTA不用内卡？）解决方法也很简单，在uncrypt.te中加所需权

allow uncrypt media_rw_data_file:dir r_dir_perms;

allow uncrypt media_rw_data_file:file r_file_perms;

巴特西

[OTA] 系统加密后Recovery是如何读取OTA升级包的

最新文章

热门文章