1
YiXinCoding OP 有这种教程,但这部分工作量有没有可能省下来: https://juejin.cn/post/6844903857080778766
|
2
fruitmonster 4 小时 41 分钟前
“服务器端生成验证串的地方使用密钥对机器码进行签名,然后在客户端只需要用公钥进行签名验证,就可以判断验证串是否有效。”
没太明白, 服务端对激活码进行了签名,只有客户端的公钥能验证,那客户端被逆向了,拿到了对应的公钥,那不也有问题了么 |
3
jeesk 4 小时 35 分钟前
@fruitmonster 如果能操作设备内存, 那么怎么都不安全.
还是建议在应用第一次启动的时候生成 keystore, 然后携带这个 keystore 加解密. 即使 http 被监听也没啥, 解密不了. |
4
YiXinCoding OP @fruitmonster 防君子不防小人啊。替换机器码,替换公钥,也都有可能。编译后藏得深一点,多加几处校验。只能这样了。
|
5
skinny 4 小时 31 分钟前
前面你们说的,这就是为什么各种 App 都要想方设法的检测 Root 、虚拟机、提权、防篡改、App 签名,不然不可能安全的。
|
6
fruitmonster 4 小时 16 分钟前
假设有一个登记的接口暂且叫`小登`,每天限量 10 个,登记信息需要身份证 A 、登记码 B
登记码 B 来暂且叫`老登`,想要调用小登接口,必须要从`老登`来获取登记码 B ,登记码每天都是不同,都会更新 而 `老登`接口又不能随便获取,会验证签名、Token ,恰恰`老登`接口在微信小程序里,逆向,反编译不了,拿不到 token 和签名的计算方式, 那是不是这个登记接口`小登`和`老登`就是安全的了? |
7
FaiChou 4 小时 13 分钟前
确实比较麻烦。做移动端开发可以用系统的内购,比如苹果内购。但会有很多 fee 。
自己部署个发卡网站,自己后台验证确实挺麻烦。 我也想蹲一个解决方案。 |