title: How to protect Google In-App Billing v3 from code hacking?
body: <p>Google provides a <a href="https://developer.android.com/google/play/billing/api.html" rel="nofollow noreferrer">convenient API</a> to implement "in-app purchase" features on an Android app.</p>
  
  <p>Along with these docs, there is also a <a href="https://developer.android.com/google/play/billing/billing_best_practices.html" rel="nofollow noreferrer">dedicated chapter</a> regarding the security level of this system and the good ways to design it.
  The web is full of articles about this step, from <a href="https://stackoverflow.com/questions/14085279/in-app-billing-security">public key protection</a> to <a href="http://evendanan.net/2012/03/In-App-Purchase-Verification-using-PHP-OR-Making-sure-you-ain-t-getting-ripped-off-PHP-style/" rel="nofollow noreferrer">remote server validation</a>, but I really can't understand why all of these techniques should work when the main problem is, simply, <strong>code hacking</strong>.</p>
  
  <p>Maybe there is a better term to explain it, but let me do a quick example. The basic idea of my application is that, at certain points, the user can't proceed unless he has purchased an item.</p>
  
  <p>Something like:</p>
  
  <pre><code>public void accessTheVeryCoolFeature() {
  
      boolean haveIt = checkIfPurchased("verycoolfeature");
      if (haveIt) {
          // YEAH! let's open this very cool feature I paid 200 bucks for
      }
      else {
          // ok... where is my wallet?
          boolean purchased = startPurchaseFlow("verycoolfeature");
          if (purchased) {
              // my wallet is now empty but happy
          }
      }
  }
  </code></pre>
  
  <p>Following the previous guidelines, the developer can protect his app during the purchase process, letting the <code>startPurchaseFlow</code> method to query a remote, trusted, server that validates the receipt.
  Purchases done using a "fake marketplace" should be avoided by this.</p>
  
  <p>Another method is to protect the unlocked content by obfuscating the code. This is really simple with tools like ProGuard and should make the life of an "hacker" a bit harder.</p>
  
  <p>Now, I tried to act the part of an hacker that want to read my code, especially the billing phase.
  It took me like 1 minute to spot the code I wrote in the previous example. Now the best part: what if I edit the (obfuscated) source code to do this?</p>
  
  <pre><code>public void atvf() {
  
      boolean hi = cip("verycoolfeature");
      hi = true; // &lt;------------------------ AHAH!
      if (hi) {
          // YEAH! let's open this very cool feature for free
      }
      // ...
  }
  </code></pre>
  
  <p>All the good words about remote verification and code obfuscation are totally gone. So why spend hours on trying to implement them when the very first problem is in a <strong>boolean value</strong>?</p>
  
  <p>Am I missing something?</p>