【问题标题】:InApp Billing Security and Remote Method InvocationInApp 计费安全性和远程方法调用
【发布时间】:2011-07-26 10:23:16
【问题描述】:

我已经在一个应用程序中实现了应用程序计费,现在我想进一步保护它。 阅读它声明的开发者资料:

除了运行混淆程序外,我们建议您使用以下技术来混淆您的应用内结算代码。

将方法内联到其他方法中。

动态构造字符串,而不是将它们定义为常量。

使用 Java 反射调用方法。

http://developer.android.com/guide/market/billing/billing_best_practices.html

混淆 - 我能做到 = proguard

将方法内联到其他方法中 - 这就是说,一旦我的代码完成,尽可能多地摆脱 OO 并将所有代码放在尽可能多的行中(对于我的应用程序的计费部分) 在一种方法中?这是否包括内联类?在 android 示例中,他们有一个常量类,我会内联所有这些吗?

即时构造字符串 - 是的,所以移动所有类常量变量 - 好的 proguard 应该涵盖这个

使用 Java 反射 - 这是我的主要问题。我应该调用所有我的方法而不是调用它们吗?

为了节省自己的精力,我可以这样做吗:

private static Object invokeMethod(String name, Class<?>[] params, Object[] args){
    try {
        return MySpecificClass.class.getMethod(name, params).invoke(null, args);
    } catch (IllegalArgumentException e) {
        // Should never happen in my code, ignore and cancel in app charge
    } catch (SecurityException e) {
        // Should never happen in my code, ignore and cancel in app charge
    } catch (IllegalAccessException e) {
        // Should never happen in my code, ignore and cancel in app charge
    } catch (InvocationTargetException e) {
        // Should never happen in my code, ignore and cancel in app charge
    } catch (NoSuchMethodException e) {
        // Should never happen in my code, ignore and cancel in app charge
    }
    return null;
}

然后我可以这样做:

private static boolean someMethod() {
    return true; // just an example
}

params = new Class<?>[0];
    if ((Boolean) invokeMethod("someMethod", params, null)) {
        // Do something
    }

这是良好的安全性,还是只是代码膨胀并让我的应用无法针对真正的用户问题进行调试?

谢谢。

【问题讨论】:

  • 我还想知道“内联方法”和“使用反射”点。这一切似乎都是巨大的痛苦。我想将你的方法变成巨型超级方法可能会有所帮助,尤其是在混淆名称之后。但是要在任何地方使用反射......(在下一条评论中继续)
  • ..但是到处使用反射会让我的头爆炸。您的反射方法很有趣,但我不确定它是否考虑了引发其他异常的方法(您没有全部捕获:catch (Exception everythingelse))。我想你可以重新抛出它并在它被调用的地方处理它。 但是您还必须考虑proguard。由于您将混淆名称,这会破坏您的反射,因此您需要将 -keep 规则添加到 proguard 配置文件中。因此,这些方法的安全性可能会稍差一些,因为它们可能具有有意义的名称。
  • 嘿,proguard 不会隐藏你的字符串。在运行时构造 then 并不意味着字符串连接。这通常意味着将它们从更模糊的状态(如字节或编码值)转换回运行时的原始字符串

标签: java android security rmi in-app-purchase


【解决方案1】:

当存在更高的盗版威胁时,这似乎是您可以调查的内容。如果它有可能损害用户体验,我将无法证明使用反射只是为了增加一层混淆。

【讨论】:

  • 所以等我的应用程序被破解和分发..然后发布更新。你在微软工作吗?
  • 呵呵,我只是觉得破解的包比较少,下载破解版的人也比较少。无论如何,您会从这些下载器中赚钱吗?我知道,作为程序员,我们被训练去假设最坏的情况,但需要某种平衡。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-07-29
  • 2012-12-14
  • 1970-01-01
  • 1970-01-01
  • 2020-01-12
相关资源
最近更新 更多