android 安全问题探讨

我都是直接 hook 然后在 okhttp 的地方把 log 开开完事

@zoharSoul 到了 hook 这一层了就没有什么必要了。拦住 99% 的破解就行了。 强行 hook 只是对抗而已。 增加破解时间罢了。

@jeesk #2 那这样的话 感觉 https 就够了

@jeesk 我分享下吧, 独立开发者，app 自上架以来一直被破解，2023 年年初时 下定决心用 flutter 重写，签名，加密解密，全在 Dart 层实现，7 月上架 Flutter 版，至今没看到一个破解版，flutter 解决了 Java 在 Android 上的安全问题，本来就是一个天然的 VMP

用 ecapture 抓包，你这种感觉防不住，最好还是对数据做个加密

@owen800q #4

抓包还是拦不住的，可以搜下 frida flutter ssl

破解倒是可以拦住，毕竟目前 flutter 似乎还没有一个较为可靠的分析器。

@flyqie 只要把全部包的请求体都在 Dart 层加密就好了，别人抓包也看不懂

@owen800q 同 all in flutter ，破解 flutter 属于 逆向 c 代码，网上相关的教程少，android 大部分教程都是逆向 java 。建议 flutter 再加上 dart 混淆配置，除了高手基本无法破解

防破解确实是个成本收益的问题，但是你如果认为 hook 就能拦住 99% 那就太理想化了。由于逆向工具的进步，学习 hook 的门槛非常低。你有正向开发的能力，半个小时学习一下 frida 甚至脚本都不用自己写，就能绕过绝大部分不设防的应用。

从知己知彼的角度上说，还是要了解逆向是怎么做的。精力放在抵御那些高度自动化的逆向方案上。

静态方面，一般防御手段是混淆和加壳。混淆可以某种程度上避免反编译后你自己的程序逻辑被分析，但是涉及到的系统 api 调用是不好藏的，所以聊胜于无。加壳对于大部分开发者来说门槛过高，选择加壳的时候，顺便搜一下对应的脱壳工具，大致上可以防技术不过硬的选手了。

动态方面，核心思路是将关键代码 native 化。同时 native 接口要采用互操作的形式，否则很容易被当作黑盒来直接调用。通常 hook native 只有在 onEnter/onLeave 环节能做一些记录入参，修改返回值的操作，所以拆解 native 逻辑避开这种利用方式也能防住很大一部分。

另外就是所有你认为的“检测”结果都不可信，这个事情哲学上就是你不可能判断自己是不是生活在虚拟世界是一个意思。相关的检测还是可以做的，但这种检测必然依赖 api 和特征，在 hook 环境中都可能是假象。检测到了随机插入假结果给逆向的人带来迷惑，远比粗暴禁用等手段有意义。这也是多数大厂的做法，用风控替代对抗。

抓包层面，大部分人都说了，除非你像 fb 一样自己实现 tls 库，不然都有自动化的解决方案。另外 ecapture 还是 hook 方案，知道的人少，被检测的几率小。如果项目合适，可以考虑用 protobuf 之类替代 http 。

@owen800q 问一下直接使用 flutter 重写就解决了破解的问题了么？还需不需要比如说加壳之类其他的加密措施？

@HojiOShi 不用，flutter VM 就是一个壳，你可以用 flutter 写一个空白的程序，就返回一个字符，反汇编后你不会看到那个字符，so 有几十万的函数，他怎么破