Windows: key scan returns 0 keys for Weixin 4.1.10.53 / 4.1.11.55 — flue.dll instead of WeChatWin.dll?

[agemoo]

Environment
OS: Windows 10 amd64
wechat-cli version: v1.6.20 (installed via release zip + install.ps1)
WeChat version: tried both 4.1.11.55 and 4.1.10.53
Install path: D:\Weixin
Data path: D:\WeChat\xwechat_files<wxid>
DB count: 25 .db files under db_storage/ (message_0~3, session, contact, etc.)
WCDB: available (status reports wcdb.available: true)

What I did
[Environment]::SetEnvironmentVariable("WECHAT_CLI_DB_ROOT", "D:\WeChat\xwechat_files<wxid>", "User")
wechat-cli.exe cache refresh --force

Expected
Keys extracted, metadata cache built, sessions returns results.

Actual
{
"ok": false,
"error": {
"code": "tool_error",
"message": "wxkey setup failed: no usable Windows WeChat raw keys found after scanning 5 process(es)..."
}
}

wechat-cli status shows readiness: blocked, blocked_by: key_config_missing.

What I've tried
✓ Confirmed WeChat is logged in and a chat window is open
✓ WECHAT_CLI_DB_ROOT points to the correct account directory (verified by cache status showing source_db_count: 25)
✓ Tried specifying WECHAT_CLI_WECHAT_PID to each of the 14 WeChat-related processes (5x Weixin.exe + 9x WeChatAppEx.exe) — all return 0 keys
✓ Tried with admin privileges
✓ Set WECHAT_CLI_KEY_SCAN_TIMEOUT=5m
✓ Downgraded WeChat from 4.1.11.55 to 4.1.10.53, re-logged in, re-tried — same result

Additional context
The WeChat 4.x installation on this machine does not have WeChatWin.dll. The main process modules include a 215 MB flue.dll instead. Other tools (wx-cli, PyWxDump) also fail because they hardcode WeChatWin.dll in their memory scan — but I assumed wechat-cli handled this since it correctly identifies the 25 source databases.

Logs
[2026-07-21T10:24:02.9848580Z] [wechat-cli] no schema-2 DB keys cached — running wxkey key setup...

No further diagnostic output available.

Happy to provide any additional debug info — let me know what you need.

[r266-tech]

Thanks for the detailed report. I checked the source shipped in v1.6.20. Direct answer: the Windows scanner does not look for or hard-code WeChatWin.dll. By default it selects Weixin.exe/WeChat.exe processes (or the exact PIDs supplied through WECHAT_CLI_WECHAT_PID). For each selected PID, it walks the virtual address space and attempts to read regions that are committed and not marked NOACCESS or GUARD. It does not enumerate or filter modules, so pages mapped from flue.dll are eligible when they are inside a selected process and ReadProcessMemory can read them; that does not guarantee every page is readable.

The current scanner is narrower in a different way: scanRawKeyLiterals only recognizes the exact ASCII form x'<64 hex key><32 hex salt>', then verifies each candidate against the corresponding source DB. It does not hook or reconstruct the key-derivation path inside flue.dll.

Your source_db_count: 25 and wcdb.available: true make a DB-root or WCDB discovery problem less likely. Testing explicit Weixin.exe and WeChatAppEx.exe PIDs, administrator access, and a longer timeout also makes the most obvious process-selection and time-budget explanations less likely. But zero verified keys does not yet identify the exact failure stage: relevant pages may not be readable; the expected literal may never materialize, may be transient and disappear before scanning, or may use a different representation; a literal's salt may not match the target salts read from the discovered DBs; or candidates may fail DB verification. #14 covers the same Windows scanner subsystem as #8 and may be related, but a shared root cause is not proven. The observed behavior is distinct: #8 recovered some keys on 4.1.10.52, while this report recovers none on 4.1.10.53 and 4.1.11.55.

Those two versions are useful additional evidence, and additional broad PID retries are unlikely to add much signal. Please do not upload raw keys, process dumps, DB files, or chat data publicly. The next useful maintainer step is sanitized scanner instrumentation that records counts and failure categories only. It must never log candidate bytes, keys, salts, DB contents, wxids, or full local paths.

One privacy note: the issue body currently includes a full wxid/account directory and local paths. Please edit those to placeholders such as <wxid> and D:\...\<account>; the exact values are not needed to investigate this, although GitHub may retain revision history.

We'll keep this issue open as an unconfirmed affected-version report for the complete zero-key behavior on 4.1.10.53/4.1.11.55; #8 remains the partial-key report for 4.1.10.52. Because the scanner does not filter on DLL names, a WeChatWin.dll/flue.dll filename switch alone would not address the observed result. The exact fix depends on identifying the failed stage above.

[agemoo]

Thanks for the detailed analysis! That rules out the DLL name theory. I've edited the issue to replace the wxid and paths with placeholders.

Looking forward to the instrumented scanner. Let me know if there's any other diagnostic info I can provide to help narrow this down.