最近搞了个网页解析Android APP 安装包 .apk 中的 AndroidManifest.xml 的小工具。

其中，整个项目最复杂的地方就是 axml 转换 xml 的实现。
因为 AndroidManifest.xml 并非是一个真正的 XML，而是一个 axml 格式的文件，需要借助特殊的工具解析、转换到 XML。

在 npm 上找了半天，没找到符合我要求的库。

NPM 上 axml 那个库和 Android 的 XML 完全没有关系！

没办法，只能自己动手实现一下了！

借鉴了 https://github.com/xgouchet/AXML 的源代码，我迁移了一个 JavaScript 版本的 axml2xml。伸手党可以直接用下面的命令添加这个库：

1

npm install axml2xml --save

转换一个 axml 文件为 xml 文件的示例：

1
2
3

const Axml2Xml = require('axml2xml');
const buf = fs.readFileSync('./tests/AndroidManifest.xml');
console.log(Axml2Xml.convert(buf));

最近做项目的时候遇到一个神奇的崩溃。
这个崩溃都集中发生在 Android 10 的机器上。

崩溃堆栈类似下面：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

pid: 2938, tid: 2940, name: crasher64  >>> crasher64 <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x5f2ced24a8
Cause: execute-only (no-read) memory access error; likely due to data in .text.
    x0  0000000000000000  x1  0000005f2cecf21f  x2  0000000000000078  x3  0000000000000053
    x4  0000000000000074  x5  8000000000000000  x6  ff71646772607162  x7  00000020dcf0d16c
    x8  0000005f2ced24a8  x9  000000781251c55e  x10 0000000000000000  x11 0000000000000000
    x12 0000000000000014  x13 ffffffffffffffff  x14 0000000000000002  x15 ffffffffffffffff
    x16 0000005f2ced52f0  x17 00000078125c0ed8  x18 0000007810e8e000  x19 00000078119fbd50
    x20 00000078125d6020  x21 00000078119fbd50  x22 00000b7a00000b7a  x23 00000078119fbdd8
    x24 00000078119fbd50  x25 00000078119fbd50  x26 00000078119fc018  x27 00000078128ea020
    x28 00000078119fc020  x29 00000078119fbcb0
    sp  00000078119fba40  lr  0000005f2ced1b94  pc  0000005f2ced1ba4

backtrace:
      #00 pc 0000000000003ba4  /system/bin/crasher64 (do_action+2348)
      #01 pc 0000000000003234  /system/bin/crasher64 (thread_callback+44)
      #02 pc 00000000000e2044  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36)
      #03 pc 0000000000083de0  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)

通过 Bugly 上报的数据发现，这个 SEGV_ACCERR 的崩溃（无访问权限）发生在读取 libc.so 的代码段(.text)内存的时候。
观察其他信息发现，libc.so的代码段权限只剩下 --xp。
怪不得我们一访问就崩溃，是因为代码段没有可读权限了！
同样的问题也发生在其他系统库上。

当时的解决方案是，通过读取 /proc/self/maps 避开系统库无可读权限的用户。

直到我不小心看到了这个文档……

只执行内存违规（仅限 Android 10）

仅对于 Android 10 中的 arm64，二进制文件和库的可执行部分会映射到只执行（不可读取）内存，作为防范代码重用攻击的一种安全强化技术。此缓解方法与其他缓解方法产生了不良互动，后已被移除。

将代码设为不可读会导致故意或意外读入已标记为只执行的内存段抛出 SIGSEGV，并且代码为 SEGV_ACCERR。这可能是因为错误、漏洞、混合了代码的数据（例如文字池）或故意进行的内存自省导致的。

编译器会假设代码和数据不是混合在一起的，但是手写程序集会导致出现问题。在许多情况下，只需将常量移动到 .data 部分，即可解决这些问题。如果可执行代码段绝对有必要进行代码内省，应首先调用 mprotect(2) 以将该代码标记为可读，然后在操作完成后重新将该代码标记为不可读。

寻思这不是Android系统你在搞事情啊！
Android 官方提供的解决方案是访问之前先 mprotect 一下需要读的内存，给他们加上可读权限。

提供一个伪代码:

1
2
3
4
5
6

auto lib = dlopen('libc.so');
auto fn_open = dlsym(lib, 'open');
auto page_start = (fn_open >> 12) << 12;
mprotect(page_start, 0x1000, PROT_READ | PROT_EXEC);
int *code = fn_open;
printf("code: 0x%X", *code);

在远古的过去（Win7之前），Adobe Flash Player 的 ActiveX插件还可以在PowerPoint中使用。当年有不少PPT中内嵌了Flash 的教案。

在2020的现在，当年的那些PowerPoint里面的Flash已经无法在Office 2016以及更高的版本播放了。更糟糕的是，你想直接导出文件也变得极度困难。

目前网上常见的招数是使用WinHex之类的软件直接硬导出 .ppt 内的文件。该方法虽然在一定程度上可行，但是过于硬核，实际操作难度非常大。

为了解决这个问题，我从另一个角度提取PPT中的Flash文件。

这种方法必须将PowerPoint文件转成 .pptx 格式。原因是 .pptx 格式的本质是一个 .zip 的压缩包，我们可以使用压缩工具解压里面的资源文件。

使用压缩工具打开 .pptx 文件后，可以在 ppt/activeX 文件夹找到PowerPoint中所有的 ActiveX 插件对应的原始的原始文件。其名称类似于 activeX{数字}.bin。

那如何识别这个 .bin 文件原本是什么文件呢？很简单，该文件后缀为 .xml 的资源配置文件里面就有答案。

1
2

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<ax:ocx ax:classid="{D27CDB6E-AE6D-11CF-96B8-444553540000}" ax:persistence="persistStorage" r:id="rId1" xmlns:ax="http://schemas.microsoft.com/office/2006/activeX" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships"/>

上面是一个Flash文件的资源配置文件内容，其中 classid 的值是代表该文件被什么 ActiveX 插件使用。

然后，classid 为 D27CDB6E-AE6D-11CF-96B8-444553540000 时，代表该 .bin 文件内存有的是 Flash 文件（.swf）。