Arm® Architecture Reference Manual Supplement, The Scalable Matrix Extension (SME), for Armv9-A
卧槽这玩意也太生猛了！
卧槽这玩意也太生猛了！
😱1👌1
最近做了个 DynamoRIO 的 poster，突然想起来之前不知道在哪儿看过的一个神奇越狱：
DynamoRIO 和 Pin 这类高性能 DBI 的核心工作原理都是将应用程序（下称 app）的代码“拷贝”到一个由自己管理的代码缓存中然后运行。在“拷贝”的过程中需要将代码转换为 PIC，并完成插桩等工作。这样既对 app 有了绝对的控制权，又可以不改变 app 的行为。
—— 但现实是不改变 app 的行为意味着 DBI 的存在必须对 app 完全透明，而这个先拷贝再运行的做法实际上已经引入了不可避免的不透明性。
app 首先运行一个特殊构造的指纹。这个指纹必须足够简单，DBI 不会做任何修改就可以原样放入代码缓存，比如下面的指令序列：
addi zero, zero, 114
addi zero, zero, 514
运行之后，app 就可以通过扫描 self/maps 找到这个指纹，即可成功确认自己是否运行于 DBI 中。
更进一步，既然找到了这个指纹，我们还能偷偷把它修改掉，比方说把它 patch 为对某个函数的调用。
这里你可能会有疑问：patch 后的函数调用实际上是 app 的代码地址，那 DBI 只需要把 app 的内存全都 map 成不可执行不就可以了？答案是不行，因为 DBI 必须保持透明，将本可执行的内存 map 成不可执行这个行为破坏了透明性。
所以，当 patch 完成，app 再次运行指纹的时候，此时就会调用到 app 的代码中，至此成功完成了越狱。
DynamoRIO 和 Pin 这类高性能 DBI 的核心工作原理都是将应用程序（下称 app）的代码“拷贝”到一个由自己管理的代码缓存中然后运行。在“拷贝”的过程中需要将代码转换为 PIC，并完成插桩等工作。这样既对 app 有了绝对的控制权，又可以不改变 app 的行为。
—— 但现实是不改变 app 的行为意味着 DBI 的存在必须对 app 完全透明，而这个先拷贝再运行的做法实际上已经引入了不可避免的不透明性。
app 首先运行一个特殊构造的指纹。这个指纹必须足够简单，DBI 不会做任何修改就可以原样放入代码缓存，比如下面的指令序列：
addi zero, zero, 114
addi zero, zero, 514
运行之后，app 就可以通过扫描 self/maps 找到这个指纹，即可成功确认自己是否运行于 DBI 中。
更进一步，既然找到了这个指纹，我们还能偷偷把它修改掉，比方说把它 patch 为对某个函数的调用。
这里你可能会有疑问：patch 后的函数调用实际上是 app 的代码地址，那 DBI 只需要把 app 的内存全都 map 成不可执行不就可以了？答案是不行，因为 DBI 必须保持透明，将本可执行的内存 map 成不可执行这个行为破坏了透明性。
所以，当 patch 完成，app 再次运行指纹的时候，此时就会调用到 app 的代码中，至此成功完成了越狱。
👌3