QQ Bot的未来以及迁移建议

[Mrs4s]

由于QQ官方针对协议库的围追堵截 持续👊🐔 , 不断更新加密方案, 我们已无力继续维护此项目.
在未来 sign-server 方案彻底被官方封死之后 go-cqhttp 将无法继续使用.
同时NTQQ的出现让我们可以使用官方 完美 实现的协议实现来继续开发Bot, 不再担心由于协议实现不完美而导致被识别.
我们建议所有QQBot项目开始做好迁移至无头NTQQ或类似基于官方客户端技术的准备以应对未来的彻底封锁,
如果你的 go-cqhttp 还能继续使用, 不建议立即迁移, 但请开始阅读相关文档并做好迁移准备

推荐项目:
如果你想在电脑/服务器上部署bot -> https://chronocat.vercel.app/blog/0050
如果你想在Android 手机/模拟器上部署bot -> https://github.com/linxinrao/Shamrock
以上项目均为调用官方协议实现
以上项目均被请喝茶了，只能说有缘再见了.

相关问题可以在这个issue下讨论

协议库的时代已经过去, 接下来是Hook官方客户端的时代了, 感谢大家三年来的支持

其实go-cqhttp项目最初只是想做一个能在路由器上跑的酷Q

——————————————————————
什么是无头NTQQ?

众所周知, QQ官方最新推出的 NTQQ 客户端使用了 electron 技术, 该技术可以非常方便的跨平台同时使用前端已有的技术栈进行客户端开发.
NTQQ 客户端项目分为前后端两个部分, 前端是使用 Web 技术开发的 UI 界面供用户交互，后端使用 nodejs addons 技术包装了一个库来处理客户端逻辑和与服务端通信 (wrapper.node).
这个库的作用和 go-cqhttp 非常相似, 所以我们完全可以将前端删除只与这个库交互, 并引出 API 来为我们的Bot服务.
从服务端视角来说我们的 Bot 和正常客户端一样, 因为都是通过 wrapper.node 与服务端通信. 并且由于是官方根据内部文档开发的模块, 我们可以说这是一个 完美 的 go-cqhttp.

优点: 无头模式下相对低的占用.
缺点: 可能会受未来QQ更新的影响.

Shamrock项目是什么原理?

Shamrock 项目使用 xposed 的 hook 技术来实现远程操作 AndroidQQ 客户端.
优点: 不容易受未来更新封堵的影响.
缺点: 需要运行一个完整 AndroidOS 环境.

如果你的服务器资源足够充足, 我个人建议观望并跟进 Shamrock 项目. xposed 是久经考验且生态完善的技术.

[yihanxx]

我的青春结束了

[fumiama]

😭😭😭😭

[Special-Week]

呜~苦露西

[Akegarasu]

我的青春

[X-Zero-L]

[ishkong]

/(ㄒoㄒ)/~~

[ishkong]

[Anillc]

[SaarChaffee]

辛苦了

[YumeMichi]

感谢~

[shigma]

go-cqhttp 项目标志着 QQ 机器人的一个时代。

我有幸亲眼见证了 go-cqhttp 从诞生到发展的所有历史节点。go-cqhttp 诞生时 CoolQ 还没有退场，那个时候机器人圈闭源横行。是 go-cqhttp (和 mirai) 推动了整个社区的开源化，并孵化出欣欣向荣的众多框架。作为一位开源开发者，我由衷的感谢 go-cqhttp 的每一位开发者为生态做出的贡献。

这些年辛苦了。

[Faultiness]

又一个时代的落幕... 祝好😢

[wfjsw]

昵昵贴贴

[lulu666lulu]

我们无以为报，唯有祝福，唯有祈愿。

[HMScygnet]

感谢你们的付出

[TheSnowfield]

爺青結

[jiangyin14]

之前unidbg-fetch-qsign出现的时候我就有预感，感觉官方下力度了，协议库要废了...
我订阅了所有gocq的issue，刚刚突然看到Github给我邮箱推送的信息，全都是“祝好”一类的，就慌了，打开一看，我不希望的事情确实已经发生了
愿在以后的QQNT项目中还能看到您的身影，这些年辛苦了，祝好。

[bobandbrony]

是一个时代的结束，也是另一个时代的开端，希望ntqq加把劲！

[liggest]

感谢

[bsdayo]

感谢有你

[fangtiancheng]

放个付款码，想打点钱

[AlanFH1842]

你们才是真的英雄🫡

[lianhong2758]

感谢

[23650]

衷心感谢go-cqhttp项目长久以来的陪伴😭

[CMHopeSunshine]

感谢gocq项目

[fy0]

都……结束了吗？
呜呜呜 祝好

[msojocs]

我们基于NTQQ实现了一个闭源机器人框架。

目前，我似乎没有看到真正的基于底层的开源框架；所以，我在此处提供一些技术细节：

这个需要运行一个有界面的QQ，占用不小：
https://github.com/linyuchen/LiteLoaderQQNT-OneBotApi

看了chronocat，所谓的无头只是忽悠人的，没意义。

1. wrapper.node 是在 major.node 中加载的，直接对require进行hook是不行的；但是，还是能通过process中的一个方法进行hook。
2. 通过1只是为了得知NTQQ进行特定操作，如 发送消息 时，底层调用的API及具体参数
3. 我们在具体应用实现中完全剔除了electron，代码中没有任何electron相关导入
4. 具体使用形式成为：./qq index.js，也就是nodejs的形式。

核心思想

还有，这不是hook，上面的hook是为了了解具体操作产生的API调用行为；以此来编写具体逻辑代码。

这是模拟NTUI层的操作，直接 调用底层API与服务器通信。

// 伪代码
const wrapper = require('wrapper.node')
const loginService = wrapper.LoginService()
loginService.loginByAccount(id, pass)

const msgService = wrapper.getMsgService()
msgService.sendMsg('msg from bot!')

占用

直接调用底层占用少了不少。

Hook Electron:

直接调用底层：

封号概率

还是有的。

因为，我们在分析底层操作时，发现几乎每一条操作都会将操作与结果上报到服务器。

于是，我们的框架在行为上可能会有一些“异常”。

适用平台

Windows/Linux

都能够这样：./qq.exe index.js / ./qq index.js 来执行机器人框架。

[3588044667HZ]

想知道wrapper.node是如何发现的，它好像没有标志性的导出函数

你 require 一下，打印出来，很明显的

哇靠我还傻乎乎地用ida看

[gaoyiping]

何去何从，有没有仙人指路？

[incubus-ohy]

ndroid 虚拟机的难度基本可以视为不可能，如果上述四条满足不了至少一条，那么 OpenShamrock 对其来说就是一场彻头彻尾的灾难(详见 Overflow)。
我的主要观点已经重复多次，这里不再赘述。

这里也知道呀，但OpenShamrock，是这里认为，在目前情况下较稳定的出路呀。

尽管，它有对于硬件的强制要求。

这里也，没有什么好办法呀。这里只有1台Root后的小米手机，还是主要使用的呢。

何去何从，有没有仙人指路？
文档里有，熟读文档
https://github.com/whitechi73/OpenShamrock

[wjs876046992]

很早之前用的一个号目前还能正常使用，最近新搭的就不行了，直接被封。

[zanjie1999]

目前的情况是每半个月封一次号，需要人脸解封，其他十分稳定

[landall]

我们基于NTQQ实现了一个闭源机器人框架。

目前，我似乎没有看到真正的基于底层的开源框架；所以，我在此处提供一些技术细节：

这个需要运行一个有界面的QQ，占用不小： https://github.com/linyuchen/LiteLoaderQQNT-OneBotApi

看了chronocat，所谓的无头只是忽悠人的，没意义。

1. wrapper.node 是在 major.node 中加载的，直接对require进行hook是不行的；但是，还是能通过process中的一个方法进行hook。
2. 通过1只是为了得知NTQQ进行特定操作，如 发送消息 时，底层调用的API及具体参数
3. 我们在具体应用实现中完全剔除了electron，代码中没有任何electron相关导入
4. 具体使用形式成为：./qq index.js，也就是nodejs的形式。

核心思想

还有，这不是hook，上面的hook是为了了解具体操作产生的API调用行为；以此来编写具体逻辑代码。

这是模拟NTUI层的操作，直接 调用底层API与服务器通信。

// 伪代码
const wrapper = require('wrapper.node')
const loginService = wrapper.LoginService()
loginService.loginByAccount(id, pass)

const msgService = wrapper.getMsgService()
msgService.sendMsg('msg from bot!')

占用

直接调用底层占用少了不少。

Hook Electron:

直接调用底层：

封号概率

还是有的。

因为，我们在分析底层操作时，发现几乎每一条操作都会将操作与结果上报到服务器。

于是，我们的框架在行为上可能会有一些“异常”。

适用平台

Windows/Linux

都能够这样：./qq.exe index.js / ./qq index.js 来执行机器人框架。

QQ开始迁移到NT时，我就一直有一个疑惑，他们计划是打算怎么反Bot的，毕竟这玩意在他们业务里属于日常工作，各种违法行为都依赖这条线。
首先HTML前端，就可以通过修改CEF库来实现读写的能力，这样的话，最差最差，就像微信PC版那个版本那样被第三方注入了。这类玩法，当年我们的在IE Core（WebBrowser）上玩得太多了，HTML/JS端无论如何都没法进行防御。

Electron是另一个弱点，只要把Electron换成自己实现的特定版本，中间想做啥都比较容易。无非是个体力问题。
如果要自定义一个差异巨大的Electron，那为什么不继续维护DirectUI框架呢？
毕竟DirectUI的地位其实就等价于Electron。

所以NT版本这事，我真的感觉非常迷惑。哪怕是没人维护DirectUI框架了，也不应该这么莽撞得上一个NT版本吧？

[jiangyin14]

何去何从，有没有仙人指路？

go-cqhttp能用就用，不能的话
用Shamrock或者LLOneBot直接当go-cqhttp的array模式用就OK

[zhaodice]

我们基于NTQQ实现了一个闭源机器人框架。
目前，我似乎没有看到真正的基于底层的开源框架；所以，我在此处提供一些技术细节：
这个需要运行一个有界面的QQ，占用不小： https://github.com/linyuchen/LiteLoaderQQNT-OneBotApi
看了chronocat，所谓的无头只是忽悠人的，没意义。

1. wrapper.node 是在 major.node 中加载的，直接对require进行hook是不行的；但是，还是能通过process中的一个方法进行hook。
2. 通过1只是为了得知NTQQ进行特定操作，如 发送消息 时，底层调用的API及具体参数
3. 我们在具体应用实现中完全剔除了electron，代码中没有任何electron相关导入
4. 具体使用形式成为：./qq index.js，也就是nodejs的形式。

核心思想

还有，这不是hook，上面的hook是为了了解具体操作产生的API调用行为；以此来编写具体逻辑代码。
这是模拟NTUI层的操作，直接 调用底层API与服务器通信。

// 伪代码
const wrapper = require('wrapper.node')
const loginService = wrapper.LoginService()
loginService.loginByAccount(id, pass)

const msgService = wrapper.getMsgService()
msgService.sendMsg('msg from bot!')

占用

直接调用底层占用少了不少。
Hook Electron:

直接调用底层：

封号概率

还是有的。
因为，我们在分析底层操作时，发现几乎每一条操作都会将操作与结果上报到服务器。
于是，我们的框架在行为上可能会有一些“异常”。

适用平台

Windows/Linux
都能够这样：./qq.exe index.js / ./qq index.js 来执行机器人框架。

QQ开始迁移到NT时，我就一直有一个疑惑，他们计划是打算怎么反Bot的，毕竟这玩意在他们业务里属于日常工作，各种违法行为都依赖这条线。 首先HTML前端，就可以通过修改CEF库来实现读写的能力，这样的话，最差最差，就像微信PC版那个版本那样被第三方注入了。这类玩法，当年我们的在IE Core（WebBrowser）上玩得太多了，HTML/JS端无论如何都没法进行防御。

Electron是另一个弱点，只要把Electron换成自己实现的特定版本，中间想做啥都比较容易。无非是个体力问题。 如果要自定义一个差异巨大的Electron，那为什么不继续维护DirectUI框架呢？ 毕竟DirectUI的地位其实就等价于Electron。

所以NT版本这事，我真的感觉非常迷惑。哪怕是没人维护DirectUI框架了，也不应该这么莽撞得上一个NT版本吧？

这还不简单，直接把QQ的那套ACE反外挂用在QQ上不就行了？

[landall]

我们基于NTQQ实现了一个闭源机器人框架。
目前，我似乎没有看到真正的基于底层的开源框架；所以，我在此处提供一些技术细节：
这个需要运行一个有界面的QQ，占用不小： https://github.com/linyuchen/LiteLoaderQQNT-OneBotApi
看了chronocat，所谓的无头只是忽悠人的，没意义。

1. wrapper.node 是在 major.node 中加载的，直接对require进行hook是不行的；但是，还是能通过process中的一个方法进行hook。
2. 通过1只是为了得知NTQQ进行特定操作，如 发送消息 时，底层调用的API及具体参数
3. 我们在具体应用实现中完全剔除了electron，代码中没有任何electron相关导入
4. 具体使用形式成为：./qq index.js，也就是nodejs的形式。

核心思想

还有，这不是hook，上面的hook是为了了解具体操作产生的API调用行为；以此来编写具体逻辑代码。
这是模拟NTUI层的操作，直接 调用底层API与服务器通信。

// 伪代码
const wrapper = require('wrapper.node')
const loginService = wrapper.LoginService()
loginService.loginByAccount(id, pass)

const msgService = wrapper.getMsgService()
msgService.sendMsg('msg from bot!')

占用

直接调用底层占用少了不少。
Hook Electron:

直接调用底层：

封号概率

还是有的。
因为，我们在分析底层操作时，发现几乎每一条操作都会将操作与结果上报到服务器。
于是，我们的框架在行为上可能会有一些“异常”。

适用平台

Windows/Linux
都能够这样：./qq.exe index.js / ./qq index.js 来执行机器人框架。

QQ开始迁移到NT时，我就一直有一个疑惑，他们计划是打算怎么反Bot的，毕竟这玩意在他们业务里属于日常工作，各种违法行为都依赖这条线。 首先HTML前端，就可以通过修改CEF库来实现读写的能力，这样的话，最差最差，就像微信PC版那个版本那样被第三方注入了。这类玩法，当年我们的在IE Core（WebBrowser）上玩得太多了，HTML/JS端无论如何都没法进行防御。
Electron是另一个弱点，只要把Electron换成自己实现的特定版本，中间想做啥都比较容易。无非是个体力问题。 如果要自定义一个差异巨大的Electron，那为什么不继续维护DirectUI框架呢？ 毕竟DirectUI的地位其实就等价于Electron。
所以NT版本这事，我真的感觉非常迷惑。哪怕是没人维护DirectUI框架了，也不应该这么莽撞得上一个NT版本吧？

这还不简单，直接把QQ的那套ACE反外挂用在QQ上不就行了？

ACE那套逻辑还是比较弱势的吧，权限低于作弊方，完全是被动的。
之前游戏反外挂不都被DMA硬件直接干得不要不要的么。

[zhaodice]

ACE那套逻辑还是比较弱势的吧，权限低于作弊方，完全是被动的。 之前游戏反外挂不都被DMA硬件直接干得不要不要的么。

腾讯的选择当时是：直接抓生产DMA硬件的人

[MoRanYue]

何去何从，有没有仙人指路？

go-cqhttp能用就用，不能的话
用Shamrock或者LLOneBot直接当go-cqhttp的array模式用就OK

若后端及其插件，只是基于OneBot协议的，则部分插件，在迁移至OpenShamrock后，可能无法直接使用，而需要部分修改呀。

emm，例如 通知事件group_increase，OpenShamrock因客户端限制，无法直接在该事件发生时，取得加入用户的QQ号码（UIN）呀，只可得到QQ NT的用户内部ID（UID），然后，后端再通过get_uin接口，来实现 取得群聊加入用户QQ号码 的效果呀

（emm，部分Bot后端，例如NoneBot2，便提供协议适配器的支持。或许，可以通过编写专用的适配器，来解决此问题呀）

[1292917512]

用了很久了，嗯，还是得说声谢谢dalao的贡献！！！

[gaoyiping]

有类cq成熟的项目，请踢踢我。

[LondonClass]

希望继续维护接收消息的部分。只要还能接收消息的话，就可以使用模拟用户操作的方式来发送消息。

[Liberations]

没法登陆了

[LondonClass]

没法登陆了

手表QQ还能用吧

[pk5ls20]

忆昔午桥桥上饮，坐中多是豪英。长沟流月去无声。杏花疏影里，吹笛到天明。
二十余年如一梦，此身虽在堪惊。闲登小阁看新晴。古今多少事，渔唱起三更。

[evaZQR]

感谢你们的付出

[BlondeMarisa]

没法登陆了

手表QQ还能用吧

手表能登陆 不过会被风控 TT 暂时没找到好一点的解决办法

[Aimang2002]

最近看到有个叫liteloadQQNNT的项目，能不能用这个项目里面的LLAPI插件向外暴露一些接口？然后老版插件可以用API连接新版QQ了。当然比起说这是办法更不如说是我对QQNT的不理解，不知道能不能这样弄

[aicorein]

最近看到有个叫liteloadQQNNT的项目，能不能用这个项目里面的LLAPI插件向外暴露一些接口？然后老版插件可以用API连接新版QQ了。当然比起说这是办法更不如说是我对QQNT的不理解，不知道能不能这样弄

你说的这个已经有项目实现了，项目叫 LLOneBot

[zyzzyh]

_

[anyanfei]

最近看到有个叫liteloadQQNNT的项目，能不能用这个项目里面的LLAPI插件向外暴露一些接口？然后老版插件可以用API连接新版QQ了。当然比起说这是办法更不如说是我对QQNT的不理解，不知道能不能这样弄

你说的这个已经有项目实现了，项目叫 LLOneBot

https://github.com/anyanfei/go-liteLoadQQNT golang照着python写的一键部署，希望大佬们来帮忙维护一下，感谢感谢了

[Linwenxuan05]

https://github.com/LagrangeDev/LagrangeGo
Lagrange.Core的Go实现已经出现 还请大家关注一下

[HowardJoness]

由衷感谢go-cqhttp为开发者们提供的便利

[ReiRzior]

lagrange之类的都可以，官网可查

…

On Mon, 19 Feb 2024 at 10:40, 高一平 ***@***.***> wrote: 何去何从，有没有仙人指路？ — Reply to this email directly, view it on GitHub <#2471 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A2BGBGTAC454RTBBW3IRB33YUK3RNAVCNFSM6AAAAAA5ZCKYI6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJRGU4TMNZQGY> . You are receiving this because you commented.Message ID: ***@***.***>

[MoRanYue]

（为何，OpenShamrock，被存档了呢……）

[SunshineboyZj]

可能谁又被TXgank了？ 现有的能用的项目的资源还是尽快备份吧，QQ版本也不要随意升级了，能用多久是多久。 欸，命运多舛的野生Bot

…

---原始邮件--- 发件人: ***@***.***&gt; 发送时间: 2024年4月27日(周六) 晚上11:54 收件人: ***@***.***&gt;; 抄送: ***@***.******@***.***&gt;; 主题: Re: [Mrs4s/go-cqhttp] QQ Bot的未来以及迁移建议 (Issue #2471) （为何，OpenShamrock，被存档了呢……） — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***&gt;

[MoRanYue]

可能谁又被TXgank了？
现有的能用的项目的资源还是尽快备份吧，QQ版本也不要随意升级了，能用多久是多久。
欸，命运多舛的野生Bot

---原始邮件---
发件人: @.>
发送时间: 2024年4月27日(周六) 晚上11:54
收件人: @.>;
抄送: @.@.>;
主题: Re: [Mrs4s/go-cqhttp] QQ Bot的未来以及迁移建议 (Issue #2471)

（为何，OpenShamrock，被存档了呢……）

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>

（唉……
不知为何，这里便突然发现，openshamrock的仓库，被存档呀）
（（难道说，现在只得，使用QQNTLiteLoader嘛……））