zoukankan      html  css  js  c++  java
  • [转]Android 制作recovery.img boot.img,重新打包recovery.img boot.img

    出自https://blog.csdn.net/whu_zhangmin/article/details/24733677

    本文以recovery.img为例来讲解说明,boot.img类似

    1、获取recovery.img

    首先将手机root,一般使用360一键root或者百度一键root,这是一种软件层面的root,无非是利用android漏洞在/system/app下植入一个superuser.apk来掌管root权限,每次用户需要root权限时,使用su命令,界面会弹出对话框要求确认。下面还会讲到另一种root,把它叫做内核root,也就是default.prop这个文件中两个属性值:

    ro.secure=0

    ro.debuggable=1

    内核root之后,adb shell直接是root用户登录,而软件层面root,adb shell依然是shell用户登录,必须通过su命令切换到root用户($ 符号变成#)。

    一般我们如果不是手机厂商用户,刚开始只能是软件层面的root。

    adb shell

    su

    切换到root用户后

    1)如果是高通芯片的手机,采用以下命令将recovery.img拷贝出来

    dd if=/dev/block/platform/msm_sdcc.1/by-name/recovery of=/storage/sdcard/recovery.img

    ps:cd  /dev/block/platform/msm_sdcc.1/by-name 到这个目录下ls -al命令可以看到revoery其实是个链接文件,链接到/dev/block/mmcblk0p16  这个分区块,因此也可以使用一下命令:

    dd if=/dev/block/mmcblk0p16 of=/storage/sdcard/recovery.img

    2)如果是MTK芯片的手机

    有两种方式:

    dd if=/dev/recovery of=/storage/sdcard/recovery.img bs=1024 count=6144

    dd if=/dev/block/mmcblk0 of=/storage/sdcard/recovery.img skip=xxxx bs=1024 count=6144

     

    注意:bs的值目前可以固定1024,count的值需要查看cat /proc/dumchar_info文件对应的recovery大小来确定(高通平台没有dumchar_info这个文件),

    比如size一列为0x600000,那么count的值为6144,也就是6M,如果为0x700000,那么count的值为7168,也就是7M大小。

    skip代表偏移,因为MTK平台recovery和boot等都在一个相同的分区中,通过地址偏移量来区分,这就是为什么高通平台不需要执行bs 和count的原因。

    3)如果手机是Nvidia芯片

    ddif=/dev/block/platform/sdhci-tegra.3/by-name/SOS of=/storage/sdcard/recovery.img 

     

    2、解压缩recovery.img

    网上很多文章有关解压缩和重新打包压缩recovery.img的,利用perl脚本split_bootimg.pl 来解压缩,但本人试验过,解压缩还行,重新打包就完全不行,生成的recovery.img根本没法用。

    recovery.img中主要包含内核recovery.img-kernel和根文件系统recovery.img-ramdisk.gz两个东西。

    这一步依然要区分MTK平台和非MTK平台

    1)对于MTK平台,过程稍微多一步

     

    ./split_bootimg.pl $1

    //如果是非MTK平台就不需要这一段代码
    filename=`basename $1`
    echo $filename.....
    dd if="$filename-ramdisk.gz" of="$filename-ramdisk.tmp.gz" skip=512 bs=1
    mv "$filename-ramdisk.gz" "$filename-ramdisk.gz.full"
    mv "$filename-ramdisk.tmp.gz" "$filename-ramdisk.gz"
    
    
    rm -fr ramdisk_bak
    mv ramdisk ramdisk_bak
    mkdir -m 777 ramdisk
    cd ramdisk
    gzip -dc ../$1-ramdisk.gz | cpio -i
    cd ../
    chmod 777 -R ramdisk
    View Code

     

    $1代表传入的参数recovery.img

    执行这段脚本代码后,屏幕会打印类似

    Page size: 2048 (0x00000800)
    Kernel size: 4285080 (0x00416298)
    Kernel addr: 268468224 (0x10008000)
    Ramdisk size: 1712833 (0x001a22c1)
    Ramdisk addr: 285212672 (0x11000000)
    Second size: 0 (0x00000000)
    tag addr: 268435712 (0x10000100)
    dt size: 0 (0x00000000)
    Board name: 
    Command line: 
    dt: 0 (0x00000000)
    dt_offset: 6002688 (0x005b9800)
    Writing revocery.img-kernel ... complete.
    Writing revocery.img-ramdisk.gz ... complete.

     

    解压之后在当前目录下就生成了ramdisk目录,里面就是根文件系统

     

    2)对于非MTK平台,比如高通平台

    ./split_bootimg.pl $1

    rm -fr ramdisk_bak
    mv ramdisk ramdisk_bak
    mkdir -m 777 ramdisk
    cd ramdisk
    gzip -dc ../$1-ramdisk.gz | cpio -i
    cd ../
    chmod 777 -R ramdisk
    View Code

     

     

    执行解压后会输出如下:

    Page size: 2048 (0x00000800)
    Kernel size: 6471072 (0x0062bda0)
    Kernel addr: 32768 (0x00008000)
    Ramdisk size: 1995775 (0x001e73ff)
    Ramdisk addr: 33554432 (0x02000000)
    Second size: 0 (0x00000000)
    tag addr: 31457280 (0x01e00000)
    dt size: 5046272 (0x004d0000)
    Board name: 
    Command line: console=none androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 ehci-hcd.park=3 restart.panic_to_dload=0 restart.download_mode=0
    dt: 2464 (0x000009a0)
    dt_offset: 8470528 (0x00814000)
    Writing recovery.img-kernel ... complete.
    Writing recovery.img-ramdisk.gz ... complete.
    Writing recovery.img-dt.gz ... complete.
    6640 blocks

    注意上面的输出内容:Kernel addr,Ramdisk addr,Command line 以及dt size(可能为0)

    Kernel addr = base addr + 0x8000

    Ramdisk offset = Ramdisk addr - base addr

    Ramdisk addr =base+0x2000000

    tag addr =base+0x100

    这里base addr为0x00000000,Ramdisk offset 为0x02000000,注意还生成了一个recovery.img-dt.gz

    同样也生成了ramdisk目录,可以替换sbin目录下的可执行文件,换成自己定制的recovery,同样的打开build.prop可以修改内核root的两个属性

    ro.secure=0

    ro.debuggable=1

    注意,改这两个属性在boot.img中,并重新打包刷到手机中,就能实现内核root了。

     

    3、重新压缩打包recovery.img

    1)对于非MTK平台:

    //将ramdisk目录打包成ramdisk-new.gz压缩包

    rm -fr ramdisk-new.gz
    ./mkbootfs ./ramdisk | gzip > ramdisk-new.gz

    rm -fr recovery-new.img
    ./mkbootimg --cmdline 'console=none androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 ehci-hcd.park=3 restart.panic_to_dload=0 restart.download_mode=0' --kernel recovery.img-kernel --ramdisk ramdisk-new.gz --base 0x00000000 --pagesize 2048 --ramdisk_offset 0x02000000  --dt recovery.img-dt.gz -o recovery-new.img

    注意看命令,在第二步中计算过的--base 0x00000000 --pagesize 2048 --ramdisk_offset 0x02000000值都用上了,同时加上--dt命令(有些recovery.img也没有包含dt文件,这种情况下就不需要--dt参数)

    2)对于MTK平台

    就不需要上面计算的参数,直接

    ./repackMTK.pl -recovery recovery.img-kernel ramdisk recovery-new.img

     

    4、接下来就是重新烧到手机中验证了,可以通过fastboot来烧写,可以参考我的上一篇记录Android 采用fastboot刷system.img boot.img recovery.img

  • 相关阅读:
    Redis 主从复制架构配置及原理
    IPTABLES详解(10):IPTABLES自定义链
    ipset
    Atitit 数据库核心技术index索引技术 btree hash lsm fulltxt目录1.1. HASH
    Atitit 存储引擎核心技术 总结目录1. 表的存储有三个文件:结构+数据+索引 12. 页式管理
    Atitit 为什么oracle这类大型数据库比mysql的性能机制目录1. 分区机制差别 11.1. Join算
    Atitit 存储与数据库性能调优流程目录1. 数据库出现性能瓶颈,对外表现有几个方面:
    ATITIT db perf enhs 数据库性能优化 目录 第一章 Cache类 1 第一节 查询cache 1 第二节 Update cache 2 第三节 内存表机制 零时表 2 第四节 雾
    Atitit 核心技术有哪些一般 目录 第一章 Rest调用交互 2 第二章 2 第三章 Cmd调用交互 2 第四章 2 第五章 爬虫技术 2 第一节 Httpclient 2 第二节 Html
    Atitit保证架构超前性 前瞻性 目录 第一章 为什么需要修改代码 1 第一节 业务增加功能 1 第二节 增加字段 1 第三节 增加表数据需要查询 修改 1 第四节 类库升级 1 第二章 简单抽象
  • 原文地址:https://www.cnblogs.com/libra13179/p/13711899.html
Copyright © 2011-2022 走看看