使用deepseek破解mac版typora

1
// LicenseIndex.js 中的 oe 函数（离线激活处理器）
2
function oe(token) {
3
    case 0:  if ("+" == t[0] || "#" == t[t.length-1]) e.next = 2  // 格式检查 OR
4
    case 2:  t = t.substr(1, len-2);                   // 去掉首尾 + 和 #
5
             window.webkit && (                         // WebKit 环境才解析
6
               n = t.split("|"),                       // 拆分为 [base64, sig]
7
               o = JSON.parse(window.atob(a)),          // atob 解码 + JSON 解析
8
               o.sig = i, t = JSON.stringify(o)         // 添加 sig 字段，重序列化
9
             )
10
    case 7:  window.alert("Invalid Activation Token")   // catch：JSON 解析失败
11
    case 11: invokeWithCallback("offlineActivation", t) // 传给原生层
12
    case 14: s ? success : window.alert("Invalid Activation Token") // 原生返回
13
}

关键细节：

window.atob() 产生 Latin-1 二进制字符串，UTF-8 多字节字符被拆分。例如 U+2019(') → 3 字节 E2 80 99 → 3 个 Latin-1 字符 â
window.webkit 必须为真，否则跳过解析，原始 base64 直接传给原生 → 必然失败

1.2 原生层（arm64 ObjC）#

1
offlineActivation:callback: (0x10006d810)
2
  └─ jsonStringToObject:           # NSJSONSerialization
3
  └─ objectForKey:@email, @license
4
  └─ writeLicenseInfo:with:from: (0x10006dd54)
5
       └─ verifySig: (0x10006da80) # RSA 签名验证
6
            └─ +[Crypto verify:with:] (0x10001f2bc)
7
                 └─ SecItemImport (PEM 公钥)
8
                 └─ SecVerifyTransformCreate
9
                 └─ kSecDigestTypeAttribute = SHA2
10
                 └─ kSecDigestLengthAttribute = 256
11
                 └─ SecTransformExecute → BOOL
12
       └─ addEntriesFromDictionary:
13
       └─ writeLicenseInfoOld      # AES 加密 + 写文件
14
       └─ hasLicense
15
       └─ tbnz → postNotification
16
   返回 x21 = verifySig 结果

1.3 备用验证路径#

1
// activate:with:force:callback: (0x10006ed0c) — 在线/手动激活
2
validateEmail:
3
quickValidateLicense: (0x10006ceec)    // 第二验证点

二、尝试过的方案及失败原因#

2.1 方案一：公钥替换 + 自签名（❌ 失败）#

思路：替换二进制中的 PEM 公钥，用自生成私钥签名 token。

验证通过项：

独立 ObjC 测试程序验证：SecVerifyTransformCreate(SHA2,256) 正确验证了 Node.js 签名
C1 控制字符（\u0080/\u0099）的 UTF-8 编解码在 NSJSONSerialization 中一致
公钥 cfstring（0x1000ca988）确认指向已替换的新公钥
JSON.parse 在 JavaScriptCore 中不抛异常

失败原因（推测）：WebKit → native 桥接层在处理含 C1 控制字符的字符串时存在不可重现的差异，导致 jsonStringToObject 收到的 JSON 损坏或 dataToSign 不一致。

2.2 方案二：二进制补丁 verifySig（❌ 失败）#

思路：将 -[LicenseManager verifySig:] 开头改为 mov w0, #1; ret。

失败原因：Mach-O fat 文件偏移在 codesign 后发生变化（x86_64 分片签名增长 → arm64 分片被挤到新位置），硬编码的文件偏移失效，补丁实际写入了无关函数，verifySig 从未被修改。

关键数字：

1
初始：arm64 分片 @ 0x188000, verifySig @ 0x1F5A80
2
重签后：arm64 分片 @ 0x190000, verifySig @ 0x1FDA80
3
硬编码补丁位置 0x1F5A80 → 写入了 NSWorkspace sharedWorkspace 函数

教训：所有 Mach-O 偏移必须从 fat 头和加载命令动态计算。

2.3 方案三：JS/HTML 修改（❌ 无效）#

发现：删除 license.html 和 LicenseIndex.js 后，激活页面仍正常工作。

原因：Typora 在启动时将 page-dist/ 下所有资源预加载到 WKWebView 内存，后续请求从缓存服务，不读磁盘。任何 JS/HTML 修改都无法生效。

2.4 外部干扰：CoreInject.dylib#

在调试过程中发现 /Applications/Typora.app/Contents/MacOS/CoreInject.dylib（16 MB x86_64 dylib），由旧注入工具（Hayaku/CorePatch）安装：

含 HTTP 端点 licenses/validate/v1/ 和 licenses/activate/v1/
独立调用 SecKeyVerifySignature 进行 RSA 验证
我们的 URL 重定向（→ 127.0.0.1）导致其验证失败

处理：删除 dylib，将 @executable_path/q 加载命令改为弱导入（LC_LOAD_WEAK_DYLIB = 0x80000018），dyld 缺失不崩溃。

2.5 brk#0 碰撞测试（关键发现）#

将 verifySig 开头改为 brk #0（崩溃指令），Typora 正常启动 → 激活时不崩溃。

结论：verifySig 从未被调用。实际失败点在 offlineActivation:callback: 的更早阶段（cbz x0, fail — jsonStringToObject 返回 nil）。

三、最终方案：运行时 dylib 注入 + 自动激活#

3.1 原理#

既然直接修改二进制逻辑容易出错（偏移问题、缓存问题），使用 ObjC 运行时方法摇摆，在 dylib 构造函数中拦截关键方法：

1
// dylib 构造函数（__attribute__((constructor))）
2
verifySig:              → 始终返回 YES
3
quickValidateLicense:   → 始终返回 YES
4
// 然后直接调用 writeLicenseInfo:with:from: 写入有效许可证

dylib 通过 LC_LOAD_WEAK_DYLIB @executable_path/q 由 dyld 自动加载。

3.2 部署流程#

1
mac.js:
2
  Phase 1 — 插入/修复加载命令（支持全新和已修改的二进制）
3
  Phase 2 — URL 重定向（store.typora.io → 127.0.0.1）
4
  Phase 3 — 编译部署 dylib
5
  Phase 4 — codesign

打开 Typora → 2 秒内自动激活，无需粘贴令牌。

3.3 关键设计决策#

决策	原因
使用 dylib 而非补丁二进制	二进制补丁受 Mach-O 偏移影响；dylib 运行时注入更可靠
弱导入（非强导入）	如果 dylib 缺失/架构不匹配，不影响 Typora 启动
动态计算 Mach-O 偏移	codesign 改变分片大小后偏移不失效
从配置文件读取机器码	支持多机器，dylib 从 `~/.typora_crack_config.json` 读取
自动激活（非手动令牌）	消除剪切板/粘贴/格式问题，用户零交互

3.4 防掉激活#

URL 重定向 → 阻止 Sparkle 更新检查和在线验证
dylib 在每次启动时重新写入许可证
Typora.bak 保存原始二进制用于回滚

四、关键逆向地址（arm64 VA）#

方法	VA	说明
`+[Crypto verify:with:]`	`0x10001f2bc`	RSA 签名验证（SecVerifyTransformCreate）
`+[Utils jsonStringToObject:]`	`0x1000257d0`	JSON 解析（NSJSONSerialization）
`-[LicenseManager offlineActivation:callback:]`	`0x10006d810`	离线激活入口
`-[LicenseManager verifySig:]`	`0x10006da80`	签名验证（公钥替换目标）
`-[LicenseManager quickValidateLicense:]`	`0x10006ceec`	备用验证
`-[LicenseManager writeLicenseInfo:with:from:]`	`0x10006dd54`	写入许可证
`-[LicenseManager activate:with:force:callback:]`	`0x10006ed0c`	手动激活入口
`-[LicenseManager writeLicenseInfoOld]`	`0x10006d984`	旧格式（AES + NSKeyedArchiver + 写文件）
`+[Crypto encryptAES:]`	`0x10001f4c8`	AES 加密
`-[LicenseManager recordFilePathOld]`	`0x10006be38`	许可证文件路径

五、关键文件#

文件	路径	说明
激活脚本	`mac.js` / `crack.js`	主脚本
Typora 二进制	`/Applications/Typora.app/Contents/MacOS/Typora`	通用二进制（arm64 + x86_64）
备份	`Typora.bak`	原始二进制备份
dylib	`Contents/MacOS/q`	编译生成的自动激活 dylib
许可证文件	`~/Library/Application Support/abnerworks.Typora/.hp*`	AES 加密的许可证
配置	`~/.typora_crack_config.json`	机器码 + 邮箱缓存
许可证 JS	`page-dist/static/js/LicenseIndex.180dd4c7.5b58fa97.js`	离线激活 JS（预加载到内存）
欢迎页 JS	`page-dist/static/js/WelcomeIndex.63db304f.1fe70769.js`	在线激活 JS
主 JS	`page-dist/static/js/main.fb2bf03d.js`	`window.Setting` 桥接定义
WebKit 缓存	`~/Library/Caches/abnerworks.Typora/`	HTTP 缓存（不影响 file://）
WKWebsiteData	`~/Library/WebKit/abnerworks.Typora/`	Service Worker / LocalStorage

六、调试工具链#

1
# Mach-O 解析
2
otool -arch arm64 -tV Typora     # 反汇编
3
otool -arch arm64 -l Typora      # 加载命令
4
otool -arch arm64 -ov Typora     # ObjC 元数据
5
nm Typora | grep verifySig       # 符号表
6
lipo -info Typora                # 通用二进制分片
7

8
# 运行时
9
codesign -dvvv Typora.app        # 签名验证
10
vmmap PID | grep q              # 进程加载的 dylib
11
log stream --predicate 'process == "Typora"'  # os_log 捕获
12

13
# JavaScriptCore 测试
14
/System/Library/Frameworks/JavaScriptCore.framework/Versions/A/Helpers/jsc
15

16
# ObjC 编译
17
clang -arch arm64 -dynamiclib -framework Foundation -framework AppKit -o q fix.m