固件决定设备信任什么、运行什么以及哪些安全修复真正起作用。当供应商发布更新时，显而易见的目标是修补漏洞、加强检查并封堵昨天还有效的攻击技巧。令人不安的事实是，昨天的固件不一定会消失。即使在更新后，之前的固件仍可能作为官方出厂镜像或完整的OTA包提供。
那么，什么阻止有人简单地安装较旧的构建版本并重新打开已经修复的漏洞呢？在本文中，我们将分解防回滚保护（ARB）及其如何在实际设备中强制执行只能向前的安全基线。
什么是防回滚保护（ARB）？
通常只有当您试图做一些合理的事情，而设备拒绝时，您才会注意到ARB。也许更新引入了一个错误，您想回滚到上一个稳定构建。也许维修车间需要较旧的镜像来恢复手机。ARB将这些向后的步骤变成了硬性阻止。
它不是一个全新的发明，但最近它被更加积极地推出。降级攻击已经变成了一个实用的攻击手册，合规压力也在上升，从欧盟网络韧性法案到汽车行业的UNECE R155/R156以及更新的物联网安全基线。行业并没有突然发现回滚保护。相反，它达到了一个临界点，即保持降级门户开放将是鲁莽的。
术语差异
防回滚保护用不同的术语来描述，这使得人们容易认为有几个不同的”锁”，而实际上底层只有一个概念。
在Android上，谷歌的正式术语是验证启动中的回滚保护，通过设备在启动期间检查的回滚索引来实现。在用户和技术人员圈子里，相同的行为通常被称为ARB，即防回滚（Anti-Rollback）的缩写。
然后供应商在此基础上添加他们自己的标签。熔丝或eFuse也被使用，因为最小接受版本存储在芯片内部的一次性可编程位中。出于同样的原因，OTP一词也在使用中，意思是一次性可编程存储器。在移动设备市场上，您经常会看到三星的回滚级别被称为”binary”修订版，或在维修车间语言中称为”BIT”，因为这是同样的只能向前边界在其刷机和维修工作流程中的表现方式。
无论措辞如何，结果都是相同的。一旦设备记录了最小接受的安全版本，它就会拒绝启动任何早于该基线的内容。最简单的描述方式是棘轮：更新可以将最小值向前移动，但普通软件无法将其向后移动。
您经常会看到它被解释为谷歌在Android 8（Oreo）中引入的功能。这个说法很接近，但不完全准确。Android 8是回滚保护变得标准化并以系统集成方式允许Android生态系统围绕它对齐的点。
最近围绕OnePlus的报道让ARB重新受到关注，但硬件强制回滚防护的基本概念要古老得多。当前的讨论更好地理解为对较新固件构建的新一轮执法，而不是引入一个全新的安全概念。
ARB解决的安全问题
在降级攻击中，攻击者不需要伪造签名或发明自定义固件。他们只需将设备推回到仍然签名、仍然看起来官方且仍然包含已被映射出的弱点的较旧构建。
这就是ARB要关闭的缺口。安全启动可以告诉您固件是真实的，但它本身并不能保证固件足够新到安全。如果较旧的签名镜像仍然可以接受，那么在较新版本中发布的修复在实践中变成了可选的。攻击者选择最简单的路线，而向后走可能比突破向前的防御更容易。
ARB阻止了这一举动。一旦设备超过了某个阈值，时光倒流的技巧就不再有效。攻击者失去了整个类别的简单胜利，因为设备不会自愿进入较旧、较弱的状态。
硬件强制的版本边界
重新刷写存储、重新安装镜像或交换分区不会改变设备已经记录为可接受的内容。一旦存储了更新的基线，即使较旧的版本被正确签名和打包，也会被视为不可接受。
这就是为什么”官方固件”在设备向前移动后不总是意味着”可刷写固件”，特别是在真实维修车间场景中，技术人员尝试较旧构建时会遇到硬性拒绝而不是警告。
为什么ARB不是软件策略
防回滚保护不是更新程序中的供应商偏好。阈值无法降低或重置，因为存储的值被设计为不可逆的。
如果最小版本可以编辑，攻击者会首先针对那个机制。ARB通过让设备的更新历史成为软件无法重写的内容来避免这个陷阱。一旦最小版本前进，平台就会将其视为从那时起的强制基线。
ARB在启动时如何工作
启动过程是一系列受控的交接。每个阶段都有定义的工作，每个阶段在控制向前移动之前都会检查下一个阶段。ARB将一个简单的问题穿插到该流程中：您即将运行的内容是否至少与设备要求的一样新？
固件版本索引
参与验证启动的每个固件镜像都携带版本信息。该值被描述为安全版本索引。较高的数字代表供应商更新时间线中的较晚时点，其中更多问题已被修复，更多安全保护措施已被引入。
使用ARB，设备在硬件支持的存储中记录最小可接受版本，每个候选镜像都与该存储的参考进行比较。设备有效地记住了它已经向前移动了多远，未来的启动尝试必须尊重这种进展。
实际上，ARB将一些向后的步骤变成了永久的非选项。曾经可以启动的构建在设备记录更高最小值后可能永远变得不可接受。
启动链验证模型
启动流程本身被构造为一个链。每个阶段在交出控制权之前验证下一个阶段的完整性和来源。在每一步都检查签名，版本数据与这些签名一起评估。
同样重要的是要注意，不是每个组件都必须同步向前移动。供应商经常独立更新链的各部分。每个元素在上下文中得到验证，与存储的最小值的比较在重要的地方发生。
这是人们在遇到ARB壁垒时感到困惑的原因之一。他们期望一个单一、简单的固件版本，但启动关键组件可能有以不同方式重要的单独版本边界。
BootROM
在启动链的开始是BootROM，这是烧录到芯片中的不可变代码，充当信任根。供应商可能会以不同方式标记第一阶段（例如，高通称之为主启动加载器或PBL），但角色是相同的。启动从固定的、受信任的基础开始。
从那时起，回滚检查就可以应用，因为早期启动代码读取存储的最小版本并阻止任何低于它的阶段，攻击者无法重写第一层来绕过规则。
在三星上，这通常是人们发现防回滚实际含义的时刻，当您尝试降级时，会直接遇到SW REV / binary墙。
为什么仅有安全启动是不够的
安全启动被正确描述为现代设备信任的基础。它确保启动序列中的每个阶段都来自经批准的来源并且没有被更改。它不保证的是经批准的代码足够新到安全。安全启动在回答固件是否真实方面很出色。它不回答固件是否陈旧。
安全启动实际验证什么
安全启动确保设备启动期间使用的软件被OEM信任。固件镜像必须数字签名，签名必须与即将执行的内容匹配。如果满足这些条件，从真实性角度来看镜像是有效的。
从生命周期角度来看，这只是故事的一部分。旧版本可能长时间保持有效签名，这正是降级攻击的开口。
签名但易受攻击的问题
较旧的固件版本可以通过每个真实性检查，但仍然暴露已经被研究的攻击路径。安全公告经常描述存在于早期构建中但在后来被消除的问题。如果设备继续接受早期构建，那么那些后来的修复只有在没有人能够倒带的情况下才有用。
通过强制最低版本，ARB阻止返回到已知弱点仍然存在的状态。
降级攻击在实践中如何工作
降级攻击遵循熟悉的模式。设备被强制或说服安装较旧的构建。然后攻击者使用只在该较旧构建上有效的漏洞。一旦他们有了立足点，他们就可以尝试持久性、数据访问或更深层的修改。
如果较旧的固件仍然正确签名，仅有安全启动本身不会阻止这一点。ARB通过首先拒绝降级在第一步就打破了链条。
ARB作为固件新鲜度强制
与安全启动结合，ARB为信任添加了第二个维度。它们一起关闭了降级攻击所依赖的缺口。没有版本控制的真实性为倒退留下了空间。没有真实性的版本控制将允许不受信任的代码运行。当两者都存在时，平台强制执行来源和时效性。
典型用例和部署领域
任何通过固件更新演进并且必须随时间保持其安全态势的平台都会受益于ARB。
Android移动设备
许多现代Android手机将ARB作为其启动和更新设计的一部分来实现。每个安全补丁级别通过关闭弱点来推动平台向前发展。允许返回到早期补丁级别将重新引入已经解决的问题。
通过强制执行最小接受版本，ARB使设备与其最新安全状态保持一致。一旦平台前进，该级别就成为未来启动和刷写的基线。
游戏机
回滚保护在游戏机中也很常见。这些系统接收固件更新，关闭漏洞路径并调整安全控制。如果可以自由恢复较旧的固件，已知的弱点将保持永久的入口点。
因此，游戏机平台使用只能向前的阈值，防止回退到某些点之前。一旦系统向前移动，返回到早期版本就被阻止，这保持了后续安全改进的有效性。
嵌入式和工业系统
长寿命的嵌入式设备和工业设备通常在物理访问现实、更新周期可能较慢的环境中运行。随着时间的推移，固件修订版本解决已发现的弱点。回滚到较旧构建可能使系统暴露于已知威胁。
ARB有助于防止向后漂移。一旦记录了新的最小版本，早期状态就不再被接受。这在设备整个运行生命周期内支持一致的安全基线。
汽车ECU
汽车电子控制单元管理影响安全和系统行为的功能。固件更新响应安全发现和网络安全评估。允许回退将削弱这些改进。
ARB风格的强制确保一旦控制单元前进到更新的固件级别，它不会返回到较旧、保护较少的状态。这支持安全期望和现代空中更新策略的完整性。
有什么缺点？
使防回滚在部署的系统中有价值的相同属性在开发期间产生摩擦。一旦版本阈值与不可逆机制绑定，灵活性下降，错误可能是永久的。
不可逆熔丝和OTP风险
允许的最小固件版本存储在旨在防篡改的硬件支持位置中，因此如果记录了错误的阈值，开发或测试设备可能最终拒绝工程师仍然需要的构建。
与普通配置错误不同，您不能通过重新安装软件来修复它，因为回滚保护在验证启动期间强制执行，专门设计为在记录更高基线后拒绝启动较旧版本。
这就是为什么恢复可能受限。一旦您越过回滚边界，常见的”只是刷写较旧构建”后备可能被阻止，在某些平台上跨越错误边界的降级被广泛报告为变砖风险而不是可逆错误。
调试限制
故障排除通常涉及比较版本间的行为。工程师可能需要返回到早期构建来重现问题或确认问题何时首次出现。在ARB到位的情况下，这些向后的步骤在已经超过阈值的设备上可能不再可能。
这改变了调查计划的方式。团队为较旧构建保留单独硬件，更多依赖模拟，或投资更好的日志记录。ARB鼓励只能向前的工作流程，当您在困难错误追踪中时这可能令人沮丧。
流水线协调挑战
版本号和发布序列必须在开发、测试和生产中仔细管理。如果一个阶段在其他阶段准备好之前就推进了最小版本，团队可能突然发现无法在共享设备上运行预期的固件组合。
因此，ARB需要协调。发布计划、版本分配和更新排序需要对齐。安全好处很明显，但运营纪律成为成本的一部分。
总结
ARB不是一个新概念，但现在被广泛部署，因为降级攻击已经成为真正的威胁模式，合规期望正在上升，基于熔丝/eFuse/OTP的存储使只能向前的基线实用和持久。
Chimera Tool提供了一个支持数千种移动设备型号和复杂服务功能的一体化软件解决方案。通过保持在移动安全研究的前沿，它允许用户管理固件、识别安全版本，并在ARB和安全启动被严格强制的环境中执行基本维修。
