sticky
Protecting your Windows Store app from unauthorized use

    Question

  • Protecting your apps

    Windows Store app licensing provides base piracy protection for all apps acquired from the Windows Store. It protects your apps from being installed on unauthorized machines and from various attempts to tamper with your app or the system on which it is running. Recently, we’ve seen attempts from a small group of users to circumvent these protections, and wanted to provide you with some techniques that you can use to further ensure that only valid customers use your apps.

    About the licensing system
    When customers acquire your app from the Store, the licensing system registers a license for that app. This license is tied to a customer’s Microsoft account, and is validated against the user’s machine when the app is installed, launched or updated. If a valid license does not exist, the app won’t run.
    To help make sure customers run your app in the way that you intended, the licensing system also validates the integrity of your app logic installed by your app package. If this has been altered after installation, Windows displays a glyph in the lower-right corner of the app’s tile in the Start screen, letting customers know that something might be wrong with the app. When customers try to launch an app in this state, Windows prompts them to repair the app, which starts a reinstallation of the app from the Store. When this happens, a customer won’t lose any of the data or settings associated with the app—regardless of whether the alteration happened because of a hardware failure, potential fraudulent actions, or some other the reason.

    This design helps ensure users don’t mistakenly or unintentionally work around the protection systems that we have put in place to safeguard your apps. And, after the app is re-installed, customers can quickly return to enjoying the app as when they initially acquired it.

    Circumvention attempts
    Unfortunately, a few people have attempted to circumvent the Windows licensing system to get apps for free. These attempts fall into two types: modifying Windows system components, or modifying a specific app.

    Modifying Windows system components
    When an attacker wants to get access to a wide set of apps for free, or circumvent existing licensing restrictions, they may attempt to hack Windows directly. This strategy requires an individual to use their administrative privileges to replace or modify the behavior of Windows system components. When a user makes this decision, it often has implications well beyond the ability to acquire apps for free. The download packages that enable these exploits often carry malicious payloads that have significant adverse effects such as system instability, personal data loss and reduced performance.

    We have seen people use this method to extend trial durations, convert trials to full featured applications and to install an applications on more machines than 5 computers. Fortunately, Windows RT devices aren’t affected by these attempts, because these devices prevent installation of exploits that require installing untrusted code.

    To prevent users from employing this strategy to illegally use your apps, we have a receipt feature that allows you to validate a user’s access to your app and service. Your app is able to obtain a signed receipt for any app-related transaction made through the Windows Store, such as the initial purchase of the app and any in-app purchases. Your app can then use this info to determine what services or features it can access for that user. A sample of a user’s receipt info is shown here.

    <Receipt Version="1.0" 
    ReceiptDate="2012-11-25T11:34:05-08:00" 
    CertificateId="b809e47cd0110a4db043b3f73e83acd917fe1336" 
    ReceiptDeviceId="4e362949-acc3-fe3a-e71b-89893eb4f528">
      <AppReceipt
        Id="182A6BB6-A7CE-4040-94E9-44AF572D7FD5"
        AppId="contoso.SampleApp_5q2xcn1j1t576"
        PurchaseDate="2012-11-14T15:48:12-08:00"
        LicenseType="Full"/>
      <ProductReceipt
        Id="90576E27-037A-4AE1-8BB8-32BD5E92E940"
        ProductId="In App Product 1"
        PurchaseDate="2012-11-18T15:49:23-08:00" 
        ProductType="Durable"
        AppId="contoso.SampleApp_5q2xcn1j1t576"/>
      <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
          ...
      </Signature>
    </Receipt>

    The ID of each receipt element is unique per user (and device) and you can validate it on your server to confirm that the transaction is legitimate for that user and not a fraudulent transaction. This is especially valuable when your app has its own authentication mechanism because it allows you to validate that each user that appears to have purchased your app is, in fact, a unique customer. For more information about how to validate the receipt see Verifying purchases using receipts

    Modifying an app
    We’ve seen some people attempt to alter an app to modify its behavior or get access to your intellectual property by trying to modify your app directly. Often, this strategy is used to hide advertisements and gain access to content or features that they otherwise wouldn’t have access.

    There are several steps you can take to protect against this strategy—such as safeguarding elements that ship with your app and by designing your app so that the sensitive elements are on your server and not in your app.
    In the app, you can both obfuscate and encrypt the sensitive portions of your app. We believe that having a rich choice of obfuscation and encryption options—tuned to the types of exploits you are trying to thwart—will help you to take the appropriate steps in protecting your apps as necessary.

    You can also protect your more sensitive algorithms and business logic from reverse engineering by putting them on a server and not in your app. This keeps them in an environment that is completely in your control and requires that you only pass the initial data and the results between your service and your app. For even more protection, you can encrypt and decrypt static data or a data stream within your app by using the DataProtectionProvider class in the Windows Runtime.




    @danreagan || Team Manager, Windows Store Developer Solutions #WSDevSol || Want more solutions? See our blog! http://aka.ms/t4vuvz

    Thursday, November 29, 2012 8:54 PM