0

I published few months ago a free Android app with In App Billing where you can buy a durable product. When coding billing part, I didn't pay attention to order validation in fact I used with code when purchase was finished:

IabHelper.OnIabPurchaseFinishedListener mPurchaseFinishedListener = new IabHelper.OnIabPurchaseFinishedListener() {
        public void onIabPurchaseFinished(IabResult result, Purchase purchase) {

            if (mHelper == null) return;

            if (result.isFailure() && result.getResponse() == 7) {
                // Already bought
            } else if (result.isFailure()) {
                return;
            }

            if(purchase != null)
            {
                // add premium features
            }
        }
    };

I know it's not a safe check.

First question. Now I'm able to see through Analytics that I get transaction with two orderID types:

  • GPA.XXXX-XXXX-XXXX-XXXXX

  • [19 digits].[16 digits]

As I could understand, the second one was deprecated about 2 years ago (link), so why I'm still receiving that orderID? Also all the orders of the first type are visible in Google Merchant Console, while the second one are not. Is it safe to add a check on app start that retrieves the purchase and deactivate premium features if the related orderID is the second one?

Second question. Assumed that it's probably an hack and also assumed I don't think it worth to perform server-side checks, would make it safer is I implement a verifyDeveloperPayload when purchasing? As far as I could understand, most of the hacks in circulation (like Freeedom) don't spoof the developerPayload, which is computed at runtime based on Google account ID, so it should be enough.

Community
  • 1
  • 1
fillobotto
  • 3,698
  • 5
  • 34
  • 58

1 Answers1

1

I'm answering my own question because no one else did and I had gathered more information about this.

To the first question: If you receive orderIDs with the old format, just discard them because they are likely to come from Lucky Patcher and other similar tools trying to spoof orders.

To the second question: Most of the above quoted tools, also spoof developer payload and replay it in the response JSON, so don't trust it.

In the end, implementing a server side verification will definitely secure your application from IAB hacks. Of course, they can still decompile it and remove server checks, but you all already know this story.

fillobotto
  • 3,698
  • 5
  • 34
  • 58
  • Most of the hack attempts we get also seem to be these old orderIds. This seems a bit weird, I'm curious why hackers would use the old orderIds over the new ones? – baris Jul 23 '17 at 16:02
  • For orders with these old orderIds, when we try to verify them on GooglePlay, they also have a wrong length signature (usually 248, 249, 252 bytes instead of 256). Did you come across that as well? – baris Jul 23 '17 at 16:04
  • @baris maybe they put this backdoor so that they would have been able to get over their own creations easily. Never checked the actual signature though – fillobotto Jul 25 '17 at 07:52