Electron应用保护业务代码的一些尝试

本文使用 DraftDepot（稿仓） https://github.com/xland/DraftDepot  编辑发布，稿仓是一款 Windows 桌面端多平台文章编辑与发布工具，支持文章一键灌入各大平台，代码块高亮自动适配，图片自动传对方图床。

ASAR的原理

开发者都知道 Electron 应用内的 asar 是没加密、没压缩的状态，就是简单的文件捆扎结构：

asar（ https://github.com/electron/asar ）工具可以把 html、js、css 源码文件和资源文件拼接成一个大文件（app.asar文件），

然后把每个文件的文件名、路径信息、开始位置、长度信息等都记录在一个 header 的结构体内，

这个结构体也存储在这个大文件中，再把这个 header 的大小也记录在这个大文件中，如图所示：

Electron 自身内置 asar 文件的解析能力（exe内，用C++实现的），

当 Electron 执行开发者的代码时，遇到 require 方法加载本地文件时，

Electron 从 asar 文件的 header 中检索出文件的位置和大小信息，

再根据这些信息读取文件的内容（从 asar 文件的指定的位置获取指定长度的数据）。

你用 hex 工具，直接打开 asar 文件，就不难看出这种文件结构。

像把 asar 文件里的源码（JS/CSS/HTML）文件解包出来，也很简单，

只要 asar（ https://github.com/electron/asar ）工具一行指令就够了。

恶意用户拿到了你的代码，就能分析你的业务，你的产品就几乎没有安全性可言了。

ASAR 的加密与解密

现在假设我们提供了一个自定义的 ASAR 文件格式。

修改了 Electron 内的读取 ASAR 的代码。

那是不是我们的业务代码就安全了呢？

照此思路我做了一些尝试：

因为要让 Electron 能在运行期解密业务代码文件

所以我们加密 ASAR 内的文件时，要选用对称加密算法

我选的是 AES 算法。

AES 加密算法需要一个固定长度、随机性强的密钥。

我又搞了一个 KDF 密钥派生函数。

把密钥拆成四段 XOR 再 SHA-256 拉伸 999 轮。得到 32 字节的 KDF。

秘钥和这个 KDF 生成函数都用 C++ 写在 Electron 的 exe 里。

（当然要改 Electron 的源码，要重新编译 Electron ，这是非常大的工作）

这样得到的 asar 文件再用 HXD 工具打开后，是如下这样：

已经完全没办法被静态分析了。

其他防护手段

fuses：

Electron团队提供了一个 fuses 工具（ https://github.com/electron/fuses ）

这个工具可以在 Electron 应用打包后、代码签名前，

通过修改 Electron 二进制文件的特定字节，来永久性地启用或禁用某些运行时行为。

这相当于给你的 Electron 应用加上了一道“物理开关”，

使得某些即使通过代码配置也难以关闭的危险功能被彻底禁用，从而有效防御供应链攻击和运行时篡改。

禁用调试参数：

如果运行初期发现类似：'inspect'、'inspect-brk' 之类的调试参数，直接退出应用。

为 exe 文件加壳：

用 upx （ https://upx.github.io/ ）之类的工具为 exe 文件加壳

这个方案行不通，因为加壳后的 electron 无法正常运行，这可能和 chromium 的多进程机制有关，我没有深入探究。

逆向分析

现在的 AI 逆向分析工具（比如 rea （ https://github.com/morluto/rea ））

可以直接逆向你的 exe 二进制代码

什么四段 XOR 、什么 SHA-256 拉伸 999 轮

十几分钟就给你跑出来。

上面做的这些工作都没啥鸟用。