Google Play In-App Billing Library Hacked


I successfully exploited two bugs in Google Play In-App Billing Library, which allow to impersonate the Google Play billing service and circumvent the signature verification. I was able to retrieve unlimited amounts of in-app items in games like Temple Run 2, which uses this library.

Edit 0: More information about the disclosure process
Edit 1: Timeline added
Edit 2: Apology from Google

This blog post was released earlier than previously negotiated with Google, because Google was unable to provide proper attribution (they even stated “we recently discovered” in an email sent to Android developers). Additionally, they ignored questions regarding other bad security practices in this library. More information can be found before the conclusion.









Vulnerable libraries

All Google Play Billing Library v3 versions before Oct, 8 distributed via Android SDK and marketbilling on Googlecode.

Problem description

  1. Any app can define a new intent-filter with a high priority to impersonate the official in-app billing service. See my AndroidManifest.xml how to do that.
  2. Signature verification returns true if given INAPP_DATA_SIGNATURE is an empty String (“”).

Proposed fixes

Browse the diff 7bc191a004483a1034b758e1df0bda062088d840 and merge the modifications into the appropriate parts of your code.

Proof of concept

  1. Clone, compile the project, and install the APK on your device.
  2. Then install Temple Run 2 or similar apps, and go to the in-app items and “buy” some items.

Remarks about the vulnerabilities

The impersonation vulnerability is quite interesting, because it shows that an Android principle regarding IPC with Intents was ignored. If an app, e.g., Google Play Services, registers an Intent filter providing an AIDL remote service, any other app can also do that using the same name. To prevent collisions, the simplest fix is to restrict the scope of of the Intent used for binding to that service from client side by setting bindIntent.setPackage(“”).

The other bug is a typical crypto implementation fail, but there is also a take-home message here. The verify method checks if the signature String is empty before going on to the actual verification. Unfortunately the method returns true per default at the bottom of the method. In my opinion verification methods should be always programmed with this in mind: always return false, return true only on success!

Remarks about responsible disclosure process

I reported the bug via and they confirmed my findings after 7 days and commited 7bc191a004483a1034b758e1df0bda062088d840. They told me that they will send emails to “high visibility partners”, so they can fix this bug before disclosure and asked for 4 weeks until I go public. I answered that I want to be mentioned in those emails, but got a response that states “[…] we are unable to provide attribution.” without further reasons. Besides answering slowly and skipping some questions I sent, this is unfair behavior and clearly a violation of common practices in vulnerability research. 5 days later I received an email to my Google Play developer email account, informing me about the following:

“If you previously used the In-app billing sample code to build your in-app billing system, please use the recently-updated sample code as it addresses an exploitable flaw we recently discovered (note that this only affects the helper sample code; the core system and in-app billing service itself was not affected).”

Conclusively, I think it’s unfair that they were unable to provide attribution, especially as I explicitly asked about mentioning me as a security researcher in prior communication with them. Additionally Google payed no bug bounty, although this library is quite important as many app developers rely on it for in-app billing.

Google’s apology

Google sent me an email yesterday apologizing for not providing proper attribution. I really appreciate this! Thanks for rectifying your behavior:

“I want to apologize for the initial lack of public credit for your discovery of a security bug in the market billing library, and our improper claim that the issue was internally discovered. This was the result of inadequate communication on our part. It was a mistake, and I want to make sure we correct it. We are now providing proper attribution in the README for the library:


2013-10-02 Report to
2013-10-05 Response that they are “investigating now”
2013-10-09 Confirmation of this bug, bug fix commit, and they told me that they will inform “high visibility partners”
2013-10-09 I answered that I want to be mentioned in those mails (besides another question)
2013-10-16 They answered that they “are unable to provide attribution”
2013-10-21 I received the email to my developer account address
2013-10-29 Public disclosure in this blog
2013-11-08 Apology from Google


If you are a programmer, consider working with us on OpenPGP Keychain to provide secure emailing for Android. I will help on pull requests and be happy about every commit!

Post navigation


  • GeorgeH

    Nice research, thanks for publishing it.

  • Jon

    Thanks for sharing. Why didn’t they pay a bug bounty?

  • Dancger

    Thanks for publishing, works great. Imho, Google has acted wrongly. However, you deserve my respect!

  • infosec

    Thanks for Proof of Concept, weird that Google didn’t pay for this, but it may not be in their scope. Still, great work! Cheers.

  • enkhchuluun

    Great research. Thanks the effort

  • steph

    Good job Dominik!
    Hey Google, haven’t you ever heard about code auditing ? Especially for not a such 😉 important thing for your business ?
    And for me, you’ve made the right decision on publishing : unfair is the right word. Sad reaction from them :-/

  • MichaelG

    The fix is still hackable the same way Android LVL is. The hacker can just patch the Google Play service to always return true on the transaction and he can also patch the Java VM to always verify the signature of the data. So both inapp billing and the Android LVL are still vulerable unless someone reimplements them in a secure manner. As far as I know only the folks at Cryptanium have an answer for that.

  • Eric Zhang

    No attribution for this? Google really needs to step it up.

  • Ben

    Androids in-app-billing has been hacked quite a while ago and I know of at least one fully working exploit still going through the net. So that’s no big news, though I don’t know which security flaws are being used in that.

  • rob

    Google totally sucks at supporting payed services, as the disappearing accounts bug for payed apps in Android 4.1.2 ist still not fixed in any way, though its the most used version.

    Nice work though!

  • Dominik

    You are talking about exploits requiring root access or decompiling/repackaging APKs. My Demo app requires zero permissions.
    Everything can be “hacked” if I have full access to the memory of running apps.

  • Pouni

    Can’t believe how Google is reacting.
    I’ve been trying to compile the PoC for the entire afternoon, without success… If someone could send me the compiled .apk of the Proof of concept, it would be really nice. Here is my email:

  • john

    does this need a rooted device?

  • X41

    [link removed]
    you’re welcome

    Edit: Sry, but please don’t post links to compiled apks.

  • h66

    Nice! Love the disclosure way!
    Man did you receive the bounty for this bug?

  • James Dand

    Great hack!! I’ve compiled and tried it with different games to test the POC. So far no success, newer recent games go directly to google wallet to pay. In others I do get the “Billing Hack” pop up but the purchase fails after the “checking for billing information” screen.

    Never the less, congrats for the hard work and I hope you get the credit you deserve.

  • jon doe

    Using this method I bought a couple hundred dollars worth of stuff from play store for free.. That I didn’t even need. Just to mess with Google for not giving you a bounty or any credit.. Great work mate!

  • Sangam Yadav

    Thanks for such a great search :)

  • Dominik

    Please, no more questions regarding a compiled APK. If you like to test this exploit you should be intelligent enough to compile it on your own.

    I have and will delete those comments.

  • Jonathin

    Dude did you get a bouny for this bug?

  • Vijay

    Plz give me step by step instructions… im confused …

  • Vijay

    Is this work for Online Games like Octro 3 Patti….

  • nick

    thanks for great sharing research.

  • Yaniv Nizan

    Hi Dominik,

    We realized that one of the members of our open source community contributed a fix based on your code to the SOOMLA framework ( Here is the pull request if you want to take a look.

    I looked up your repo in Github and there is no mention of a license so I’m contacting you to know if its ok to use your code or if we need to take it out.

    Please email me back to



  • Tangela

    They can have a far more protected experience on a
    dedicated console system. Upgrade the collectors
    and mines to as high a level as is possible at this
    stage. If he notices that you are tracking his gaming hours, tension between both of you may rise.

  • sat

    Hey dominik ..
    Can u pls tell me how to hack octro teen Patti
    I have rooted my device n have full access
    Its saying

  • John


    Some apps that hasn been updated to may-june 2015 has patched your billing hack. please find another bug again so i can cheat Shadow Fight 2 and Perfect Shift again :(

  • raghav

    Please can you help me in hacking clash of clans.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" cssfile="">