线刷需要“解锁”，稍有些经验的机友大概都听过这句话。
但疑问也随之而来：
虽然 BL 锁的存在保证了 FASTBOOT 下无法刷机，那么是否有办法绕过 BL锁？
进一步地，还有什么手段防止刷机？
预备在回答问题之前，我们先补充一点点知识。
我们常说的 FASTBOOT 在手机上是作为 Extensible Bootloader (XBL)存在，但是，基于高通处理器的机型都有一个 Emergency Download Mode(EDL)，即我们常说的 9008 模式。
该模式下，Primary Bootloader (PBL) 可以接管设备控制权，允许通过Qualcomm Sahara 协议加载一个 ELF文件，作为第二阶段引导加载程序（SecondaryBootloader）(SBL)，从而实现对存储的刷写。该模式存在的初衷为了防止 SBL损坏而设计的应急措施。注: XBL 可以看做是 SBL 的一个子集
我们知道，BL 锁，“锁”住的是 XBL。如果我们能想办法加载自己的XBL，问题不就解决了吗？
分析在早期，确实如此，我们可以通过 EDL 模式绕开 BL 锁，实现刷机。
这也就引出了我们的第二个问题——“还有什么手段防止刷机？”
AlpheSecurity & Qualcomm2017 年，AlephSecurity 团队正式向高通方面报告了这样的一个漏洞（QPSIIR-909），指出了某些情况下，PBL可以被利用，进而实现在设备上执行任意代码。
作为修复，高通方面则引入了安全启动 (SecureBoot) 以及 防回滚机制（Anti-Rollback）。
上述的机制通过一系列验证手段，来避免未签名的恶意程序被 PBL加载。同时防回滚也确保了 SBL / ABOOT / TZ等不会被降级至有漏洞的旧版本，从硬件层面堵上了恶意注入的漏洞。
安全启动主要通过密钥链对加载进设备的代码进行可信度验证，同时决定是否接收这些代码。为了优化存储空间以及处于拓展性的考虑，高通并未对整个ELF 加密，而是将一些签名信息写入到 Hash Table Segment之中
总体验证流程如下图。为了防止验证的某一过程被修改，下图的Root CA Hash & Cert 被写死在硬件之中。
各层证书联系紧密， Attestation Cert 的签名由Attestation CA Cert 的私钥生成，而Attestation CA Cert 的签名由 Root CA Cert的私钥生成，最终 Attestation Cert 对代码进行签名。
所有证书公钥及其签名都被刷写到手机，在加载代码时，会逐层用公钥对签名进行验证，一旦验证不通过，将会触发：“有内鬼！停止交易”（终止并报错）。
私钥则由高通公司及手机厂商严格保密保存，若是无法取得私钥，就无法生成各级证书签名，无法对代码签名，导致验证不通过。
Miflash & ELF file时至今日，这套保护机制已经很完善了，我们结合具体情况来看看。
如果有小伙伴进入 EDL 模式进行刷机，若是用新版 Miflash工具，则会提示需要登陆账号验证权限，若是有权限，刷机可以继续；若是无权限，则刷机终止。若是使用20180528 之前旧版本的 Miflash，将会收到一条miflash ERROR: Only nop and sig tag can be recevied before authentication.这样的信息，从而无法继续刷机。
该信息从何而来？
在 EDL 模式下，Miflash 会调用高通提供的 QSaharaServer程序将 prog_firehose_ddr.elf 刷写到手机作为 SBL。之后再通过fh_loader 刷写镜像。正是因为prog_firehose_ddr.elf没有收到授权验证，拒绝了后续的刷机请求。
使用 IDA 逆向 prog_firehose_ddr.elf即可相关看到相关逻辑。
在 View 中打开 Strings 视图，搜索字符串Only 。
双击后按下 X 查看交叉引用，定位到函数sub_14824FC4。
双击跟进，即可看到验证逻辑，图中仅仅截取了一部分。小伙伴们从左下角的Overview 窗口不难看出，实际上这套验证逻辑很复杂。
图中上面一个橙色框标识的就是 ELF文件中引入的授权验证之一。由于我们并没有刷机权限，在标识处验证不通过，程序向Miflash 回报了Only nop and sig tag can be recevied before authentication这样的错误信息，大致意思是，“在完成验证之前，只有签名信息和 nop指令可以被接收（其他代码拒绝接收）”。
有的小伙伴也许会说，那么我们修改掉 ELF 中的判断逻辑不就可以了吗？
这并不可行。正如前文所述，所有引入设备的代码都需要经过签名验证。如果我们修改了这个ELF文件，由于我们无法获取签名所需的私钥，就无法生成正确的签名，会导致签名校验失败，刷机进程终止（上图中下面一个橙色框）。
用 16 进制文件编辑工具（或者记事本）打开 ELF文件，就可以看到一些证书相关字段。例如Xiaomi Attestation CA0、XBL Sec Attestation Root CA。
因此，无法通过逆向工程方法破解 ELF，来达到绕过授权验证的目的。
经过授权的刷机流程结合个人经验，推断经授权的刷机流程如下：
prog_firehose_ddr.elf 被加载到手机代码执行到“要求进行签名验证”处（可能是小米加入的），向 Miflash回报特定错误代码，新版 Miflash 将要求登录账号。登录后，若服务器端判定“有刷机权限”，则在云端计算生成部分数据（推测是用私钥生成某阶段的Signature）发回 Miflash.Miflash使用这些数据作为参数，传递给手机，使得验证通过，之后可以正常加载刷机代码，接收文件。小结综上所述，进行验证的大致流程如下图所示。
验证流程再整理一下思路：
刷机需要解锁BL，这需要账号与设备绑定以及云端验证。同时每台设备的解锁 Token与硬件绑定，通过服务器运算得出。若想绕过 BL 锁，需要进入 EDL。而 EDL 的进入有一定难度（目前 EDL几乎只能通过“拆机短接”进入。）即便进入了 EDL，在没有授权信息的情况下，ELF镜像无法加载执行，无法刷机。授权信息也是在云端生成。虽然 “磁盘模式” 也可以刷机，但常规情况下需要执行fastboot erase aboot & fastboot reboot指令进入（而执行该指令需要解锁）。正是在如此层层保护之下，才使得一个小小 “BL锁” 能够有效地 “锁住”我们的安全。
利与弊凡事总有两面性。不可否认，这些机制的引入，一方面极大地保护了我们的安全，但在另一方面，这也毫无疑问地提高了自行刷机（救砖）的门槛。
回想初次认识的小米手机，是某代号为 cancro 的“板砖”，在那几年正是玩机乐趣的巅峰。
现在手里拿着新机型，一边感慨着 “9008”“磁盘模式”的狂热褪去，“刷不死”“为发烧而生”的时代落下华章；一边又赞叹着层层精妙严谨的设计，为崭新的信息时代构筑了安全后盾。
不管这么说，“限制权限、注重安全”总是发展的大方向，“世间安得两全法，不负如来不负卿”。
END个人经验毕竟有限，若有错误还请各位不吝斧正。
文本原创首发于 小米社区 & 个人 Blog，转载请注明。