# WeChat Message Sending — Attack Surface Analysis

Date: 2026-06-30
WeChat: 8.0.74, Android 16, Magisk root
Context: After completing XHS BCIM architecture analysis, user wants same framework applied to WeChat.

## 1. Architecture

```
Java UI: ChattingUI (message compose → send)
    ↓
Java Storage: EnMicroMsg.db message table (status: sending)
    ↓
JNI Bridge: libMMProtocalJni.so (serialize + encrypt)
    ↓
mars Framework (C++ native):
    libmarscomm.so     — task dispatch, STN queue
    libmarsquic.so     — QUIC long connection
    libproto.so        — protobuf encode/decode
    libMMProtocalJni.so — JNI entry point
    ↓ TCP/QUIC → WeChat Server
```

**Protocol**: Protobuf over mars long connection, ECDH key exchange + AES encryption.
**Key difference from XHS**: mars is C++ native (not Java), protobuf (not JSON), encrypted (XHS BCIM isn't).

## 2. Local Assets Available

| Asset | Path | Status |
|-------|------|--------|
| EnMicroMsg.db | `/MicroMsg/<hash>/` 20MB | SQLCipher encrypted |
| UIN | `auth_info_key_prefs.xml` | Extracted |
| Auth Key | `auth_info_key_prefs.xml` | Protobuf binary |
| mars config | `files/XNetLib/` | Present |
| APK | `/data/app/.../base.apk` | Extractable |
| Native libs | `libmarscomm.so, libmarsquic.so, libMMProtocalJni.so, libproto.so` | Symbol analysis possible |

## 3. Attack Vectors (ranked by feasibility)

### Path A: Database Injection ⭐ Most Promising

**Hypothesis**: WeChat stores pending messages in EnMicroMsg.db before mars picks them up.
INSERTing a row with status=sending may trigger mars to send it automatically.

**Steps**:
1. Copy + decrypt EnMicroMsg.db
2. Inspect message table schema for status/send_state columns
3. INSERT test message row
4. Monitor if mars picks it up (check status change or network activity)

**Risk**: mars may verify message origin, but historical WeChat versions had this vulnerability.

### Path B: LSPosed Java Hook (xhshook pattern)

**Target classes** (based on known WeChat structure):
- `com.tencent.mm.model.c` — core message handler
- `com.tencent.mm.plugin.messenger.foundation.a.a.j` — send interface
- Note: heavily ProGuard-obfuscated, class names are single letters

**Advantage**: xhshook v3 framework proven, only need to find hook point.
**Disadvantage**: Needs jadx decompilation first; class names obfuscated.

### Path C: mars Task Queue Injection

Hook native `mars::stn::NetSource::StartTask()` to inject serialized protobuf tasks.
**Requires**: protobuf schema reverse engineering, Frida native hook.
**Difficulty**: High — C++ native, protocol may change.

### Path D: HTTP Fallback API

WeChat uses HTTPS for CDN/assets. If message send has HTTP fallback, bypass mars entirely.
**Verification**: jadx decompile + xhshook capture.
**Likelihood**: Low — core messaging is mars-only by design.

### Path E: Full Protocol Reverse Engineering

Hook `libMMProtocalJni.so` → capture proto before encryption → reverse schema → build messages.
**Obstacles**: WeChat anti-Frida (more mature than XHS libsentry), frequent proto changes.

## 4. Recommended Execution Order

```
Step 1: Decrypt EnMicroMsg.db → inspect message table for sending queue (30 min)
   ↓ IF DB injection works
Step 2: INSERT test message → verify send (1 hour)
   ↓ ELSE
Step 3: jadx decompile → find Java send entry → xhshook hook (days)
```

## 5. Comparison: XHS BCIM vs WeChat mars

| Aspect | XHS 私信 | WeChat 消息 |
|--------|----------|-------------|
| Transport | Longlink (Java) | mars (C++ native) |
| Encoding | JSON | Protobuf |
| Encryption | None extra | ECDH + AES |
| OkHttp blind | ✅ | ✅ |
| DB injection | Low (WCDB checks) | Medium (history) |
| Community docs | Almost none | Some (mars open-source) |
| Anti-tamper | libxyass + libsentry | More sophisticated |
| Hook surface | Java BCIMClientAdapterImpl | JNI + C++ native |

## 6. Key File Paths (for future jadx)

```
com/tencent/mm/model/c.java              — core message
com/tencent/mm/modelmulti/               — message sync
com/tencent/mm/plugin/messenger/          — messenger plugin
com/tencent/mm/protocal/                 — protocol layer
com/tencent/mm/network/                  — networking (Java side)
```

## 7. mars Open-Source Reference

mars is open-source: https://github.com/Tencent/mars
Key components:
- `mars::stn` — Short Network Task (STN) module
- `mars::comm` — common utilities, message queue
- `mars::cdn` — CDN module (used for image/file upload)
- `mars::app` — application layer callbacks

Understanding mars source helps identify hook points in WeChat's compiled libs.

## 8. DEX Analysis Results (WeChat 8.0.74 Tinker patch, classes12.dex)

From `analyze_wechathook.py` run on 2026-07-03:

**gm0.j1** — DI container singleton:
- Static field `m: Lgm0/j1;` — the singleton instance
- `gm0.j1.i() → Lgm0/j1;` — SINGLETON ACCESSOR (sget-object on field m).
- `gm0.j1.g(Lkm0/c;)V` — init method. Hooked but **never fires** in 8.0.74.

**w11.r0** — NOT the real send path:
- Constructors: `(String,String,int,int,long)` and `(String,String,int,int,Object)`
- Never called by WeChat itself during normal send.
- Calling manually: NPE in main process, "Kernel not initialized" elsewhere.

**sk.p0(String,int,String)** — REAL send entry:
- `com.tencent.mm.ui.chatting.component.sk` — SendTextComponent
- Needs `d` field (Lyb5/d chat context) initialized — unavailable without ChattingUI open.
- Full analysis: `frida-android-setup` → `references/wechat-internal-send-api.md`

## 9. WeChat Restart Pitfall

**Do NOT force-stop or restart WeChat without explicit user permission.**
`am force-stop` + `am start` kills the login session. WeChat requires re-authentication
after restart. If using LSPosed module for tablet/alternate login, session loss means
manual re-login. Before any action that might restart WeChat, ask the user.