一直比较喜欢Typora的简洁与美观（尝试过用 vscode 搭配插件编辑 markdown 文件，体验还是要差一些的），突然发现自己windows机器上很久前安装的typora不让用了，提示：

幸好原始安装文件还在，对比一下版本，原始安装文件是 0.9.93 版本，而不让用的是 0.10.11。
在我的 ubuntu22.04 机器上安装有 1.7.4 版本，win10上安装了 1.7.6版本。貌似最新的版本开始收费了，还分国内/国外两个版本。（typora.io 这个官网貌似被墙了，真不知道为了个啥。）
本着一个cracker无知者无畏的折腾到底的精神，开始瞎整！

逆向分析的第一步就是要了解目标软件是用啥开发的，架构是啥。
一看 typora.exe 好家伙，100多个M，这么大的可执行程序还分析个啥？IDA分析一下都不知道要多久。
由于目前主用 ubuntu22.04 系统，想着顺便从 0 开始学习使用 ghidra 进行 Linux 平台的逆向分析工作。于是从一个小目标开始，需要瞎搞的知识点有了第一次扩充。

悲催的是用 ghidra 静态分析 1.7.4 版本的 typora 有160多M，分析了10个小时也没结束。这个弯路绕太远了，毫无意义。直接放弃。

正确的打开方式：直接网上搜索
有大神直接用 IDA 分析 typora.exe，提示了一些有用的东东。结合两位成功破解的大神的文章，可以确定 typora 是使用 electron + nodejs 框架，用 javascript 开发的跨平台的桌面程序。（和vscode类似）
所以，啥是 electron/nodejs/javascript？0 基础的暴走，奇怪的知识点需要进行第二次扩充。
这几个每一个都是大部头，越底层的难度越大。被V8引擎绕进去花了不少时间（虽然了解一下好处很多，带着VM的思路去了解，能有不少收获），但就typora的破解来说，只需要涉猎以下内容：

node.js Addon 可以在 js 层直接 require 一个 dll/so。electron 入口可能也是 require 引入 package.json 及里面定义的入口 js 文件的。
0.10.11 版本：PEid 查看算法常数，发现 sbox/rsbox，基本可以确定使用了AES算法。只是windows版本去符号，要从 rbox 逆推找到 AES KEY 和取定其 mode 难度还是比较大的。网上也有人分析到这一步放弃的。当然大神可以直接找到 mode CBC iv 和 AES KEY。
1.7.4 linux 版本：神奇的是没有去除符号，但与0.10.11版本不同，KEY 和 mode 的地方进行了混淆处理，不知道把 CBC 的 iv 怎么藏起来了。懒得去反混淆分析了（主要是能力不够）
有大神直接给出了 main.node 保护electron app的概念验证项目：https://github.com/toyobayashi/electron-asar-encrypt-demo。
有了第二部分提到的知识准备后，就可以尝试看一下这个项目。当然像我一样 0 基础的，也可以边看边学，借助 N-API 文档和chatGPT的帮助。
简单总结一下这个项目的思路：

结合V8执行js的基本逻辑来理解上面的思路：

V8执行js代码有两个过程，Compile 和 Run。Compile 只接受 V8 的托管字符串（js代码），而 C++ 字符串需要在 isolate（V8的一个独立的运行时虚拟机容器）内创建一个托管的 V8::String，用 N-API 库的话，相应函数是 napi_create_string_utf8(...)。
所以，既然把入口 js 的代码放到 C++ 层加解密，那么要执行它，比然经过上面的三步。重载 _compile 函数就是为了在这一步，给传入的 C++ string（js code）进行解密并创建对应的托管String，以便传给原来的 compile 函数。
理解了这个过程，那么最快、最容易的获取解密后的入口 js code，就在这个过程中。有两个思路，后面介绍。

实际上找入口这一步是多余的，有了源代码只要结合关键字符串 _compile 和相应的函数调用，就能很快定位到 init 函数。只是作为一个cracker对流程跟踪的执念，瞎整。

疑似的ModulePrototypeCompile这个函数往里面看的时候，和源代码完全不一致：

当时也懵了，因为自己是在windows系统上用IDA完全对照源码静态分析。使用静态分析工具查看 refrence to 和 refrence from 都连不上。无奈之下启用 x64DBG 调试。（找到真实的ModulePrototypeCompile函数还是很容易的，因为根据源代码，这个函数里面有非常明显的字符串"app.asar"，而且是一个对称的if ... else ...结构。只是想弄清楚开发者到底怎么魔改的。）最后发现真实的ModulePrototypeCompile地址被打包在了上面替换函数的参数里面。调用变成了 call qword ptr [r8]，从而避免了静态分析时候被一撸到底。实际的trick是这样的：

直到分析 1.7.4 linux版本的时候，就看的很清楚了。

两者结合可以清楚看到多了一层 Wrapper 把真实函数地址隐藏在 Wrapper的参数里面。

后面的部分对于 0.10.11 windows版本来说，和源代码几乎一模一样，就是AES解密的过程，没有源代码那么多函数层级，中间的函数调用估计被 inline 了。但基本结构是一样的。CBC 模式的 iv 被藏在了实际chunck的最前面16个字节。
对于 1.7.4 Linux 版本整体架构不变，但 getKey 和 getIV 做了混淆，IV 怎么藏的也没看明白。尝试用函数的返回值，参照老版本的格式进行解密，发现是错误的。对混淆没什么能力，还是绕路吧。毕竟最终目标是去 main.node 运行。

可以直接解密 app.asar（因为打包了几乎所有重要 js 文件，所以一个个调试获取源码也麻烦。）
其AES KEY就编码在指令中，无论是静态获取还是调试 getKey 处获取都可以。
IV 是放在chunck前的16个字节。根据这两个条件，可以直接编写代码对 app.asar 进行解密。

因为看不懂 key 和 iv 的混淆，只能骚操作——直接调试获取 atom.js 的源代码。（只加密了这一个文件，估计是要保证启动速度）
在第三部分的最后，卖了一个关子，说到有两种方式可以获取解密后的 atom.js 入口，这里介绍一下：
（1）其实这个main.node加密框架本身就提供了获取方法，既然能重载_compile，在调用原始_compile之前对js code 进行解密，那么这个框架本身，也可以被cracker用来再次重载_compile，等着后续的main.node将解密好的 js code 传过来，然后 console.log 就可以了。
我不是搞开发的，看这个框架要配置编译环境貌似挺复杂的，留给有electron开发经验的朋友吧。这个方法的好处是：一次投入，终身享受。只要还使用这个框架，点下鼠标就能获得源代码。（当然typora作者也是有备而来，后面会讲到）
（2）napi_create_string_utf8，这个函数接受 C++ 字符串，可以直接从 GDB 或者 x64DBG 中把参数的值 dump 出来。不过因为调用这个函数的地方很多，需要手动定位 ModulePrototypeCompile 函数解密分支里面的那个，下断点。Decrypt函数直接返回了托管字符串，所以还需要深入进去找到正确的返回前最后一个调用 napi_create_string_utf8 的地方。

当然大神使用 frida 动态挂钩 napi_create_string_utf8 这种骚操作，咱小白也不懂。

优点是可以保持最快的加载速度，相当于完全开源了。

根据0.9.93版本的目录架构，将解密后的文件丢到 typora/resources/app/ 目录下，其他保持不变，就可以直接运行了。

使用解密后的 atom.js 按照 0.10.11 版本那样直接运行 win10 会弹窗提示 scheme 变量没有定义；linux 下有 typora 进程，不提示错误，需要用 GDB 调试运行才能知道，错误是一样的。这又是闹哪一出？

这5个暗桩，有的是隐藏了键名，有的是隐藏了键值。

1.7 版本的 js 使用了 webpack 打包，main.node init 最后的入口调用有两步：

有了上面这些信息，单独写一个 main.js 把4个全局变量加进去，按步骤调用入口就能实现去 main.node 运行了。

这些属于 js 层面的东东，还是经过 webpack 打包和混淆过的。对于 javascript 小白来说，看这种代码和天书差不多。找了个debundle工具，能还原未加密的 dist/static/js/ 里面的文件，但还原 atom.js 报错。最后找了个 webcrack 工具，效果是比较好的格式化了 atom.js，比vscode js fommatter 之类的强。果断祭出大杀器——chatGPT。一开始心太黑，直接把整个 atom.js 复制给 chatGPT，想让它给格式化代码，并给出解释。结果 chatGPT 直接给了一个长长的菜谱，真的是用心良苦。

0.x版本应该都是作者发布的开发测试版本。而0.10版本很可能是作者第一个使用 main.node 进行加密的验证版本，因为 js 里面连个注册页面都没有，只有简单的验证逻辑和时间校验，超时不让用。
让 0.10.11版本重新跑起来也很间，直接将 License.js 里面表述注册与否的变量的初始值从 null 改成 true 就可以了。

这两个版本在 main.node 里面对 AES KEY 和 IV，以及暗桩的处理上，有一些差异，win10版本的更复杂和强化了一些。js 层上，关于注册的 445 类，对win32系统有着更加强化的校验。1.7.4linux版本，似乎是可以无限试用的，超时验证逻辑存在bug。
js 分析后，确定 445 类是处理所有注册/校验相关的。联网校验优先，涉及数据结构：

注册信息会用服务端私钥加密，本地用公钥解密。再进行 email 和 license 的校验。本地注册也是这个解密验证过程。网络验证不成功，会清空 SLicense，回到未注册版本。
由于公钥解密的介入，想要完美本地注册已经没有意义。想持续使用的思路大致两个（没仔细研究，可能还有坑，看个大概齐吧）：

手动修改 IDate（install date） 时间。

由于采用 main.node 这种框架把入口的解密放到 C++ 层，那么不可避免的，框架本身可以用来直接获取解密后的 js code，或者是绕不开字符串从 C++ 到 V8容器托管的转换过程。这是 electron 项目保护最大的难点。
作者也进行了很多努力：AES 关键的 key 和 iv 进行了隐藏和混淆；埋了一些暗桩并加密。但用前面的各种骚操作都可以绕过。
个人建议既然埋暗桩，与其花经历在几个全局变量的名字和值上进行各种花式操作，还不如把 445 注册校验类整体/部分放到 main.node 中。至少尽可能让不能脱离 main.node 运行。底层还能使用各种成熟的二进制保护技术，甚至可以引入虚拟机保护，增加逆向成本。

typora风格的markdown编辑器，好像github上有开源的了，有道笔记的 markdown笔记似乎也改成typora这种所见即所得风格了（不过上图要付费，或者自己注册一个免费图床）。选择面变多了。不过typora依然是桌面最优雅的。
整个逆向分析过程学到了不少东西，毕竟几乎整个是从 0 开始学起的。
在 ubuntu 平台使用 ghidra 进行静态分析和动态调试；
对面向对象有了更深层次的理解；
托管与非托管的相互调用，从C#、V8 js、python，有点理解python作为胶水语言在这种场景下为什么强大；发现 js 后面的 AST 是一条不归路啊。
对框架的理解，在逆向中的作用越来越重要了。现在的程序似乎都依赖于某个框架。

参考文章：
《向Typora学习electron安全攻防》
《Typora 授权解密与剖析》
《Typora解密之跳动的二进制》
《Electron程序逆向（asar归档解包）》
《electron开发、打包与逆向分析》

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！