@skies457 啊？管家和 powertoys 是同一个团队做的吗？

可以用 ida 或者 ghidra 之类反汇编工具，看下 printf 实际调用的参数究竟是什么字符串。

当然，从汇编也是可以看出来的，只要你找得着……

别太把工作当回事，该下班就下班。

现在其实除了脱离原人际关系以外，也没什么换手机号的需求吧

TCP/UDP 连接是否重复是四元组(dstPort,dstIp, srcPort,srcIp)决定的，而不是你理解的单个 port

@honhon 挺久没干过这个事情了，依稀记得以前是通过提取手机上的 jar 实现的。

不过这里有一个问题：
新版本 Android 里的 jar 包都会预编译成 oat ，.jar 一般都是空的，需要找对应的 oat 、odex 或者 vdex 的文件，然后转 dex 再转 jar 。

编译出来的不应该没有啊，不然它自己也没法调……一般只是 SDK jar 里没有。你是不是找错位置了？

反射找不到是因为反射的时候做了限制屏蔽了一些类，找个绕过限制的 SDK 就好了，github 上一大堆。

这种回收站你自己实现起来也很容易。

把 rm alias 到 trash 上。然后开个定时任务定期清理就好了。

@zhenjiachen
对比方案可以参考 112 楼的设计。其实就是很简单的 nonce+hash 的嵌套。

其实只要换个角度就好理解了：你把密码第一次做了 hash 之后的结果当明文，然后该咋办还是咋办。

bcrypt 说到底只是一个样板方案，只要能达到效果就行，不是说非得严格死板一条条按它那个来的。

@zhenjiachen

你前端都使用 bcrypt 了，还多此一举把明文传给后端干嘛？当然是直接把 nonce 和 hash 传给后端啊。

主要是你的思路实在太奇怪了，从头到尾除了你就没人说 aes ，就算要加密口令也不可能脱离 tls 单独用 aes 。不赞同用 aes 听起来就像不赞同裸 http 明文传递密码一样，不赞同了个寂寞。

@zhenjiachen 不持久化存就根本不需要 AES 加密啊。即使要加密也可以用非对称加密，这样就没有逆向破解的问题。

而且前端可以直接做 nonce+hash 的 bcrypt——至于原因，前面某楼已经说了，哈希跟加密相比，最大的区别是避免后端得知密码明文。

@zhenjiachen 又不在前端持久化存密码，你要加密干嘛？

bcrypt 跟传输密码的哈希又不矛盾

@HojiOShi Java 给我的感觉正好相反：除了你开发的目标环境必须用 Java ，没有任何使用 Java 写东西的理由。

而且不是现在如此，在十年前可能就已经是这样了……

@FTLIKON 因为证书误用导致的 https 破解其实并不罕见。

其实就算证书没误用，如果 ciphersuite 配的不对，也完全有可能被破解（不过说实话现实中没见过类似的攻击案例，只在 PoC 中见过）

其实关于 https 传输明文密码这个问题，答案是很确定的。

它肯定没有传输加盐哈希安全，但对于 99%的情况足够安全。

当然，1%并不是一个很低的概率，所以现实中我们也可以看到因为明文传输、存储密码导致的大规模安全问题已经发生很多次了。

对新手来说，Mac 不会用，Windows 会用，Windows 胜。

对刚入门的人来说，Mac 能避免一些配环境的 corner case ，相比 linux 又更易用一些。Mac 胜。

对老手来说，没有我配不好的环境，没有我编译不了的库。啥平台都一样。

@carpeDiemJll 很多二三线城市的房并没有那么便宜。稍微像点样子的也得两三百万了。

既然 AI 写的代码不好，你又干嘛不写更好的代码呢？这不就是为什么别人用了 copilot 没废，而你废了么。

如果就手机一个平台的话，说真的不如开个云同步服务。比如 iCloud 。

价格比 NAS 便宜得多，2 个 G 的容量也绰绰有余