魔改Telegram - 群组内屏蔽

屏蔽弱智的效果

原始

Windows

iOS

起因

• 这个人技术实力很差：对阿里云等云服务了解很浅，同时理解别人的话的速度也很慢（别人都理解了，他还在那里问）

• 这个人却并不承认自己技术很差：
• 最开始：告诉他阿里云入站不要钱，出站流量费，他说“我只用过固定带宽计费的”。这种最基础的概念都缺失，那根本没法讨论更高层的问题
• 所以我说他对阿里云了解太浅。结果他拒绝承认，还说自己用过很多阿里云轻量，说都用的“流量包”（谁没用过？需要你告诉别人吗？什么弱智）

• 这个人并不关心问题的解决，只想杠：
• 起因：需要募集捐款，目前用的是微信收款码。问题包括捐赠人昵称显示不全，捐赠人无法获知项目进度，捐赠人没有公示表彰等等。我建议使用爱发电
• 这时这个傻逼就开始说“为什么不用支付宝接口自己做一个网站，凭什么让爱发电收6%的捐赠费”
• 首先，6%的手续费根本不多，收10000捐款也才需要600
• 其次，支付宝接口并不好搞
• 支付宝正常来说收款需要营业执照，其他的当面付、个人收款码实际上实际上都是违法协议的
• 一个营业执照办下来成本可绝对不止
• 不需要营业执照支付宝的支付接口都有人做成平台卖钱的（各种收款平台，机场用的很多）
• 手续费可不止6%
• 然后，也缺少人手编写这样的网站。毕竟你都能写出来一个爱发电了，那你为什么不直接跟爱发电竞争去？
• 尽管我说的非常有道理，但是他还是在杠
• 我显然无法忍受这样的行为，因此我轻度人身攻击后直接ban。这个时候他见我急了，非常开心，还觉得自己赢得了辩论的胜利（确实贵物）

• 这个人人品极差：大部分人互ban后都会留点社交距离避免污染群环境，可惜这个人不是
• 被ban后，他仍然对着我的每一句话开杠
• 被ban后，他发出来问大家怎么区分各个被ban了的人（因为都没有头像）
• 得知可以单独设置头像后，他直接把我设置成了小丑头像，并把截图发布在了群里
• 随后我表示不爽回复了一下，他遍说“我以为这*用奇怪的客户端屏蔽我了”
• 嗯，你说的没错，时间问题而已
• 我自然以人身攻击回应

• 这个人自己技术差，却觉得别人技术更差：
• 无奈于我持续的人身攻击，他开始回怼：我不想为了你换客户端，真当自己是个人物了？
• 然而，换客户端是个很麻烦的事情吗？Telegram全云端，无非是目前没有人编写这样的客户端而已
• Telegram是全开源的，可以自己随便编译，想怎么改怎么改。只要魔改下Qt的tdesktop和Swift的Telegram-iOS就可以了
• 简而言之：就是这个人菜逼，不会改，所以只好这么犯贱
• 这也是这篇文章的起因

魔改Telegram Windows

最开始的思路：hook Telegram客户端的函数，这样就不用自己build了

• 经过搜索，找到了很多issue提到需要在群组内屏蔽消息的功能
• 绝大部分这样的issue都说这个功能会被Telegram发送ToS violation（如NekoX已经于2020年移除这个功能）
• 但是我找到了https://github.com/kotatogram/kotatogram-desktop/issues/17#issuecomment-688528399
• 这个人的fork里面有个分支叫block-users-in-groups：https://github.com/ilya-fedin/kotatogram-desktop/tree/block-users-in-groups，添加了这个功能

• 尝试取巧：Telegram一直声称自己的reproducible build，那么会不会能在一些地方下载到debug symbol？

• 搜索telegram pdb找到了：https://github.com/telegramdesktop/tdesktop/issues/9882#issuecomment-748671635
• 这个人是Telegram官方repo的Collaborator
• 这个人说的23rd/tdesktop repo会跳转到Forkgram/tdesktop
• Forkgram是个维护了4年的Telegram fork，持续在merge upstream

• 问题：Telegram最近更新了Topics功能，老客户端是没法使用的。经测试
• Kotatogram：搜索源码，直接不支持topics
• Unigram：下载试用，发现支持topics，但是不完善，在topics里面经常加载不出来history，而且typing也显示的不对
• Telegreat等早于2022年更新的客户端均不可能支持这些功能
• 其他的client使用的框架太过怪异，没法用

转变思路：重新编译Telegram

• 研究Forkgram
• 这个repo进一步做了github actions，可以自动编译
• 编译出来Telegram.exe直接替换原来的Telegram.exe就行了很简单

• Cherrypick kotatogram的代码
• kotatogram实际上也是tdesktop的一个fork，而forkgram也是，所以他们俩改的地方都一模一样，直接改了就可以了
• 我甚至懒得在本机编译（下载一堆第三方库太恐怖了）

• 修复Github Actions
• Forkgram当前的Github Actions编译基本上没问题，主要是在编译依赖库的时候会报错空间不足
• Forkgram原有的行为在第三方库编译结束后再删除中间文件（pch、pdb、obj），而目前在编译依赖库的中间就已经空间不足了
• 我们改成在prepare.py的每个stage都删除一遍中间文件即可（注：这个时候pch就不能删除了， 要不然Mac平台会报错，毕竟预编译头用的地方还是很多的）

魔改Telegram iOS

iOS的魔改思路

• iOS上经过研究Hook方法是不可行的
• 首先：iOS语言为Swift，调用约定怪，根本没有hook框架
• 其次：iOS目前没有好的hook C函数的方法

• 重编译的思路上，我们学习上面的Forkgram经验，我觉得
• Telegram的ci肯定写的没有Nicegram好
• 而且Nicegram功能多
• 因此，iOS的魔改以Nicegram为基本

• 我不会写Swift，肯定没法直接改，所以我拿出来了M1 Mac更新到了最新的Xcode 14.2来开发

研究Nicegram如何编译

• Nicegram也就是Telegram-iOS用的bazel，不是Xcode（我不熟悉）

• Nicegram分为两套编译流程
• 直接手动build-system/Make/Make.py
• fastlane ci

• 尝试修复fastlane ci：
• 在ci/generate-project.sh里面提到会source ./fastlane-env.sh
• 在fastlane-env里面仿照Github Actions的yml里面的env填了环境变量
• 然而并不能用，appstore connect api那一步必须非空
• 必须手动使用Make.py了

• 区分Telegram与Nicegram：Nicegram对编译流程做了一些修改，直接按照Telegram官方的操作编译是不成功的
• Nicegram的--configurationPath需要填json配置文件而不是目录
• 基于猜测，我直接把build-system目录下面的appstore-configuration.json拿了过来，发现基本能用，就只少了ng_env和google_client_url_scheme
• 随后使用noCodeSigning参数就可以开始编译了

• 尝试bazel转Xcode之后用Xcode开发并编译，然而发现并不行
• 转出来的Xcode项目不全，只能勉强用
• 被迫每次直接命令行build

制作Nicegram的编译配置

• 搞定provisioning profile并编译fakesign的ipa
• 不能直接无脑noCodesign
• 通知、iCloud存储、Keychain都是依赖于mobileprovision的，因此很重要
• 使用noCodesigning只能编译出来simulator app
• Telegram官方带了一个fake-codesigning目录，有一套自签名开发者证书和对应provisioning profile
• 然而，怎么做出来这些cert的并没有交代
• 经过查找，有这么一片文章https://dkimitsa.github.io/2018/01/04/ios-homemade-provision-profile/
• 核心是自己建立代码签名证书后，将mobileprovision的plist中的Certificate相关信息换掉，最后用security cms命令封装回mobileprovision
• 从Telegram的fakesign provisionfile制作Nicegram的provision file
• 核心要点
• Nicegram的TeamID和Telegram不同
• Nicegram的BundleID和Telegram不同
• 需要替换provision的证书为我们的自签名证书
• 首先：我们提取Telegram的provision file中的plist
• 然后：魔改provision plist
• 我们用sed全局替换teamid和bundleid
• 用plutil替换证书信息
• 最后，plist包回mobileprovision

• 逆向出Nicegram的特殊参数ng_env
• 我一开始ng_env填写的是prod（因为actions里面有的env填的是这个，但是应该不是ng_env）
• app会闪退，提示json解析失败，位置大概在GlobalSettings那边
• 寻找官方客户端的ng_env：
• 我把ng_env改成了prod12345676534这样的特殊字样，然后搜索，发现是挨着另一个字符串的
• 对应在app里面找到了一个base64字符串，解开发现就是ng_env的json base64

重新制作CI

• Nicegram现在在用的fastlane肯定是没法用的，通过翻阅commit history可以看见Nicegram是在1.1.2到1.1.3从Telegram原来的ci改到fastlane的，所以我又换回了之前Telegram的action

• 问题1：始终报错找不到签名identity
• 经过搜索，这个跟开发者证书的导入有关
• 原因1：没有导入开发者证书私钥（我一开始只导入了证书公钥）
• 原因2：Github官方的这个导入方法似乎在bazel身上并不能用：https://docs.github.com/en/actions/deployment/deploying-xcode-applications/installing-an-apple-certificate-on-macos-runners-for-xcode-development，

• 问题2：签名的时候卡死
• 猜测：一直卡死但CPU占用率却不高肯定是因为有什么东西block了，我猜测肯定是Mac的对话框
• 原因：我把证书加到了~/Library/Keychain/login.keychain，而这个keychain经常会上锁
• 解决：修改加入到全局的keychain db里

• 问题3：AssetCatalogCompile崩溃，Exit 247
• 原因：AssetCatalogCompile需要使用的资源较多，bazel每次执行6个任务，Swift任务占用内存很大，导致内存耗尽而崩溃
• 解决：
1. 多次尝试编译：本质上没有问题只是资源限制，多试几次就可以了，编写了一个for循环尝试编译3次
2. 在失败时继续编译：AssetCatalogCompile在最后一步才需要，利用continueOnError在出错时将swift模块都编译完即可在下一次的时候只编译assetCatalog，这样就避免了资源耗尽

END