From f458873a82fee1e488d291060d80f17bd2b3a775 Mon Sep 17 00:00:00 2001 From: colin4k Date: Tue, 14 Apr 2026 14:17:54 +0800 Subject: [PATCH] fix(keys/macos): report correct key count after init MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The C binary `find_all_keys_macos` writes entries as `{"rel/path.db": {"enc_key": "..."}}` without a `salt` field, but `scanner_macos.py` built `key_map` by filtering on both `enc_key` AND `salt`, so the map was always empty and init reported "提取到 0 个密钥" despite `all_keys.json` being written correctly. Downstream lookups (`get_key_info`) already key by rel_path, so the file itself was usable — this was purely a misleading display bug that made users think key extraction had failed. Build the map keyed by rel_path instead. --- wechat_cli/keys/scanner_macos.py | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/wechat_cli/keys/scanner_macos.py b/wechat_cli/keys/scanner_macos.py index ea316ee..5508acb 100644 --- a/wechat_cli/keys/scanner_macos.py +++ b/wechat_cli/keys/scanner_macos.py @@ -212,11 +212,11 @@ def extract_keys(db_dir, output_path, pid=None): if os.path.abspath(c_output) != os.path.abspath(output_path): os.remove(c_output) - # 构建 salt -> key 映射 + # 构建 rel_path -> key 映射（C 二进制仅写入 enc_key，不带 salt） key_map = {} for rel, info in keys_data.items(): - if isinstance(info, dict) and "enc_key" in info and "salt" in info: - key_map[info["salt"]] = info["enc_key"] + if isinstance(info, dict) and "enc_key" in info: + key_map[rel] = info["enc_key"] print(f"\n[+] 提取到 {len(key_map)} 个密钥，保存到: {output_path}") return key_map