某主流 Markdown 编辑器本地激活机制与安全边界突破分析
引言
基于 Electron 架构的客户端软件因为跨平台能力强，在生产力工具里很常见。这类软件的核心逻辑大多用 JavaScript 和 HTML 构建。这种设计带来开发便利的同时，也让代码容易暴露在反编译和本地篡改的风险之下。
这里我们从逆向安全角度，拆解一种针对这类客户端的本地硬编码绕过手段，看看它的认证逻辑缺陷到底卡在哪里，并给研发和企业防守方提供一些加固思路。
声明：本文分析仅用于安全研究、逆向工程教学和合规审计。请支持正版软件，勿将相关手段用于非法目的。
1. 激活绕过与技术实现细节
这种本地绕过手段通常分为三步：修改核心逻辑状态、抹除本地化提示、干预渲染进程生命周期。
主程序状态劫持（核心逻辑篡改）
- 目标文件：
Typora\resources\page-dist\static\js\LicenseIndex.[hash].chunk.js - 改动前：
e.hasActivated="true"==e.hasActivated - 改动后：
e.hasActivated="true"=="true"
安全分析
这是直接在客户端做布尔值硬编码注入。
原来的逻辑要看右侧表达式的计算结果。程序需要检查本地存储或接口返回的激活状态字符串是不是 "true"。改动之后，右侧表达式变成了永真式。不管前置的授权校验怎么跑，最终的激活状态变量都会在执行到这一步时被强制覆盖。
软件直接把核心授权状态交给了本地内存变量控制，而且没有在运行时对关键 JavaScript 脚本做签名验证或哈希校验。
UI 静态资源修改（视觉去标化）
- 目标文件：
Typora\resources\locales\zh-Hans.lproj\Panel.json - 改动前：
"UNREGISTERED":"未激活" - 改动后：
"UNREGISTERED":" "
安全分析
这属于本地化资源劫持。
主程序的核心逻辑虽然被改了，但如果某些边缘校验分支没有被完全覆盖，UI 上可能还是会触发未激活的提示。通过把语言包里的警告文本直接改为空格，能从视觉上隐藏掉这些痕迹。这只是一种前端障眼法，没有技术层面的绕过能力。
DOM 注入与弹窗干扰
- 目标文件：
Typora\resources\page-dist\license.html - 改动前：
</body></html> - 改动后：
</body><script>window.onload=function(){setTimeout(()=>{window.close();},1000);}</script></html>
安全分析
这属于后置脚本注入。
核心逻辑被修改后，可能会破坏授权页面的原有生命周期。比如程序在判定激活成功后本该自动关闭窗口，但因为状态异常导致弹窗卡在桌面上。在页面尾部加一段原生 JavaScript 定时器，等页面加载完 1 秒后强行调用窗口关闭方法，是用粗暴关闭进程的方式来掩盖逻辑流错误。
2. 潜在的安全边界风险
对企业内网和运维安全团队来说，放任这类被改动过的客户端在生产环境运行，会引发一些实质性的安全隐患。
| 风险维度 | 威胁描述 |
|---|---|
| 供应链污染 | 非官方分发的补丁和激活脚本，容易被人在里面掺杂后门、键盘记录器或者远程控制木马。 |
| 完整性破坏 | Electron 应用的 resources 目录一旦对非管理员开放了写权限，攻击者就能利用同样的通道往里塞恶意 JS 代码，可能导致跨站脚本攻击演变成远程代码执行。 |
| 合规风险 | 企业内网做数字化资产审计时，这种明显的篡改特征很容易触发终端安全管理（EDM）软件的告警，带来版权合规麻烦。 |
3. 研发与防守方加固建议
要对抗这种本地篡改，软件开发商或企业安全团队可以参考以下做法。
- ASAR 增量签名与运行时校验：
把前端资源打包进
app.asar，并对文件做数字签名。进程启动的时候，用底层 C++ 或 Rust 写的 Node.js 扩展去校验签名，如果哈希对不上就直接拒绝启动。 - 控制流平坦化与代码混淆： 对关键授权逻辑做深度的抽象语法树（AST）混淆，把变量名弄乱，打碎控制流，拉高逆向分析的时间成本。
- 动态密钥防篡改： 不要用单纯的布尔值当判断依据。激活状态应该绑定本地机器的硬件特征，比如 UUID 或 MAC 地址，生成动态加密 Token，让核心渲染逻辑定期在后台解密校验。
讨论 0