本文包含高通9008模式以及联发科SP Flash Tool刷机的原理，这段文字放在开头方便想要了解的朋友更加容易找到此文。

在开始之前，先了解一下高通平台的启动流程，以下为启动流程图

高通平台启动流程图

从图中看出，按下电源键后，运行的第一段代码便是PBL（高通称其为Primary Boot Loader，通用的叫法为BootROM，BootROM是在SoC生产时就已经写死在芯片内部的，不可以更改），PBL负责验证并加载下一阶段的BootLoader（XBL或SBL，在16年之前被称为SBL），并响应异常情况，还会读取QFUSE来执行相应的策略，这部分在文章后面再说。XBL会验证并加载TEE以及ABL（TEE的具体加载流程在文章后面），ABL是指Android BootLoader，也就是大家熟悉的FastBoot线刷时所处的位置，ABL会执行AVB（Android Verified Boot安卓验证启动）策略，比如说检查BL锁状态来决定是否执行下一阶段的启动验证，检查软件版本，防止未经授权的降级等等。如果检测到用户按下某些按键，或者触发某些事件（如OTA升级，恢复出厂设置等等）则会启动到Recovery模式，正常启动时会验证并加载Boot分区（Android系统的Linux内核部分），最后由Linux内核验证并加载Android系统剩余部分。至于图中的TrustZone，则是XBL负责加载的，详情文章后面再说。

我们再来看一下ATF（ARM Trusted Firmware 可信固件）架构

ATF架构图

大多数ARM SoC的安全启动架构基于ATF，其中BL1对应BootROM，BL2对应XBL，BL33对应着ABL和之后的启动流程部分，BL32和BL31提供了TEE（Trusted Execution Environment可信执行环境，用于处理如生物识别数据等对安全性高度敏感的场景），其中BL31负责Normal World与Trusted World之间的数据交互，BL32负责运行TEE操作系统（如OPTEE，QTEE，Trusty等），TA（Trusted Application 可信应用）运行在TEE操作系统上，就像我们在Andoid系统上安装的应用，只不过TA不能由用户自由安装，只能由OEM决定，TA是具体执行各种需要安全性任务的应用程序，如生物数据的识别与存储，DRM的实现（如最著名的Widevine），各种凭据的验证与存储，各种文件的系统加密等等。

Normal World和Trusted World之间通过ARM TrustZone技术隔离，原理是利用硬件控制器强制隔离两者的寄存器，RAM等资源，各种运算器采用分时复用的方式同时处理来自两者的指令，Normal World不可以直接访问Trusted World的资源，反过来Trusted World可以访问Normal World的资源，我们常见的Android系统运行在Normal World上，而TEE操作系统等运行在在Trusted World上（具体看上图，有详细的划分）。

除了以上的隔离措施，ARM还准备了更细粒度的权限控制框架，叫做EL（Exception Level），分为EL3，EL2，EL1，EL0，权限依次由大减小，权限大的可以访问权限小的资源，反之不行。注意，权限的控制还要符合以上Trusted World与Normal World的隔离规则，比如说Normal World EL2虽然数字大于Secure World EL0，但是也无法直接访问Secure World EL0的资源，因为违反了Secure World 与Normal World之间的隔离规则。以上的ATF框架图涂有不同颜色的部分代表其中所处的EL，说明在图中右下方。

EL框架图，图中Secure World等同于Trusted World

聪明的读者可能会发现，BL2处于Secure EL1，BL31处于EL3，而BL31是由BL2负责加载的，按照通常的情况，先加载的权限是大于后加载的，那这是怎么做到的呢？答案是BL2通过向BL1的SMC handler发送SMC指令初始化BL31运行所需的环境，间接地实现写入比自身权限更高才能访问的资源，当然这个过程是受监控和限制的，不能随便乱来，这也是SMC存在的意义。

有了以上内容的铺垫，我们来看一下实际的攻击案例。

高通EDL模式（9008模式）的漏洞

回顾以上高通平台的启动流程，PBL会响应各种异常情况，出现异常情况后，PBL会进入EDL模式，高通准备了以下方式进入EDL：按键组合（只有部分OEM会选择实现这种方式，如一加，联想，moto等）；主板触点短接（几乎所有机型都会有）；USB接口触点短接，俗称深度刷机线（新机器基本上都禁用了这种方式）；软件方式，如adb指令，部分OEM只有在解锁BL后才会正确响应；启动流程中ABL及之前的流程校验失败，所有机型都有。
进入到EDL模式后，需要通过USB使用Sahara协议发送Programmer，Programmer本质上是XBL的变种，只不过XBL是PBL由硬盘里加载的，Programmer是PBL由USB加载的，来源不同而已。PBL的EDL模式本身只实现了Sahara协议，并验证和加载Programmer，其它功能需要由Programmer实现。Programmer需要OEM的有效签名，不能自己编写，不然PBL会拒绝加载。

短接图中黄色方框的触点即可进入EDL模式，不用机型位置不同

俗称“深度刷机线”

Programmer通常不会被OEM公开，但是有一些例外，如小米的官方线刷包里都会有Programmer，一加的ColorOS尝鲜版刷机包里也有Programmer，联想和moto官方的刷机程序也会自动下载对应机型的Programmer等等。但是不公开不等于没有，有很多从不公开的OEM，网上也会有内鬼泄露的Programmer，不然某宝上满大街的刷机服务是怎么来的

Programmer可以由OEM定制，大部分OEM会选用Firehose Programmer，高通官方默认的Programmer，只做少许的修改以实现OEM自定义的功能，如小米的售后账号授权机制。

搞到了Programmer后，尝试执行降级攻击，一般情况下，锁定BL时是不允许刷写任何分区的，但是这个机制是由ABL实现的，在启动流程中处于较为靠后的位置，Programmer处于启动流程的第二步，处于非常靠前的位置，权限比ABL高得多（Programmer处于Secure EL1，ABL处于Non-Secure EL2），自然有能力访问，写入任何分区。在部分机型上有已知的漏洞，这里以一加3T为例，将ABL降级到易受攻击的版本，易受攻击版本有以下漏洞，CVE-2017-5626和CVE-2017-5624，在Fastboot模式下输入以下指令，并返回了以下信息
$ fastboot oem disable_dm_verity
...
OKAY [ 0.045s]
finished. total time: 0.045s
$ fastboot oem 4F500301
...
OKAY [ 0.020s]
finished. total time: 0.020s

这时验证启动被关闭，BL锁被解除，但是没有触发恢复出厂设置，此时可以刷入第三方REC提取出data分区的所有数据，无需验证锁屏密码，造成严重的隐私泄露。（手动开启安全启动即可避免数据被提取，不过默认情况下不会开启，大部分普通用户受到此漏洞的威胁）

这里再说一个较为新的例子，原帖在以下链接
查看链接
具体来说，在一加Nord 2上有Root Shell 漏洞，启动到REC模式下，停留在语言选择界面，然后连接电脑和手机，在adb下输入adb root，然后就获取了root权限，而且不会触发数据清除，可以利用这个漏洞绕过锁屏密码提取隐私数据，还可以在不清除数据的情况下安装具有root权限的木马，危害极大，目前这个漏洞已经修复，不过还没人测试过降级攻击是否凑效，若降级REC后仍然可以正常启动，那么这个漏洞等于没修复。

再来一个红米Note 5A的例子，读取devinfo分区，稍作修改再写回去，可以发现BL锁被解除还没有触发数据清除，数据提取方式如一加3T。

一加3T和Note 5A的例子来源于AlephSecurity，针对高通平台EDL的研究和BootROM漏洞的开发利用也是AlephSecurity，感兴趣的读者可以访问他们的官网查看链接
现在暂时访问不了，可以通过查看链接
访问历史镜像（要t）

以上的攻击是针对存储的，最强大的攻击方式是针对RAM和寄存器的攻击，通过一定的漏洞利用方法，可以做到以EL3的最高权限执行任意代码，限于篇幅和个人水平，这里不做详细的原理解析，基本思路是想方设法绕过内存地址的访问和写入限制，将恶意代码通过缓冲区溢出的方式写入执行位，导致任意代码的执行，这种攻击无法通过软件更新修复（有一些例外，接下来会举例），可以干几乎任何事情，包括但不限于暴力破解密码，伪造指纹支付请求，解密受DRM保护的媒体等，具体实现上由于TEE部分的闭源，实际上很难实现。以下我将介绍这种攻击方式的实例。

mtk kamakiri漏洞：最早由XDA用户xyz`发现，联合XDA用户k4y0z发布了第一个实际用例，解开Fire TV Stick 4K的BL锁，原帖地址：
查看链接

Fire TV Stick 4K拆开后的样子

后来基于这个漏洞，k4y0z开发出了现在著名的SLA/DAA绕过工具，也是众多联发科机型秒解BL能够实现的基础，原帖地址：
查看链接
名词解释：
SLA（Serial Link Authentication 串行链路认证）
开启了SLA的机型，需要在SP Flash Tool加载特定的.auth文件才可以让BootROM接收并加载来自USB发送的DA，不然会拒绝加载。
DAA（Download Agent Authentication 下载代理认证）
DA（Download Agent 下载代理）类似于上文提到的Programmer，是Preloader的变种（Preloader类似于上文提到的XBL，同样处于ATF的BL2级别）,OEM可以自行定制DA以实现不同的DAA方式，同样以小米为例，较新的联发科机器会要求登录售后小米账号才可以进行深度刷机。BootROM加载的DA仍然需要有效的OEM签名（不能自己编写DA），不然即使通过了SLA也会拒绝加载。
SLA和DAA可以同时存在，也可以只存在其中一种，取决于OEM，其中SLA政策是烧写入SoC内部的eFuse（电子熔丝），是一个密钥，需要拥有这个密钥的人才可以通过SLA，一旦烧写就无法更改 或擦除。

Amlogic BootROM漏洞：由fred发现，个人主页：
查看链接
此人从Khadas VIM3L 开发板上转储了S905D3 SoC的BootROM镜像，正常来说，BootROM镜像是不可以由外界读取的，Normal World也无法读取，只能由Secure World读取，但这个开发板是没有烧写过eFuse的，意味着并没有开启安全启动，于是他编译了自定义的BL2，在Secure World里获取到了BootROM，然后通过UART端口传输出来。在分析后他发现了BootROM级别的漏洞，然后找来了搭载S905D3G的Chromecast with Google TV，大家可以去了解一下Chromecast with Google TV，这是谷歌推出的电视盒子，搭载Android TV 10系统（Google TV UI）在我看来这是全世界最安全的电视相关的设备（Apple TV除外），为什么这么说？首先它是全球第一批底层为Android 10的电视设备之一，针对Android TV分支，10相比9有重大安全性改进，根据Android CDD要求，所有出厂时搭载Android 10及以上（升级到Android 10及以上的旧设备没有强制要求）的设备必须开启FBE强制加密，还要实现基于硬件的安全启动和防回滚（防降级），在Android 9 CDD里只针对手持设备（手机和平板）强制要求，对于电视类，车机等等其它安卓设备不做这方面的强制要求。除此之外Chromecast with Google TV还做了额外的保护，使用了AES-CBC 256算法高强度加密了U-Boot镜像（处于BL33，等同于ABL），密钥存储在SoC内部的eFuse里，只有处于Secure World才能获取，使得分析更加困难，这种做法在业内罕见，连手机都没有这么保密。但是最终还是被击败了，锅在Amlogic上，S905D3和S905D3G的BootROM几乎一样，此前他发现的BootROM漏洞成功在Chromecast with Google TV复现，也就有了接下来的故事。

Chromecast with Google TV实拍图

Chromecast with Google TV拆开后的样子

首先他利用了BootROM漏洞获取了U-Boot加密密钥，禁用了BL2的的ARB（Anti-rollback防回滚）检查，禁用了BL33的镜像验证，最后利用获取的密钥加密了修改好的U-boot镜像，最后重启，再次利用BootROM漏洞加载修改后的BL2，然后通过USB加载处理好的U-boot镜像，最后成功启动了Ubuntu系统。
另一个人利用了这个BootROM漏洞，开发了Chromecast with Google TV解锁BL工具，这是项目地址

查看链接

原理是修改env分区对应的比特位。

图文中还有一些名词没有解释清楚，还有一些厂商的应对措施，安全建议和现状，在以下做出补充。

eFuse和QFUSE：除了高通的EFUSE，都是指SoC内部的电子熔丝，一旦烧写就无法变更或擦除，一个SoC内有多个熔丝，高通的EFUSE基于RPMB实现，可以在TEE内更改，是非永久性的。QFUSE等同于eFuse，只不过QFUSE是高通的叫法。

RPMB：具体解释可以利用搜索引擎，我在某个帖子的热评里有详细的解释

查看链接

简单来说，RPMB具有防篡改，防伪造，防重放功能，外界无法写入数据到RPMB，只有本机SoC可以写入，SoC可以确保从RPMB里读取的数据不是攻击者伪造的，也不是之前读取过的数据，可以保证时效性，具有防重放特性。像各种序列号，各种证书，各种加密文件系统的元数据，BL锁状态，自定义信任根（刷入第三方ROM后锁定BL，只有部分机型支持），查找手机相关数据（激活锁）等会放入RPMB。

KeyMaster：安卓系统上用于存储和验证各种凭据的服务，如锁屏密码，帐户凭据等。可以运行在TEE或者SE中。

SE（Secure Element）：安全组件的统称，指有自己独立的安全运算器，安全存储器，独立的TRNG等组件的芯片，不与其他部分共用资源，相比TEE减少了许多攻击面，可以集成入SoC（如高通骁龙888及更新的SoC，麒麟的部分SoC，苹果A7及之后的SoC等等），也可以做成独立的芯片，如Pixel手机搭载的Titan M，电脑上常见的dTPM等。

厂商后续的缓解措施：Fire TV在后续生产的批次直接禁用了Download模式，使得外界无法与BootROM进行交互，自然也就间接地缓解了这个漏洞，这个禁用策略是烧写入eFuse的；Chromecast with Google TV则是在2020年1
2月以后生产的批次和2021年2月的固件更新启用了burn-mode password，这意味着没有密码将无法与BootROM进行交互，自然也就无法利用BootROM漏洞了，为了使这个密码不被破解，我估计谷歌是使用了由SoC内部的TRNG（真随机数发生器）生成的高熵密码，写入了eFuse，这样子就没有任何人可以与BootROM进行交互了，包括谷歌自己。好在电视盒子类的硬件非常便宜，如果有问题无法刷机还不如直接换新了，可以这么搞。

安全建议以及现状：
防降级：
大部分SoC是支持利用eFuse/QFUSE实现底层固件防降级的，启用了这个功能，可以实现BL33及之前的部分防降级，如果强刷降级，会导致设备进入到EDL/Download模式。三星和moto开启了这个功能，其它OEM则大都没有开启，有一定的安全隐患，这也和谷歌的要求有一定的联系，目前谷歌只要求ABL之后的组件实现防降级，这是基于RPMB实现的，将版本信息写入RPMB，如果低于规定的版本，则不得解密data分区，但是如果漏洞出现在ABL及之前，这个限制将毫无作用，一样会有泄露隐私数据的风险，谷歌对于ABL及之前的组件防降级只是建议，毕竟连谷歌自己的手机都没有做到。但是谷歌另辟蹊径，将KeyMaster从TEE搬到了外置SE（Titan M芯片），来平衡安全性以及易用性（使用Pixel的开发者有降级刷机的需求），Titan M可以将用户数据与版本号绑定，如果在没有输入正确密码的情况下，强制升级或者降级都会导致无法解密用户数据。

号称最难刷机的ViVO/iQOO：蓝厂的联发科机型同样受到BootROM漏洞的影响，同样可以秒解BL，但是蓝厂的ABL是魔改过的，虽然会检测BL锁状态并作出相应提示，但是无论BL是否解锁，一律不会禁用AVB，刷入非官方ROM会拒绝启动，解了个寂寞。虽然说BootROM漏洞可以无视系统更新，但是这个漏洞的利用是临时的，要是改动了系统相关分区，重启之后就会变砖，需要重新连接电脑再次利用漏洞，使用起来非常不方便。再说了蓝厂不开源，就算能刷进去第三方ROM，适配是个大问题。

隐藏ID机：上面说到，一些手机的Programmer或DA能力过于强大，授权又没做好，或者BootROM有无法修复的漏洞导致任意代码以EL3权限执行，这时就可以利用这些漏洞，篡改存储在RPMB里的查找手机相关数据，关闭激活锁，一些系统还会在使用时联网验证，如果没有处理好会导致激活锁回锁，强解BL后刷入非官方ROM是ID机常见的处理方式。还有一种隐藏ID机是纯手撕的，原理是利用系统UI层面的漏洞导致激活锁界面被跳过，这种漏洞真是多如牛毛，网上一搜一大把，最离谱的是Android自带的FRP（中国大陆地区的ROM也有FRP的底层代码，但是不会呈现在UI上，原因是FRP依赖于GMS，GMS在中国大陆地区的ROM默认隐藏了），没有一款手机的FRP是没有漏洞的，油管上搜手机品牌+FRP就能搜出一堆教程，而FRP一旦成功绕过，可以随便恢复出厂设置，随便刷机都不用担心回锁，因为FRP相关信息只会保存在手机本地。在UI层面防护做的最好的应该是MIUI了，强制显示特定的Activity，一旦检测到有其它Activity覆盖了窗口，立马强制启动特定的Activity将非法Activity弹下去，基本上没有手撕成功的例子。这方面我就得夸一下苹果了，激活锁信息保存在云端，刷机后想要正常使用必须强制联网激活，联网就会触发激活锁，不是主人无法激活使用，可惜Checkm8漏洞（A11及之前的SoC有BootROM级别的漏洞，无法通过软件更新修复，可以用于越狱跳过激活锁页面）影响范围实在太广，旧手机的防盗不给力了。不过在iPhone 12和13这代苹果在防盗方面上升到一个全新高度，想要防止被查找只能拔电池或者放入信号屏蔽袋，有激活锁的12和13拆配件也没人要，因为苹果将几乎所有带芯片的组件都做了加密绑定，放在其它机器上无法正常使用让脏机的价值大大降低，这是业界首次将手机防盗做到如此极致。

底层固件开发的安全建议：
虽然理论上不泄露Programmer，DA，用于SLA的.auth文件可以避免通过底层固件进行攻击（前提是BootROM没有漏洞，或者具有缓解措施，在上面的例子里有提到。联发科可以抬走了，从19年发现到现在的天玑1200还没完全修复这么严重的BootROM级别漏洞，秒解BL影响了多少手机），但是这是不太可能的，因为这些东西售后会广泛使用，全世界那么多售后网点不可能完全保密的，总有机会会被泄露出来，一种较好的做法是限制Programmer和DA的能力，让其只能读写普通分区，不要给其编辑RPMB区的能力，就像三星，只通过Programmer写入S-Boot（三星对于BL2和BL33的称呼）来救死砖，可以进入ODIN模式后再刷写剩下的分区。或者将Programmer和DA做成苹果DFU那种动态加载模式，在云端进行权限的控制和身份验证，这是最佳做法，可以保证安全性和易用性，又无需担心Programmer和DA甚至是.auth文件的泄露，但是目前没一个OEM这样做，只停留在我的理论当中。

结语：码字一整天，查阅了许多资料，难免会有些许错误，如果有知道的朋友可以指出来，让我们多交流交流
#信息安全# #玩机技巧#
@酷安小编 @alexkillers 烧脑码字一下