[原创]4.0微信朋友圈媒体解密全解析-逆向工程-看雪安全社区

> 本文记录了 <a href="elink@1b8K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6Z5K9h3y4U0j5$3x3%4y4#2)9J5c8W2N6W2c8X3I4G2N6H3`.`.">WeFlow</a> 项目中实现朋友圈图片/视频/实况照片解密的完整过程——从硬搬 DLL 函数来调用，到用纯 TypeScript 独立实现。

## 0x00 背景：朋友圈的图片为什么打不开？

如果你尝试直接访问朋友圈图片的 CDN 地址（*形如* 
```https://mmsns.qpic.cn/sns/...```） ，你会发现下载下来的文件根本不是正常的 JPEG 或 PNG——它是 **加密过的**。

微信服务器在返回媒体数据时，会在 HTTP 响应头里带上一个字段：
```
x-Enc: 1
```

这个 `x-Enc: 1`  就是在告诉客户端："这个数据是加密的，你得解密后才能用。" 而解密需要一个 **key（密钥）**，存储在朋友圈动态的 XML 数据里。

那加密用的是什么算法？图片、视频、实况照片的加密方式一样吗？这就是本文要逐一解答的问题。

## 0x01 媒体数据是怎么下载下来的？

在谈解密之前，首先要搞清楚：**图片/视频的 URL、鉴权令牌和密钥从哪来，怎么请求？**

### 一切数据都在本地数据库里

朋友圈的数据存储在微信本地的 WCDB 数据库 ```(~\xwechat_files\wxid***\db_storage\sns\sns.db)```  中。每条动态都有一段 XML 格式的原始数据，里面包含了媒体信息。不同类型的动态，XML 结构有所不同：

**普通图片动态：**

```xml
<media>

<token>xxxxxxxxxxxxxx</token>

</media>
```

**视频动态（Type 15）：**

```xml
<media>

<token>xxxxxxxxxxxxxx</token>

</media>

<enc key="2105122989" />
```

**实况照片（Live Photo）：**

```xml
<media>

</livePhoto>

</media>

```

### URL 修正

数据库中存的 URL 不能直接用，需要做几个处理：

```

// 1. HTTP → HTTPS

let fixedUrl = url.replace('http://', 'https://');

// 2. 图片：把缩略图 /150 改成 /0 获取原图（视频不需要）

if (!isVideo) {

fixedUrl = fixedUrl.replace(/\/150($|\?)/, '/0$1');

}

// 3. 拼接 token（没有 token 服务器直接 403）

if (isVideo) {

// 视频：token 必须放在参数最前面

return `${baseUrl}?token=${token}&idx=1${existingParams}`;

} else {

// 图片：token 追加到末尾

return `${fixedUrl}${connector}token=${token}&idx=1`;

}
```

### 区分图片和视频 URL

微信用不同的域名/路径来分发图片和视频：

| URL 特征                      | 类型  | 说明         |
| --------------------------- | --- | ---------- |
| ```mmsns.qpic.cn/sns/...``` | 图片  | 朋友圈图片      |
| ```vweixinthumb...```       | 缩略图 | 视频封面，本质是图片 |
| ```snsvideodownload...```   | 视频  | 视频文件       |

代码上用一个简单的判断：

```
const isVideoUrl = (url: string) => {

if (url.includes('vweixinthumb')) return false;  // 排除视频缩略图

return url.includes('snsvideodownload') || url.includes('video') || url.includes('.mp4');

};
```

### 请求头伪装

微信的 CDN 会检查 *User-Agent*，普通浏览器 UA 会被拒绝：

```

headers: {

'User-Agent': 'MicroMessenger Client',

'Accept': '*/*',

'Connection': 'keep-alive'

}
```

图片请求可以加  ```Accept-Encoding: gzip, deflate, br```  （CDN 可能对图片做 gzip 压缩返回）。但**视频请求不要加**，视频流通常不压缩，加上可能导致异常。

## 0x02 第一阶段：逆向小白，直接调 DLL

作为一个逆向小白，我最开始的思路非常朴素：**既然微信客户端自己能解密，那我直接调用它的解密函数不就行了？**

### 在 IDA 里找到解密函数

用 IDA Pro 打开 ```Weixin.dll```（约 170MB），基地址 ```0x180000000。```

**第一步：搜字符串。** 在 IDA 的字符串窗口里搜 ```x-Enc``` ，找到它位于地址 ```0x1885282ac``` 。

**第二步：交叉引用。** 右键 → "跳转到交叉引用"，发现有 9 个函数引用了这个字符串。其中 ```sub_1845B0BC0``` 是 HTTP 响应头解析函数：

```

0x1845b1323  lea  rdx, aXEnc        ; "x-Enc"

0x1845b132e  call sub_1826819D0     ; 在响应头中查找

0x1845b1359  mov  [rcx+1428h], al   ; 把结果写到对象 +0x1428 偏移处

```

**第三步：顺藤摸瓜。** 在收包处理函数 ```sub_1845B4360``` 里，找到检查这个标志的代码：

```

0x1845b4473  cmp  byte ptr [rax+1428h], 1   ; 是否需要解密？

0x1845b447a  jnz  loc_1845B4525              ; 不需要就跳过

; ...

0x1845b44f3  call sub_182674280              ; 调用解密函数！

```

就这样，通过 **字符串搜索 → 交叉引用 → 追踪调用链**，定位到了真正的解密函数：```sub_182674280```
，位于 DLL 偏移 ```0x2674280```。

### 解密函数的反编译结果

IDA 反编译后，这个函数其实很短（约 0x134 字节），核心逻辑如下：

```c

// sub_182674280 的简化伪代码

// 参数：rcx=输入缓冲, rdx=长度, r8=输出缓冲, r9=seed(密钥)

void decrypt(uint8_t* input, uint64_t length, uint8_t* output, uint64_t seed) {

uint8_t state[4128];          // 巨大的状态缓冲区

uint64_t keyblock;

init_state(state, &seed, 1);  // 用 seed 初始化状态机

for (int i = 0; i < length; i++) {

if ((i & 7) == 0) {

// 每 8 字节取一次新的密钥块

uint64_t raw = get_next_keyblock(state);

// 注意这里的字节序转换！

keyblock = htonl(hi32(raw)) << 32 | htonl(lo32(raw));

}

output[i] = input[i] ^ ((uint8_t*)&keyblock)[i & 7];

}

}
```

核心就是：**用 seed 初始化一个状态机，持续产生 8 字节密钥流，然后逐字节 XOR。** 标准的流密码结构。

### 用 koffi（FFI）直接调用

既然找到了函数地址，最简单的做法是直接调用它。用 [koffi](https://koffi.dev/)（Node.js 的 FFI 库）加载```Weixin.dll``` :
```

const WEIXIN_DLL_OFFSET = 0x2674280n;

// 加载 DLL，获取内存基地址

const koffi = require('koffi');

const weixinLib = koffi.load(dllPath);

const kernel32 = koffi.load('kernel32.dll');

const getModuleHandleW = kernel32.func(

'void* __stdcall GetModuleHandleW(str16 lpModuleName)'

);

const modulePtr = getModuleHandleW('Weixin.dll');

const base = koffi.address(modulePtr) as bigint;

// 计算解密函数的绝对地址

const decryptAddr = base + WEIXIN_DLL_OFFSET;

// 解码为可调用的函数指针

const addrBox = new BigUint64Array(1);

addrBox[0] = decryptAddr;

const decryptPtr = koffi.decode(addrBox, 'void *');

const decryptProto = koffi.proto(

'uint64 __fastcall SnsImageDecrypt(void* src, uint64 len, void* dst, uint64 key)'

);

const decryptFn = koffi.decode(decryptPtr, decryptProto);

// 调用解密

const out = Buffer.allocUnsafe(data.length);

decryptFn(data, BigInt(data.length), out, parsedKey);

// out 就是解密后的数据
```

### 这种方式的问题

| 问题                | 说明                     |
| ----------------- | ---------------------- |
| **依赖 Weixin.dll** | 用户必须本地安装了微信，且路径可找到     |
| **版本耦合**          | 微信更新后函数偏移可能变化          |
| **平台限制**          | 只能在 Windows 上运行        |
| **安全风险**          | 加载 170MB 第三方 DLL 到自己进程 |
| **黑盒调用**          | 完全不知道算法原理，出问题无法调试      |

## 0x03 第二阶段：搞清楚算法 —— ISAAC-64

### 关键线索：初始化函数里的魔数

深入看 ```sub_1845E3860```（状态机初始化函数），一进函数就看到一组硬编码常量和特征操作：
```c
// 8 个初始变量都被设为同一个值

a = b = c = d = e = f = g = h = 0x9e3779b97f4a7c15;

// mix 函数中的位移操作

a = (a - e);  f ^= (h >> 9);   h = h + a;

b = (b - f); g ^= (a << 9); a = a + b;

c = (c - g);  h ^= (b >> 23);  b = b + c;

d = (d - h); a ^= (c << 15); c = c + d;

e = (e - a);  b ^= (d >> 14);  d = d + e;

f = (f - b); c ^= (e << 20); e = e + f;

g = (g - c);  d ^= (f >> 17);  f = f + g;

h = (h - d); e ^= (g << 14); g = g + h;

```
```0x9e3779b97f4a7c15``` 是黄金比例 φ 的 64 位定点表示。搜索这个常量加上那组位移量 
9, 9, 23, 15, 14, 20, 17, 14，直接命中 —— 这是 **ISAAC-64**。

**ISAAC** 全称 _Indirection, Shift, Accumulate, Add, and Count_，是密码学家 Bob Jenkins 在 1996 年发明的 CSPRNG（密码学安全伪随机数生成器）。ISAAC-64 是它的 64 位版本。

### DLL 函数与 ISAAC-64 的对应关系

| DLL 函数              | 作用            | ISAAC-64 对应                        |
| ------------------- | ------------- | ---------------------------------- |
| ```sub_1845E3860``` | 初始化（含 mix 操作） | ```randinit()```                   |
| ```sub_1845E3430``` | 生成一轮 256 个随机数 | isaac64() 核心循环                     |
| ```sub_1845E33E0``` | 从池中取下一个随机数    | ```rand()```— 逆序消费 ```randrsl[]``` |
| ```sub_1845E36F0``` | 拷贝 seed 入缓冲区  | ```seed()```                       |
| ```sub_182674280``` | XOR 解密循环      | 应用层解密                              |

核心循环 ```sub_1845E3430``` 里最有特征的一段：

```c

// 四步循环，根据 i%4 使用不同位移

case 0: aa = ~(aa ^ (aa << 21)); // 取反 + 左移21

case 1: aa =   aa ^ (aa >> 5);     // 右移5

case 2: aa = aa ^ (aa << 12); // 左移12

case 3: aa =   aa ^ (aa >> 33);    // 右移33
```

对比**ISAAC**原始 C 实现的位移量完全一致。

### 一个容易忽略的细节：字节序

在 ```sub_182674280``` 的 XOR 循环中：

```c

v12 = htonl(HIDWORD(v10));    // 高 32 位 → 大端序

v13 = htonl(v11);              // 低 32 位 → 大端序

v15 = (v13 << 32) | v12; // 重新组合
```

**每个 64 位密钥块在 XOR 之前会被转成大端序（Big-Endian）**。这个细节如果搞错，解密出来就是乱码。

## 0x04 第三阶段：完全独立实现

理解了算法后，就可以彻底摆脱 DLL，用纯 TypeScript 重写。

### ISAAC-64 的 TypeScript 实现

完整实现只有约 130 行代码，核心分三部分：

**1. 初始化** **init()**

```

// 黄金比例 —— ISAAC-64 的签名常量

a = b = c = d = e = f = g = h = 0x9e3779b97f4a7c15n;

const mix = () => {

a = (a - e) & MASK; f ^= (h >> 9n);  h = (h + a) & MASK;

b = (b - f) & MASK; g ^= (a << 9n); a = (a + b) & MASK;

c = (c - g) & MASK; h ^= (b >> 23n); b = (b + c) & MASK;

d = (d - h) & MASK; a ^= (c << 15n); c = (c + d) & MASK;

e = (e - a) & MASK; b ^= (d >> 14n); d = (d + e) & MASK;

f = (f - b) & MASK; c ^= (e << 20n); e = (e + f) & MASK;

g = (g - c) & MASK; d ^= (f >> 17n); f = (f + g) & MASK;

h = (h - d) & MASK; e ^= (g << 14n); g = (g + h) & MASK;

};

for (let i = 0; i < 4; i++) mix(); // 预混 4 轮

// 把种子混入并写入 256 槽的 mm[] 数组

for (let i = 0; i < 256; i += 8) {

a = (a + randrsl[i]) & MASK;  // randrsl[0] = seed

// ... b~h 同理

mix();

mm[i] = a; mm[i+1] = b; /* ... */ mm[i+7] = h;

}
```

**2. 生成随机数** **isaac64()**

```

private isaac64() {

this.cc = (this.cc + 1n) & MASK;

this.bb = (this.bb + this.cc) & MASK;

for (let i = 0; i < 256; i++) {

let x = this.mm[i];

switch (i & 3) {

case 0: this.aa ^= ~(this.aa << 21n); break;

case 1: this.aa ^=  (this.aa >> 5n);  break;

case 2: this.aa ^= (this.aa << 12n); break;

case 3: this.aa ^=  (this.aa >> 33n); break;

}

this.aa = (this.mm[(i + 128) & 255] + this.aa) & MASK;

const y = (this.mm[Number(x >> 3n) & 255] + this.aa + this.bb) & MASK;

this.mm[i] = y;

this.bb = (this.mm[Number(y >> 11n) & 255] + x) & MASK;

this.randrsl[i] = this.bb;

}

}
```

**3. 生成大端序密钥流**

```

public generateKeystreamBE(size: number): Buffer {

const buffer = Buffer.allocUnsafe(size);

for (let i = 0; i < Math.floor(size / 8); i++) {

buffer.writeBigUInt64BE(this.getNext(), i * 8);

}

return buffer;

}
```

## 0x05 图片解密：全文件 XOR

图片的解密最简单——**整个文件每个字节都被 XOR 加密**：

WCDB 数据库
    │  解析 XML → 拿到 url, token, key
    ▼
修正 URL (http→https, /150→/0, 拼 token)
    │
    ▼
HTTPS GET (UA: MicroMessenger Client, Accept-Encoding: gzip/br)
    │
    ▼
解压 gzip/br → 拿到加密的原始数据
    │
    ▼
检查响应头 x-Enc: 1 → 需要解密
    │
    ▼
ISAAC-64(media.key) → 生成与图片等长的密钥流
    │
    ▼
encrypted[i] ⊕ keystream[i] → 解密后的 JPEG/PNG/WebP
    │
    ▼
验证文件头魔数 (FF D8 FF = JPEG, 89 50 4E 47 = PNG, etc.)

核心代码：

```

const wasmService = WasmService.getInstance();

const keystream = await wasmService.getKeystream(key, raw.length);

const decrypted = Buffer.allocUnsafe(raw.length);

for (let i = 0; i < raw.length; i++) {

decrypted[i] = raw[i] ^ keystream[i];

}
```

## 0x06 视频解密：只加密前 128KB

视频解密和图片有三个关键差异。

### 差异一：密钥来源不同

图片的密钥在 ```media[].key```字段里，但视频的密钥**藏在整条动态 XML 的```
<enc key="..." />``` 标签中**，需要正则提取：

```

const extractVideoKey = (xml: string): string | undefined => {

const match = xml.match(/<enc\s+key="(\d+)"/i);

return match ? match[1] : undefined;

};
```

### 差异二：只加密前 128KB

视频文件动辄几十 MB，微信不可能对整个文件做流式 XOR。只加密头部就够了——MP4 的关键元数据（```ftyp```、```moov``` atom）都在前面，头部损坏就无法播放：

```

// 只生成 128KB 密钥流

const keystream = await wasmService.getKeystream(key, 131072);

// 只解密前 128KB（或文件长度，取较小值）

const decryptLen = Math.min(keystream.length, raw.length);

for (let i = 0; i < decryptLen; i++) {

raw[i] ^= keystream[i];

}

// 验证：检查 offset 4 处是否为 'ftyp'

const ftyp = raw.subarray(4, 8).toString('ascii');

if (ftyp === 'ftyp') { /* 解密成功 */ }
```

### 差异三：下载方式不同

图片小，可以在内存里拼接。视频要**先流式写入临时文件**，下载完再读出来解密：

```

// 1. 下载到临时文件

const tmpPath = path.join(os.tmpdir(), `sns_video_${Date.now()}.enc`);

const fileStream = fs.createWriteStream(tmpPath);

res.pipe(fileStream);

fileStream.on('finish', async () => {

// 2. 读出加密数据

const raw = await readFile(tmpPath);

// 3. 解密前 128KB

const keystream = await wasmService.getKeystream(key, 131072);

const decryptLen = Math.min(keystream.length, raw.length);

for (let i = 0; i < decryptLen; i++) {

raw[i] ^= keystream[i];

}

// 4. 写入缓存，删除临时文件

await writeFile(cachePath, raw);

await unlink(tmpPath);

});
```

另外视频请求**不要设置** ```Accept-Encoding: gzip```，视频流不走压缩。

## 0x07 实况照片：图片 + 视频的组合

实况照片本质上是**一张静态图片 + 一段短视频**的组合，分别用各自的逻辑处理。

### 数据结构
```
SnsMedia {
 url: "静态图片 CDN" ← 按图片流程处理
 key: "123456" ← 图片的解密密钥
 token: "xxx"
 livePhoto: {
 url: "视频 CDN" ← 按视频流程处理
 token: "xxx"
 key: (可能为空)
 }
}
rawXml 中:<enc key="2105122989" /> ← 视频的解密密钥
```

### 密钥的优先级

```

// 图片部分：直接用 media.key

imageKey = m.key;

// 视频部分：优先用 XML 提取的 key，其次用 livePhoto 自带的 key，最后用 media.key

videoKey = xmlEncKey || m.livePhoto.key || m.key;
```

### 处理流程
```
实况照片
    │
    ├── 静态图片部分
    │   └── 走图片解密流程（全文件 XOR，key = media.key）
    │
    └── 视频部分
        └── 走视频解密流程（前 128KB XOR，key = XML enc key）
```
## 0x08 三种媒体类型对比

| | 图片 | 视频 | 实况照片 |
| ---------------- | --------------------- | ------------------------- | ------------------------------- |
| **URL 域名** | ```mmsns.qpic.cn``` | ```snsvideodownload``` | 图片 + 视频各一个 |
| **密钥来源** | ```media[].key``` | XML 中 ```<enc key>``` | 图片用 ```media.key```；视频用 XML key |
| **加密范围** | 全文件 | 仅前 128KB | 图片全文件；视频前 128KB |
| **下载方式** | 内存收集 chunks | 流式写临时文件 | 分别处理 |
| **gzip 解压** | 需要 | 不需要 | 图片需要；视频不需要 |
| **URL token 位置** | 追加到末尾 | 放在参数最前面 | 各按类型 |
| **缩略图 → 原图** | ```/150``` → ```/0``` | 不做替换 | 图片替换；视频不替换 |
| **验证方式** | JPEG ```FF D8 FF``` | MP4 ```ftyp``` @ offset 4 | 各自验证 |
| **解密算法** | ISAAC-64 + XOR | ISAAC-64 + XOR | ISAAC-64 + XOR |

**核心解密算法完全一样**——都是 ISAAC-64 生成密钥流然后 XOR。区别只在于密钥来源、加密范围和下载方式。
## 0x09 WASM 加速与 Fallback

BigInt 在 JavaScript 中性能不太好，解密大视频时会比较慢。所以项目中做了三层实现：

```

let keystream: Buffer;

try {

// 第一优先：WASM 版本（C 编译的 ISAAC-64，性能最好）

const wasmService = WasmService.getInstance();

keystream = await wasmService.getKeystream(key, size);

} catch (wasmErr) {

// Fallback：纯 TypeScript BigInt 版本

const isaac = new Isaac64(key);

keystream = isaac.generateKeystreamBE(size);

}

```

WASM 版本通过 Emscripten 编译，在 Node.js 中用 ```vm.createContext```沙箱加载，暴露 ```
WxIsaac64```类调用。

## 后记

本人对于逆向基本是一窍不通 所以本文由我和claude opus 4.6在<a href="elink@810K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6Z5K9h3y4U0j5$3x3%4y4H3`.`.">cc</a>的研究基础上共同完成 感谢阅读到这里

致谢：
<a href="elink@0a8K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6E0M7X3g2^5L8$3c8A6j5g2)9J5c8X3W2V1j5g2)9J5k6s2m8J5L8#2)9J5k6r3#2U0M7l9`.`.">ida-mcp</a> 基于此加上codex5.3对微信朋友圈的加密算法初步了解
---

_本文基于 <a href="elink@8d7K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6Z5K9h3y4U0j5$3x3%4y4#2)9J5c8W2N6W2c8X3I4G2N6H3`.`.">WeFlow</a> 项目的实际开发过程撰写，逆向分析使用 IDA Pro 对 Weixin.dll 进行。_

回复或点赞可查看完整内容

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。

最后于 2026-3-3 00:29 被xunchahaha编辑，原因：

#调试逆向 #加密算法

最新回复 (33) 1 2 ▶
xed 雪币： 64 活跃值： (750) 能力值： ( LV3，RANK：20 ) 在线值：发帖 17 回帖 221 粉丝 4 关注私信	xed 2 楼和视频号一样是isaac64 2026-2-20 14:45 0
wanttobeno 雪币： 6374 活跃值： (3470) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 217 粉丝 3 关注私信	wanttobeno 3 楼感谢你的贡献，论坛因你而更加精彩！ 2026-2-24 11:43 0
xunchahaha 雪币： 247 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 6 粉丝 3 关注私信	xunchahaha 4 楼 xed 和视频号一样是isaac64 并非还是有细微差异 2026-3-3 00:30 0
git_175601972811753 雪币：能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 4 粉丝 0 关注私信	git_175601972811753 5 楼 666 2026-3-3 15:00 0
绿林科技雪币： 19 活跃值： (453) 能力值： ( LV2，RANK：10 ) 在线值：发帖 8 回帖 81 粉丝 5 关注私信	绿林科技 6 楼谢谢分享~ 2026-3-8 04:54 0
zjone 雪币： 217 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 7 粉丝 0 关注私信	zjone 7 楼谢谢分享 2026-3-10 15:48 0
laris 雪币： 400 活跃值： (75) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 5 粉丝 0 关注私信	laris 8 楼感谢分享 2026-3-13 12:46 0
kingking888 雪币： 3235 活跃值： (6337) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 302 粉丝 6 关注私信	kingking888 9 楼 666 2026-3-13 12:57 0
wx_啊啊啊啊雪币： 217 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 44 粉丝 0 关注私信	wx_啊啊啊啊 10 楼感谢分享 2026-3-13 14:07 0
mb_avxhfbwd 雪币： 327 能力值： ( LV1，RANK：0 ) 在线值：发帖 3 回帖 7 粉丝 0 关注私信	mb_avxhfbwd 11 楼求助大佬，安卓微信小程序游戏，号被限制社交了，游戏内赠送道具分享出来的图链接只能分享给自己或文件传输助手，求帮转成明文链接。不白忙活 2026-3-13 16:28 0
mb_weyfdhks 雪币： 259 活跃值： (452) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 25 粉丝 0 关注私信	mb_weyfdhks 12 楼学习 2026-3-14 20:04 0
wx_ㅤCary 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 8 粉丝 0 关注私信	wx_ㅤCary 13 楼学习 2026-3-23 06:39 1
mb_qumjpdob 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 9 粉丝 0 关注私信	mb_qumjpdob 14 楼学习 2026-3-26 15:06 0
mb_mluhxxjd 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 1 粉丝 0 关注私信	mb_mluhxxjd 15 楼感谢大佬分享 2026-3-28 18:48 0
小迷糊ddd 雪币： 268 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 152 粉丝 0 关注私信	小迷糊ddd 16 楼感谢分享，学习一下。 2026-4-8 11:52 0
notregret 雪币： 4419 活跃值： (336) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 2 粉丝 0 关注私信	notregret 17 楼看看是啥 2026-4-12 22:17 0
ammmmo 雪币： 257 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 1 粉丝 0 关注私信	ammmmo 18 楼聊天消息里面的图片、视频、文件是不是也是一样的。目前在手机上hook了消息，但是没实现自动下载这些资源。最后于 2026-4-15 09:59 被ammmmo编辑，原因： 2026-4-15 09:58 0
slan 雪币： 17 活跃值： (980) 能力值： ( LV4，RANK：50 ) 在线值：发帖 12 回帖 51 粉丝 1 关注私信	slan 1 19 楼感谢分享，学习一下。 2026-4-15 14:00 0
mb_ezrxxhss 雪币：能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 3 粉丝 0 关注私信	mb_ezrxxhss 20 楼学习 2026-4-23 15:05 0
wx_Jony_548 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 1 粉丝 0 关注私信	wx_Jony_548 21 楼整体思路是对的，不过我尝试过你这个ts版本算法，获取的随机数貌似是有问题的 2026-4-30 14:38 0
ByboyCn 雪币： 221 活跃值： (134) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 6 粉丝 0 关注私信	ByboyCn 22 楼学习学习 2026-4-30 14:49 0
cecini 雪币： 11 能力值： ( LV1，RANK：0 ) 在线值：发帖 2 回帖 34 粉丝 0 关注私信	cecini 23 楼谢谢分享，为啥格式乱了 2026-5-5 08:06 0
cecini 雪币： 11 能力值： ( LV1，RANK：0 ) 在线值：发帖 2 回帖 34 粉丝 0 关注私信	cecini 24 楼 WCDB数据库是加密的吗 2026-5-5 08:21 0
mb_xzwzvabc 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 9 粉丝 0 关注私信	mb_xzwzvabc 25 楼谢谢分享，为啥格式乱了 2026-5-8 10:54 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复