关于付费 APP 加密方式的一些疑问

可能因为我的水平有限，我所能想到的加密方式似乎都没有实际用处。

比如，某个业务场景是付费用户可以创建无限的素材，而非付费用户只能创建不高于某数量的素材。

虽然我已经用了各种方式来加密这个“某数量”的值，不过不管前面写的多绕，但是最终还是会回归到一个 if 逻辑判断。

比如，针对上述场景，我是这样写的：

    val a = "RWM="
    val b = a.decodeBase64()?.string(Charset.forName("utf8")) ?: "${Char(0)}${Char(0)}"

    val realNum = 10

    if (realNum <= b.toCharArray()[1].code - b.toCharArray()[0].code) {
        println("pass")
    }
    else {
        println("you need pay first")
    }

但是反编译下来是这样的：

（节选）

      if (realNum <= var8 - var3) {
         var4 = "pass";
         System.out.println(var4);
      } else {
         var4 = "you need pay first";
         System.out.println(var4);
      }

不管你前面写的有多复杂，最终还是会回归到简单的 if 逻辑判断，别人修改时只需要删除或者直接改一下这个判断就能轻松破解了。

判断是否付费同理，不管前面写的多复杂，最终会回归到简单的逻辑判断。

所以我现在加密完全依赖于加固，但是加固也只能防的住“脚本小子”一键破解，如果是有大牛专门破解的话，也很容易被脱壳。

虽然防住“脚本小子”已经满足我的需求了，但是我还是想知道，应该怎么在不加固的情况下避免被“一键”破解呢？

据我所知，某个业内有名的 APP ，就没有使用加固，但是就是至今没被破解，甚至作者还专门搞了个悬赏，让别人区破解它。据我了解的是，至今没人破解成功。

补充：

APP 性质决定了没法将需要加密的逻辑放到服务器避免被本地破解
上述代码只是做了一个示例，实际使用比这个复杂，而且核心代码也是写在 c++ 中的，不过正如我上述说的，即使写在 c++ 中，最终也是回归到 java 调用 c++的代码，然后做一个简单的逻辑判断
我想到的是把加密和业务逻辑混合在一起，但是自己实际测试过，即使这样反编译后效果也不理想。

i3x

2022-07-01 15:11:10 +08:00

@equationl 360 这个也不是解不了。虚拟机 dump 之类的都过时了。。。。暂时我还没发现安全的加固。只是难度不同罢了。我是个萌新，但是我目前木有发现解决不了的，解决不了的发给群里的大佬，几分钟就解决了，他们都有现成的环境。。。

冲你的目标，对付脚本小子来说，你自建一个混淆机制，不要用市场现有的，让他找不到脚本，没有真正的技术就解决不了了。

相关的防护我做的是比较多了。。。java php js 之类的代码保护，对于这些人来说，反倒是最不安全的自创逻辑混淆最安全。反而是你用标准的付费的高端的加密器，让他们很容易找到解密工具。先混淆到他们无法利用，在这个里边加几步授权，让这种人几乎完全无法利用就够了。

虽然对大佬来说写几个脚本就解密掉了。但是有一些逻辑也因为变量名字被替换，也是难以理解的，大佬对这种东西也不感兴趣，看一下结构自己都知道怎么写了，对破解这种东西根本就不感兴趣了。
至于你说混淆没有用，是因为你的逻辑太简单。你碰到一个授权不一定要在一个地方判断，很多地方判断搞好几十个逻辑，有的逻辑可能导致整个程序不可用，而有的逻辑会导致一部分比较恶心的东西。比如说有的地方校验不通过会随机性崩溃。程序不要做必然性的逻辑。还有存储这些判断逻辑，也不一定要存储一个固定的常量。可存储很多的值，有的数字是对的，但是是是而非。比如说你要存最大允许 10 个素材，你可以在一个地方出一个常量 10 。但是你根本就不调用这玩意儿，你调用的是 2*5 ，或者 9+1 。至于这个加减乘除怎么做你也不一定要存常量。可以从其它地方获得这个数字，就更难搜索定位了。有一些部分的逻辑自建类似于为加固的东西，用对称加密保护住。还有的功能做在网络上。虽然本地有逻辑，但是网络逻辑也作为额外的吊销手段。

当然只要你的东西足够有价值脚本小子没准就通过你的项目，成为大牛。。。