本人开发了一个全局消息加解密 APP，有风险吗？

@UnluckyNinja 这个确实是一个难点，目前的形式是安装软件会提供默认密钥，可以基于默认密钥的情况下沟通新密钥，但是如果审查方也下载了我的软件，并拿到了你们沟通密钥的密文，也确实可以解密，感觉最稳妥还是线下等不留痕地去做这个密钥的沟通

↑ 好像是这个

https://github.com/NoManTeam/Hole

@shmilypeter 密文一直是汉字，原理是二进制密文做 BaseN 运算转成 0 宽字符，然后再塞入一些常规汉字组成密文，好处是别人无法直接通过看你发的消息长度来推测密文长度，当然复制到一些字符串长度统计网站还是能看到实际会多很多

长期发这些谜语,会被封号吧

@ETiV 哇，原来还有这种，看了一下，十年前的项目了，看来很早就有人有了类似想法

@wafm 我在 QQ 上之前也做过一个加密插件，长时间在使用，没有出现问题。更多的检测是 NTQQ 插件框架本身被检测，内容倒是还好。我觉得一方面是因为我用到的 0 宽字符是正常拼接 emoji 会用到的字符，也就是并非完全罕见的那种。

@WJZ0821 嗯嗯 我只是说存在这种可能性 早期古早年代我们在百度 hi 和 空间 使用加密后的内容被审核后都会被直接封停

使用无障碍处理也是一种外挂。并且是可以被检测的。
并且根据 https://zhuanlan.zhihu.com/p/1907372254662198397 来看，微信是有上报机制和白名单机制的

即使不带具体的应用，也属于擦边的，存在风险的。

之后 https://github.com/WJZ-P/NekoCrypt/blob/6daaa42ff6b81323b55c909797939570af6127db/app/src/main/java/me/wjz/nekocrypt/util/CryptoUploader.kt#L33 似乎是把图片上传到微信的对话平台……

以及 代码里还有 com.dianming.phoneapp.MyAccessibilityService ？是为了伪装成点明之后注册吗……那这个还涉及了和 南京点明软件科技有限公司 之间的风险

还有就是 写了 EPL-2.0 但是实际的 LICENSE 文件是 GPL 2.0

P.S.: NekoIconCreator.html 挺好玩（（）

@UnluckyNinja 交换密钥不需要走其他的软件和渠道，直接在微信聊天窗口中用明文 DHKE 协商一个密钥就行了，你想用户身份认证腾讯都已经帮你做好了，你直接和对方协商一个密钥就可以了。当然了有其他渠道更加保险。

你要想想这东西主要用户就是黑灰产。被顺藤摸瓜，你不盈利也要被调查一番，运气不好就得吃国家饭了。

@WJZ0821 我的意思就是说，你不能去特殊定义这个全局，必须是真全局。你的 app 也要在这个全局之下，在全局加密下下发及更新。

如果做不到，那自然就意味着是假全局，在你所谓的全局之上，还存在个上帝层，可以看到足够多的信息。那自然可以抓你，自然也就是假全局。

@yaoyao1128 网链和无障碍包名属于黑魔法，不太适合展开。上传的图片和文件都是过了加密处理的，所以就算拿到了没密钥也解密不出来，安全性可以保证。另外，这个图标生成器其实是 Gemini 写的，哈哈，我拿来做了个图标

@HTravel 软件层的全局加解密意思是不特定于具体软件，能够做到适配大部分聊天软件的加解密，只要能拿到四要素：输入框，发送按钮，消息列表节点和具体消息节点就可以。其中后两个只有沉浸式解密需要，正常点按解密的话也不需要后面这两个。

至于更高层面的监控的话，在软件层我就无能为力辣

先去搞艘船，去公海再发

人少随你折腾 人一多,就会去喝茶

默认密钥是 op 生日吗？

@oneisall8955 并不是，是我喜欢的女生的生日，我和她是高中同班同学，高考完她去复读，我去上大学了，后续她考到了其他的城市。现在离开我有一年多了吧，睡觉时经常想起。

我不会说多浪漫的情话，就把思念写在代码里吧。

@WJZ0821 来自程序员的浪漫🥹

@oneisall8955 But it's a sad story.

看了下代码，加解密的用户输入的 key 衍生方案（ deriveKeyFromString ）是单次的 sha256 ，没有加入 salt 和迭代次数，衍生密钥的强度不够，建议改成 PBKDF2(1000 起)。此外这个 base64 的变体隐写，字典很容易被 regex 硬匹配，特征太明显。