Windows Mobile Developer Blog

Windows Marketplace for Mobile: Advanced Anti-Piracy Protection

Mike Francis — Fri, 15 Jan 2010 23:16:52 GMT

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.

How Advanced Anti-Piracy Protection works

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.

How to obtain the AAPP Code

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:

 using System.Runtime.InteropServices;
using System.Security.Cryptography;
using System.Text;
// ....
static string m_certModulus = "a26T2aaMKaafWSaI5JOaaQ7...";
static string m_certExponent = "DUPQ";
static string m_appSku = "dddddddd-70e8-4b15-9c90-46fca72d6959";
[DllImport("coredll.dll")]
private extern static int GetDeviceUniqueID([In, Out] byte[] appdata,
    int cbApplictionData,
    int dwDeviceIDVersion,
    [In, Out] byte[] deviceIDOuput,
    out uint pcbDeviceIDOutput);
static void Main()
{
//Pre-Initialization code
// ....
byte[] licenseBytes = 
    Microsoft.Win32.Registry.CurrentUser.OpenSubKey(
    "Security\\Software\\Microsoft\\Marketplace\\Licenses\\")
    .GetValue(m_appSku) as byte[];
string data = m_appSku.ToLower() + " " + GetUniqueDeviceID();
RSACryptoServiceProvider rsa = new RSACryptoServiceProvider();
//Create a new instance of RSAParameters.
RSAParameters RSAKeyInfo = new RSAParameters();
//Set RSAKeyInfo to the public key values. 
RSAKeyInfo.Modulus = Convert.FromBase64String(m_certModulus);
RSAKeyInfo.Exponent = Convert.FromBase64String(m_certExponent);
rsa.ImportParameters(RSAKeyInfo);
byte[] bData = System.Text.Encoding.ASCII.GetBytes(data);
if (null == licenseBytes || 
    !rsa.VerifyData(bData, new SHA1CryptoServiceProvider(), 
    licenseBytes))
{
    MessageBox.Show("Could not verify signature");
}
else
{
    MessageBox.Show("License is valid!");
}
// ...
// Post-initialization code
Application.Run(new Form1());
}
 
public static string GetUniqueDeviceID()
{
// Call the GetDeviceUniqueID
byte[] appData = Encoding.Unicode.GetBytes("Marketplace");
int appDataSize = appData.Length;
byte[] outData = new byte[20];
uint outSize = 20;
GetDeviceUniqueID(appData, appDataSize, 1, outData, out outSize);
StringBuilder resultSB = new StringBuilder();
foreach (byte b in outData)
{
resultSB.Append(string.Format("{0:x2}", b));
}
return resultSB.ToString();
}
 

Integrating AAPP Code into your Application

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.

The code provided by the portal does not catch NullReferenceException thrown by the Registry class if the license key cannot be found. This is most commonly caused by installing the CAB outside of the Marketplace client. This is because during installation, the Marketplace client installs the license into the registry. Most often you will see this during your own ad hoc testing. To help you avoid this error, in Debug mode, the sample installs a test license into the registry. Additionally the sample includes a handler for this exception.
In the portal code, if the validation succeeds or fails, the application will still run. In most cases you will want to notify the user and exit. The sample displays an error message and the application exits following the users response.
In the portal code, if the validation succeeds, the code will notify the user telling them so. This notification is probably not necessary in a real world scenario. The sample simply continues if the validation succeeds. Note that in the sample the same validation (VerifyData) is called in both Debug and Release modes. In Debug mode the test license is validated using the test key. In Release mode the real license is validated using the public key included in the developer portal code.
In the portal code, the error message does not have any context. A (hopefully) clearer message “License verification failed. Please install via Windows Marketplace for Mobile.” is used in the sample.
In the portal code, there is no way to test the validation logic since there is currently no way to install a license. As mentioned above, the sample creates and uses a test license that tests the validation logic. This goal of the sample is to demonstrate a way to use a test license in Debug mode and a real license in Release mode with all other code being the same.
The error message is not localized. In the sample, the message is localized in English and German (de-DE).

Please let me know in the comments if there any other gaps in the AAPP code that you have had to fill.

Thanks,

Mike

New Windows Mobile Developer Certificates

Roshan Khan — Tue, 12 Jan 2010 19:43:52 GMT

As of 12/31/2009 the test certificates that shipped with the Windows Mobile SDK expired. However, we’ve gone ahead and generated new certificates that you can drop in to rectify this problem.

If you’re a developer you can put these certificates right into Visual Studio (or sign via command line). If you’re a tester, you can follow these instructions to create a provisioning file for a device, so that you don’t need Visual Studio to push certificates onto test platforms.

Download new certificates here.

Windows Marketplace for Mobile – a Worldwide Marketplace for Developers

Frank Prengel — Wed, 18 Nov 2009 11:35:00 GMT

Hello there, my name is Frank Prengel, and I’m a technical evangelist at Microsoft Germany, helping the Windows phone and Marketplace teams establish Windows Marketplace for Mobile in my country. Since I work with the German developer & ISV community, let me share with you some thoughts from a local perspective – they may help you develop for Marketplace, especially if you live outside the US.

Let’s first remember that Windows Mobile has always had a very active developer community, and that it gives you freedom in how software is developed and distributed. There are more than 20,000 Windows Mobile applications today which you can get and install from Web sites, software portals, forums, etc. – provided you are a tech savvy person, and you know how to do it. With Windows Mobile 6.5 we have begun addressing non-tech savvy consumers as well. This is exactly why we introduced Windows Marketplace for Mobile as an easy way for people to find and install additional software on their new Windows phones.

If you are a developer, this means one thing for you: an additional great opportunity to potentially reach millions of new customers. Windows Marketplace launched with commerce in 20 markets as well as developer registration support in 29 markets, more than any other app store at launch. It offers credit card as well as mobile operator billing, and self-serve refunds of certified apps. It now supports Windows Mobile 6 and 6.1 and even allows for browsing and purchasing apps from the PC, with over-the-air synchronization to the user’s Windows phone. If your goal is to expand your business or the reach of your software, you should take the opportunity to join. For more information on the recent Windows Marketplace updates, including availability on 6 and 6.1, accessibility to browse and purchase apps from the PC and antipiracy protection benefits for developers, check out Todd Brix’s blog post at the Windows Mobile Developer Blog, and Eric Nelson’s post at the Windows Phone Blog.

As with every retail marketplace, there is a bit of administrative work involved. Windows Marketplace for Mobile is a new service and a fresh approach that improves frequently with feedback from the developers and ISVs we work with. We are committed to continually improving the entire experience as we learn more about developer and customer needs and behavior. (If you find that Marketplace is not the right distribution channel for your business model, after all, you can of course use any other channel, such as those mentioned above, as they continue to be available. Windows Mobile means freedom of choice.)

If you are in the US, signing up and getting apps certified should be pretty straightforward by now. In other countries there may be additional steps related to the business and financial processes involved. There also is localization work to be done when you want to submit products to several markets, as the application needs to be localized in the proper language (including the screenshots and descriptions). If there are any questions during this process, your first support resource is the Windows Marketplace help page. You can also use the contact form in your Windows Marketplace portal, and ask for help or information. Then, we have a dedicated forum where team members try to answer your questions as quick as possible.

Beyond all that, in some countries there are additional dedicated resources that you should know – let me take Germany here as an example: We have a dedicated Windows phone blog with news and a contact form for questions, we have our local Windows Mobile Developer Center on MSDN, a Twitter channel, a comprehensive introductory document on Windows Mobile development, a webcast series – we even have an exciting local developer contest which complements the global one!

You see, there are a lot of great resources that should help you get started with Marketplace. Don’t miss this great opportunity to expand your mobile business. Good luck!

Frank

Announcing New Features in Windows Marketplace for Mobile

Todd Brix — Wed, 11 Nov 2009 21:47:58 GMT

I’m pleased to introduce a few much anticipated upgrades for Windows Marketplace for Mobile going live today. We introduced Windows Marketplace with the launch of Windows phones on October 6^thand promised a second wave of features in November. Today, we’re adding more advanced anti-piracy protection and an improved developer portal for our registered ISVs, as well as introducing PC based shopping and account management for Windows phone customers.

Developer portal improvements and stronger anti-piracy protection

We’ve been gathering input on what we can do to improve the developer experience and have made some subtle but important enhancements to the developer portal to enable easier uploading of images, greater insight into account status and several other refinements based on feedback from developers. Today’s update also provides more advanced anti-piracy protection. While the underlying technical changes will be transparent for customers, developers will now be able to take advantage of these new protections by following the steps outlined in this anti-piracy whitepaper. As always, updates to existing applications can be submitted for free. To learn more about developing applications for Windows phones, head over to the Windows Mobile for Developers site.

Browse and buy applications from the PC
While we’ve heard great feedback on the Marketplace experience on Windows phones, sometimes people just want the benefits of a shopping on a PC. Starting today, Windows phone customers can browse, buy and download applications online at the Windows Marketplace for Mobile site. The selected applications are delivered wirelessly to the customer’s Windows phone and install the next time the Windows Marketplace client runs on the device. This creates another way for customers to easily find and purchase applications and gives developers a whole new level of exposure.

Marketplace has been extremely active and I couldn’t be happier with the reactions from both developers and customers. We’ve been open for just over one month and already we can see that there’s demand for an application marketplace that doesn’t compromise on quality or experience. I look forward to providing a more detailed update on Windows Marketplace for Mobile when we extend the service to Windows Mobile 6.0 and 6.1 customers later this month.

The Windows Marketplace for Mobile Client and your Setup code

Mike Francis — Thu, 29 Oct 2009 19:17:45 GMT

The Windows Marketplace for Mobile client provides users a streamlined experience to purchase and install applications on their Windows Mobile 6.5 devices (coming soon for 6.1, and 6.0).

As you will notice when installing applications, the user interface is different from the typical CAB file installation (see below) perhaps you are used to.

It is very important that the Marketplace install experience be uniform and streamlined. To keep it this way, no custom UI (errors, prompts, informational messages, etc.) should be displayed during installation or uninstallation.

If you absolutely must display custom UI, there are some things you should know about the Marketplace client.

The Marketplace client achieves a streamlined experience by suppressing the normal user interface, displaying a client specific progress bar and providing feedback when the installation has completed. This can cause problems for applications that have custom prompts implemented in the setup dll. For example, you may want to prompt the user to start your application after installation has completed. This is easily done by adding the appropriate MessageBox prompt to the Install_Init export of your setup dll. However, there can be problems with this.

The foreground display of your MessageBox or other custom UI, depends on knowing the window handle of the calling process. When your application is installed with the Marketplace client, no window handle is passed to your setup DLL’s exported functions. This can cause your custom UI to not be displayed in the foreground. This causes confusion for the user since it looks like the installation is still running, but there is no UI feedback. The only recourse for the user is to use task manager to locate the prompt window and select it to bring it to the foreground. This is a very poor user experience.

You can resolve this by using the MB_TOPMOST | MB_SETFOREGROUND flags when calling MessageBox or WS_EX_TOPMOST when creating a window for custom UI.

Have you tried the Marketplace client yet? No? Don’t have a 6.5 ROM update or device yet? No problem. Download the Windows Mobile 6.5 standalone emulator images here. These come with a fully functional Marketplace client you can download and install apps with.

Hope this helps.

Mike

Widget Anatomy – Touch and D-Pad inputs, oh joy!

Jorge Peraza — Wed, 28 Oct 2009 01:00:00 GMT

This is fifth and final part of my Widget Anatomy series that described the ins and outs of the Widget Framework that shipped with windows mobile 6.5. In this installment we will discuss the different ways a Widget can receive inputs from the user and how best respond to them.

First the easy one: Touch

Touch is the primary input for all our professional devices and it looks like they will be a significant percentage of our device offering. Handling this is fairly easy since the browser engine translate the touch event into a mouse click which can be handled by using the onclick event handler as shown in the following example:

        1: <html>

       2: <head>

       3:     <script type="text/javascript" src="js/ImageSearch.js"></script>

       4: </head>

       5: <body>

       6:     <div id="SearchBox">

       7:         <input id="SearchQuery"/>

       8:         <img src="images/search.png" class="searchIcon" 
               onclick="doSearch();" />

       9:     </div>

      10: </body>

      11: </html>

It is important to note that, since there is no “mouse” for widgets most of the other mouse related events like onmouseover, onmousemove, etc will not be triggered in a reliable enough way to use them.

Now the hard one: The Directional-Pad

I been making special emphasis to the fact that Widgets work seamless across all Windows Phones so, we need to ensure that the can be used correctly when the user interacts with it using the directional path.

It is important to note that, unlike IE6, a The widget framework will respond to a D-Pad input event by moving the focus to the closed actionable element in the direction of the user click. This behavior is similar to the old pocketIE and among friends we call it “Link to Link navigation”.

An actionable element is defined as any DOM element that can receive focus (Like a form field) or an element that implements its onclick event handler. When an actionable element gain focus the onfocus even is triggered, the same way, the focus is moved away from the element the onblur event is triggered. Now we can easily use those events to show the user where the focus is since the Widget Framework does not automatically highlights the focused element. We do this because we don’t want to inhibit the creativity of the widget creator to design his/her own focused highlight strategy.

The only “little” extra detail is that all elements that can gain focus need to have the tabindex property defined (the value is not important). This is easily forgotten but if not set, the focus and blur events will not trigger,

    <html>

    <head>

    <script type="text/javascript">   1:     2:     function OnFocus(element) {   3:         element.style.backgroundColor = "red";   4:     }   5:        6:     function OnBlur(element) {   7:         element.style.backgroundColor = "white";   8:     }</script>

    </head>

    <body>

    <div onfocus="OnFocus(document.getElementById('one'))"

         onblur="OnBlur(document.getElementById('one'))"

         onclick="alert(1)"

         tabindex=1>

            <p id="one" style="font-size:medium:">1</p>

    </div>

    <div onfocus="OnFocus(document.getElementById('two'))"

         onblur="OnBlur(document.getElementById('two'))"

         onclick="alert(2)"

         tabindex=2>

            <p id="two" style="font-size:medium;">2</p>

    </div>

    </body>

    </html>

In this example, we created two divs that can receive the input focus, you can move from one to the other using the D-Pad, the element that receives focus changes the color of its background to red.

Conclusion

Writing Windows Mobile applications is now as easy as writing a web page, and, by following some best practices your widget can be as functional and attractive as any other native application on the platform.

This is the end of this blog series and since Windows Phones are now available on many countries, you should go get one and write many cool widgets for it. Don’t forget to share the results with the world by uploading them to the marketplace!

Until next time

Jorge Peraza

Widget anatomy series at glance

#1 The manifest

#2 The keys for a great user experience

#3 Performance and battery life

#4 Security insights

#5 Touch and D-Pad inputs, oh joy!

Widget Anatomy – Security Insights

Jorge Peraza — Thu, 15 Oct 2009 22:45:00 GMT

Previous post: Widget Anatomy – Performance and battery life

This is part four of my Widget Anatomy series which which will explain the ins and outs of the Widget Framework that is shipping as part of Windows Mobile 6.5. In this installment I will discuss the Widget Framework’s security model..

Inside the sandbox – The Widget Framework security model

It is true, Widgets are executed inside a sandbox, and because of this, there are bounded to a rather strict security policy but can be summarized as follows:

Widgets can’t read files from the device nor can access the registry directly. A notable exception are all files that are part of the Widget package itself.
Cookies can be used as temporary storage but developers are encouraged to use the persistent storage API instead. Cookies, browser history and local cache are isolated per widget and completely separated from the browser.
Widgets can’t navigate their main frame to any URL with the exception of fragment inside itself. You can use an iframe to open a web URL though.
Widgets can navigate to the following specific purpose URIs

URI	Description	Example
SMS:	Starts composing an SMS message addressed to the given phone number	sms:1111111111
mailto:	Starts composing a mail message using the specified parameters (Like destination, subject and body)	mailto:test@test.com?subject=Hello?body=From%20Here
callto:	Initiates a voice call to the given number	callto:1111111111
tel:	Initiates a voice call to the given number	tel:1111111111
http:, https:	Opens the specified URI using the default browser.	http://www.microsoft.com

Widgets and the Marketplace

Windows Mobile 6.5 restricts distribution of Widgets to trusted sources only. This means consumers will only be able to install widgets from the Marketplace and, on some cases, Mobile Operator stores directly. This restriction was implemented because we don’t currently support digital signature verification for widget files which prevents users from being able to verify the origins and authenticity of any given widget. This might seem a little restrictive but I believe it provides the right balance between security and flexibility, specially if you consider that there are ways to allow enthusiasts and developers to install widgets from non-trusted sources, as long as they acknowledge and understand the risks of doing so. Use your best judgment :).

Other important security considerations

The local persistent storage is unencrypted, use caution when storing information that should be protected in clear text.
The widget ID is sent to the server as part of the user agent string if you would like to use it on your server for any reason.
Widget files are stored unencrypted on the device file system so anyone with device access can potentially read them.
Cross domain data access is allowed, this is super important for widgets since they can be used to mash up data from multiple sources.

That’s it for now, feel free to comment about any other security related questions that were not covered.

Next post: Widget Anatomy – Touch and D-Pad inputs, oh joy!

Marketplace Client, Your Applications, and Registry Keys

Mike Francis — Tue, 13 Oct 2009 00:25:42 GMT

The Windows Marketplace for Mobile is off to a great start since its release October 6th. One issue that has tripped up a few developers submitting their applications has been the use of internal registry keys used to determine the location of the application. Some clever developers have discovered that there is a list of installed applications stored in the registry under: HKEY_LOCAL_MACHINE\Software\Apps. Under the application name, you will find the directory in which the application has been installed. For example:

HKEY_LOCAL_MACHINE\Software\Apps\Company Application Name
InstallDir=”\Program Files\Application Name”

a similar list can be found here:

[HKEY_LOCAL_MACHINE\Security\AppInstall\Company Application Name]
InstallDir=”\Program Files\Application Name”

Since Windows Mobile does not support the concept of a current working directory, this has been one way to determine where the EXE is running from. A better approach, that is not dependant on these registry keys, uses the following code (See Chistec’s blog post):

GetModuleFileName(GetModuleHandle(NULL), pszFullPath, MAX_PATH);

For managed code (See Chistec’s blog post):

using System.Reflection;

private string GetApplicationExe()
{
  // Determine the full path to the application executable
  return Assembly.GetExecutingAssembly().GetName().CodeBase;
}

You can then parse out the application path from the returned file name.

So what is wrong with using these undocumented registry keys? When your application is installed by the Marketplace client, it creates these registry keys, but not with the names you would expect. Therefore, if your application is relying on any of these keys, if will fail to find them, because they will not exist. This has tripped up a few developers because this issue does not surface unless you install the application after it has gone through the Marketplace ingestion process. (The processing of your application after it has passed certification testing.)

To summarize, if you need to get the directory in which it was your application was installed, use either the native or managed APIs above. Also, make sure you are not using either of these undocumented registry keys.

Thanks,

Mike