Jailbreak Exploits
Discusses Microsoft's strict lock-down on running Win32 applications.
Last updated
Was this helpful?
Discusses Microsoft's strict lock-down on running Win32 applications.
Last updated
Was this helpful?
If you've used Windows RT for any length of time you have probably already realized that trying to run a traditional Windows executable is not possible under a stock configuration. If you do try and run one you will probably see a message like the following.
There are two reasons why this happens. The first reason is that Windows RT uses a completely different type of CPU architecture to the one used on standard Windows. Rather than using the x86/x64 from Intel or AMD, Windows RT instead uses the 32-bit ARMv7 architecture. So since almost every Windows executable on the internet is compiled for x86/x64 so do they all fail to work under Windows RT.
This may arguably have been trivial for software developers to solve were it not for the next major problem. If you do get your hands on an ARMv7 compiled executable and try to run it, you will see something like the next following message.
This is caused by another difference Windows RT has to standard Windows which is what is called the minimum signing level. This level is set in the kernel and cannot be changed as far as we know. It goes like this:
#
Level
Description
0
Unsigned
This is the value found on standard Windows machines. It allows any executable to be ran.
4
Authenticode
Would only allow for an executable to be ran if it were signed by a verified publisher. You could not run applications with a "Unknown Publisher".
8
Microsoft
This is what Windows RT is set to. Only code signed to run by Microsoft is able to be ran by a user.
12
Windows
Would lock any executable from running except those included with the Windows install.
Allowing only for Microsoft code to run in the context of Win32 completely cut off any third party support for the system in this area. Third party developers were instead expected to write their software for the Windows Store.
Over the years there have been a couple of exploits for bypassing the aforementioned signing requirement. Since all are quite vaguely named, I shall refer to them only by their author. Here are all known exploits...
Exploit
Date
Description
January 10 2013
The earliest known exploit. Works by using Windows Symbolic Debugger (cdb.exe) to change the minimum signing level loaded in RAM. Requires two minute system up time to work properly and may sometimes cause a BSOD.
October 14 2015
bcdedit /set '{current}' loadoptions '/TŅSTSIGNING' enables test signing mode. Works around /testsigning option being blocked because blocked options are checked for before they are passed to ntoskernel.exe. Once passed ntoskernel.exe truncates unicode down to 8-bits and Ņ becomes E.
