Electron 的一些调试技巧

0x00 背景

Electron 是一套跨平台UI框架，允许使用 Web 技术栈构建桌面应用。相对于 Native GUI，Electron 的维护成本较低，因而十分流行。VS Code、一些企业的 IM 工具，都使用了 Electron 。然而成本低也有成本低的代价，Electron 除了饱受诟病的性能问题外，还为桌面应用引入了一个新的攻击面 —— XSS 。找到一个 XSS，即很有可能在对方电脑上执行任意系统命令。

分析 Electron 应用的 JS 代码，应该是找 XSS 最有效的手段。然而，有些厂商也想到了这一点，并做了一些对抗升级。比如早期版本的飞书（Lark），对 JS 代码进行了一层加密（现在已经放弃了 Electron 框架）。

本文主要分享如何调试这类 “加密” Electron程序。

0x01 分析 Electron 程序

0x0101 普通 Electron 程序

一个普通的 Electron 程序，通常它的 JS 源码会被打包到 .asar文件中，或者直接以 JS 文件的方式存储在程序目录内。如 VS Code ，JS 代码会放在 Resouce 的 out/ 目录下，以及打包到 node_modules.asar中。

更常见的一种形式是，整个 JS 代码都打包到一个名为 app.asar 的文件中。

对于直接明文存放的 JS 文件，直接打开文件分析即可。对于 asar 文件，使用 Electron 官方提供的工具（https://github.com/electron/asar），即可完成解包。

当然，直接看 babel 打包的代码很累，要是能够加载 source map 或像浏览器一样可以动态调试就好了。Electron 本身实际上也是个 Chromium，可以像类似于 Chrome 一样打开开发者工具进行调试。对于一些善良的开发者，甚至会直接将打开开发者工具的入口暴露给你，比如 VS Code，毕竟本身就是开源的。

这种情况下，基本上就可以像 Chrome 一样加载 source map、下断点调试了。

然而大多数情况下，开发者不会将这个入口暴露出来，甚至还将 asar 文件加密了。下文将介绍如何轻易打开开发者工具。

0x0102 加密的 Electron 程序

Electron 实际上也是个 Chromium ，可以用 Chromium 的方式开启开发者工具。以 Docker Desktop 为例，在运行程序时，添加--remote-debugging-port=9222 参数，即可在 9222 端口为 Electron 主窗口开启远程调试功能：

此时，用 Chrome 访问 chrome://inspect/ ，同时确保 Discover network targets 选项已勾选，且Configure...中包含 9222 端口，即可管理远程调试目标：

点击 Inspect 即可打开相应的开发者工具：

以上方式只能开启 Render Process 的开发者工具，如果想要调试  Main Process 怎么办？这里可以使用到另外一种开启方式，运行 Electron 程序时，添加 --inspect=9222 参数。这时同样可以利用 Chrome 进行远程 Debug，只不过 Debug 的对象变成了 Main Process：

这种方式下，基本可以毫无限制地执行 NodeJS 代码，比如通过下面代码为所有 Electron 窗口开启开发者工具：

const { BrowserWindow } = require('electron')

注意，这时候打开的开发者工具，已经不是 Chrome 远程调试的开发者工具了，而是 Electron 程序自己的 DevTool 。

由于 Chrome 远程调试技术的存在，即使 app.asar 被加密了，也可以通过上述方式轻轻松松查看、调试未加密的 JS 代码。2020 年版本的 飞书（Lark）即可通过该方法突破 asar 文件的加密。（本来想直接演示加密版本的飞书，奈何已经找不到 2020 年版本的飞书了）

0x0103 CEF ？

2021 年某个时间，飞书（Lark） 切换到了 CEF（Chromium Embedded Framework），猜测是因为性能的原因。但由于 CEF 也是基于 Chromium 的，可以使用 --remote-debugging-port=9222 的方式强制打开远程调试：

这种情况下，即使飞书后续对 CEF 的资源文件进行了加密，也意义不大，毕竟 Chromium 这层执行的 JS 文件，还是明文的。

0x03 小结

那么采用 Electron/CEF 或者类似技术栈的应用，该如何保护自己的代码呢？先说不推荐的思路：

1.对 JS 文件本身进行 VMP 加壳

2.对 Chromium 内核本身进行修改

不推荐的原因很简单：Electron 本身已经够卡了，JS 加壳雪上加霜。对小部分重要逻辑进行加壳倒是可行；有修改 Chromium 的精力，不如重写一个 Native 应用，性能还更好。

再分享一些相对比较好的思路：

1.部分逻辑用 Web Assembly 实现

2.部分逻辑放在 .so/.dll 文件中