修复假群主导致的消息乱码

[starmiaoa]

概要

• 撤回 FunProtoData 中无法彻底区分文本、bytes 和子消息的启发式修改
• 按“加密抄送”的思路，改用 UnknownFieldSet 只修改假群主需要的 protobuf 路径：3 → 1 → 2[] → 37 → 19 → 4 = 300
• 未修改的消息元素直接复用原始 ByteString，不再经过 JSON 或递归 protobuf 往返，避免 ui。、95 等内容被重编码
• repeated 字段会全部遍历；同字段号的其他 wire type 会保留；目标 37/19 损坏时整包不改
• 识别并重建原有四字节长度头

发送流程

假群主仍在 QQMsfReqHandler/sendToMSF 阶段处理，但不再取消原请求或另发新包。只有完整构造成功后才调用一次 ToServiceMsg.putWupBuffer()，然后继续交给 QQ 后续原生编码和签名流程。

加密抄送是在更晚的 nativeEncodeRequest 阶段改包，所以需要 FEKit 重签；假群主的拦截点更早，因此不需要扩大到 QQHookCodec，也不会要求用户开启存在检测风险的 Codec hook。

验证

• :app:testDebugUnitTest 通过
• :app:assembleRelease 通过
• 单测覆盖 ui。、95、9号还是10号?、emoji、合法 protobuf 形状的不透明 bytes、混合 wire type、repeated、损坏的 37/19 和长度头

[KyuharuTE]

你这样改应该没办法彻底修复，想修复最好换成和加密抄送一样的方式

[starmiaoa]

你这样改应该没办法彻底修复，想修复最好换成和加密抄送一样的方式

我等会看看

[starmiaoa]

已按建议重做：现在和加密抄送一样使用 UnknownFieldSet 局部重建目标 protobuf，不再修改公共 FunProtoData，也不再做整包 JSON 往返。

这里保留了原来的 sendToMSF 拦截点，但只在完整构造成功后替换原 ToServiceMsg.wupBuffer，让 QQ 后续原生编码/签名流程继续处理；没有取消请求、没有另发包，也没有引入 QQHookCodec 的检测风险。

未修改的消息元素会直接复用原始 ByteString。repeated、混合 wire type、损坏的 37/19 和四字节长度头也补了处理与单测。testDebugUnitTest 和 assembleRelease 均已通过，麻烦再看一下。

[KyuharuTE]

你直接替换了吗？测试了没有？我记得qq走到这里就已经签名完了吧，签名不对发不出去的

[starmiaoa]

你直接替换了吗？测试了没有？我记得qq走到这里就已经签名完了吧，签名不对发不出去的

等下，这个是我让codex改的 我没注意，他改完直接替换pr了，我还没进行审查与测试 请稍等下

[starmiaoa]

本评论由 Codex 自动发送。

根据前面的审查和 QQ 9.2.95 实测，已将假群主改为更窄的原生发送链路：

• 在主进程 sendToMSF 入口只对目标 protobuf 做 UnknownFieldSet 局部重建，保留未修改字段和原始消息元素。
• 不直接覆盖已经签名的原请求；取消原请求后，构造带修改后 payload 的新 ToServiceMsg，交给 QQ 原生 sendToService 重新编码和签名。
• 为重发包加入一次性标记，避免再次进入假群主拦截器形成循环。
• 不再要求开启 CodecWarpper，避免 QQ 9.2.95 的全局 Codec hook 影响登录和收消息。

验证结果：

• :app:testDebugUnitTest 通过。
• :app:assembleRelease 通过。
• BlueStacks Android 9 + QQ 9.2.95 测试通过，发送测试文本后无 EOFException、重发异常或崩溃。
• Codec 关闭时假群主正常加载；单独开启 Codec 会复现 QQ 的 EOFException，因此没有把该依赖带入修复。

补充：BlueStacks 当前是 Android 9，而 ONO 设置 Activity 的最低 API 是 Android 10；设置页在该模拟器上崩溃属于测试环境兼容性问题，不是本 PR 的 protobuf 修改。

[starmiaoa]

你直接替换了吗？测试了没有？我记得qq走到这里就已经签名完了吧，签名不对发不出去的

改了一下,模拟器测试了下没什么问题 我这边环境暂时上不了实体机,可能得需要等到8月我才有测试环境