跳至内容

SafeW 风险档案 · 博客

SafeW 用「安全报告」骗你:一篇说 Signal,一篇说 Telegram

当你搜索「SafeW 安全吗」,排在前面的那些「安全评测」「安全报告」,多半不是中立的第三方,而是 SafeW 自己。它注册了一批名字相近的域名——safews.cnsafew.orgsafew-app.orgsafew-im.com 等——反复发布口径一致的「安全分析」,把搜索结果的首页占满,让你第一眼只看到它替自己写的「清白证明」。

先把话说在前面:一个往自己应用里植入窃密木马的开发方,它出具的「安全报告」没有任何可信度可言。它说自己用了 Signal、说自己端到端加密、说自己通过了某项国际认证,你都没有理由相信——这些说法既无法在一个闭源又加壳的程序上得到核实,又出自一个已经被查实在偷用户数据的团伙之口。下面之所以还要逐条去对,不是因为它的材料值得当证据,而是因为它自己的几份说法,连彼此之间都对不上。

一份说 SafeW 用的是 Signal 协议,另一份说是 Telegram 协议。这是两套互不兼容的方案,同一个软件却给出两种说法——它的「报告」想怎么写就怎么写,哪一份都做不得准。

# 一、协议自相矛盾:一篇 Signal,一篇 Telegram

safews.cn 上那篇《安全评测》说得很肯定:

「SafeW 采用 Signal 开源加密协议,这是目前全球密码学界公认最可靠的端到端加密方案。」

safews.cn 称 SafeW 采用 Signal 协议

safews.cn 那篇:「SafeW 采用 Signal 开源加密协议」。

safew.org 那份 PDF《安全报告》却换了一套说法:

「SafeW 的核心通信加密机制基于 Telegram 的 MTProto 2.0 协议。」

safew.org 的 PDF 称 SafeW 基于 Telegram MTProto

safew.org 那份 PDF:「核心通信加密机制基于 Telegram 的 MTProto 2.0 协议」。同一个软件,两种说法。

Signal 协议和 Telegram 的 MTProto 2.0 是两套完全不同、互不兼容的方案。同一个软件,不可能既「采用 Signal 协议」又「基于 MTProto 2.0」。两份都挂着「官方」名号的材料直接对不上。两种自相打架的说法摆在一起,能说明的不是哪一份对、哪一份错,而是它的「报告」根本就是想怎么写就怎么写,哪一份都做不得准

不过,至少有一处可以直接证伪。那份《安全报告》为了证明「用的库都合法」,在自己的截图里列出了应用的核心库:

  • libtmessages.48.so,它自己标注成「Telegram 核心通信 API」
  • 本地数据库叫 cache4.db,消息表叫 messages_v2
报告列出的核心库包含 libtmessages.48.so

那份 PDF 自己列出的核心库,libtmessages.48.so 被标注为「Telegram 核心通信 API」。

这些都是 Telegram 的东西,是技术上抹不掉的痕迹。SafeW 不过是一个套了壳的 Telegram 改版。这样一来,safews.cn 那篇言之凿凿的「采用 Signal 协议」,就是一句可以当场拆穿的假话。至于另一份把自己说成「基于 Telegram」的报告,也同样不必照单全收——一个加壳闭源、又被查出投毒的应用,它声称自己用了什么、加了什么密,本来就无从验证。

对照项safews.cn 那篇safew.org 那份
加密协议采用 Signal 协议基于 Telegram MTProto 2.0
端到端范围所有通讯内容都端到端加密端到端只限「秘密聊天」
服务器存储零存储,不保留消息内容普通聊天经 MTProto 服务器中转

同一个软件,三个关键问题,两份材料给出了三处对不上的答案。

# 二、「Signal 的审计适用于 SafeW」——偷换概念

那篇评测还有一句很能唬人的话:

「Signal 协议接受过 Cure53 等多轮独立审计……由于 SafeW 直接使用 Signal 协议,这些审计结果同样适用于 SafeW。」

这句话站不住,有两层原因。第一,前面已经说明,SafeW 用的根本不是 Signal,这个前提本身就是假的。第二,就算它真的用了某一套协议,审计一套协议和审计你这个具体的应用,完全是两码事。Cure53 审的是 Signal 公开的源代码;而 SafeW 是闭源的,没人看得到它的实现,别人对 Signal 的审计结论,没有任何理由套到它头上。

真正愿意接受检验的软件,是把源代码公开、让任何人都能复核。SafeW 走的恰好是相反的方向,这一点在下一节会看得更清楚。

# 三、那层「爱加密」的壳,保护的是投毒的人,不是你

那份《安全报告》把一件事当成卖点反复强调:自己用了「爱加密企业版」加固、DEX 文件 VMP 虚拟化、代码混淆,能「对抗静态逆向分析」。

报告展示的加固信息:爱加密企业版

报告把「爱加密企业版」加固当成卖点展示。给应用加壳,挡住的正是分析者的视线。

这件事需要说穿。给一个应用加壳、做混淆,目的就是让别人没办法把它拆开、看清里面到底在做什么。对一个干净的软件,这顶多算防盗版;可对一个已经被卡巴斯基查实植入了窃密木马的软件,这层壳保护的是谁就很清楚了——它挡住的是安全研究员和杀毒引擎的视线,让植入的木马更难被发现、更难被取证。在这里,加壳和「保护用户安全」没有半点关系,它保护的是投毒的那一方

而他们居然把这层「让你查不出问题」的壳,当成「安全特性」写进报告、向用户宣传。这本身就说明,他们很清楚自己有东西见不得光。

# 四、「全部端到端加密」——退一步,按它自己的说法也兜不住

还是那句话:它说端到端加密,不等于真的端到端加密。这是一个闭源、加壳、而且已经被查出投毒的应用,它给出的任何加密承诺都无法核实,也不值得采信。

退一步,哪怕完全按它自己的材料来读,这个承诺照样是破的。那篇评测说「SafeW 的所有通讯内容都经过端到端加密」;可那份《安全报告》自己写的是,端到端只覆盖「秘密聊天」,而且「秘密聊天记录仅保留于当前设备,更换设备或卸载应用后需重新建立新会话」。这正是 Telegram「秘密聊天」的特征:默认关闭、需要手动开启、不跨设备。也就是说,你日常的普通聊天走的是经服务器中转的模式(报告里抓包打到的 45.204.21.75:5222,就是它的服务器地址)。

所以「所有通讯都端到端加密」这句话,连它自己另一份材料都不支持。而那篇评测同时还宣称「服务器零存储、不保留消息内容」,又和普通聊天必须经服务器中转的事实对不上。

# 五、ISO 27001、VirusTotal 全绿、腾讯检测通过——拿不出实据,还偷换概念

这几样招牌,两份材料都搬了出来,但都经不起追问。

ISO 27001、ISO 27034 认证:从头到尾,没有一个证书编号、没有发证机构、没有任何可以查证的记录。真正的 ISO 27001 证书带注册号,能在认证机构官网查到。这些都给不出来。一个查无实据、却被反复写进宣传里的「认证」,不是什么自我标榜,而是冲着用户来的欺骗

「VirusTotal 65 个引擎全绿」「腾讯检测通过」:把一个提交上去的安装包扫一遍、当时没报毒,并不能证明这款应用是干净的。原因有几个。其一,SparkCat 这类窃密木马本来就经过加壳混淆(就是上一节那层壳),靠特征码的杀毒引擎本来就容易漏掉。其二,完全可以拿一个干净的版本去跑出一份「检测报告」,再从自家网站分发真正带毒的安装包——绕开应用商店审核,正是它口中「私有化部署」的真实用途。其三,腾讯那张截图的小字写得很清楚,那只是一个免费的在线查毒服务,构不成任何背书。

真正有分量的结论恰好相反:卡巴斯基在 2025 年 2 月、The Hacker News 在 2026 年,分别公开点名 SafeW / SafeX 植入了 SparkCat 窃密木马。一家独立安全厂商的实测结论,比它自己印多少份「全绿报告」都更有说服力。

# 六、READ_MEDIA 那张截图:答非所问

那份《安全报告》特意贴了一张 JADX 代码搜索的截图,展示应用在申请 READ_MEDIA(读取相册、媒体)权限,org.safew.messenger 下一批类在检查 READ_MEDIA_IMAGESREAD_MEDIA_AUDIO 之类。它想借这张图说明:自己只在确有需要的时候才申请相册权限,所以「权限设计是合理的」。

报告里的 READ_MEDIA 权限代码截图

报告里那张 READ_MEDIA 权限代码截图。问题不在何时申请,而在拿到相册之后做了什么。

这套说法绕开了真正的问题。要害从来不是「什么时候申请权限」,而是「拿到相册之后,它对你的照片做了什么」。SparkCat 的手法,正是在拿到相册权限后,用 OCR 扫描你截图里的加密钱包助记词,再把钱包里的资产转走。卡巴斯基查实的就是这个「拿到之后的窃取行为」,跟它申请权限时表现得克不克制毫无关系。

更关键的是,它拿来自证的这套表现,恰好对上了卡巴斯基对 SparkCat 的描述。卡巴斯基安全团队指出,SparkCat 的手法,正是把窃取行为伪装成正常的权限申请——用一个看起来合理的理由取得用户授权,再在后台悄悄扫描相册。这样一来,「我只在确有需要时才申请、设计得很合理」非但不能给它洗清,反而正是这类木马惯用的伪装。它越想用这张截图证明自己的「权限请求很合理」,就越是和卡巴斯基描述的作案方式严丝合缝。

何况「只在需要时才申请」这句话,也不过是它配着一张截图的自述。这是一个闭源、加壳的应用,它给你看的,只是它愿意给你看的那几段代码;壳里面、那张截图之外,相册数据被读走之后究竟流向哪里,你根本无从查证。拿一张「我申请得很克制」的截图,去回应独立机构对「窃取行为」的指控,是在转移话题。

# 七、它本来就不是安全团队,是内容农场

safews.cn 这类站点,本质上是个不停产出 SEO 文章的内容农场:《SafeW 隐私保护怎么设置》《SafeW 桌面版完全指南》《SafeW 语音视频通话实测》……几天更新一篇,关键词铺得满满当当,目的只有一个,就是把和「SafeW」有关的搜索结果占满。一个内容农场随手拼凑出来的「安全评测」,张口就来「Signal 协议」「ISO 27001」也就不奇怪了,反正没人较真、也不用为此负责。

「官方下载站」这个名头,则同时挂在 safews.cnsafew.org 等好几个不同域名上。哪来这么多「官方」?这正是矩阵站的套路:同一套说辞,复制到几十个相近的域名上,彼此引用、占满整页搜索结果。

# 结论

把这两份「自证」放在一起看,能确认的不是「SafeW 有多安全」,而是它的说法既不能自洽,也根本不能信:

  • 加密协议自相矛盾,一篇说 Signal,一篇说 Telegram;
  • 借 Signal 的审计来冒充自己的安全、误导用户,自己却闭源、加壳,谁也核实不了;
  • 把一层「让人查不出问题」的加壳,当成安全特性来宣传;
  • 「全部端到端加密」的说法,连它自己另一份材料都不支持;
  • ISO 认证拿不出一个编号,VirusTotal「全绿」也挡不住独立厂商的实测结论。

判断一款软件是否安全,靠的是卡巴斯基这类独立机构的检测结果,而不是开发方自己印的报告,更不是它注册的一堆站点相互背书。何况这个开发方,已经被查实在自己的产品里植入了专门窃取加密钱包的木马——它说的每一句「我很安全」,都应该反过来读

SafeW 和 SafeX,两个都不要装;已经装了的,尽快撤掉它的相册等权限、卸载,并把加密资产转移到一个全新的钱包。完整的证据和时间线,见 nosafew.com