Typora 授權解密與剖析

11月23日，Typora 正式發布 1.0 版本，進入了收費時代。

1.0 版本是一次性付費而非訂閱的，只要支付人民幣 89 元，可以在 3 臺設備里使用。

Typora之于我

如你所見，這一篇文章就是使用Typora所寫。自搭建個人博客起，Typora就成為了我主要的寫作平臺。

用慣了Markdown，WordPress的古騰堡編輯器沒法滿足我的需求，于是開始尋找替代品，最終的結果便是typora。

當然，多數人使用的原因不外乎以下

• 輕盈、干凈
• 所見即所得
• 圖床
• 主題、生態
• (beta)免費
• ……

如今，typora進入收費階段，不乏使用者被迫遷移至其他寫作工具上。下面，我們來一探究竟。

敬告

請勿使用盜版，支持正版授權，文中內容僅作學習和討論，請不要從事任何非法行為。由此產生的任何問題都將讀者/用戶（您）承擔。

尋蹤覓源

通過火絨劍監測行為日志，程序加載的一些模塊。

在Windows下，typora會記錄日志至{UsersRoot}\AppData\Roaming\Typora\typora.log，能看到可疑的注冊表操作記錄。

正版激活的注冊項內容：

嘗試修改SLicense：

重新運行軟件后，從錯誤日志中發現調用棧暴露。

漸入佳境

這里關注到了app.asar，通過搜索引擎，嘗試解包。

npm install -g asarasar extract {installRoot}/Typora/resources/app.asar workstation/outs

發現文件被加密：

JavaScript不管是字節碼還是明文腳本都會在運行時加載，結合模塊列表尋找加載點。

關注到解包得到的main.node：

IDA尋找字符串特征：

通過交叉引用定位，看到一些導入函數。

由字符串聯想到對加密文件進行的base64解碼，導入表查找到 napi Node-API | Node.js API 文檔 (nodejs.cn)。

簡單分析偽代碼后，其實就是運行。

Buffer.from(e,"base64")

刻舟求劍

嘗試Findcrypt尋找算法，找到AES的Sbox和InvBox，通過交叉引用定位到可疑函數點 main.node+E440。

IDA動態調試，模塊加載斷點：

跑起來，直至加載main.node：

分析模塊后，定位base+offset下斷，運行，看到：

正好與我們的文件對應偏移16。

繼續調試能看到 分組加密的形式：

同時能夠找到前16字節：

正是作為iv進行異或：

柳暗花明

分析調用函數，最終能夠確定其函數功能：

通過偏移EF19，能夠確定AES輪數為13輪，對應為AES 256，偏移B510處的函數，能夠得到AESKey。

落葉歸根

解密得到明文腳本，授權主邏輯在Lisence.js中。

授權邏輯如下圖：

本地驗證->獲取用戶特征->網絡驗證授權->返回密文->RSA公鑰解密->設備指紋對比

破解的思路，不多做闡述。

修改完成后，只需要按相同格式加密并打包為app.asar即可實現補丁Patch

typoraCracker

typoraCracker是一個Typora解包解密程序，也是一個打包加密程序。你可以輕松的打造獨屬于你的補丁，但請注意法律上的可行性。

測試

總有一種人，喜歡享受“正版”激活的感覺。而我就是……

我采用 Patch+KeyGen，補丁去除網絡授權，KeyGen用于本地驗證，測試成功。

typora針對electron下的源碼加固仍是一片空白。

簡單思考后，傳統代碼混淆的方式對關鍵邏輯的保護依然有較大的提升空間，不失為一個恰當的加固方向。

期待typora越做越好。——來自一個正版使用者