在这篇博客中，我们将完整解释如何攻击上一篇博客中提到的漏洞。

上次说到，我已经将漏洞报告给了高通。他们送给我了一台新的Moto X 2014，这将是以后的很多个博客的主题。（更加深入到TrustZone架构以及其他该设备上的安全部件）

当开发这个攻击时，我手头上只有我的Nexus 5。这意味着所有的内存地址以及下面其他特定的信息都是基于这个设备。

以防有人想要重新实现下面阐述的实验，这里提供我的设备的版本：

好了，现在开始正题吧！

依据上一篇博客，你已经知道了那个漏洞可以允许攻击者在TrustZone内核的虚拟内存空间的任意位置写入一个值为0的DWORD。

0写原语并不好用。他们收到的限制非常大，而且经常会无法基于他们产生攻击。为了能依靠这个漏洞产生可靠地攻击，我们先要利用这个弱漏洞产生一个强漏洞。

由于TrustZone内核被加载在一个已知物理地址，这意味着所有地址预先就已经被知道了，所以不需要通过执行来探索。

然而，TrustZone内核的内部数据结构以及状态大部分都未知并且会因为很多不同的进程与TrustZone内核交互而改变（从外部中断，到安全世界的应用程序等等）。

而且，TrustZone的代码分段被映射为只读权限，这在安全开机的过程中就被验证了的。这意味着一旦TrustZone的代码被加载到了内存中，理论来说它不应该再被改变。

上图是TrustZone内存映射与权限

那么，我们如何才能利用一个0写原语来完成任意代码执行？

我们可以尝试编辑TrustZone内核内任何可更改的数据（不如说堆，栈，全局），这也许会是允许我们创建一个更好原语的跳板。

就像我们上篇博客里说的，当一个SCM命令被调用了，任意一个参数，如果他是一个指向内存的指针，那么他将被TrustZone内核验证。这个验证是用来确保这个指针的物理地址在允许范围内，而不是比如说在TrustZone内核所用的内存范围。

这些验证听上去似乎是一个很好的备选，因为如果我们可以禁止掉这个功能，我们将可以利用其他的SCM调用来创造各种不同的原语。

让我们从给内存验证函数一个名字开始。从现在开始，我们将会叫他 “tzbsp_validate_memory”.

以下是这个函数的反编译：

这个函数实际上调用了两个内部函数来完成验证，我们讲叫他们做“is_disallowed_range”和“is_allowed_range”。

如图，这个函数实际上用下面的方法用了给定地址的前12个比特：

——前7个比特位用作表的索引，包含了128个值，每个值32比特宽。(从地址0xfe8304ec开始，存在一个表，这个表里面有128个32位宽的用于比较参量)

——后5个比特位用来与那些个32位宽的参量作比较（top_12_bits & 0x1f 使得top_12_bits里只剩后5位，2的5次方为32，所以1最多可以向左移31位，所以这是要用32位宽的原因）

换句话说，对每个1MB（所以不用管地址的后20位） 的与验证区域相交的区域，在上面表中都会存在一个比特来代表那个区域的数据是允许还是不允许。如果是不允许，函数将会返回一个代表这个结果的值。不然，这个函数将会把这个区域当做有效。

虽然这个函数长了些，这个函数仍然不难。基本上，它简单的遍历了一个静态数列，这个数列包含以下的结构：

这个函数会开始遍历一个表里的每一个向量，这个表的位置在tzbsp_validate_memory函数调用这个函数时给定，当遇到当前向量里end_maker偏移处的值为0xffffffff会停下来。

每个由这样一个向量确定的范围将会被验证以确定这个内存范围是被允许的，虽然如此，就像上面反编译所示，只要那个向量的flags偏移的第二个比特位被置位，那么这个验证就会被省去！

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！