WJZ0821

V2EX 第 699279 号会员，加入于 2024-07-03 21:37:58 +08:00

今日活跃度排名 443

问与答 • WJZ0821 • 4 分钟前 • 最后回复来自 WJZ0821

分享创造 • WJZ0821 • 20 天前 • 最后回复来自 WJZ0821

分享创造 • WJZ0821 • 303 天前

分享创造 • WJZ0821 • 321 天前 • 最后回复来自 WJZ0821

分享发现 • WJZ0821 • 353 天前 • 最后回复来自 WJZ0821

分享创造 • WJZ0821 • 2024-09-14 15:03:31 PM • 最后回复来自 wjz1369727119

WJZ0821 最近回复了

4 分钟前

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

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

4 小时 22 分钟前

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

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

4 小时 24 分钟前

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

5 小时 12 分钟前

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

5 小时 14 分钟前

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

5 小时 16 分钟前

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

5 小时 18 分钟前

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

5 小时 55 分钟前

@suyuyu 感谢各位大佬的留言，我自己也多加留意，反正不能用这个赚钱，这个是底线

5 小时 56 分钟前

@LxnChan 嗯，基于输入法的话可以连输入法层面也防范内容被上传，但是实际上要 hook 输入框和发送按钮这些，还是得基于无障碍，所以就没考虑输入法的形式

6 小时 52 分钟前

@guiyumin 其实也主要是练手，学下 compose 开发和 kotlin 语言。