ICDYCT / I Can Do, You Can Too

Preface Group members reported that IPv4 priority cannot be set on Debian 13 Analysis Thanks to the group members of the Debian Chinese group for providing the information https://t.me/c/1039975886/766705 Thanks to the group members of the 233 group for providing the information https://t.me/tg233boy/1228524 Now we know that gai.conf controls the behavior of the getaddrinfo system interface /etc/gai.conf How can we prove that a certain program calls getaddrinfo (controlled by gai.conf)?  Hooking to intercept system interface calls Thanks to the inspiration from the group members of the Debian Chinese group https://t.me/c/1039975886/766779 I don't know how to use gdb for debugging, but I know how to compile. I asked GPT, and the library for getaddrinfo is libc.so.6 You can find the getaddrinfo symbol here, e.g. nm -D /lib/x86_64-linux-gnu/libc.so.6 | grep getaddrinfo I originally wanted to find the source code and compile a copy of libc.so.6 myself. The idea was to not affect t...

前言 群友反馈在Deiban13下不能设置IPv4优先

The goal is to achieve the Ctrl effect on long press of CapsLock, and the Esc effect on short press of CapsLock The AutoHotKey code inside is as follows: SendMode Input SetWorkingDir %A_ScriptDir% SetCapsLockState, AlwaysOff CapsLock::   Send {Ctrl Down}   KeyWait, CapsLock   Send {Ctrl Up}   if (A_PriorKey = "CapsLock")     Send {Esc} return Walking through the code reveals the problem: whether long-pressed or short-pressed, it sends out Ctrl Down and Ctrl Up signals In most environments, this extra Ctrl signal doesn't matter, but if a certain environment is sensitive to this extra Ctrl signal, ... What I thought of is, a delay should be added to determine whether it's a short press or a long press. While preparing to develop with GPT, I thought, it would be better to give GPT an open-ended question. Analyze what problems this code has, and how it can be improved The result exceeded my expectations. 1. First, let's look at the delay-added solution SendMod...

逛B站的时候看到 <告别腱鞘炎！Vim 党必看! CapsLock 一键双用：Ctrl + Esc 全搞定> 目的是 长按CapsLock实现 Ctrl 的效果, 短按CapsLock实现 Esc 的效果 里面的AutoHotKey代码如下: SendMode Input SetWorkingDir %A_ScriptDir% SetCapsLockState, AlwaysOff CapsLock::   Send {Ctrl Down}   KeyWait, CapsLock   Send {Ctrl Up}      if (A_PriorKey = "CapsLock")     Send {Esc} return 走读代码就能发现问题, 不管是长按还是短按, 都会发出 Ctrl Down 和 Ctrl Up 信号 在大部分环境下, 这个多余的 Ctrl 信号没关系, 但是如果某个环境对这个多余的Ctrl信号有关系的话, ... 我想到的是, 应该加个延迟来判断是短按还是长按. 准备面向GPT开发的时候, 我想到, 不如给GPT一个开放的问题. 分析这段代码有什么问题, 可以怎样改进 结果超出我的期望. 1. 首先来看加延迟的方案 SendMode Input SetWorkingDir %A_ScriptDir% SetCapsLockState, AlwaysOff CapsLock::     KeyWait, CapsLock, T0.2  ; 等待释放 等待0.2秒          if (ErrorLevel)  { ; 长按超过0.2秒         Send {Ctrl Down}         KeyWait, CapsLock  ; 等待释放         Send {Ctrl Up}     }     else  { ; 轻按（短于0.2秒）   ...

Preface In a previous blog post , our join-group verification bot got a new feature that lets us manually trigger the join-group verification for any group member. The problem it solved was this: when the bot leaves the group (or goes offline abnormally), new members join the group, but those new members never went through the join-group verification. Then a new question pops up — how do I know which members joined during the period when the bot was absent from the group?

前言 在前面一篇博文中 , 我们的入群验证机器人增加了一个功能, 可以手动启动对某个群成员的入群验证. 解决的问题是, 当机器人离开群组(或异常)的时候, 群组有了新的成员, 但是这些群成员没有经历入群验证. 那么一个新问题就随之而来, 我怎么知道哪些成员是在机器人离开群组的时间段入群的呢?

Background Today while reviewing the bot logs, I found 4 anomalies. The exact cause of the anomaly isn't entirely clear; I suspect it's a network issue where the bot program timed out when asking the Telegram server to set user permissions. This opens a loophole: these 4 new users were never muted and never went through the join-group verification process.

背景 今天在查看机器人日志的时候, 发现有4个异常. 异常的原因不完全清楚, 猜测是网络原因, 机器人程序向Telegram服务器要求设置用户权限时 超时了. 这样就带来一个漏洞, 这4个新用户没有被设置禁言, 没有通过人机验证流程.

I don't support pulling various external bots into groups, as this makes the information in the group easier to be scraped. After granting these bots admin permissions, it's hard to guarantee that these bots won't do malicious things. Does anyone still remember the incident of the bidirectional chatbot livegarm bot posting ads? For anti-advertising, there are basically two approaches. One is human verification. The other is analyzing whether the message content is an advertisement. There are many ways to do human verification.  Answering questions, solving problems, using Cloudflare's human verification, etc... The approach I chose is to reply to text. First, it's easy to customize. Second, it's easy to increase the difficulty of the questions. If you want to have meaningful random questions, that's also possible. For example, what is the title of my latest blog post Theoretically, human verification cannot solve the situation where real people are used to a...

我不支持把各种外部机器人拉到群里面来, 这样会让群里的信息更容易被抓取. 在给了这些机器人管理权限之后, 很难保证这些机器人会不会作恶. 不知道大家对于 双向聊天机器人livegram bot 发广告的事件还有没有印象. 对于防广告, 基本上是两个思路. 一个是人机验证. 另一个是对消息内容进行分析是否广告.

A lot of advertising accounts were kicked from the group under the handling of the anti-advertising bot. In other words, they are listed in the group's Permissions - Removed Users list. Because advertising accounts get reported a lot, they actually get banned by Telegram pretty quickly and become Deleted Accounts. The purpose of this project is to clean up this list by removing the accounts that have already been banned.

有很多广告账号在防广告机器人处理下, 被踢出了群组. 也就是在群组的 Permissions - Removed Users 列表中. 而广告账号因为被举报得很多, 所以实际上比较快就会被telegram封禁, 成为 Deleted Account 本项目的目的就是清理这个列表, 把已经被封禁的账号移除.

Preface Some anti-advertising bots, in order to avoid accidentally kicking legitimate users, only mute users who haven't passed verification instead of kicking them out of the group. As a result, these users leave a record in the group's Exceptions list without speaking permission. When there are a huge number of such records, doing it manually one by one is too time-consuming. So let's let a script do the work for us.

前言 有一些 防广告机器人为了防止误踢用户, 只对未通过验证的用户设置了禁言, 并没有将用户踢出群组. 那么, 这些用户会在 群组Exceptions列表中留下一条没有发言权限的记录. 当这样的记录非常多时, 逐条手工操作太费时. 那么, 我们让程序来帮忙吧.

The first message validation bot we implemented previously. https://github.com/crazypeace/tg-send-msg-exam-bot When reading the code, I noticed that the bot frequently needs to read the yaml file. This significantly increases I/O overhead and slows down processing. Every time a new message is detected in the group, it calls is_valid_user() function -> load_valid_users() function -> opens the yaml file A common optimization strategy is,  to keep a cache in memory.  When the program starts, load from the file into the in-memory cache. When querying, query from the in-memory cache. When modifying, modify the in-memory cache and also modify the file. This caching approach is quite common, so once again, we use GPT to develop it. Copy and paste the entire original code, and add one more sentence. In the program above, every validation requires reading VALID_USERS_FILE. Would this cause efficiency issues? Thanks to the well-structured original code, the changes to add this cache are no...

我们前面实现的 首次发言 验证机器人. https://github.com/crazypeace/tg-send-msg-exam-bot 在阅读代码时发现, 机器人经常需要读取 yaml 文件. 这会显著增加I/O开销, 降低处理速度. 每次发现群内的新消息, 都要调用 is_valid_user()函数 -> load_valid_users()函数 -> 打开yaml文件

Preface In the previous post , we obtained a list of active group member IDs by querying the most recent 1000 messages in a group. If I want to be especially kind to the members in this group, anyone who is currently in the group should not be bothered by bots. So I need to get all the members in the group.

前言 上一篇 中, 我们通过查询群组中最近的1000条发言, 得到活跃群成员的id列表. 如果我想对这个群里的成员特别厚道, 只要是目前在群里的, 我都不希望有可能被机器人打扰. 那么我需要得到群组内的全部成员.

In the previous post, we built a bot for first-message human verification . This brings up the following requirement: I already have many members in my group. From their daily messages, you can tell none of them are bots. But once I add this first-message verification bot to the group, every member would have to go through verification before their first message after this point in time. That would cause unnecessary trouble for these existing members. Of course, this project also provides a verification list file called valid.yaml where you can manually add the userids of your group members. Among these, only the userid is valid; the other information is meant to assist humans in managing this file and is not involved in the program's logic. So, you can manually add the userids of your group members. Like this: So, the requirement this article aims to address becomes: Query the recent messages of a group and count the userids of message senders

前言 上一期我们实现了 第一次发言 人机验证 的机器人 . 那么就带来了这样一个需求: 我这个群已经有了很多群友. 天天发言, 也能看出来都不是机器人. 但是我把这个第一次发言人机验证的机器人一拉进群里. 那每个人在这个时间点之后的第一次发言之前都要验证一遍了. 这样会给这些群友带来不必要的麻烦. 当然, 这个项目本身也提供了一个验证列表文件 valid.yaml 你是可以手动添加群友的 userid 的. 其中, 只有userid是有效的, 其它信息是辅助人类管理这个文件用的, 不参与程序的逻辑判断. 所以, 你可以手动添加群友的userid进去. 就像这样: 所以, 本文要解决的需求就变成: 查询群组最近的消息 统计发言账号的ID

Earlier we implemented two anti-advertising bots https://github.com/crazypeace/tg-join-group-exam-bot https://github.com/crazypeace/tg-send-msg-exam-bot These two bots, when setting group members to mute and unmute, both add records to the Exceptions list.  We found that users who passed the verification also leave records in Exceptions, even if they are consistent with the group's default permissions. For the convenience of group management, we hope to clear this kind of records. This way, the remaining records are definitely those with restricted speaking permissions, i.e., those who did not pass the verification. We can kick them out of the group directly. After so many days of use, we are already an "old hand" at GPT development. Can the following requirements be achieved using the Telethon library? Check all settings in the exceptions of the group's permissions, if a certain group member's permissions are the same as the group's default permissions, then ...

前面我们实现了两个防广告机器人 https://github.com/crazypeace/tg-join-group-exam-bot https://github.com/crazypeace/tg-send-msg-exam-bot 这两个机器人在设置群成员禁言和解除禁言时, 都是在 Exceptions 列表中添加了记录.  我们发现, 通过了验证的用户, 也在 Exceptions 中留有记录, 哪怕是与群组默认权限一致.

Environment Description Telegram interface sets the default permissions for the group. The join group verification bot (tg-join-group-exam-bot.py) sets permissions in Exceptions after a new member passes the verification. The Clear Exceptions tool (tg-clean-exceptions.py) reads the group's default permissions, then reads the permissions of a user in Exceptions. Test Process Case 1.  Group default permissions  music - Close voice messages - Close tg-join-group-exam-bot.py sets permission can_send_audios=False, can_send_voice_notes=False, After the new member passes the verification, the record in Exceptions is like this, which meets the expectation tg-clean-exceptions.py What is read out by default_rights = entity.default_banned_rights What is read out by rights = getattr(p.participant, 'banned_rights', None)  You can see the default permissions are correct. This property is default_banned_rights. So True means Close. But the user's permissions read from Exceptions are...

环境说明 Telegram界面设置群组的默认权限. 进群验证机器人 (tg-join-group-exam-bot.py) 在新成员通过验证后, 会在 Exceptions 里面设置权限. 清除 Exceptions 工具 (tg-clean-exceptions.py) 会读取群组的默认权限, 再读取 Exceptions 中某个用户的权限.

There are many advertising bots that pass verification when first joining a group, and then stay silent. Until one night they start sending ad messages. So I thought, if we add a human verification when a group member sends their first message, would that greatly improve this issue?

现在有很多广告机器人, 在第一次加群时通过了验证, 然后一直不发言. 直到某天晚上开始发广告信息. 所以我想, 如果在群成员第一次发言时加上一个人机验证, 是不是可以大幅改善这个问题?

In the previous episode, we implemented custom Question-Answer . But it was too rigid. So, besides arithmetic problems, what other ways can we generate flexible Question-Answer pairs? For example, what is the title of the latest blog post on my blog?

上一期中, 我们实现了自定义 问题-答案 . 但是过于死板. 那么, 除了算术题, 还有什么可以生成灵活 问题-答案 的方式呢? 比如, 我的博客最新一期博文的标题是什么?