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 the or...

前言 群友反馈在Deiban13下不能设置IPv4优先 分析 感谢 Debian中文群的群友 提供信息  https://t.me/c/1039975886/766705 感谢233群的群友提供信息  https://t.me/tg233boy/1228524 我们知道了, gai.conf 控制的是 getaddrinfo 系统接口的行为 /etc/gai.conf 怎么证明某个程序调用了 getaddrinfo(被gai.conf控制) 呢?  钩子拦截系统接口调用 感谢Debian中文群的群友的灵感  https://t.me/c/1039975886/766779 gdb调试我不会, 但是我会编译啊. 我问了一下GPT, getaddrinfo的库是 libc.so.6 可以在这里面查找到 getaddrinfo 的符号, 如 nm -D /lib/x86_64-linux-gnu/libc.so.6 | grep getaddrinfo 我本来想找到源码自己编译一份 libc.so.6 文件. 思路是不影响原有的getaddrinfo功能, 只是在命令行多打印一份日志. 这样就可以确定某个软件 是不是 调用了 getaddrinfo , 于是就受到 gai.conf 的控制 (IPv4优先 / IPv6优先). 我拿这个想法去问GPT. 回答超出我的预期. GPT告诉我,  1. 最好不要替换系统库, 因为会影响整个系统. 2. 有办法可以针对 某个程序 挂个钩子. 在钩子 里监控 调用系统 getaddrinfo 的行为, 然后打印日志. 然后在钩子里原样 调用系统原本的 getaddrinfo, 不影响实际行为. 相关代码如下, 例如  hook_getaddrinfo.c #define _GNU_SOURCE #include <stdio.h> #include <dlfcn.h> #include <netdb.h> int getaddrinfo(const char *node, const char *service,                 co...

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 SendMode...

逛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 the previous blog post , we added a feature to our join verification bot that allows manual initiation of the join verification for a specific group member. This solves the problem that when the bot leaves the group (or experiences an anomaly), new members join the group, but these new members did not go through the join verification process. So a new question arises: how do I know which members joined the group during the time period when the bot was away from the group? Requirement Output the join time of group members. Implementation I recalled that we had a tool for querying group member information https://github.com/crazypeace/tg-get-group-member We just need to do some GPT-based programming and describe our requirements. Based on the code above, add the feature:  Save the time when group members joined the group The modifications are very small. I found that in the result obtained, the join times are out of order. Adding a follow-up requirement to GPT Query results ne...

前言 在前面一篇博文中 , 我们的入群验证机器人增加了一个功能, 可以手动启动对某个群成员的入群验证. 解决的问题是, 当机器人离开群组(或异常)的时候, 群组有了新的成员, 但是这些群成员没有经历入群验证. 那么一个新问题就随之而来, 我怎么知道哪些成员是在机器人离开群组的时间段入群的呢? 需求 输出群成员的入群时间. 具体实践 想到我们有过一个查群成员信息的工具 https://github.com/crazypeace/tg-get-group-member 我们只要面向GPT编程, 描述我们的需求. 基于以上代码, 增加功能:  保存群组成员加入群组的时间 修改量很小. 发现得到的结果中, 入群时间是无序的. 向GPT追加需求 查询结果需要按入群时间排序 GPT给出的结果 基本功能是正确的, 但是对于保存在文件中的格式, 我有一点特别的要求. 最初这个项目是为了生成一个用户列表, 供  发言验证机器人  作为 已验证用户列表 valid.yaml 所以需要保存在文件中的格式为: 6617181826: username: atefatman full_name: 子 肥 7919966027: username: crazypeace_anti_bot_bot full_name: CZ_antibot_bot 我尝试了几种方案. 如果用 list , 保存在文件中的形式是 - id: 399932510 username: crazypeace full_name: ǝɔ∀ǝdʎz∀ɹɔ 👽 joined_at: '2025-10-06T17:47:39.202290' - id: 661519101 username: testuser full_name: 测试 用户 joined_at: '2025-10-07T12:11:22.501119' 如果用 OrderedDict , 保存在文件中的形式是 !!python/object/apply:collections.OrderedDict - - - 1716213463 - username: 8lojbk full_name: 系统安装 处理 搭建网络环境 joined_at: '...

Background While reviewing the bot's logs today, I found 4 exceptions. The exact cause of the exception is not fully clear. I suspect it's a network issue—the bot program timed out when requesting the Telegram server to set user permissions. This creates a vulnerability: these 4 new users were not muted and did not go through the human verification process. Requirement Need the ability to proactively initiate the same flow for a specific user as when a new member joins the group (mute, require completing human verification in a private chat with the bot, then unmute). Practice After reading the code, I found that in the new member verification flow, the track_chat_member function only requires chat and user as external data. It's well-suited for refactoring. So once again, we program with GPT in mind 对 track_chat_member 函数进行重构,  目的是为机器人新增一个命令 /new_member_verify  这样可以主动将某个成员当作好像新成员一样进行验证流程. (禁言, 与机器人私聊, 回答问题, 等等) The result was very satisfying. Not only did it refactor th...

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

There are many advertising accounts that have been kicked out of groups by the anti-advertising bot processing. That is, in the group's Permissions - Removed Users list. Because advertising accounts get reported a lot, they actually get banned by Telegram relatively quickly, becoming Deleted Account The purpose of this project is to clean up this list and remove accounts that have already been banned. Once again, developed with GPT. Based on our previous project, copy and paste the entire code into ChatGPT, then attach the following requirements 基于上面的代码, 实现以下功能: 在群组的 permissions - removed users 里面, 找出被封禁的账户 Deleted Account, 清除掉. Github https://github.com/crazypeace/tg-clear-removed-users Usage effect 📢 群组: FuckGFW-Newbie 翻墙新手村 ✅ 保留: 7887288719 (Trinity Griselda) - 被踢出状态 ⏭️ 跳过: 8125834274 🗑️ 检测到 Deleted Account: 7623369260，正在清理... ✅ 保留: 6331849477 (bk ) - 被踢出状态 ✅ 保留: 6709325050 (易捷支付 机场特惠 ) - 被踢出状态 🗑️ 检测到 Deleted Account: 8173951376，正在清理... 🗑️ 检测到 Deleted Account: 7499278394，正在清...

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

有一些 anti-spam bots, in order to avoid accidentally kicking out users, only set users who have not passed the verification to be muted, without kicking them out of the group. Then, these users will leave a record without speaking permission in the group's Exceptions list. When there are many such records, doing it manually one by one is too time-consuming. So, let's let a program do it for us. Once again, developed using GPT. Based on our previous project  https://github.com/crazypeace/tg-clean-exceptions Refer to the code above to implement the following features Check all the settings in the exceptions of the group's permissions, If a user does not have speaking permission, kick that user out of the group. As you can see, for such a simple project, you don't need an IDE development tool, nor a vibe programming assistant, nor the latest model. Any GPT will do. Even if you hit the GPT-5 quota, GPT-4 is enough. However, as in the previous blog post, the overall framework ...

前言 有一些 防广告机器人为了防止误踢用户, 只对未通过验证的用户设置了禁言, 并没有将用户踢出群组. 那么, 这些用户会在 群组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文件

In the previous post , we obtained the list of IDs of active group members by querying the most recent 1000 messages in a group. If I want to be especially kind to the members of this group, as long as they are currently in the group, I don't want any of them to be disturbed by bots. Then I need to get all the members within the group. Developed with GPT. Don't forget, we just finished the project for querying recent messages in a group . For ease of reading and learning, copy and paste all the code from the previous project, and add the following requirements. Send it to GPT. Query all members in a telegram group Output format is yaml telegram account userid:  uesrname: telegram account username  full_name: telegram account full name For example 6611601789:   username: skypatch   full_name: 蛙 女 This group may be a public group or a non-public group After some simple debugging, the code ran normally. But the users obtained included users in the exceptions. This is not what we w...

前言 上一篇 中, 我们通过查询群组中最近的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. 使用 Telethon 库, 可以做到下面的要求吗? 在群组 的 permissions 的 exceptions 里检查所有的设置, 如果某个群成员的权限 是与群组的默认权限相同的, 那么就从 exceptions 删除这一条设置. Unfortunately, the framework logic of the code given by GPT looks fine, but it keeps reporting errors when running. It seems...

前面我们实现了两个防广告机器人 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...