其实写习惯了并不会有什么困扰，别嵌套太多层，没那么容易写错。

这玩意儿主要的问题还是：跟现代 IDE 协作不太好。写其它语言很多时候先复制一段代码然后 format 来自动调整，但 python 里就没法这么干

@xiaoshan5733 AS 第一次打开大项目确实会慢点，但“最少都要十几分钟”（你开发的是什么，微信吗？），“每次打开都会”，这就不只是 AS 的问题了……肯定是使用姿势哪里出了问题。

1. 防重放的 nonce 可以服务端生成下发。
2. 仅客户端也可以做防重放的，加固了解一下。别说什么加固也可以破，现实是就是有很多加固现在还好好运行在那里没被破。

如果量不大的话根本不需要考虑那么多……我天天用自己的 GPT3.5 token 跑沉浸式翻译，一个月的账单就十几块钱。这个开销跟免费也没啥区别了。

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