当前位置:   article > 正文

android的刷机方式_android 刷机

android 刷机

         刷机攻略,回归一下。

         主要刷机方式,EDL(紧急下载,USB端口9008),fastboot工具线刷,OTA升级(全包/差分升级,nonAB系统与AB系统升级)。这个玩android系统的基本都知道,还是列个表:

环境

进入方式

工具

EDL模式

*

音量上+音量下

厂商工具(QFIL)

fastboot模式

Bootloader

音量下

Fastboot

recovery模式

Kernel+RecoveryFS(nonAB)

音量上

Adb

update_engine

Android system(AB)

update_engine

         表中进入方式不要认为是电源键+音量上/下,模式选择在开机时判断,长按电源键是为了重启。
下面分节,并带GPT修改和NV保留问题去看这几个刷机方式。

目录

1、EDL模式

2、fastboot模式

3、OTA升级

3.1、nonAB系统升级

3.2、AB系统的OTA升级

4、userdebug版本adb push 到/dev/block/by-name/对应的块设备节点


1、EDL模式

         详细见下面blog

高通 MSM8K bootloader 之二: SBL1_Fybon的博客-CSDN博客

1.1、分析xml文件

  1. <?xml version="1.0" ?>
  2. <data>
  3. <program SECTOR_SIZE_IN_BYTES="512" file_sector_offset="0" filename="boot.img" label="boot_a" num_partition_sectors="131072" physical_partition_number="0" size_in_KB="65536.0" sparse="false" start_byte_hex="0x1d220000" start_sector="954624" />
  4. </data>
  5. Program 可以改为read 来dump设备,
  6. SECTOR_SIZE_IN_BYTES 扇区大小
  7. file_sector_offset 偏移
  8. filename 文件名
  9. label 分区名
  10. num_partition_sectors 分区扇区数
  11. sparse 是否是sparse镜像格式,非sparse格式就是直接写。
  12. start_byte_hex 起始位置
  13. start_sector 起始扇区号

1.2、 MODEL参数(NV分区)保留

         方法1,有tool->QCN backup按键。

         方法2,有partition Manager->read.

         方法3configuration->FireHose configuration->Auto backup Restore QCN (读取后重写入)/Auto preserve(不动这几个分区)

1.3、分区下载

         使用partition manage读出的分区文件都是bin格式,load进去也必须是bin格式。

         把其它设备的userdata数据刷入到其它同样设备,数据完全保留,可用。(userdebug调试user的数据,手机还是需要设置开机密码的)

2fastboot模式

使用fastboot命令刷机流程详解_Android小码农的博客-CSDN博客_fastboot

2.1、文件分析

          android镜像分析已经提到。

2.2、fastboot命令

fastboot flash比较常用,刷指定分区命令类似于fastboot flash boot boot.img,下面几个命令可以了解下:

  1. fastboot -w 恢复出厂调试时发现不能同时刷modem,现在还未解)
  2. fastboot flashing unlock/lock 设备解锁/锁定,verify boot相关)
  3. fastboot --disable-verity --disable-verification flash vbmeta.img 关闭DM-verity)
  4. fastboot getvar all 读取设备相关信息)
  5. fastboot -aa/-ab 切换当前系统slot)
  6. fastboot erase  ***擦除分区)
  7. fastboot update otapackage.zip 没用过,应该是包先放入cache,重启后再recovery升级;OTA包线刷用adb sideload)
  8. fastboot boot boot.img 镜像分析boot.img有提到过,可直接调试boot.img)

cmdline 有点长

core_ctl_disable_cpumask=0-7 kpti=0 console=ttyMSM0,115200,n8 androidboot.console=ttyMSM0 androidboot.hardware=qcom msm_rtb.filter=0x237 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 androidboot.bootdevice=7824900.sdhci earlycon=msm_serial_dm,0x78af000 firmware_class.path=/vendor/firmware_mnt/image androidboot.usbconfigfs=true loop.max_part=7 buildvariant=userdebug androidboot.emmc=true androidboot.verifiedbootstate=orange androidboot.keymaster=1 dm="1 vroot none ro 1,0 4918112 verity 1 PARTUUID=1301d1c2-456f-1c8f-e1c1-1b435756052c PARTUUID=1301d1c2-456f-1c8f-e1c1-1b435756052c 4096 4096 614764 614764 sha1 2d97a9989b5bf9c8ae5263f2d88c40e34254210d 7e61282c660bf96ef462600a73a88471b5edab47 10 restart_on_corruption ignore_zero_blocks use_fec_from_device PARTUUID=1301d1c2-456f-1c8f-e1c1-1b435756052c fec_roots 2 fec_blocks 619606 fec_start 619606" root=/dev/dm-0 androidboot.vbmeta.device=PARTUUID=88b216e2-034a-fcbc-d3a5-6e06f26402da androidboot.vbmeta.avb_version=1.0 androidboot.vbmeta.device_state=unlocked androidboot.vbmeta.hash_alg=sha256 androidboot.vbmeta.size=4992 androidboot.vbmeta.digest=d434fe934f80dc3434a804980a8c13139b3a381a953778e7dd69c3190c7fcfa6 androidboot.veritymode=enforcing androidboot.serialno=0000000000 androidboot.baseband=msm mdss_mdp.panel=1:dsi:0:qcom,mdss_dsi_st7701s_tn_400p_video:1:none:cfg:single_dsi androidboot.slot_suffix=_a skip_initramfs root wait ro init=/init androidboot.dtbo_idx=0

         这里再说几点:

fastboot oem *** 可以aboot中自定义命令而不用修改fastboot工具。

fastboot -w 是fastboot getvar获取容量后,生成userdata.img镜像,再write,这就与flash userdata其实差不多了

fastboot -w有文件系统,fastboot erase userdata清空分区,后面这种进入system后识别userdata被擦,自动重启到recovery格式化userdata。

fastboot不支持读。

         如果设备直接连到你的编译服务器,可以设置刷机路径,使用fastboot flashall命令(我们都是windows批处理来刷机)。

3OTA升级

         OTA升级制作主要两种包,全包和差分包(现在翻译为增量包)。android 6开始OTA按块升级,差分包也是按块对比。

通过target-file包制作OTA全包命令:

./build/tools/releasetools/ota_from_target_files ${source_zip} ${output_zip}

通过target-file包制作OTA差分包命令:

./build/tools/releasetools/ota_from_target_files -i ${source_zip} ${target_zip} ${output_zip}

 ota_from_target_files更多参数可查看帮助。

        如果target-file包含所有fastboot升级包的所有内容还可以制作fastboot升级包

  1. unzip -q -o ${target_files_zip_name} IMAGES/vendor.img -d ${fastboot_out_tmp}/AP
  2. ***
  3. ***
  4. ***
  5. unzip -q -o ${target_files_zip_name} IMAGES/system.img -d ${fastboot_out_tmp}/AP
  6. unzip -q -o ${target_files_zip_name} IMAGES/modem.img -d ${fastboot_out_tmp}/MP

         现在区分nonAB和AB的android系统,虽然制作命令相同,但它们OTA包里面文件的格式,升级流程有很大差异。

3.1、nonAB系统升级

         nonAB升级流程是recovery调用OTA包中的update-binary二进制执行程序,解析updater-script脚本,按该脚本流程升级。

官网https://source.android.com/devices/tech/ota/nonab详细了解nonAB的OTA升级流程的看下面这系列的blog比较好

Android OTA升级包制作脚本详解(一,参数解析)_高桐@BILL的博客-CSDN博客

         system模式和recovery模式的文件系统不同,nonAB系统的recovery文件系统在recovery.img中,AB系统的recovery文件系统在boot.img中。执行程序在文件系统的sbin/recovery

         提示,如果是userdebug版本的recovery,可以挂载system使用adb

3.1.1 nonAB系统的OTA文件分析

         Android 4.4还是以文件方式升级,所以OTA包直接解压可以看到所有的文件。

         Android 6.0以块方式升级,要刷的system内容在system.new.dat中,这里sdat2img.py先转换下,然后挂载即可。OTA包解压,如下

File *

  1. boot.img:             Android bootimg, kernel, ramdisk, page size: 2048, cmdline (console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidbo)
  2. file_contexts.bin:    data
  3. firmware-update:      directory
  4. META-INF:             directory
  5. system.new.dat.br:    data
  6. system.patch.dat:     empty
  7. system.transfer.list: ASCII text
  8. vendor.new.dat.br:    data
  9. vendor.patch.dat:     empty
  10. vendor.transfer.list: ASCII text

sdat2img.py system.transfer.list system.new.dat system.img

  1. sdat2img binary - version: 1.0
  2. Android Nougat 7.x / Oreo 8.x detected!
  3. Skipping command erase...
  4. Copying 1024 blocks into position 0...
  5. Copying 1024 blocks into position 1024...
  6. Copying 1024 blocks into position 2048...
  7. Copying 1024 blocks into position 3072...
  8. ***
  9. ***
  10. ***
  11. Copying 1 blocks into position 345084...
  12. Copying 1 blocks into position 345086...
  13. Skipping command zero...
  14. ***
  15. Skipping command zero...
  16. Done! Output image: /***/system.img

sudo mount system.img systemtest挂载查看

         其中system.patch.dat这个是补丁文件,差分包才会使用。OTA包里面升级脚本执行程序在/META-INF/com/google/android/update-binary,升级脚本在/META-INF/com/google/android/updater-script。Android OTA升级原理和流程分析(一) --update.zip包的制作_发飙的IT宅男的博客-CSDN博客

3.1.2 recovery模式OTA包升级操作

         方法1、adb sideload updater.zip通过USB线升级。

         方法2、OTA包放入SD卡中升级

         recovery是无法读取userdata里面数据去升级的,当然你可以把一个分区当作sdcardfs文件类型来使用,达到使用内部数据升级的目的(sdcardfs文件类型区别于systemmedia等类型,https://www.anquanke.com/vul/id/1344320有描述sdcardfs的权限提升漏洞)

         方法3、使用MISC分区传送指令升级

通过misc传送指令可以实现system上层的升级

         下面是misc内数据分析

  1. 擦除数据      recovery\n--wipe_data
  2. 升级             recovery\n --update_package=/cache/some-filename.zip
  3. 工厂测试      FFBM-00(01/02)

3.1.3 升级工具update-binary分析

         该工具update-binaryupdater复制而来。updater源码在bootable\recovery\updater,编译出obj\EXECUTABLES\updater_intermediates\LINKED\updater后,再去掉一些信息转换成updaterLINKED下的updater可以通过nm -n 获取main函数起始位置,而最后得到的updater无法获取,android的可执行程序基本都如此)。下面是通过读取section(.text)去猜测main函数起始位置。(如果能直接得到,请赐教)下面开始反汇编:

file update-binary

update-binary: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, BuildID[md5/uuid]=55f330750d82ac7c1d716cd1ce1968e5, stripped

aarch64-linux-androidkernel-readelf -a update-binary

  1. Section Headers:
  2.   [Nr] Name              Type             Address           Offset
  3.        Size              EntSize          Flags  Link  Info  Align
  4.   [ 0]                   NULL             0000000000000000  00000000
  5.        0000000000000000  0000000000000000           0     0     0
  6.   [ 1] .note.android.ide NOTE             0000000000400158  00000158
  7.        0000000000000018  0000000000000000   A       0     0     4
  8.   [ 2] .note.gnu.build-i NOTE             0000000000400170  00000170
  9.        0000000000000020  0000000000000000   A       0     0     4
  10.   [ 3] .text             PROGBITS         00000000004001c0  000001c0
  11.        00000000001332bc  0000000000000000  AX       0     0     64
  12.   [ 4] .rodata           PROGBITS         0000000000533480  00133480
  13.        000000000004b200  0000000000000000   A       0     0     64
  14.   [ 5] .gcc_except_table PROGBITS         000000000057e680  0017e680
  15.        000000000000d404  0000000000000000   A       0     0     4

aarch64-linux-androidkernel-objdump -d update-binary –start-address=(.text)起始地址

  1.             00000000004001c0 <.text>:
  2.   4001c0:           f81e0ff3        str       x19, [sp,#-32]!
  3.   4001c4:           a9017bfd      stp      x29, x30, [sp,#16]
  4.   4001c8:           910043fd      add     x29, sp, #0x10
  5.   4001cc: 2a0003f3      mov    w19, w0
  6.   4001d0:          9404023c      bl        0x500ac0
  7.   4001d4:          aa1f03e0      mov    x0, xzr
  8.   4001d8:          94040165     bl        0x50076c
  9. ***
  10. ***
  11. ***
  12.   400894:          d65f03c0      ret
  13.   400898:          d10743ff       sub     sp, sp, #0x1d0
  14.   40089c:           a9176ffc       stp      x28, x27, [sp,#368]
  15.   4008a0:          a91867fa      stp      x26, x25, [sp,#384]
  16.   4008a4:          a9195ff8       stp      x24, x23, [sp,#400]
  17.   4008a8:          a91a57f6      stp      x22, x21, [sp,#416]
  18.   4008ac: a91b4ff4      stp      x20, x19, [sp,#432]

3.2、AB系统的OTA升级

         update_engine是AB系统升级工具。源码位置system/update_engine,其中 payload_consumer/delta_performer.cc中有限制升级的规则,包括检查时间戳,版本补丁等级等信息。

         目前AB系统做法是不再使用recoveryUI界面,在恢复出厂时还是用到该模式。由于该模式系统不挂载systemvendoruserdata分区,可以进行格式化操作。(当然你可以再开recoveryUI,也可以update_engine_sideload中添加boot_ctrl的静态库来支持recoveryOTA升级)

3.2.1、AB系统的OTA文件分析

 file *

  1. care_map.txt:           ASCII text
  2. compatibility.zip:      Zip archive data, at least v2.0 to extract
  3. META-INF:               directory
  4. payload.bin:            data
  5. payload_properties.txt: ASCII text

payload_dumperextract_android_ota_payload 可以解包其中的payload.bin文件

python3 payload_dumper.py payload.bin

file *

  1. aboot.img:     ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped
  2. boot.img:      Android bootimg, kernel, ramdisk, page size: 2048, cmdline (console=ttyMSM0,115200,n8 androidboot.console=ttyMSM0 androidbo)
  3. cmnlib64.img:  ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), statically linked, stripped
  4. cmnlib.img:    ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), statically linked, stripped
  5. devcfg.img:    ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped
  6. dsp.img:       Linux rev 1.0 ext4 filesystem data, UUID=af32c008-2a39-7e5b-a5dc-201456d93103, volume name "dsp" (extents) (large files)
  7. dtbo.img:      data
  8. keymaster.img: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), statically linked, stripped
  9. lksecapp.img:  ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), statically linked, stripped
  10. mdtp.img:      data
  11. modem.img:     DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "MSDOS5.0", sectors/cluster 32, root entries 512, Media descriptor 0xf8, sectors/FAT 22, sectors/track 63, heads 255, sectors 180224 (volumes > 32 MB) , serial number 0xbc614e, unlabeled, FAT (16 bit)
  12. rpm.img:       ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped
  13. sbl1.img:      ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped
  14. system.img:    Linux rev 1.0 ext2 filesystem data, UUID=4788ae58-ad4a-5bea-ae45-5b2f9b4368be (extents) (large files) (huge files)
  15. tz.img:        ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped
  16. vbmeta.img:    data
  17. vendor.img:    Linux rev 1.0 ext2 filesystem data, UUID=5204afa9-c67d-5902-83ce-5a06b5cc26f1, volume name "vendor" (extents) (large files) (huge files)
  18. xbl.img:       ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, corrupted section header size

         变成镜像后可以根据前面镜像分析去解析,这里几个sparse格式镜像都变成文件系统格式(Linux rev 1.0 ext2 filesystem data),因为制作的OTA包是按块刷写,不能使用sparse压缩格式,制作差分包也不能用sparse格式。

3.2.2update_engine的使用

    Android9.0系统OTA升级update_engine_-Ryan的博客-CSDN博客_applypayload请求升级

4userdebug版本adb push /dev/block/by-name/对应的块设备节点


这种也相当于刷机,所有分区不要push压缩格式(system/vendor/userdata/persist分区不要push sparse格式)


 

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/IT小白/article/detail/336172
推荐阅读
相关标签
  

闽ICP备14008679号