标题: WorkBuddy信封中的AES-256-GCM 创建: 2026-11-09 13:06 更新: 链接: https://scz.617.cn/misc/202611091306.txt https://mp.weixin.qq.com/s/CaFM1JcI2ne__lpJs8PQCg 以Windows版WorkBuddy为例 %LOCALAPPDATA%\CodeBuddyExtension\Data\Public\auth\workbuddy-desktop.info 此文件以json格式存放WB登录态信息,某些字段加密存放,降低直接暴露的风险。比 如WB登录时用的手机号,经AES-256-GCM加密存放。 { "account": { "uid": "...", "phoneNumber": { "$wbEncrypted": 1, "envelope": "eyJzdWl0ZSI6MSwia2V5SWQiOiIyMjIyMjIyMjIyMjIyMjIyIiwibm9uY2UiOiJFUkVSRVJFUkVSRVJFUkVSIiwiYXV0aFRhZyI6ImljU0tDU1cyNk9Jbko1NGpqUWgzWWc9PSIsImNpcGhlcnRleHQiOiJsVHdKMk8ydEFtUDNrL1k9In0=" }, envelope字段并不直接对应密文,对之BASE64解码并美化后,形如 { "suite": 1, "keyId": "2222222222222222", "nonce": "ERERERERERERERER", "authTag": "icSKCSW26OInJ54jjQh3Yg==", "ciphertext": "lTwJ2O2tAmP3k/Y=" } suite、keyId用于组装参与加解密运算的Additional Authenticated Data (AAD)。 AAD的结构形如 "WB-AAD\0" | 0x01 | LP("WBEV1") | LP("sym-v1") | suite | LP(keyId) | framingCode | 0x00 | 0x00 在当前上下文中,framingCode恒为2,表示AAD绑定登录态文件的单个字段。于是AAD 只受suite、keyId影响,它们是已知的。从前述envelope组装出AAD 57422d41414400010000000557424556310000000673796d2d7631000000010000001032323232323232323232323232323232020000 00000000 57 42 2d 41 41 44 00 01 00 00 00 05 57 42 45 56 |WB-AAD......WBEV| 00000010 31 00 00 00 06 73 79 6d 2d 76 31 00 00 00 01 00 |1....sym-v1.....| 00000020 00 00 10 32 32 32 32 32 32 32 32 32 32 32 32 32 |...2222222222222| 00000030 32 32 32 02 00 00 |222...| nonce对应AES-256-GCM的IV,envelope中nonce是HEX的BASE64形式。 AES-256-GCM加密时需要 protectorKey 0000000000000000000000000000000000000000000000000000000000000000 nonce 111111111111111111111111 suite 1 keyId 2222222222222222 AAD 57422d41414400010000000557424556310000000673796d2d7631000000010000001032323232323232323232323232323232020000 plaintext 13800000000 WorkBuddy.exe内嵌经混淆存放的atRestSecretKey,PE自己知道怎么还原它,社区有 现成方案。 对atRestSecretKey求SHA-256,得到protectorKey。不要对atRestSecretKey进行 BASE64解码,要直接求SHA-256。 上例只是演示说明,所以用了全0的protectorKey。加密后得到两个值 ciphertext 953c09d8edad0263f793f6 authTag 89c48a0925b6e8e227279e238d087762 将nonce、ciphertext、authTag从HEX转成BASE64 nonce ERERERERERERERER ciphertext lTwJ2O2tAmP3k/Y= authTag icSKCSW26OInJ54jjQh3Yg== 即envelope中的形式 AES-256-GCM解密时需要 protectorKey 0000000000000000000000000000000000000000000000000000000000000000 nonce ERERERERERERERER AAD 57422d41414400010000000557424556310000000673796d2d7631000000010000001032323232323232323232323232323232020000 authTag icSKCSW26OInJ54jjQh3Yg== ciphertext lTwJ2O2tAmP3k/Y= 解密时会新算一份authTag,与解密前提供的authTag相比较,不匹配则不交付明文, 解密失败。 用CyberChef测试 -------------------------------------------------------------------------- From Base64 lTwJ2O2tAmP3k/Y= // ciphertext AES Decrypt Key (HEX) 0000000000000000000000000000000000000000000000000000000000000000 // protectorKey IV (BASE64) ERERERERERERERER // nonce Mode GCM Input Raw Output Raw GCM Tag (BASE64) icSKCSW26OInJ54jjQh3Yg== // authTag Additional Authenticated Data (HEX) // AAD 57422d41414400010000000557424556310000000673796d2d7631000000010000001032323232323232323232323232323232020000 IV from input Off 输出 13800000000 -------------------------------------------------------------------------- 从解密过程看,envelope解码后所有字段都派上用场,suite、keyId用于组装AAD, 并非无用。 尽管CyberChef解密时要求提供authTag,但此字段对我们这种上下文没啥必要性。因 为已知protectorKey、nonce、AAD、ciphertext的情况下,可计算出authTag。不过 CyberChef并未提供针对这种情形的菜谱。