这篇文章上次修改于 580 天前,可能其部分内容已经发生变化,如有疑问可询问作者。
第一次变砖是没有解BL的时候,提权改了boot分区
xaga => Redmi Note 11T Pro
不要尝试不要尝试不要尝试
起因是执行了下面的命令:
mkdir -m 755 /data/local/tmp/fake_system_lib64
cp -rf /system/lib64/* /data/local/tmp/fake_system_lib64/
mount -t tmpfs tmpfs /system/lib64
/data/local/tmp/busybox-arm64 mv /data/local/tmp/fake_system_lib64/* /system/lib64/
cp /data/local/tmp/libmagtsync.so /system/lib64/
chown root:root -R /system/lib64/*
chmod 644 -R /system/lib64/*
chcon u:object_r:system_lib_file:s0 -R /system/lib64/*
执行下面这一句命令之后,原来的/system/lib64
会被屏蔽,但此时如果重启,系统还是正常的
mount -t tmpfs tmpfs /system/lib64
下一步本来是是mv命令,但是系统的mv依赖于/system/lib64
下面的库,然而在好奇心的驱使下,我找来了busybox操作
然后mv命令成功,接着cp也是成功了的
然后下面三个命令出现了Read only system
字样的提示
chown chmod chcon
随后尝试打开下任意APP,起初只是黑屏,状态栏没有黑
然后还能切换到系统设置,也就是通过状态栏下拉,可以长按进入WIFI等设置界面
但是全面屏手势失效,于是长按关机键,尝试重启
无法开机,出现Android的logo画面,但是无法到MIUI的logo画面
后多次尝试刷机,但不擦除userdata的情况下,均未成功
其他信息:
- 最近从MIUI13升级到MIUI14,也就是系统进行了一次大更新,从原先的slot a换到了slot b
- 有尝试把5.10.66的twrp刷入到了slot b,也就是Android 13,但是内核是5.10.101,后来得知这会导致hard brick,不过我当前并没有,因为还是能刷fastboot的
支持xaga 5.10.101内核的twrp:
- https://sopy264-onedrive.vercel.app/zh-CN/TWRP/
- https://sopy264-onedrive.vercel.app/zh-CN/TWRP/5.10.101%20wbs
github上那个只有5.10.66内核的twrp,一开始没有发现这个5.10.101的,sad,如果最开始找到这个也许能正常恢复
非常重要的提醒:
Lethal Warning: Flashing twrp.wbs.66 in A13 roms leads to guaranteed hard brick (hard brick = can't boot into system, and recovery and fastboot partitions are inaccessible too. Need to visit service centres for fix.)
Command to flash fastboot flash vendor_boot <twrpbuild>.img
Notes: Dont use fastboot flash recovery since a12 google move recovery into vendor_boot
后续
准备送售后,希望至少个人数据还有救,待我补充后续
libmagtsync.so
之前有个想法,就是搞个tmpfs,然后修改系统库的依赖,再加一个自己的so,这样实现对任意APP的注入
但是这样还是太麻烦了,就没有尝试
然后昨天(2023/04/19)调试的时候,发现logcat出现找不到libmagtsync.so,这tag甚至叫FBI(
E/FBI: Can't load library: dlopen failed: library "libmagtsync.so" not found
找了下发现是miui的libgui.so会去尝试dlopen这个库
于是想着直接编译一个loader,改成这个名字,放到/system/lib64下面,这样注入(没什么别的就是想试一下tmpfs这样行不行,系统正常运行情况下,而非magisk在开机的时候通过脚本做。。)
然后就是上面的悲剧了 :)
后续补充
进三方recovery,看到的各个分区情况:
xaga:/ # ls -al /dev/block/platform/soc/112b0000.ufshci/by-name/ --color
total 0
drwxr-xr-x 2 root root 1780 2009-12-31 18:02 .
drwxr-xr-x 3 root root 1860 2009-12-31 18:02 ..
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 apusys_a -> /dev/block/sdc36
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 apusys_b -> /dev/block/sdc65
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 audio_dsp_a -> /dev/block/sdc27
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 audio_dsp_b -> /dev/block/sdc56
lrwxrwxrwx 1 root root 15 2009-12-31 18:02 backup1 -> /dev/block/sdc2
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 backup2 -> /dev/block/sdc21
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 backup3 -> /dev/block/sdc47
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 backup4 -> /dev/block/sdc52
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 backup5 -> /dev/block/sdc76
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 backup6 -> /dev/block/sdc85
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 boot_a -> /dev/block/sdc43
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 boot_b -> /dev/block/sdc72
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 boot_para -> /dev/block/sdc50
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 ccu_a -> /dev/block/sdc31
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 ccu_b -> /dev/block/sdc60
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 connsys_bt_a -> /dev/block/sdc41
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 connsys_bt_b -> /dev/block/sdc70
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 connsys_wifi_a -> /dev/block/sdc42
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 connsys_wifi_b -> /dev/block/sdc71
lrwxrwxrwx 1 root root 15 2009-12-31 18:02 countrycode -> /dev/block/sdc9
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 cust -> /dev/block/sdc83
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 dpm_a -> /dev/block/sdc29
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 dpm_b -> /dev/block/sdc58
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 dram_para -> /dev/block/sdc51
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 dtbo_a -> /dev/block/sdc45
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 dtbo_b -> /dev/block/sdc74
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 efuse -> /dev/block/sdc49
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 expdb -> /dev/block/sdc11
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 ffu -> /dev/block/sdc79
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 flashinfo -> /dev/block/sdc87
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 frp -> /dev/block/sdc12
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 gpueb_a -> /dev/block/sdc35
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 gpueb_b -> /dev/block/sdc64
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 gsort -> /dev/block/sdc78
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 gz_a -> /dev/block/sdc38
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 gz_b -> /dev/block/sdc67
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 lk_a -> /dev/block/sdc39
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 lk_b -> /dev/block/sdc68
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 logo_a -> /dev/block/sdc40
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 logo_b -> /dev/block/sdc69
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 mcf_ota_a -> /dev/block/sdc26
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 mcf_ota_b -> /dev/block/sdc55
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 mcupm_a -> /dev/block/sdc34
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 mcupm_b -> /dev/block/sdc63
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 md1img_a -> /dev/block/sdc24
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 md1img_b -> /dev/block/sdc53
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 mem -> /dev/block/sdc80
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 metadata -> /dev/block/sdc20
lrwxrwxrwx 1 root root 15 2009-12-31 18:02 misc -> /dev/block/sdc1
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 mvpu_algo_a -> /dev/block/sdc37
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 mvpu_algo_b -> /dev/block/sdc66
lrwxrwxrwx 1 root root 15 2009-12-31 18:02 nvcfg -> /dev/block/sdc7
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 nvdata -> /dev/block/sdc13
lrwxrwxrwx 1 root root 15 2009-12-31 18:02 nvram -> /dev/block/sdc5
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 oem_misc1 -> /dev/block/sdc82
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 oops -> /dev/block/sdc81
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 otp -> /dev/block/sdc23
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 para -> /dev/block/sdc10
lrwxrwxrwx 1 root root 15 2009-12-31 18:02 persist -> /dev/block/sdc8
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 pi_img_a -> /dev/block/sdc28
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 pi_img_b -> /dev/block/sdc57
lrwxrwxrwx 1 root root 15 2009-12-31 18:02 proinfo -> /dev/block/sdc6
lrwxrwxrwx 1 root root 15 2009-12-31 18:02 protect1 -> /dev/block/sdc3
lrwxrwxrwx 1 root root 15 2009-12-31 18:02 protect2 -> /dev/block/sdc4
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 rescue -> /dev/block/sdc84
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 scp_a -> /dev/block/sdc30
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 scp_b -> /dev/block/sdc59
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 sec1 -> /dev/block/sdc48
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 seccfg -> /dev/block/sdc22
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 spmfw_a -> /dev/block/sdc25
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 spmfw_b -> /dev/block/sdc54
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 sspm_a -> /dev/block/sdc33
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 sspm_b -> /dev/block/sdc62
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 super -> /dev/block/sdc77
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 tee_a -> /dev/block/sdc46
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 tee_b -> /dev/block/sdc75
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 userdata -> /dev/block/sdc86
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 vbmeta_a -> /dev/block/sdc14
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 vbmeta_b -> /dev/block/sdc17
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 vbmeta_system_a -> /dev/block/sdc15
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 vbmeta_system_b -> /dev/block/sdc18
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 vbmeta_vendor_a -> /dev/block/sdc16
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 vbmeta_vendor_b -> /dev/block/sdc19
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 vcp_a -> /dev/block/sdc32
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 vcp_b -> /dev/block/sdc61
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 vendor_boot_a -> /dev/block/sdc44
lrwxrwxrwx 1 root root 16 2009-12-31 18:02 vendor_boot_b -> /dev/block/sdc73
从OTA包中解包出来的镜像有这些:
- miui_XAGA_V13.0.14.0.SLOCNXM_559aa81f92_12.0.zip
顺带一提,一些解包工具可能比较老,有可能解包不全,所以尽可能找新一点的工具,我这里用的是android-ota-payload-extractor
apusys.img
audio_dsp.img
boot.img
ccu.img
dpm.img
dtbo.img
gpueb.img
gz.img
lk.img
logo.img
mcf_ota.img
mcupm.img
md1img.img
mvpu_algo.img
odm.img
pi_img.img
preloader_raw.img
product.img
scp.img
spmfw.img
sspm.img
system.img
tee.img
vbmeta.img
vbmeta_system.img
vbmeta_vendor.img
vcp.img
vendor.img
vendor_boot.img
完整的线刷包解压结果:
- xaga_images_V13.2.3.0.TLOCNXM_20221124.0000.00_13.0_cn_a53f0a67ea.tgz
C:.
│ anti_version.txt
│ apusys.img
│ audio_dsp.img
│ boot.img
│ ccu.img
│ crclist.txt
│ cust.img
│ dpm.img
│ dtbo.img
│ efuse.img
│ elf_path.txt
│ gpueb.img
│ gsort.img
│ gz.img
│ lk.img
│ logo.bin
│ mcf_ota.img
│ mcupm.img
│ md1img.img
│ MT6895_Android_scatter.txt
│ MT6895_Android_scatter.xml
│ mvpu_algo.img
│ oem_misc1.img
│ pi_img.img
│ preloader_xaga.bin
│ rescue.img
│ scp.img
│ sparsecrclist.txt
│ spmfw.img
│ sspm.img
│ super.img
│ tee.img
│ userdata.img
│ vbmeta.img
│ vbmeta_system.img
│ vbmeta_vendor.img
│ vcp.img
│ vendor_boot.img
│
└─download_agent
DA_BR.bin
flash.xml
flash.xsd
通过对比,发现手机上只有一个misc分区是刷机包+OTA包没有的
另外我各种刷机过程,userdata分区肯定没有清除过
只是在中途的时候,把userdata分区改了下文件系统格式,后面又改回去了
另外关于metadata分区,由于始终选的是flash_all_except_data_storage.bat
,或者使用OTA包刷入单个镜像
因此metadata分区目前也是没有被更改过的
可以看到数据都还是有的:
简单总结下目前的状况:
- 由于一些错误操作,比如更改文件系统格式,虽然没有导致数据的全部丢失,但是userdata分区开头还是被改过了。如果想完整保留数据【加密状态】,请不要做这样的操作。
- metadata分区数据还在,userdata分区文件开头部分被修改
- 在熟知metadata分区的密钥解密?或者提取方法的前提下?可以尝试对userdata分区的数据进行恢复,不过这个技术只有极少数的人知道。另外就是,userdata分区开头部分数据错误了,只能采取全盘扫描的方式,先解密,再恢复的手段拯救文件。
- 目前已经对上述两个分区做了完整备份,也许有朝一日能修复部分数据。
关于备份分区,在data分区未解密的时候,肯定不能随便写入什么位置,所以采用dd over netcat的方案提取完整分区
主要参考这个文章:Imaging Android with ADB, Root, Netcat and DD
主要是下面几个命令:
在手机进入recovery之后,用adb进入,看看分区情况,目录一般是/dev/block/platform/soc/112b0000.ufshci/by-name/
这样的路径,然后使用dd+nc准备好数据传输
dd if=/dev/block/sdc20 | busybox nc -l -s 127.0.0.1 -p 18888 -v
PC端的命令如下:
adb forward tcp:18888 tcp:18888
"C:\Program Files (x86)\Nmap\ncat.exe" 127.0.0.1 18888 > userdata.img
说明:
- 用了Nmap的ncat替代nc,另外下载的一个被火绒报毒,原因未知
- 上面的端口可以自己改
- 上面的命令没法实时显示传输了多少数据,所以对于userdata这个巨大的分区,可以看看硬盘减少情况来预估时间;实测一般是USB接口速度拉满,米系基本都是USB2.0,我这跑出来是40M/s
xaga:/ # dd if=/dev/block/sdc86 | busybox nc -l -s 127.0.0.1 -p 18888 -v
listening on 127.0.0.1:18888 ...
connect to 127.0.0.1:18888 from 127.0.0.1:45641 (127.0.0.1:45641)
223297472+0 records in
223297472+0 records out
114328305664 bytes (106 G) copied, 2756.823617 s, 40 M/s
理论上有这两个分区足以,现在数据暂时是搞不回来了,但可以好好刷机完整恢复系统了 :)
由于在元数据加密密钥可用之前,userdata 分区中的所有内容均无法读取,因此分区表必须留出一个名为“metadata 分区”的单独分区,用于存储保护该密钥的 Keymaster Blob。metadata 分区的大小应为 16MB。
解密也许要研究系统的底层机制,看到一个gist,看起来确实是有希望的
大佬语录:
格式化虽然不会清除数据,但把f2fs的metadata头毁掉了,整个磁盘扫挺费时间的
因为格式化只写开头
不影响文件
扫描只会扫出的更多
不会更少
...
是在完全不了解文件系统的情况下,按照文件头搜索
我说的扫,是知道f2fs,fbe,mtk的情况下
按照f2fs寻找node信息,重新建立文件,知道fbe+mtk的情况恢复密钥,知道pin的情况下解密文件
mosec那个mtk的ppt不是讲了最后一步吗
fbe也可以
只不过是反过来的
先解密,再恢复数据
其他文件
只是记录下内容,比如这个elf_path.txt
,里面是个内网地址
l16-xaga-t-stable-symbols-20221019_203356_981ee10d1.tgz
[小米同学] Please visit http://husky.pt.miui.com/buildFile/modemSymbols to download the file.
[ODM同学] Please visit modem-symbols/ directory to find the file.
已有 2 条评论
有后续吗?同样手机砖了 想保存数据
我救回来了
https://www.coolapk.com/feed/57709897?shareKey=MmM1MjNhMWM2YWYyNjZhMDM3MDA~&shareUid=10441802&shareFrom=com.coolapk.market_13.0.2