Operating Systems and Internet Messenger in the USA

I have been working on this post slowly for several days, but Reed and Steve are seriously kicking my butt on posting solid developer-focused technical security content. Read their blog - they covered a lot of this material sooner and better than I did.

Some non-touchscreen Windows Mobile devices ship with a set of security policies that prevents developers from adding their own codesigning certificates. I don't know of any touchscreen devices that ship like that - it's possible to configure those devices to be locked down but none ship like that by default as far as I know. For some of these devices, it's possible to tweak the security policies via supported methods so you can install development certs,debug, and develop privileged applications. Internally we call this "the user is manager" meaning that the user has the ability to freely modify any software setting on the phone. In this post I'll describe how to figure out the security policies on your device and how to figure out if you are "application locked" or not.

For this post I'll assume that the end goal is to get the SDK certificates (sdkcerts.cab) installed on the phone. Once you've done that, you can run the remote registry editor from the SDK, develop and sign your own programs and do whatever you want.

Try This First

Let me get to the point first - I'd recommend two things, in order of likelihood of success

1. Use the Device Security Manager. It has a great facility for inspecting the security policies and cert stores of a connected device, and even has a menu option to install the SDK certs for you.
2. Try installing the unsigned sdkcerts.cab on the device. There are a few cases where the Security Manager tool errs on the side of caution and tells you that you can't install the certs, but they will really work via unsigned cab. I'll describe this case below.

If either of those work, the SDK certs are installed and you can now develop, change security policies, do whatever you want.

Local security policies

There are several security policies that come into play here. To install the SDK certs you need the highest level of trust on the device. (manager)

Unsigned CAB policy: If policy is set to 0, then unsigned CABs won't install. The typical role is User Auth which means the CABs will install but they have a similar set of privileges as code running at the Normal level. If this policy is set to Manager, then the unsigned CABs have all privileges, and you can use the unsigned cab technique to change any setting.

Two-tier security policy: If this is set to "One-tier" then CAB files and programs have the ability to change any setting on the device. Some smartphone devices ship in one-tier mode. Those phones are definitely not application locked - you can use the unsigned cab technique to apply any setting.

Grant Manager policy: This policy contains a list of roles that are elevated to manager. If this role contains "User Auth" then every action taken by the user has full administative access. Installing the setup XML from a cab file counts as one of those actions, so if grant manager contains User Auth, you can again use the unsigned cab technique to change any setting.

RAPI security policy: I think it's pretty uncommon for this policy to be open when the previous policies are be locked down, but if this policy is set to Open (2) then all of the API calls over Activesync are processed as trusted/manager, so you'll be able to change any setting or security policy using RAPI.

Inspecting security policies with the Device Security Manager

Here's the default configuration for a Windows Mobile "Standard" non-touch-screen device. All of the security policies mentioned above are in their restricted state. You won't be able to install the SDK certs onto a phone like this. It is possible to run unsigned untrusted code, so you can write some classes of apps, but the development and debugging experience is not great. The Device Security Manager will tell you that it can't install the SDK certs on a device like this. This is typically what most people mean when they say "Application Locked".

 Here's another possible configuration. On this phone, the Grant Manager policy is set to "User Auth".  This means that an unsigned cab will install with full privilege, after the prompt. The Device Security Manager still thinks this phone is locked down, so you'll need to install the unsigned cab by hand.

For a default Windows Mobile 6 SDK install, the SDKCerts cab is located at "C:\Program Files\Windows Mobile 6 SDK\Tools\Security\SDK Development Certificates\Certs.cab". Copy this CAB to a device configured like the above, and it will successfully install. Once the SDK certs are installed, you can write your own programs and use all the development tools that ship with the SDK.

Protect your question with an impenetrable cloak of vagueness.

1) Choose a subject line that conveys no information. This means that the subject matter expert needs to choose between spending more time on your message to figure out what it's about, or just moving on to other questions that can be triaged faster.

2) Bury your message in an towering pile of forwards, so that the meat of the question isn't even on the screen of the recipient.

Inspired, of course, by Raymond and the original ESR rant.

There are a few different things that people might mean when they say their phone is "locked". I wanted to provide this post to help define the different types of lock.

SIM Locked

This typically means that the phone will only work on the network of one specific operator. This is handled by the GSM network and doesn't have anything in particular to do with the Windows Mobile software itself. More info

Bootloader Locked

In many cases, Windows Mobile devices can only be reflashed by the OEM or operator. The "bootloader lock" typically refers to this state. The bootloader is the very first part of the phone that starts up, and it usually has the capability to enter a reflash mode or various other debug or diagnostic modes.

Application Locked

This term is a little bit ambiguous. In the most strict meaning, it means that the device can't run unsigned code and that most settings and the registry entries can't be changed by the end user. Sometimes the term is used to refer to the default settings on a two-tier Smartphone device, where unsigned code runs at the "normal" trust level and only some settings and APIs can't be used. If there is interest, I can do a followup post with more detail on what this means and ways to tweak this state on development devices.

PIN Locked (or Device Locked)

This refers to the device state where you need to enter your PIN (or password) to unlock and use the device. Internally we call it "device lock" but "PIN lock" is probably more clear. There's also "key locked" where most keypresses don't register except the unlock key.

SIM PIN Locked

The SIM itself can require a PIN in order to change settings or use the phone features at all. If the PIN is entered incorrectly enough times, the SIM will lock down and you have to get an unlock code (PUK) from the operator to continue. This functionality is implemented entirely on the SIM - all the Windows Mobile software does is pass the PIN code from you to the SIM

I'm moderating this post, so please don't post links to various unlock sites and resources - I won't post those comments for various different reasons including our partner relationship with OEMs and operators.

Scott

Our Device Management and Security (DMSec) team recently produced a series of security booklets. These were very well recieved at the MEDC 2007 event last week. So I'd like to point out that these are also available online. Among the topics you will find:

• Security Risks in the Mobile Enterprise
• The Windows Mobile Security Architecture
• Security Considerations on the Exchange Server
• Security Considerations within the Corporate Network
• more...

There are 2 booklets available online:

Security Considerations for Windows Mobile Messaging in the Enterprise

Security Model for Windows Mobile 5.0 and Windows Mobile 6

Bookmark these great resources and read them when you want an in depth look at the Windows Mobile security model - either as a developer or an IT administrator.

-Mel Sampat

Michael Howe, the all powerful Test Lead in Windows Mobile just got back from paternity leave to find a few small gifts in his office...

Now you know where all those recycled monitors go... :)

Have a great weekend everyone.

Here's the spoof video that was shown at MIX '07 and MEDC last week.

Behind the humor, there's a serious message - adapt your app! Windows Mobile devices are coming in all shapes and sizes. If you're hard-coding things like screen sizes and coordinates, or assuming any particular orientation or device form factor in your code, stop! Visit the Adapt Your App page on MSDN for resources on designing device independant applications.

A while back someone asked which phones the Windows Mobile team uses.  While I will end up answering that question, in typical form, I’m going to be really verbose about it.

In Windows Mobile, we’re very strong proponents of what we call, “Eating our own dogfood.”  What this means is that we use the code we’re developing on our primary phones.  If you’ve ever been on a “Beta test,” you know that beta code isn’t always very stable or bug free.  Well, we frequently use builds that aren’t even up to beta quality.  When internal people complain about this, my response tends to be, “They don’t call it dogfood because it tastes good.”  We dogfood (it’s a verb too :-) to find bugs.  Better it be unstable for us than for you….

Many developers do a lot of their work on the same emulators you use in the SDK.  Emulators are nice because we own all the code for them and can easily make them do whatever we want.  The downside, of course, is that you can’t put an emulator in your pocket and carry it around.  Microsoft doesn't make phone hardware, so to do actual dogfooding we need to work with our partners to get a device to use.

We don’t make the chicken or the egg

One of the huge challenges we face in Windows Mobile is finding acceptable devices to use for Dogfood.  Because the device we need to use hasn’t been created yet, we almost always develop the next release on a device created for the previous one.  This causes serious problems (that lead to clever solutions) when the previous hardware doesn’t have features we’re trying to develop.  For example, it was hard to add QWERTY keyboard support because no device had a QWERTY keyboard.  And no one was going to make a QWERTY device until we added QWERTY support.

Another issue is that a huge amount of the code in a WM phone isn’t written by us.  It’s written by the OEM who manufactures the phone.  Frequently, to develop a new version of our software we need to modify the OEM parts of the code.  The trouble is, the OEMs generally don’t want to give us their code.  They’re worried that we might give it to their competitors. 

For these reasons, our choice of development platforms is limited not only by finding devices that will do what we need, but also by finding OEM partners willing to either let us use their code or make changes for us when we ask for them.  The “make changes for us” idea is a pain for the OEM, because they don’t sell phones based on that work.  Any time they spent making something work for us is time they didn’t spend making a phone they’re actually going to sell. 

These things contribute to the “dogfood not tasting good” situation.  Frequently our internal development builds are done on inappropriate hardware with driver modifications that were made by an overworked team with higher priority things to do.  As cool as this place is, it’s not always glamorous.

Dogfood through time

We’ve actually been doing this for ten years now, but I’ll just go back to the PocketPC 2000 release.  One of the main development platforms for that was the Compaq Aero 2100.  In these fun times, the only way to update a device was to physically remove the ROM chips and replace them with new ones.

When PocketPC 2000 came out, the most popular device created for it was the Compaq iPaq 3600.  The iPaq was a natural choice for our development/dogfood platform, but maybe not for the reasons you’d think.  First, we already had a relationship with the OEM (both the iPaq and the Aero were made by HTC).  That helped us convince them to give us access to its driver code.  Second, it ran on an ARM processor.  This was before we had standardized on ARM, but that was the direction we were heading.  Third, but maybe most importantly, it had Flash memory that let us install new builds without physically replacing ROM chips. 

While working on that, we also had a group doing the first Smartphone (for the Smartphone 2002 release).  There we had a huge chicken and egg problem.  There was no previous device that was anything at all like what we were trying to build.  Our division actually has a small hardware team that designed and built a few prototypes for us to use.  The first was called “Avenger” and the second was “Avenger 2.”  We don’t have the manufacturing capability to make a lot of these, so we worked with an OEM to make a version of Avenger 2 for us.  While this was supposed to be called “AV2,” a language mishap turned the name into “AR11.”  We also did a ton of work with a small phone company, but that didn’t end well.  I’ve got plenty of stories to tell there, but … won’t. 

We had a similar chicken and egg problem with the next PocketPC release (2003).  It needed to be a phone but there were no previous phone PocketPCs.  Thankfully, we were able to work with HTC (who had made the best Smartphone 2002 device) on what would become the XDA (aka the Wallaby).  For development of non-phone PocketPCs, we continued to use the iPaq.

For Smartphone 2003 we continued to use the AR11.  We also used the HTC SPV (aka the Canary) for a while but switched to the Motorola MPX200.  There were a number of reasons for using the MPX200, but one of the biggies was that the OEM who made it was willing to give us code for the drivers.  Our work on the AR11 had made HTC worried about giving us the SPV driver code.

Our next release was WM 2003 Second Edition.  One of the features in this release was QWERTY support in PocketPC.  To do this, we first paid a company to make a QWERTY sled for the iPaq.  We had a grand total of two of those, and I believe they cost us more than most people’s salaries.  We also found a company that was planning to make a keyboard attachment for the XDA, paid them to put a different layout on it, and bought a ton of them.  These were cheaper because the company was already manufacturing the keyboards.

We needed a way to do 240x240.  We did that by taking a 320x240 iPaq and just making its display driver only draw the first 240 pixels.  We needed a way to do 640x480.  For that we used an XDA (which had a 320x240 screen), made its display driver tell the system it had a 640x480 screen, and then “pixel quartered” the output (average pixels together) to make it fit.  It was ugly, but if you squinted, you could almost pretend it was the higher resolution.  And it let us test to make sure that text fit on the screen correctly, etc.

The most funky thing we needed to do was 240x320 for Smartphone.  We couldn’t use the pixel quarter trick there because the MPX200 was 176x220, which isn’t an even multiple.  Instead we made the Smartphone version of our code run on the XDA.  To simulate the number pad, we overlaid a number pad on the screen and let you tap it with your fingers.

For Windows Mobile 5, we had a number of devices.  On the PocketPC side we had three: the HTC XDA II (aka Himalaya), a prototype HTC CDMA device that didn’t end up shipping, and the Toshiba E750.  Although HTC had reluctantly given us source code for the iPaq and the first XDA, they wanted it more restricted this time.  So we worked out a deal where only two people in the entire company could see the code for those platforms.  These two developers were tasked with all driver development for the release.  Thankfully they were both extremely good developers (and one of them is a superhuman who typically gets more done than any two or three normal people).  On the Smartphone front we started with the MPX200.  Trouble was, it didn’t have enough ROM to hold WM5.  After a lot of herculean measures to keep it going, we finally switched to using the HTC SMT 5500 (aka the Typhoon).  We never got source code for the 5500, but HTC was using it to practice for their upcoming WM5 device and we were able to ride on those coattails.  

Windows Mobile 6 continued to use the 5500 for a while but switched to its replacement, the HTC SDA (Tornado).  We also used the HTC MDA (Wizard).  At the tail end, we got some HTC Dashes in.  In all of these cases, we didn’t have access to any of the source code.  An HTC engineer made changes for us. 

Completeness

Not everyone in Windows Mobile works in the main feature team.  Some people work on focused items for OEMs so they see and use more devices than the main group does.  For instance, we worked really closely with Motorola on the development of the Q.  As a result, many people dogfooded Qs.  Etc.   But, for the majority, the above pretty much tells the tale.

Mike Calligaro

Hi, my name is Patrick Derks and I work as a developer in the Windows Mobile Shell. I’ve owned the softkey code in Windows Mobile for a few months now and I keep getting questions about how to do basic stuff with the softkeys. For example, I had  a developer just the other day ask how they could change the label of a softkey. These sorts of questions are a good indication of just how lousy our documentation has been for softkeys and we’ve tried to rectify that in the Windows Mobile 6 SDK. If you search for “softkeys” in the SDK you should be able to find an entry with the following table detailing all the toolbar messages (TB_*) that the softkey bar supports (included below). Hopefully this will help take away some of the mystery on how to get stuff done with the softkeys.

You'll notice in the table that for a number of the TB_* messages it mentions "changing the softkey bar to a toolbar" in the description. This automatic transformation to a toolbar was put in place in Windows Mobile 5 (WM5) when softkey support was first added for Pocket PC. Prior to WM5, Pocket PC apps all got toolbars when SHCreateMenuBar was called but in WM5 this was changed so that a softkey bar was created instead of a toolbar. In order to try and not break every Pocket PC application out there a bunch of support for TB_* messages was added to the softkeys in Pocket PC and thats why Pocket PC (excuse me, I mean Windows Mobile Professional/Classic) supports a larger set of TB_* messages than Smartphone (Windows Mobile Standard). If you ask me its kind of silly that we have different levels of support for TB_* messages for the two SKU's and rest assured I'm working hard to rectify this for a future release.

By the way, if anybody has any questions, comments or suggestions about the softkeys in Windows Mobile I’d also be very interested to hear them.