Select a language to translate this page!
Powered by Microsoft® Translator
If you are developing applications for Windows phone, you have probably read about the Standard and Advanced Anti-Piracy Protection available to developers to help protect your hard developed IP. If you haven’t done so yet, check out the Windows Marketplace anti-piracy model white paper available here. Advanced Anti-Piracy Protection (AAPP) is designed to thwart the illegitimate sharing of your Windows phone applications. Even if a hacker obtains the binaries from one device, AAPP will prevent that application from running on any other device. While Standard Anti-Piracy protection does not require any intervention by the developer, AAPP does require that you integrate code into your application. We will walk through how AAPP works, how you obtain the AAPP code from Microsoft and how to integrate the AAPP code into your application.
Installation Time: The Marketplace Client installs a license, derived from the application id and the device id, into the registry. The license is protected using RSA security.
Application Run Time: The startup code (obtained from the Marketplace section of the Windows phone Developer Portal) in your application verifies that the license stored in the registry matches your application. You (the developer) has control over the error handling. You can choose to display an error and quit, shift into ‘demo’ mode, or do whatever you deem appropriate.
Obtaining the AAPP code is part of the application submission process. You will see the following at Step 3 (Product Info).
Clicking on ‘Show Managed Code…’ we see the following code:
This code has all the basics you need to implement the Advanced Anti-Piracy Protection. However there are a few gaps that you need to fill-in. I’ve put together a sample (HelloAAPP) that has these issues worked out. You can download it from here.
Please let me know in the comments if there any other gaps in the AAPP code that you have had to fill.
I've already answered wieser's question in the MSDN forums, but for the sake of any one else reading I am reposting. Your certificate is unique to your publisher ID. So your cert modulus and cert exponent won't match some one elses. If you download another's app you won't know their cert mod/exponent and thus cant use their license. You will need to use your own app.
I uploaded an app, got it certified, and then "purchased" it for free so that I would have a key on my device that I could use for testing.
Started submission of a product, so I could get to the code, and sure enough, Modulus and CertExponent are different from the listed example.
Further to my earlier post, downloaded two freebie apps (one microsoft, and one from somewhere else), but alas, Joe's trick didn't work.
So is it just my device, a bug in my code, or would we expect it not to work, because the CertModulus and CertExponent are in fact different for each product.
Regarding Joel's suggestion, Are the CertModulus and CertExponent always the same for every app, or does marketplace switch them around occasionally?
Apparently this mechanism has been cracked, according to this site:
Looking at the reported work around, it sounds like intercepting the call to the VerifyData call, and always returning true.
So, to make this hack not work, we'd need to poke in some data that we know is wrong.
So here's the question:
Can one guarantee that by changing a single bit in the data to be verified, the hash will always be different? If so, we could detect this interception from a false positve.
Thanks Joel. That's a clever way to test with a real license.
If you have a free application in the Windows Marketplace for Mobile then you may be able to use it to test this code. Install your free application and the license will be installed to. During the development of your code set the app ID to be the same as what it is in your free application and now you can see how your code behaves in the presence of the proper license key.
Thanks MAZZTer - Yes. The registry access should be wrapped in a using statement. Thanks for pointing that out.
One thing that jumps out at me with that code block is that you open a registry key but never close it. I'm guessing .NET will close it for you once the RegistryKey object goes out of scope and gets destroyed. I'm not sure when .NET does that in this circumstance... possibly after Main() finishes, making it more important since it'll only close the key after your app is closed, although if .NET is smart enough it'll realize it goes out of scope after that line of code. Of course, even when it does go out of scope, no guaranteed it will be destroyed immediately. Best to leave no uncertainty and free resources manually when the option is available, IMO.