InApp计费安全和远程方法调用

Blu*_*ell 15 java security android rmi in-app-purchase

我已经在应用程序中实现了应用程序计费,现在我想要更多地保护它.阅读开发者材料,它说:

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

内联方法转换为其他方法.

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

使用Java反射来调用方法.

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

混淆 - 很好我可以做那个= proguard

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

动态构造字符串 - 是的,所以将所有类常量变量排成一行 - 精细程序应该涵盖这一点

使用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;
}
Run Code Online (Sandbox Code Playgroud)

然后我可以做这样的事情:

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

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

这是一个很好的安全性,还是只是代码膨胀,让我的应用程序可以解决真正的用户问题?

谢谢.

Mat*_*lis 1

当盗版威胁明显增加时,您似乎可以考虑这一点。如果反射有可能损害用户体验,我就无法证明使用反射只是为了额外的一层混淆是合理的。

  • 所以等到我的应用程序被破解并分发..然后发布更新。你在微软工作吗? (8认同)
  • 呵呵,我只是觉得破解的包比较少,下载破解版的人也比较少。无论如何,您会从这些下载器中赚钱吗?我知道,作为程序员,我们被训练去假设最坏的情况,但需要某种平衡。 (6认同)