Circumventing Windows RT’s Code Integrity Mechanism | On the Surface of Security

It’s taken longer than expected but it has finally happened: unsigned desktop applications run on Windows RT. Ironically, a vulnerability in the Windows kernel that has existed for some time and got ported to ARM just like the rest of Windows made this possible. MSFT’s artificial incompatibility does not work because Windows RT is not in any way reduced in functionality. It’s a clean port, and a good one. But deep in the kernel, in a hashed and signed data section protected by UEFI’s Secure Boot, lies a byte that represents the minimum signing level.

This is proof of a few things.

1. Secure Boot serves no purpose other than to attempt to block alternative operating systems and software from running on a device. It does NOT in any way protect users from exploits.
2. As the author states, the decision to block traditional desktop applications was a choice the suits made, it had no technical basis whatsoever.
3. This is a sign of things to come. If the RT were a successful product it would have encouraged Microsoft to proceed with locking users out of their desktop applications once and for all, sometime down the line. After all, piracy is probably the desktop’s primary use in practice at this point.

That last one is important, because it’s still a clear and present threat. Microsoft’s marketing and messaging for their products clearly states that the desktop is the past, and the App Store is the future. Read more: http://surfsec.wordpress.com/2013/01/06/circumventing-windows-rts-code-integrity-mechanism/