请教：lingma 的 encode/decode 和签名算法是通过什么方式逆向出来的？

[coolxll]

你好，想请教一下：

lingma 的以下内容是通过什么方式逆向出来的？

1. encode/decode 算法（自定义 Base64 字母表 + 重排逻辑）
2. 签名算法（Bearer COSY.{payload}.{sig} 的计算方式）

具体是：

• 抓包分析：拦截请求/响应，通过黑盒测试推导
• 静态逆向：反汇编/反编译二进制，还原函数逻辑
• 还是两者结合？

感谢分享经验！

[cubk1]

逆向的Qoder CLI，这个东西是Go写的，很多字符串和Metadata没擦除

[coolxll]

请教一下，我目前在分析 Trae CN 的跨进程通信（IPC）机制，目标是实现第三方客户端对本地 ai_agent.dll 的 AI 能力复用。目前遇到了一些非常棘手的困难点：

1. 虽然在 JS 侧看到了类似 model, chat 等服务的引用，但它们到底是怎么通过 ZeroMQ 进行通信的，我目前完全没搞定，抓包和链路分析都卡住了。
2. JS 侧混淆非常严重（数十万行单行代码），定位 ZMQ 客户端初始化逻辑极具挑战。
3. ai_agent.dll 类似于通义灵码的一个 sidecar（不过灵码是 Go 写的，而 Trae 的这个 sidecar 是 Rust 写的），集成了字节内部的 TTNet 协议栈，最终通信还走了特定的通信 DLL。
4. 鉴权凭证 x-ide-token 的生成逻辑也疑似深嵌在 native 层，静态模拟很困难。

目前我初步判断主攻方向应该是 Frida 动态 Hook 或者 IDA Pro 静态/动态分析。另外我也在想是不是该从 Trae CLI 入手？但 Trae CLI 似乎仅对企业用户开放，鉴权体系可能和 IDE 这一套不一定是一回事。

补充一些目前的分析发现：

• IPC 架构：基于 @aha-kit/ipc (ZeroMQ Router-Dealer)，Windows 下走 Named Pipe。
• Native 栈：aha_net.dll 负责自定义 fetch，trae-network-node.node 集成了 ZmqClient 和字节内部 TTNet 协议。
• Electron 定制：preload.js 导出了非标准的 ahaIpc 模块，怀疑是直接魔改了 Electron 源码。

看到大佬之前分析过 Qoder CLI，不知道在处理这类复杂的 sidecar 架构、ZMQ 通信以及混淆时，在 Frida 或 IDA 分析方面有没有什么经验或者类似的思路可以指导一下？

[coolxll]

另外补充个题外话，之前基于大佬分享的 Qoder 解码逻辑，我搞了个 lingma-tap，因为发现通义灵码和 Qoder 居然复用了同一套加解密逻辑。再次感谢大佬之前的分析分享！

[iamsxm]

两位大佬，借地请教个东西：我目前通过适配openai的v1/responses接口，能在codex中响应回答了，但是工具调用好像有问题，这方面是否有思路呢

[coolxll]

两位大佬，借地请教个东西：我目前通过适配openai的v1/responses接口，能在codex中响应回答了，但是工具调用好像有问题，这方面是否有思路呢

可以先用 cc-switch 的整流器，用 chat/completions 接口先用着吧

[cubk1]

没接触过Electron，但是如果 native 没壳或者是 go 这种逆向比较友好的语言写的话那一般来说搜字符串也能搜出来了，cpp 和 rust 的话有点难，而且 trae 也不提供很高级的模型我感觉研究出来也没啥用…

[coolxll]

没接触过Electron，但是如果 native 没壳或者是 go 这种逆向比较友好的语言写的话那一般来说搜字符串也能搜出来了，cpp 和 rust 的话有点难，而且 trae 也不提供很高级的模型我感觉研究出来也没啥用…

lingma和qoder 拿到OAuth 交换真实凭据这块的逆向有做吗？ 想搞成类似CLIProxyAPI一样，直接在服务端OAuth了

[cubk1]

这个是网页上的API吧，又不难做
抓个包的事情

[coolxll]

这个是网页上的API吧，又不难做 抓个包的事情

callback 里的要去换Credentials，但我本地生成的cosyKey 服务器好像不认 ，抓包什么grantAuthInfo，该走的接口都走过了