SQLCipher

分析对象:飞书 macOS 客户端 /Applications/Lark.app(v131.0.6778.268 起分析,143.0.7499.203 复验,Electron/Chromium 内核)。 方法:静态逆向(strings / 反汇编 / asar 解包)+ 真实撤回的落盘观察 + 前端 asar 补丁注入的实测迭代。 本文讲原理与逆向过程;拿着结论去动手改客户端,见下一篇《飞书防撤回补丁复现指南》。 TL;DR:撤回是怎么实现的 撤回 = 服务端下发一条带撤回标记的消息资源更新,客户端把本地 SQLite 行打上 is_recalled=1 等标记列,前端按标记切换渲染成「撤回了一条消息」提示。而原始 content 会被一并抹掉(实测:绕过渲染门之后,被撤回的消息渲染成空气泡;DB 加载与撤回推送两路拿到的 content 均为空)。所以单纯改前端的布尔分支只能得到空气泡——防撤回必须「渲染即存档、撤回时还原」。 完整链路: 发起方:前端菜单 → JSB 命令 RECALL_GROUP_MESSAGE / RECALL_MESSAGE → Rust 核心 liblark.dylib(lark-message 模块)→ 长连接(pipe/websocket protobuf,非 REST)→ 服务端。日志串:recall_message callback for id: / recall message success: id=。 接收方:服务端推送更新后的 Message protobuf(字段含 is_recalled / recaller_identity / recall_type / recall_user_id)→ lark-message/src/logic/dependencies/processor.rs 校验(chat recall message validate failed, recaller not found 等)→ 更新本地库 → 通知前端。 本地库:SQLCipher 加密的 SQLite,messages 表同一行内:content BLOB(原始内容)+ is_recalled BOOLEAN + recaller_id BIGINT + recaller_identity INTEGER + recall_type INTEGER + recall_user_id BIGINT。 前端渲染(messenger asar,已提取实证代码): let{isRecalled:r,isDeleted:a,recallerIdentity:n}=t; return r ? <E recallerIdentity={n}/> // "X 撤回了一条消息" 提示条 : a ? <S.A/> : <N {...e}/> // 正常消息 以及 function L(e){return !e.isRecalled && !!e.content.filePath} —— 撤回消息对象上 content 依然存在,只是被布尔位挡住(但值已被掏空)。 通知/红点同步收尾:do not push notice to oneself when is recalled(自己撤回的不推通知)、thread 根消息标记 root_message_is_recalled、回复计数修正 update reply count for msg has recalled。 一、客户端架构 层 位置 作用 Electron 主进程 Contents/MacOS/Feishu 壳、窗口、升级 渲染进程 Lark Helper (Renderer) 加载 webcontent/*.asar(messenger.asar = 聊天 UI) aha-service 后台进程 Lark Helper --type=backend(加载 liblark) Rust 核心:同步、存储、JSB 命令 核心库 Libraries/liblark.dylib(84MB) 全部业务逻辑,Rust 编写,字符串含 lark-message/src/*.rs 等源码路径 DB 层 liblark 内静态链接 SQLCipher 4 本地库全加密 前后端通信:JS Bridge 命令表(全大写,如 GET_CHAT_MESSAGES、RECALL_GROUP_MESSAGE、HANDLE_PIPE_PACKET、HANDLE_WEBSOCKET_PACKET);服务端长连接推送走 pipe/websocket 包,protobuf 编码。 ...