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
