Microsoft has attempted to lock down some aspects of Windows 8 and has done even more to secure Windows RT. As you might expect this is simply an invitation to jailbreak the system, but surprisingly the jailbreak attempt has led to a slightly deeper question - why is the Windows RT desktop locked down at all?

The first thing to say is that we don't have a complete jailbreak just yet in the sense that it isn't really user friendly. Windows RT is windows for the ARM processor and it supports WinRT applications which work on both x86 and ARM with suitable recompilation. However, Windows RT also supports desktop applications - that is applications that run under the Win32 API. The big problem is that Microsoft has decided that you can't run desktop applications under Windows RT - only signed applications authorized by Microsoft can be loaded.

The jailbreak, by a programmer going by the name clrokr,
uses a long standing vulnerability in the kernel that has been ported to ARM - a hashed code which determines the security level. On x86  machines it is set to zero to allow anything to run, but on Windows RT on ARM it is set to 8 which means an app has to be signed by Microsoft to run. The jailbreak simply locates the hashed data and changes it to the hash for the zero level. Actually changing the value isn't easy because WinRT apps don't have the security context to change data owned by another process. The trick requires the use of the remote debugger and some clever code to change the byte. The only problem is that the value is reset when the machine reboots, making the change less than permanent.

What is interesting is that that clrokr claims that the hack works on Windows 8 and that Windows RT is a "clean port of Windows 8". What this means is that if you take a classic Win32 app and recompile it to ARM code then it should just work. 

Microsoft has provided a number of reasons for the ban on Win32 apps running under Windows RT. The first was that Windows RT only includes a very basic and incomplete port of Win32. This seems not to be the case. A later explanation was that it was in order not to confuse users who might try to load and run x86 versions of desktop apps. They might be annoyed that they don't work because they haven't been compiled to ARM code. Of course with the lockdown they are now just annoyed that they can't even attempt to load them. Either way they don't work and if Windows RT wasn't locked down programmers could recompile their desktop apps and make them available under Windows RT.

All in all locking down Windows RT doesn't make much sense. Other suggested reasons for doing so include security concerns and battery life problems. While these could be an issue, the huge bonus of having Windows desktop apps available to run under Windows RT would seem to make them insignificant considerations.

One possible and plausible reason for wanting to keep desktop apps off ARM processors is that Microsoft really wants desktop apps to die out. The future is the WinRT app and Win32 is legacy would fit with the act of locking desktop apps out of Windows RT. The same sort of attitude also exists in Windows 8, where the new start screen isn't something that can be turned off. Under Windows 8 you can't avoid WinRT apps and you can't simply retreat to your old desktop and carry on as if nothing had changed.

The Windows RT desktop lockdown probably has more to do with making sure that programmers get the message that the desktop API is dead than anything else.

Microsoft doesn't seem to be too worried by the current jailbreak, citing the fact that it isn't really a security threat and it isn't really practical. It also seems to be intent on fixing the problem in a future release of Windows RT.

As clrokr  says in his blog entry:

"The decision to ban traditional desktop applications was not a technical one, but a bad marketing decision. Windows RT needs the Win32 ecosystem to strengthen its position as a productivity tool. There are enough “consumption” tablets already.

Microsoft, please consider making code signing optional and thereby increasing the value of your Windows RT devices!"

He is not alone in this opinion.

How many Surface devices have been returned because the user thought that it was a true Windows device? With one small change the Surface range could become much more like a true Windows device.