Deconstructing Windows Mobile


Michael Moser

IBM Research GmbH, Switzerland
Editor: Helen Martin


Not satisfied by the answers provided by a Microsoft representative in last month's interview about security issues surrounding the Windows Mobile platform, Michael Moser takes matters into his own hands and delves a little deeper.


Last month's issue of Virus Bulletin contained an interview conducted by Juha Saarinen with Microsoft representative Brett Roberts about the update issues surrounding Microsoft's Mobile operating system platforms (see VB, July 2005, p.13). However, Mr. Roberts' answers were left largely uncontested, so the following are a few points that I felt were missing from the article.


As a supplement to this article, VB's Technical Editor Morton Swimmer provides a brief overview of the Microsoft Windows Mobile platform on p.13 - Ed

No escape

Juha's first question related to whether (unlike on the PC platform) it is safe to run a Windows Mobile device without updates. However, the answer provided by Mr. Roberts did not include a discussion of securing the operation of the device - for example, what is done or offered by the OS, so that a malevolent piece of software (such as one that always shuts off the device and/or reinstalls itself during reboot) cannot prevent the user from regaining full control of his/her device?

Windows Mobile (WM) has no 'restricted' or 'safe-mode' to allow rebooting while skipping the normal startup programs, thus allowing the recovery and cleanup of an infected system. For a common user the dreaded operation that in Windows CE parlance is known as 'hard-reset' - a complete memory re-initialization and reset to factory defaults (which also implies 100 per cent data loss) - appears to be the only available 'solution' to resolve such a situation [1].

Furthermore, there is no encapsulation of processes that would ensure limited threats from flawed drivers or other third-party software that comes pre-installed on the system. For example, some Bluetooth stacks are well known to have security holes. There is no OS support for executing certain parts of the software in a restricted or limited mode to prevent access to and/or modification of critical OS data, amongst other things.

Mr. Roberts emphasizes the rather trivial point that not getting infected is the best way to stay uninfected - i.e. do not download and/or install 'doubtful' software. This needs to be emphasized because, once the system has been infected, Windows Mobile does not have any further system-internal protection, access controls, or any other safety barriers. However, a program does not even have to be explicitly malevolent in order to cause disruption. Just a simple program error can be enough to wipe out the entire system and/or render it useless (by causing endless reboots, etc.).

No, not never

Further on in the Q & A, Mr. Roberts states that it is difficult, if not impossible, to distribute patches directly to end-customers due to the diverse nature of Windows Mobile devices. He claims that Microsoft depends on the hardware manufacturers and OEMs to integrate and forward its patches.

Alas, the hardware manufacturers and OEMs seldom feel the need to forward these patches with the due urgency. My own experience (with multiple generations of devices from Casio, Toshiba, Siemens and several Compaq/HP iPAQs) is that the release of such updates takes at least two, but more typically three to six months, during which time users remain exposed and essentially can do nothing about it. The burden, therefore, is on the user to avoid being exposed to malicious software. This problem is revisited throughout the article.

However, I find this situation hard to accept, since many sources indicate that, when a manufacturer requests to license Windows Mobile, Microsoft has a pretty strong say in what a device must offer, how it must appear and behave, what applications must be included and which must not come pre-installed, etc.

Given such power, it would seem comparatively easy for Microsoft to enforce a standardized API, via some code package (of course sealed, signed, etc.) that would be able to reflash at least parts of the OS without requiring an OEM's further blessing and support.

Given that we have already gone through several generations of Windows CE / Handheld PC / Pocket PC / Windows Mobile and whatever-they-name-them-today devices, there would have been ample time to require such a capability and thus I rather suspect that the issue was not considered very important or urgent (to date). I wish the Mobile group had exhibited the same 'great work by the Windows division on Windows update technology'.

No discretionary execution of code

Mr. Roberts points out that the Windows Mobile platform can also be operated as a closed platform (using techniques from the Trustworthy Computing Initiative), where operators or businesses have full control over what software can be installed to a device, thus minimizing the risks. This, of course, is just a way of sidestepping the real problem by merely preventing discretionary execution of code - and due to its restrictive nature this is not a popular or widespread approach.

Furthermore, operating as a closed platform to minimize risks is not 100 per cent secure, since (as previously indicated) the code does not even have to be malevolent to cause problems; a simple bug is enough!

A controlled environment simply reduces the probability of software bugs by making the assumption that approved applications are tested more thoroughly before they are widely deployed, especially regarding their interaction with other controlled applications. This is probably a faulty assumption and a dangerous one.

No conectivity

Finally, today's PDAs are still far less continuously connected to the Internet than desktop systems, and in many cases they connect to the Internet only via some 'sync partner'.

As a result, there is only a relatively small population of attackable devices available on the Internet at any point in time, and the channels via which worms and viruses would have to travel to infect them are convoluted and contain barriers that need to be crossed. But, with more and more Windows Mobile devices being constantly and directly connected to the Internet (thanks to integrated WiFi and/or built-in high-speed phone capability, e.g. GSM/GPRS or UMTS, and especially with billing models based on generated traffic rather than connection time) this picture may change quickly and dramatically.

No place to hide

There is one major risk on the horizon for Windows Mobile, that is quite troubling and that was not mentioned at all in Juha's article: most of the newer Windows Mobile devices have a large flash memory in which not only do they store the OS and the pre-installed applications, but a part of the memory (usually a quarter to a half) is also made available to the user as a place where he/she can install applications and store data. The feature was meant originally to provide users with a place where they could store data that would be safe even when the device runs out of battery and all normal RAM content is lost.

The flash memory on such devices is, in effect, split into two 'partitions'; one for the OS and pre-installed applications and one for user data. However, the boundary between these two partitions is purely virtual and can be shifted, thereby allowing a newer (and most likely larger) version of the OS to consume a slightly larger fraction of that memory than the previous one.

Such a mechanism also means that, given the device-specific or brand-specific knowledge on how to write data to the flash, viruses, too, could 'burn' themselves into the OS area of the 'ROM' such that they would survive hard-resets, i.e. complete 'memory loss' and reset to factory defaults. Such viruses would not be removable with any means available to the normal user, meaning that an infected device would have to be sent back to the manufacturer for repair.

That, together with the growing CPU [2] [3] and architectural homogeneity of Windows Mobile devices, will become a major threat in the probably not-so-distant future. The requirement for hardware-assisted memory protection and OS-supported security models will thus soon become a requirement for Windows Mobile-based PDAs and phones.

[1] There is now a third-party tool available that offers exactly such a feature (see, but the standard Windows Mobile lacks that capability.

[2] Earlier versions of Windows CE ran on different CPUs (MIPS, SH-3/4, misc. Philips processors, etc.), while versions since Pocket PC 2002 run only on XScale and other StrongARM-compatible processors.

[3] For an overview of CPUs and architectures Windows Mobile runs see Chris de Herrera's excellent compilation at



Latest articles:

VB2018 paper: Lazarus Group: a mahjong game played with different sets of tiles

The number of incidents attributed to the Lazarus Group, a.k.a. Hidden Cobra, has grown rapidly since its estimated establishment in 2009. In this paper, ESET researchers Peter Kalnai and Michal Poslusny look at various cells within the group, that…

VB2018 paper: Fake News, Inc.

As the world grapples with massive disinformation campaigns waged by the intelligence agencies of hostile nations, we should not forget that such activities are not limited to the purview of the Bears or Pandas of the world, and that even relatively…

Alternative communication channel over NTP

Nikolaos Tsapakis explores Network Time Protocol (NTP) as an alternative communication channel, providing practical examples, code, and the basic theory behind the idea.

VB2018 paper: Under the hood: the automotive challenge

In an average five-year-old car, there are about 30 different computers on board. In an average new car, there are double that number, and in some cases up to 100. That’s the size of network an average SMB would have, only there’s no CIO/CISO, and…

VB2018 paper: Android app deobfuscation using static-dynamic cooperation

Malicious Android applications are quite common, and can even be found from time to time in the Google Play Store. Thus, a lot of work has been done in both industry and academia on Android app analysis, and in particular, static code analysis. One…

Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.