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:

VB2017 paper: Browser attack points still abused by banking trojans

With the ever-increasing use of banking-related services on the web, browsers have naturally drawn the attention of malware authors. They are interested in adjusting the behaviour of the browsers for their purposes, namely intercepting the content of…

Does malware based on Spectre exist?

It is likely that, by now, everyone in computer science has at least heard of the Spectre attack. Since many excellent explanations of the attack already exist, this article focuses on the probability of finding Spectre being exploited on Android…

EternalBlue: a prominent threat actor of 2017–2018

At the centre of last year's infamous WannaCry ransomware attack was an NSA exploit leaked by the Shadow Brokers hacker group, known as ‘EternalBlue’. The worm-like functionality of the exploit made a deadly impact by propagating to interconnected…

VB99 paper: Giving the EICAR test file some teeth

There are situations that warrant the use of live viruses. There are also situations where the use of live viruses is unwarranted. Specifically, live viruses should not be used when safer and equally effective methods can be used to obtain the…

Powering the distribution of Tesla stealer with PowerShell and VBA macros

Since their return more than four years ago, Office macros have been one of the most common ways to spread malware. In this paper, Aditya K Sood and Rohit Bansal analyse a campaign in which VBA macros are used to execute PowerShell code, which in…

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.