InApp Billing Security and Remote Method Invocation

Question

I've implemented in app billing in an app, and now I want to secure it a little more. Reading the developer material it states:

In addition to running an obfuscation program, we recommend that you use the following techniques to obfuscate your in-app billing code.

Inline methods into other methods.

Construct strings on the fly instead of defining them as constants.

Use Java reflection to call methods.

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

Obfuscation - fine I can do that = proguard

Inline methods into other methods - is this saying once my code is complete, get rid of much OO as I can and put all my code in as many lines as I can (for the billing part of my app) in one method? Does this include inlining classes? In the android example they have a constants class, would I inline all these?

Construct strings on the fly - yes so move all class constant variables in line - fine proguard should cover this

Use Java Reflection - this is my main question. Should I invoke all my methods instead of calling them?

To save myself some effort could I do this:

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;
}

I could then do things like this:

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

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

Is this good security, or is it just code bloat and making my app undebuggable for genuine user issues?

Thanks.

Lorgnon

I was also wondering about "inline methods" and "use reflection" points. It all seems like a giant pain. I suppose turning your methods into giant-super-methods might help a bit, esp after obfuscating names. But to use reflection everywhere... (continued in next comment) – Incorrupt

..But to use reflection everywhere would make my head explode. Your approach for reflection is interesting, but I'm not sure if it accounts for methods that throw other exceptions (you didn't put a catch all: catch (Exception everythingelse)). I suppose you can rethrow it and handle it where it's called. But you also have to account for proguard. Since you'll be obfuscating names, that will break your reflection, so you need to add -keep rules to the proguard config files. So maybe those methods will be slightly less secure since they will probably have meaningful names. – Incorrupt

Hey proguard doesn't hide your strings. To construct then at runtime doesn't mean string concatenation. It typically means converting them from a more obfuscated state like bytes or encoded values and back to the original string at runtime – Rapt

Answer 1

This seems like something you could look into when there is a higher demonstrated threat of piracy. I wouldn't be able to justify using reflection just for an extra layer of obfuscation if it had a chance of compromising the user experience.

Yuma

So wait till my app has been cracked and distributed .. then issue an update. Do you work for Microsoft? – Lorgnon

Heh, I just think that relatively few packages are cracked and relatively few people download the cracked versions. Would you be making money from these downloaders anyway? I understand that as programmers we're trained to assume the worst, yet some kind of balance is demanded. – Yuma