（原文链接: BootStomp: On the Security of Bootloaders in Mobile Devices）
7 Evaluation
这一部分讨论对应用在来自商业手机设备的bootloader的BOOTSTOMP评估。尤其是，对它们中的每一个，我们运行分析工具来定位在第6章讨论的两类漏洞。在第一个实验中，我们使用工具自动发现潜在的路径 ，从攻击者控制的数据(例如，flash 内存) 到代码中能引起内存破坏缺陷的位置。第二个实验，我们使用工具来发现关于锁定/解锁机制如何实现的潜在的漏洞。我们在一台126GB内存的12核运行ubuntu 16.04 的intel机器上运行所有的实验。
我们首先讨论我们使用的bootloader的资料集，结果的分析，和几个用例的深入（in-depth）探讨。
7.1 资料集
为了这个工作，我们考虑了5种不同的bootloader。 这些设备代表3种不同的芯片集家庭：华为 P8 ALE-L23(华为/海思 芯片集)， 索尼Xperia XA(MediaTek 芯片集)和 Nexus 9 (NVIDIA Tegra 芯片集)。我们同样也考虑高通开发的两个版本的基于LK的bootloader。尤其是，我们考虑一种老的版本的高通的LK bootloader（它因包含一个安全缺陷而众所周知，CVE-2014-9798 [19]），和它的最新可获得版本（根据官方的 git 库[22]）。
7.2 发现内存破坏
我们用BOOTSTOMP去分析在我们资料集中的五种bootloader 来发现内存破坏漏洞。这些漏洞能导致任意的代码执行或者拒绝服务攻击。 表2 总结了我们的发现。尤其，表中展示了在每个 bootloader 中识别出来的seed, sink和入口点的数量。表中也展示了为每个 bootloader的筹集的警告数量。由于（out of） 总数36个，对它们中的12个来说，这个工具识别了从一个源头到类似memcpy 的sink的一个潜在的路径，它导至一个buffer overflow的潜在可能。这个工具抛出5个关于一个污点变量被间接引用的可能性的警告，它们能依次构成(constitute)一个内存破坏bug。最终，它们中的19个，这个工具识别出，污点数据能够到达一个循环的控制条件语句，这可能导致拒绝服务器攻击。我们然后手动调查（investigate）所有的警告，来确定是否这个工具没有覆盖安全漏洞。我们手动调查透漏（reveal）总计7个安全漏洞，
他们的六个是以前未知的（5个已经被各自的（respective）供应商确认）,然而剩下的一个是以前已知的 CVE-2014-9798 ,它影响到一个高通的老的基于LK 的bootloader。注意，因为BOOTSTOMP 提供一系列基本块，它和相关的污点seed和sink组合成污染踪迹，即使是对不那么熟练的分析者，手工检查(inspection)也变得容易和快速。我们也注意到，因为在angr中和ARM的THUMB模式指令分析相关的bug,MediaTek bootloader不能被正确的处理。
这些结果说明（illustrate）一些关于BOOTSTOMP的可扩展性和可能性的有趣的点。第一，我们注意到， 每一个入口点的运行耗时（elapse）平均少于5分钟（持续在每个EP纵列）， 发现了总共7个bug。我们用40分钟的时间限制，运行了一些列相同的实验。尽管如此(nonetheless)，我们注意到没有额外的警告产生。这两个结果令我们相信十分钟的超时（也就是，2倍于平均分析时间）是合理的。第二，在针对LK bootloader测试我们的工具时，我们记下来一个内存消耗(consumption)的峰值（peak）。调查后，我们发现LK
是资料集中唯一一个有知名的头（ELF）的bootloader，这允许我们对属于.data和.bass段的字节无约束，就像在 第6章规定的。第三，我们注意到，被报出的所有警告的数量是十分少的，甚至在没有调试信息或者其他****信息的情况下操作，也是在人类分析师能够合理分析它们的范围内。最后，正如我们在表中展示的，对一个相同的潜在的（underlying）漏洞多于一个警告被触发。针对同一个漏洞的多重(multiple)警告的出现，是给一个问题的分析者的强烈指示（indicator）。这发生在当超过1个 seed
属于（fall within）产生唯一bug的相同路径时，例如（for instance），当超过1个污染的参数存在于类似memcpy的函数调用时。
出于这种考虑（with this in mind），并且通过观察表，你可以看到污染 的路径的38.3%左右真正地代表真实的漏洞。同时也注意，在污染路径上下文中，没有报告的警告是误报（也就是，没有污染的路径），然而，误报在理论上（theoretically）是可能的，像7.4部分讲的那样。
我们的工具在华为的android bootloader上 发现了（uncover）5个新的漏洞。首先，当解析保存在boot分区中的linux kernel的设备树（DTB）时，一个任意内存写操作或者拒绝务器能发生。第二，当读root可写的oem_info 分区时一个heap buffer overflow会发生，这是由于没有检查num_records字段。另外，有root权限的用户能够向nve和oem_info分区写，能从这些分区读到配置数据和控制手机外设的内存访问的权限。剩下的两个漏洞会在下面描述细节。
不幸的是，由于华为 bootloader的的架构，正如在3.1部分详述的，这些漏洞在整台设备的安全的影响是相当严重的。因为这个bootloader 运行在EL3，并且负责几乎（virtually）所有设备组件的初始化，包括调制解调器(modem)的基带(baseband)固件和安全的OS，这个漏洞将不仅允许你打破信任链，并且它也将会组成一个手段（mean）来建立（establish）在设备上的存留(persistence)，这是不容易被用户检测的 （detectable），或者来获得任何其他种类的攻击。华为确认了这些漏洞。
BOOTSTOMP 也发现一个在NVIDIA的hboot 上的漏洞。 hboot 运行在 EL1，这意味着它有和linux kernel 一样在对硬件上相等的 特权，虽然它存在于信任链的早期，并且因此它的危害（compromise）能够导致一个攻击者增加存留。我们已经报告这个漏洞给英伟达，并且和他们一起工作来修复它。
最后，我们重新发现一个以前的漏洞，对高通的 aboot报告的，CVE-2014-9798。这些漏洞允许一个攻击者来执行拒绝服务攻击。然而，这个漏洞已经被提交补丁，并且我们对当前aboot 版本的分析没有产生（yield） 任何警告。
案例研究： 华为内存破坏漏洞。 BOOTSTOMP 产生多重的涉及一个函数的警告，这个函数的原始名字我们相信是叫read_oem()。尤其是，工具突出了这个函数如何从flash 读内容并写到buffer 中。一个手动的调查透露（reveal）这个函数如何易受内存破坏的攻击的。尤其是，这个函数读取整体的(monolithic)用于记录的数据结构，这个结构保存在设备存储中的一个叫oem_info的分区。这个分区包含一些记录，它们都能跨越（span）多重块（block）。每一个块是0x4000字节，其中前512字节构成（constitute）一个头。这个头主要包含以下 4个字段： record_id, 它指明记录的类型；record_len, 它指明记录的总长度；record_num,它知名组成这个记录的块的数量；record_index,它是一个基于1的索引（1-based index）。
漏洞列在以下： 函数将首先扫描匹配record_id的块的分区。 现在， 考虑一个record_num 是2的块， 并且它的record_index 是1. 事实上，record_num是2表明这个记录跨越2个不同 的块。 在这一点上， read_oem 函数假设当前块的长度是最大的，也就是 0x4000，并且，它将因此把这些所有字节拷贝到目的数组，完全忽略作为参数传入的长度值。因此，因为oem_info分区能被攻击者控制，一个攻击者能创建一个特殊的精心制作的（crafted）记录，以至于触发一个缓冲区溢出。不幸的是，这个bootloader用这个分区来存放至关重要的信息，这些信息在每一次启动的最开始被访问，比如bootloader的logo。因此，一个攻击者将能够完全危害bootloader，
fastboot和信任链。 结果，它将因此让攻击者安装持久稳固的（persistent）root工具成为可能。
案例研究： 华为任意内存写入 。 我们准备的第二个案例研究是一个任意内存写入漏洞，这个漏洞是我们的工具在华为的 bootloader上识别的。尤其是，这个工具产生一个和read_from_partition 有关的警告。 特别的， 这个工具精确地找到（pinpoint） 以下函数调用（invocation）read_from_partition("boot"，hdr->kernel_addr)，并且，工具突出显示hdr结构能被攻击者控制。手工调查显示不仅hdr(而且它的字段，包括kernel_addr)能被攻击者完全控制，而且函数实际上从一个被 输入("boot",在这个案例)指定的分区读内容，然后复制到被hdr->kernel_addr指定的地址。由于这个目的地址是攻击者控制的，一个攻击者能依赖这个函数写任意内存（通过修改"boot"分区的内容） 到任意地址，攻击者能把它指向 bootloader它自己。我们注意到，这个漏洞只是在bootloader bei被解锁时可利用，但是，尽管如此，它是一个允许攻击者运行任意代码作为bootloader 它自己的漏洞（并且，不只是作为不安全OS的一部分）。此外，下一部分提供证据，证明至少对这个特定的案例，一个攻击者解锁bootloader是容易的。