安卓开发收费会员系统,被反编译,一个用户的返回数据无数人嫖用!
一直对安卓的安全性很担忧,被反编译的可能性很高,反编译了竟然还能重新打包!!!无语了
APP 用 360 免费加固,不知道有没有 5%的可能性被完美反编译。
破解者用一个正常的账号从服务器请求到正常的会员信息,途中无论用什么加密。
因为 APP 被反编译了,在客户端最终会得到解密后的明文。
破解者是不是就可以用解密的明文肆无忌惮地免费用软件,还重新打包拿去倒卖
这样的局该如何破呢。。
好头痛,还是异想天开了?完全没有思路了
一直对安卓的安全性很担忧,被反编译的可能性很高,反编译了竟然还能重新打包!!!无语了
APP 用 360 免费加固,不知道有没有 5%的可能性被完美反编译。
破解者用一个正常的账号从服务器请求到正常的会员信息,途中无论用什么加密。
因为 APP 被反编译了,在客户端最终会得到解密后的明文。
破解者是不是就可以用解密的明文肆无忌惮地免费用软件,还重新打包拿去倒卖
这样的局该如何破呢。。
好头痛,还是异想天开了?完全没有思路了
目前可行的解决办法就是参考方正字体这种高额版权费呗。
话说你所说的这种情况,是有人重打包了你的 APP 然后放到网上骗了一些普通用户,普通用户在你这充了会员之后,重打包的那人通过这个 APP 得到了普通用户的登录态,并用普通用户的登录态来免费用你的软件?
这基本无解的啊,你只能是尽量确保所有正规下载渠道(应用商店)都覆盖到你的正版 APP,避免普通用户下到重打包的盗版。或者,通过法律手段解决问题。
然后是下的建议:
在线服务、服务端验证…这种都可以忽略了,这种会员可见的模式只能通过反逆向和风控来限制。
加密逻辑或安全要求比较高的代码采用 native 实现可行,但也只能是增加成本而已。
代码里埋坑是可以的,但必须得要让人难以分辨出是干什么用的,不要混在主要逻辑中,要不然很容易被发现。另外,由于对方已经反编译并重打包过你的 APP,所以如果你要埋坑的话,一定要先把代码混淆和加固弄好了再发出去,要不然别人可以很轻易地通过代码对比发现你埋的坑。
—
其实所有设备 ID 、签名信息之类的都不可信,说白了就是客户端生成一下的事情…还是得要结合实际业务逻辑来做风控。
道高一尺,魔高一丈,通过移动端去做只是增加了破解者破解的时间,你更应该从后台的反爬虫策略出发,还有就是上说的,保证几个正规的大渠道分发的都是你的包即可
至于后台的反爬虫策略,我不记得是豆瓣还是哪个平台,人家就算是收费用户在连续看了前几十页的内容后,后面的内容就不给看了,认为是爬虫程序在爬数据,为了反爬都做到这种地步了
其实应该高兴发现这种事情,攻防很有意思的。
据我了解,付费的商业加密有些比较高级的方法,是内存级的混淆,这个在我浅薄的 java 知识看来已经很难破解了。
把一部分代码从主程序里移出,放到服务器上,登录后从服务器下载加密的源代码,动态编译后,来实现这部分功能。这样只要他不登录,本地的代码无论如何都是缺失的,不可能跑起来。这个方式有哪些可行的可能?
客户端是不可信任的环境,客户端加固只能增加破解成本,但不能彻底避免破解问题,所以安全方面最好尽可能在服务端做。
可以尝试做互踢,同一个账号多人登录会踢掉当前已经登录的设备,服务端需要记录用户登录会话的状态,如果有重复登录的情况出现则强制让统一账号的所有现有的用户会话失效;这样被踢出的用户需要重新登录,可以使用基于后端判断的验证码等方式来提升登录操作成本(无法自动化登录,必须人工干预);以及检测到违规使用的情况就封禁账号,必须联系客服反映情况来解封,相应的风控规则最好写到用户协议里,避免投诉和法律风险。
然后一个 cookie 的有效期短一点
代理服务器的话可以判断请求 ip,除非别人服务器很多(成本问题)。然后可以做一些简单的异常分析,比如访问 A 页面的同时又在访问 B 页面
1.对自己的用户有足够的了解,在用户行为上做出限制。
正常用户用 app,肯定有操作路径,如果没有相应的操作直接请求接口,直接拒绝+黑名单。
用户协议写死了不能用第三方客户端,否可予以封号。
2.app 数据采集足够详细,该埋点往死里埋点,用户的操作详情以改善用户体验的名义上传。
具体展开可以看这篇文章:
https://mp.weixin.qq.com/s?subscene=23&__biz=MzI2MzE2NDczMw==&mid=2649738162&idx=1&sn=7337af200665862fd6592b263e1dad16&chksm=f25b6de0c52ce4f67e026c8066379c5fec6a9899811471ccef6bb74ccf4e22ac5d3c2f702b0e&scene=7&key=2cc21493b77c18de07e0c7b2f0c7df8284c8c3382227dbb70403bf33ff118eb1aa836e22afaf2401057c07a7ebc0303d6902fd5257415215568ed7bec797b5400f82817fd2941c78dbf293fbee052a6f&ascene=0&uin=MjkxMjAyOTM0MA%3D%3D&devicetype=Windows+10+x64&version=62090529&lang=zh_CN&exportkey=AdbThuhPM7pHajrPpqX9ttQ%3D&pass_ticket=VpiFKjDhyGkOpEoF9Jh97zJ8O2hp5nGA2EvbnN1ADuSy%2Fld71hBU1Ad49FE6Owz5
策略看这张图片:
如果你内容是纯静态的(比如文字),你还可以把屏幕转成视频直播,然后套上第三方支持 TrustZone 等的硬件级 DRM,这样抓屏都很困难,就不可能转给别人用。
如果你不舍得服务器资源,那可以简单一点,UI 在客户端渲染,但是 UI 逻辑全部在服务端,就是说所有用户的输入(比如坐标,事件类型)都是传到服务器,服务器计算 UI 要怎么更新,再发到客户端渲染,Java 里全部可以通过反射和 proxy 实现。然后你要限制比如说用户最快每秒点一次(因为点快了也来不及处理),他就很难复用账号了。
你还可以在内容 /UI 中加入一些识别是不是同一个人使用的验证,比如每过一段时间就要用户选则哪个操作是用户最近做过的才能继续(类似淘宝验证),账户复用的话,用户是不知道其他用户都做了什么的。
还可以恶心共享账户的人,比如强制绑定一个支付渠道,然后设置一些内付几毛钱才能使用的功能。
如果你觉得最终用户不知道他们是下了假的软件,可以偶尔把正常内容替换成验证信息,比如软件是授权给谁,举报账号复用有奖等。