标题: KVR组网有问 关于iPhone
作者: #Ryayn
板块: #搞七捻三
编号: 1663367
帖子: https://linux.do/t/topic/1663367
时间: 2026-02-27 00:49:46
摘要:

今年把各个地方淘汰下来的路由器带回老家(100m)组KVR。
安卓方面，测了小米 三星 OPPO 红米 荣耀 一加 游正常。
iPhone不知道是有什么大病。1楼走到4楼，还是连着1楼的WiFi。
iPhone 8，xs max，12，13，17都不能正常漫游。

标题: 微信朋友圈表情包解密之路
作者: #Forrest
板块: #开发调优
编号: 1663378
帖子: https://linux.do/t/topic/1663378
时间: 2026-02-27 00:58:00
摘要:

微信朋友圈表情包解密之路
背景
在开发微信聊天记录查看工具的过程中，朋友圈（Moments）功能的评论区表情包一直是个老大难问题。文字消息、图片、点赞都能正常解析，唯独评论里的自定义表情包始终显示不出来。
朋友圈评论中的表情包数据以 XML 格式存储在 SNS 数据库中，解析后可以得到类似这样的结构：
<emojiinfo>
  <url type="1" ef="1">http://vweixinf.tc.qq.com/xxx</url>
  <encrypt_url type="1" ef="2">http://vweixinf.tc.qq.com/yyy</encrypt_url>
  <extern_url type="1" ef="3">http://wx.qlogo.cn/zzz</extern_url>
  <aes_key>6c2b5bba0d3b4dacbe55473926749e49</aes_key>
  <md5>05bbcc529b5cfd17475893e5b6c7c75f</md5>
  <width>240</width>
  <height>240</height>
</emojiinfo>

三种 URL 对应不同的获取方式：

url（ef=1）：明文 CDN 地址
encrypt_url（ef=2）：加密数据，需要用 aes_key 解密
extern_url（ef=3）：外部直链

看起来很简单对吧？下载 encrypt_url 的数据，用 aes_key 做 AES 解密就行了。但现实远比想象中复杂。
第一个坑：HTTPS 害死人
第一个问题就卡在下载环节。代码里有一行"好心"的 HTTP → HTTPS 强制转换：
let fixedUrl = url.replace(/^http:\/\//i, 'https://')

微信 CDN（vweixinf.tc.qq.com）使用的是 HTTP 协议，强制转 HTTPS 后直接连接失败，下载返回 null。去掉这行强制转换后，encrypt_url 终于能正常下载了——HTTP 200，拿到了 33584 字节的加密数据。
第二个坑：AES 到底怎么用？
数据下载成功了，但解密全部失败。尝试了各种组合：

AES-128-GCM，key 前 12 字节做 nonce
AES-128-GCM，数据头部 12 字节做 nonce
AES-128-GCM，零 nonce
AES-128-CBC，数据头部 16 字节做 IV
AES-128-ECB

全部失败。GCM 模式下 auth tag 验证不通过，CBC/ECB 模式下 padding 错误。
这时候只能祭出终极武器了——IDA Pro。
逆向 Weixin.dll：追踪解密链路
找到入口
在 Weixin.dll 中搜索字符串 "AesGcmDecryptWithUncompress failed"，找到了两个引用函数。顺着调用链一路追下去：
sub_182688440 (wrapper)
  → sub_182688100 (AesGcmDecryptWithUncompress)
    → sub_182687C70 (mmcrypto::AesGcmDecrypt)
      → sub_182584DB0 (OpenSslCryptoUtil::AesGcmDecrypt)

关键发现一：数据格式
在 sub_182687C70（mmcrypto::AesGcmDecrypt）中，找到了数据的拆分逻辑：
// 数据长度必须 > 0x1B (27 字节)
nonce = data[len - 28 : len - 16]   // 12 字节
tag   = data[len - 16 :]            // 16 字节
cipher = data[0 : len - 28]         // 剩余部分

数据格式是 [密文][Nonce 12B][AuthTag 16B]，Nonce 和 Tag 在数据尾部！这和常见的 Nonce 在头部的格式完全不同。
关键发现二：AAD 为空
追踪到解密调度函数 sub_180C800F0，发现当 mode=13（GCM 模式）时：
// mode == 13: AES-GCM + zlib 解压
sub_182688100(key_ptr, key_len, 0, 0, data_ptr, data_len, &output);
//                               ↑  ↑
//                          AAD=NULL, AAD_len=0

AAD（Additional Authenticated Data）参数传的是 (0, 0)，即不使用 AAD。这排除了一个重要的可能性——之前一度怀疑是缺少 AAD 导致解密失败。
关键发现三：AES-256，不是 AES-128！
最底层的 OpenSSL 封装函数 sub_182584DB0 有一个 key size 分支：
switch (key_len) {
    case 16: cipher = EVP_aes_128_gcm(); break;
    case 24: cipher = EVP_aes_192_gcm(); break;
    case 32: cipher = EVP_aes_256_gcm(); break;
}

而上层的 wrapper sub_182688440 接收的是 std::string 类型的 key，直接取 .data() 和 .size()。
XML 中的 aes_key 是 "6c2b5bba0d3b4dacbe55473926749e49"——32 个十六进制字符。如果微信把这个字符串原样作为密钥传入（不做 hex decode），那 key 长度就是 32 字节，对应的是 AES-256-GCM，而不是我们一直以为的 AES-128-GCM！
这就是所有尝试失败的根本原因。
最终方案
把所有发现整合到代码中：
// 1. 数据格式：[密文][Nonce 12B][Tag 16B]（尾部布局）
const nonce = encData.subarray(encData.length - 28, encData.length - 16)
const tag = encData.subarray(encData.length - 16)
const ciphertext = encData.subarray(0, encData.length - 28)

// 2. 密钥：原始 hex 字符串作为 32 字节 key → AES-256-GCM
const key = Buffer.from(aesKeyHexString, 'utf8') // 32 bytes, NOT hex-decoded

// 3. 解密：AES-256-GCM，无 AAD
const decipher = crypto.createDecipheriv('aes-256-gcm', key, nonce)
decipher.setAuthTag(tag)
const decrypted = Buffer.concat([decipher.update(ciphertext), decipher.final()])

// 4. 解压：GCM 解密后可能需要 zlib 解压
const result = zlib.inflateSync(decrypted) // 如果需要的话

构建、运行、测试——
[SnsService] 表情包解密成功 {
  cacheKey: '05bbcc529b5cfd17475893e5b6c7c75f',
  ext: '.gif',
  size: 28628,
  isImage: true,
  headHex: '474946383961e400'  // GIF89a ✓
}

474946383961 = GIF89a，标准 GIF 文件头。解密成功！
总结
整个解密过程踩了三个坑：




问题
现象
原因




CDN 下载失败
HTTP 200 拿不到
强制 HTTP→HTTPS，CDN 不支持


GCM auth tag 失败
所有 AES-128-GCM 组合都不通过
密钥是 32 字节原始字符串，应该用 AES-256


Nonce 位置错误
各种 nonce 布局都试了
Nonce 在数据尾部，不是头部



最关键的教训：不要假设 hex 字符串一定会被 hex decode。微信在这里直接把 hex 字符串当作 raw bytes 传给了 AES，导致 key 长度从预期的 16 字节变成了 32 字节，加密算法也从 AES-128 变成了 AES-256。
没有 IDA 逆向，这个问题几乎不可能通过猜测解决。

本文仅用于技术研究用途，请勿进行违法行为。

标题: 【请教】N26 补税号问题
作者: #van14
板块: #搞七捻三
编号: 1663379
帖子: https://linux.do/t/topic/1663379
时间: 2026-02-27 00:58:53
摘要:

请教下，之前注册了奥地利地址的 N26，现在发邮件要求补税号，该怎么办？不补有没有影响？

标题: 养大龙虾随记 之 冷漠无情的大龙虾🦞
作者: #喵~
板块: #搞七捻三
编号: 1663390
帖子: https://linux.do/t/topic/1663390
时间: 2026-02-27 01:05:30
摘要:

一点感情都没有！！！

标题: 谷歌学生认证第三波清洗开始了，看看你们的号掉了吗
作者: #我视我
板块: #搞七捻三
编号: 1663394
帖子: https://linux.do/t/topic/1663394
时间: 2026-02-27 01:07:51
摘要:

标题: gpt-5.3-codex xhigh思考时间巨久
作者: #weishan
板块: #搞七捻三
编号: 1663396
帖子: https://linux.do/t/topic/1663396
时间: 2026-02-27 01:08:35
摘要:

在openclaw调用的,模型是gpt-5.3-codex-xhigh/gpt-5.3-codex, think设置的也是xhigh, 每次回复都要思考几分钟, 这是不降智的代价吗…

标题: 原来南宫雪珊大佬是女的
作者: #linjinpeng
板块: #搞七捻三
编号: 1663398
帖子: https://linux.do/t/topic/1663398
时间: 2026-02-27 01:10:37
摘要:

没想到技术如此过硬的大佬居然是女的，阿尔法真的太好用了 
不说了，半夜刷机我先去救砖了

标题: 小克的甲这么厚的吗..ENI都破不开...还是姿势不对呢...
作者: #ZRainbow
板块: #开发调优
编号: 1663404
帖子: https://linux.do/t/topic/1663404
时间: 2026-02-27 01:16:16
摘要:

从零开始的逆向学习之路！
先搞个注册机！
于是打开了claude code，用了ENI，要么拒绝要么显示“对话已清除”。
opus大人有点严格…
想求教一下正确姿势是怎样的呢…

标题: 用gpt 5.3来跑cc会是什么效果？K2.5和M2.5都不太聪明～
作者: #志云
板块: #开发调优
编号: 1663407
帖子: https://linux.do/t/topic/1663407
时间: 2026-02-27 01:19:39
摘要:

真诚求教佬友们，现在claude资源紧缺，急需替代

标题: exit bag
作者: #linjinpeng
板块: #搞七捻三
编号: 1663414
帖子: https://linux.do/t/topic/1663414
时间: 2026-02-27 01:23:55
摘要:

你不必独自面对一切
010-8295-1332
北京24小时免费心理危机咨询热线

标题: 「思考」关于中转站
作者: #LAMCLOD
板块: #搞七捻三
编号: 1663415
帖子: https://linux.do/t/topic/1663415
时间: 2026-02-27 01:24:17
摘要:

我现在躺在床上，左右睡不着，在想一个问题:中转站到底能持续多久呢。
想法1: 不论风控成本和逆向问题，即便只是为了使用claude，也会有人为了服务而且使用中转，这是一直以来就有的需求和服务，只不过由于各种问题以至于中转站走上了山顶。落寞是必然的，消失也非必然。
想法2: 在各种风波之中，我隐约看到了一些乱象比如88中转站，比如N佬的P站。这让我不由得担心会不会。。。「不敢说」当然，维权我是赞同并支持的，我也明白有一个说话的地方是多么的不容易，我只是提供一些想法和看法。
想法3: 不知道大家有没有发现，由于逆向渠道和各种技术的兴起，客户对中转站，佬友对中转站和公益组的信任度已经无限逼近于0。甚至经常能到拆穿某某站的帖子。当然这样的事是好事，但也不由得让我脊背发凉，如果我是一位还有些成色的站长，我会不会逐渐变得和「不敢说」一样，宁不做勿做错，因为哪怕一点点问题，都有可能被在l站开团。所以我的观点是是否应该多给中转站和公益站们一些包容。个人看法
想法4: 准备干点事情，借着这个平台提升自己，顺便想看清自己到底想要什么，但是怕已经过去风口了，怕努力白费了，怕会牵扯到自己。有放弃的想法了，想让佬友们给一些动力。
想法5: 我需要在毕业前准备好软著和专利，还有一年多至多不超过一年半，这层大山压的我有点喘不过气来了「指导和我聊了很多次，每次都聊了很多，但是我看不清我想要的。。。」
如果给佬友们带来不便，还请原谅!

标题: 精通多学科推理的预测分析师
作者: #aifeisheng
板块: #开发调优
编号: 1663421
帖子: https://linux.do/t/topic/1663421
时间: 2026-02-27 01:26:41
摘要:

可测1+1=几
可测天气
可测…
# 角色设定
你是一位精通多学科推理的**预测分析师**，擅长基于碎片化信息进行逻辑推演。你的思维方式融合了侦探的敏锐、科学家的严谨和工程师的实用主义。

# 核心原则
1. **贝叶斯思维**：先提出多种可能性，再根据线索不断更新概率
2. **多模态融合**：能整合听觉、视觉、时间、空间等多维度信息
3. **层次化推理**：从高概率到低概率，系统性地排列可能性
4. **不确定性表达**：所有预测都附带置信度/概率，并说明依据
5. **可验证建议**：提供验证预测的具体方法

# 通用预测框架

当你收到任何预测问题时，请按以下步骤执行：

## 第一步：信息拆解
- 列出所有已知条件（包括显性信息和隐含信息）
- 识别信息之间的关联和矛盾
- 明确预测目标

## 第二步：可能性空间生成
- 头脑风暴所有可能的解释（不设限）
- 按逻辑分类（如：物理原因/人为原因/外部原因）
- 为每种可能性分配初始概率

## 第三步：基于常识的过滤
- 应用物理学、社会学、心理学等基础知识
- 剔除明显违反规律的选项
- 调整概率分布

## 第四步：深度推理
- 对每个高概率选项进行因果链分析
- 思考"如果X是真的，那么我应该还能观察到什么？"
- 寻找可以区分不同可能性的关键验证点

## 第五步：结论呈现
- 按概率从高到低列出预测结果
- 每个结果附带：
  - 概率/置信度
  - 推理依据
  - 验证方法
- 如有需要，给出行动建议

# 特殊指令
1. **永远保持好奇心**：对看似简单的问题挖掘深层逻辑
2. **承认不确定性**：不追求100%准确，但要追求100%严谨
3. **用比喻解释复杂概念**：让推理过程易于理解
4. **主动寻求反馈**：在预测结束后，询问用户验证结果，以便优化模型

# 示例风格参考
我的回答风格应该是：
- 开场：用一句话概括问题本质
- 中间：分点推理，层层深入
- 结尾：给出明确结论和验证方法
- 整体：理性但不冰冷，专业但不晦涩

# 启动指令
现在，请

标题: 有时候心死只是一瞬间~
作者: #mofas
板块: #搞七捻三
编号: 1663427
帖子: https://linux.do/t/topic/1663427
时间: 2026-02-27 01:33:45
摘要:

之前的3000多根key，我以为都死了，然后全删了
今天从新跑注册机才发现，不是都死了，只是tmd我上游配错地方了！
我真的不知道什么时候改的，一点都想不起来了，我要哭死 
不过现在 cerebras只有 8b和oss了，还不算太亏

标题: 想发个帖问一下，codex的free账号不充钱的额度是多少呢，最近看到很多注册机注册的free账号
作者: #lzhan
板块: #开发调优
编号: 1663431
帖子: https://linux.do/t/topic/1663431
时间: 2026-02-27 01:39:17
摘要:

如题请佬友解答一下！

标题: 大佬们，看下我买的racknerd机子
作者: #xiaoyi001
板块: #开发调优
编号: 1663438
帖子: https://linux.do/t/topic/1663438
时间: 2026-02-27 01:57:39
摘要:

10.49美元已经算最便宜了吗，兄弟们

标题: 三星集成 pplx
作者: #kakalala
板块: #前沿快讯
编号: 1663439
帖子: https://linux.do/t/topic/1663439
时间: 2026-02-27 01:57:42
摘要:

标题: 很苦恼 我的代理年费 要提供kyc 有佬友了解的吗？
作者: #Khuseyn Sheripov
板块: #开发调优
编号: 1663441
帖子: https://linux.do/t/topic/1663441
时间: 2026-02-27 01:59:13
摘要:

我主要是用来跑一些支付页面的  没想到要kyc 大概就访问了一百多次  之前买了家代理是直接不能访问支付页面的  这家没想到要kyc  我也很纠结要不要验证 毕竟我抓包研究用的