熔断的本质——一场欧加供应链安全失控与底层防护缺位却由用户担责的“闹剧”
前几个月有离职内鬼泄露了欧加大部分高通机型的firehose给ch***ra(奇美拉工具),导致ch***ra可以畅刷欧加真高通设备(不包含mtk、
不包含8 芯片、不包含一加15及以后型号),后有人从ch***ra提取了firehose,公布到互联网。再然后有人开发了更便捷的刷机工具可以方便的使用这些firehose,而oppo也采取了相应的措施,通过OTA更新禁止掉熔断这次免授权9008。
但熔断代码具体存在于全量包哪个分区?熔断后为什么既阻止了免授权edl却又阻止了用户正常降级?是否像网上某些人所说的是谷歌/骁龙下发了补丁来阻止这次泄露?“熔断EDL”和“反降级Anti-Rollback (ARB)”是否可以分开进行?
本文将从代码层面深度分析和探索OTA是如何做到熔断的
首先,我们知道,要做到Anti-Rollback (ARB),则理论上可以通过进入到bootloader内输入
fastboot getavar anti
fastboot getavar rollback_index
fastboot getavar all……
等等,一般都能从免熔断升级(
x.com/i/status/2013081490511…)
到Coloros16.0.3.501后再从bootloader处获取到ARB的版本
然而……
很显然,欧加真为了防止用户对着版本降级屏蔽了fastbootd/bootloader对ARB查询的接口,且fastboot getavar all也没有输出任何关于反降级和熔断的任何信息(据我所知欧真加系是唯一一个这么做的厂商😡)(图一)
所以只能转换思路,从OTA全量包下手,将一加13的Coloros16.0.3.501解压后得到一个巨大的payload.bin,使用TIK工具箱将其解包后得到其中所包含的分区
['system', 'system_ext', 'product', 'vbmeta_system', 'boot', 'init_boot', 'vendor_boot', 'recovery', 'vendor', 'vendor_dlkm', 'system_dlkm', 'odm', 'dtbo', 'vbmeta', 'vbmeta_vendor', 'xbl', 'xbl_config', 'engineering_cdt', 'uefi', 'aop', 'aop_config', 'tz', 'hyp', 'modem', 'bluetooth', 'abl', 'dsp', 'keymaster', 'spuservice', 'devcfg', 'qupfw', 'uefisecapp', 'imagefv', 'shrm', 'cpucp', 'featenabler', 'oplus_sec', 'splash', 'xbl_ramdump', 'pvmfw', 'cpucp_dtb', 'soccp_debug', 'soccp_dcd', 'pdp', 'pdp_cdb', 'oplusstanvbk', 'my_product', 'my_engineering', 'my_stock', 'my_heytap', 'my_carrier', 'my_region', 'my_bigball', 'my_manifest']
然后,我们挑选一些很有可能是熔断代码所在的分区使用16进制编辑器HxD - Freeware Hex Editor and Disk Editor进行搜索字段
然而……我搜遍了abl,xbl,tz,uefi……等等分区均未能找到anti/rollback等字样……难道是被编译后混淆隐藏了?😡😡😡
那就不得不……
逆向,启动!🤬
我使用老美的Ghidra工具,整个反编译了abl和xbl分区
然后我就傻眼了,我又是比较一加15的502版本的分区又是搜索字段,可读性代码确实多了,但都跟ARB毛关系都没有!🤬🤬愣是一点痕迹都找不到!
然后迫不得已走投无路问了下DeepSeek鲸哥
DeepSeek表示:找不到明确字段的另一个深层原因,
机制本身可能已实现硬件化。
商通过熔断主板上的物理电子熔
CPU内部OTP寄存器值来实现防
这种硬件级别的版本号不会以可
现在任何软件镜像中,而是在启
ootloader读取硬件状态并与固件
期值比对。硬件级防回滚更彻底
级便无法逆转。
我了个豆,真是硬件级别的反熔断,oddo这招太狠了。如果没有专门的读取工具,根本无从知晓ARB的版本!挂不得无论怎么分析全量包都没有结果,因为真正熔断的代码在芯片内部,OTA全量包里只有字段,除非高通内部内鬼泄露安全工具否则根本无从得知ARB值在哪个字段、哪个img分区、哪个位置😢😢
所以……就真的束手无策了吗?😭😭😭
XDA,上号!
在国际友人Soft_M的帮助下,我获得了一个工具sectools
我查了一下,查不到这个命令行工具的源码,只找到高通的一篇文档(
docs.qualcomm.com/doc/80-700…),我只能说,懂的都懂😉😉😉
根据文档内的工具,我打开命令提示符CMD,将xbl_config.img放在和sectools.exe同一目录下,然后cd到那个目录,之后输入命令
sectools.exe secure-image --inspect xbl_config.img | findstr /C:"Anti-Rollback Version"
我发现一加15的502版本的xbl_config.img会返回(图四上半部分)
而一加13Coloros16.0.3.501的xbl_config.img则返回0x1
于是我测试了一加13Coloros16.0.3.501的其他分区,发现tz.img/uefi.img/xbl.img的值都返回了
Anti-Rollback Version: | 0x0
可见501版本不是XBL和ABL的Anti-Rollback发生了改变,而是xbl_config的Anti-Rollback值发生了改变,我们都错了🥵🥵🥵
由此得知,根本就没有什么谷歌/高通发布补丁,oddo就是通过增加ARB值并在全量包内更新EDL证书签名来废除掉泄露的免授权EDL签名(防止降级攻击)
而玩机佬也可以通过拆包后用Sectools来判断Anti-Rollback值是否增加,来判断之后的更新全量包是否会导致熔断了😋😋😋