安卓开发收费会员系统,被反编译,一个用户的返回数据无数人嫖用!

2020 年 7 月 10 日
 atfeel

一直对安卓的安全性很担忧,被反编译的可能性很高,反编译了竟然还能重新打包!!!无语了

APP 用 360 免费加固,不知道有没有 5%的可能性被完美反编译。

破解者用一个正常的账号从服务器请求到正常的会员信息,途中无论用什么加密。

因为 APP 被反编译了,在客户端最终会得到解密后的明文。

破解者是不是就可以用解密的明文肆无忌惮地免费用软件,还重新打包拿去倒卖

这样的局该如何破呢。。

好头痛,还是异想天开了?完全没有思路了

23712 次点击
所在节点    Android
68 条回复
wupher
2020 年 7 月 10 日
1. 不要信任所有的客户端请求,包括浏览器,App
2. 在服务端进行安全验证和控制,返回相应的数据。
tctc4869
2020 年 7 月 10 日
@wujieyuan 代理服务器的破解方式,服务端有没有什么办法?
Vclow
2020 年 7 月 10 日
只能增加反编译成本,铁了心搞你真心很难反抗。
wujieyuan
2020 年 7 月 10 日
@tctc4869 代理服务器的话, 服务端没有办法, 我目前能想到的我上面的帖子已经说过了, 就是埋单上报, 看看客户端是不是篡改了域名, 签名等等, 如果破解者够耐心或者够聪明, 删掉了上报代码, 那就没有任何办法了
wujieyuan
2020 年 7 月 10 日
@tctc4869 我说的上报其实比较笼统, 可以灵活运用, 也不一定需要上报, 比如在 native 中检测, 如果发现异常直接退出等等, 不过这些手段都可以被干掉, 无非就是增加一点破解难度
tctc4869
2020 年 7 月 10 日
@wujieyuan 拿这种方式可以不,就是动态编译(如果 java 有的话),

把一部分代码从主程序里移出,放到服务器上,登录后从服务器下载加密的源代码,动态编译后,来实现这部分功能。这样只要他不登录,本地的代码无论如何都是缺失的,不可能跑起来。这个方式有哪些可行的可能?
libook
2020 年 7 月 10 日
其实 iOS 安装包本身的安全性可能还不如安卓,只不过 iOS 大家一般用非越狱系统,统一从 App Store 下载应用可以规避很多安全问题,顺便提一下,如果 iOS 应用加固力度过强可能会被 App Store 拒绝,因为会被怀疑是马甲 App (让人琢磨不透的苹果¯\_(ツ)_/¯)。

客户端是不可信任的环境,客户端加固只能增加破解成本,但不能彻底避免破解问题,所以安全方面最好尽可能在服务端做。
可以尝试做互踢,同一个账号多人登录会踢掉当前已经登录的设备,服务端需要记录用户登录会话的状态,如果有重复登录的情况出现则强制让统一账号的所有现有的用户会话失效;这样被踢出的用户需要重新登录,可以使用基于后端判断的验证码等方式来提升登录操作成本(无法自动化登录,必须人工干预);以及检测到违规使用的情况就封禁账号,必须联系客服反映情况来解封,相应的风控规则最好写到用户协议里,避免投诉和法律风险。
dingwen07
2020 年 7 月 10 日
之前听说过一个防止账号共享的方法:
让改邮箱和密码变得极为简单 不需要邮件验证什么的
hongfushi
2020 年 7 月 10 日
有意思,看来还是只能从经济角度考虑,不然总有破解方法。
no1xsyzy
2020 年 7 月 10 日
最终解“按量付费”。
听你的说法这是个 SaaSS,就按计算发生的次数付费。
一种比较可用的变形是限制单位时间的使用次数,这个次数限制对大部分用户来说基本不可能用完。
比如见过每分钟 20 次查询的限额,转手代理服务器卖就很难不超过 20/min 。
并且一旦发现这样的服务,立刻向各个渠道宣传。
让众包羊毛党薅死他这个转包的羊毛党。
no1xsyzy
2020 年 7 月 10 日
俺寻思按量付费也不是什么新鲜玩意。
为什么在整个互联网 ICP 基础设施全面转向按量付费的情况下,程序员的诸位想不到按量付费?
(bgm38)深深地表示惋惜!
iyaozhen
2020 年 7 月 10 日
帐号互踢不就行了

然后一个 cookie 的有效期短一点


代理服务器的话可以判断请求 ip,除非别人服务器很多(成本问题)。然后可以做一些简单的异常分析,比如访问 A 页面的同时又在访问 B 页面
HappyFox
2020 年 7 月 10 日
这个是风控的问题,如果不是职业相关,个人开发者想解决这些问题其实怪麻烦的。说一下我的思路,抛砖引玉。

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

策略看这张图片:
SenLief
2020 年 7 月 10 日
客户端返回的信息都是不可信的。
如果不是多端的话那就互踢是最省事的,比如爱奇艺。
最直接的手段就是限制设备的个数,比如 1 手机 1pc,然后接着互踢。
再次一点就是拉黑名单,比如 1 天请求登陆了很多次,那肯定是搞事的,直接把账号 ban 了,并发账号被盗,解封。
最直接的就是迭代版本的速度快一点,每次换个方式混肴,也会大大增大难度了。
Jirajine
2020 年 7 月 10 日
@wujieyuan 一众“流媒体解锁”服务不就是这么搞得么,通过服务器反代+共享账号,netfl1x 都没什么好办法应对。
hoyixi
2020 年 7 月 10 日
自己合法吗,合法的话,损失大可以报案。
jones2000
2020 年 7 月 11 日
只要数据是在后台的,前端怎么破解都没关系的呀, 最后的验证都在后台服务器的, 账户通过在线数来限制,1 个账户允许 2-3 个设备在线,在多的连接就直接剔,或直接锁账户, 让用户手机验证改密码解锁。
billccn
2020 年 7 月 11 日
我有一个终极的办法:把你的客户端变成 VNC,所有逻辑和 UI 在服务器上跑。这样他也没法把几个账号复用了,因为同一个账号同时只能有一个人能正常操作,账号复用多个人同时操作要打架了。

如果你内容是纯静态的(比如文字),你还可以把屏幕转成视频直播,然后套上第三方支持 TrustZone 等的硬件级 DRM,这样抓屏都很困难,就不可能转给别人用。

如果你不舍得服务器资源,那可以简单一点,UI 在客户端渲染,但是 UI 逻辑全部在服务端,就是说所有用户的输入(比如坐标,事件类型)都是传到服务器,服务器计算 UI 要怎么更新,再发到客户端渲染,Java 里全部可以通过反射和 proxy 实现。然后你要限制比如说用户最快每秒点一次(因为点快了也来不及处理),他就很难复用账号了。

你还可以在内容 /UI 中加入一些识别是不是同一个人使用的验证,比如每过一段时间就要用户选则哪个操作是用户最近做过的才能继续(类似淘宝验证),账户复用的话,用户是不知道其他用户都做了什么的。

还可以恶心共享账户的人,比如强制绑定一个支付渠道,然后设置一些内付几毛钱才能使用的功能。

如果你觉得最终用户不知道他们是下了假的软件,可以偶尔把正常内容替换成验证信息,比如软件是授权给谁,举报账号复用有奖等。
Niphor
2020 年 7 月 11 日
付费账号 只准一个 IP 在线
loginbygoogle
2020 年 7 月 11 日
flutter 教它做人

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://study.congcong.us/t/688777

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX