clrokr (@clrokr) – 6. Jan 2013
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.
Finding the right spot
The minimum signing level determines how good an executable’s signature is on a scale like this: Unsigned(0), Authenticode(4), Microsoft(8), Windows(12). The default value on x86 machines is of course 0 because you can run anything you like on your computer. On ARM machines, it defaults to 8.
That means that even if you sign your apps using your Authenticode certificate, the Surface or any other Windows RT device (at this moment) will not run them. This is not a user setting, but a hardcoded global value in the kernel itself. It cannot be changed permanently on devices with UEFI’s Secure Boot enabled. It can, however, be changed in memory.
Finding this byte in the kernel takes a while, there is no exported symbol for it and not even in the symbol database at MSFT. I found it using WinDbg and a machine running Windows 8 Pro, creating processes and watching how the system behaves when the signature checks happen all the way through CI.dll and back. Because Windows 8 and Windows RT are so similar, locating it in the ARM kernel was not hard:
LDR R3, =0x59FFA6 This is our byte, 0x19FFA6 at 0x400000 image base
LDRB R3, [R3]
CMP R3, #4
There are many more places where you can find this byte accessed, but none of them have an exported symbol.
A while ago I read an article about how the Windows kernel assumes that data passed by certain processes is always well-formed . This vulnerability exists in Windows RT, but exploitation is a bit harder than on Windows 8 because unsigned binaries can’t be run in the first place (and store apps don’t have the security context you need to attach to other processes). But Microsoft decided to provide something very important  that made this whole endeavour a lot easier. This remote debugger, when run as Administrator, can attach to the user’s CSRSS process and manipulate its memory.
CSRSS contains a lot of calls to the vulnerable NtUserSetInformationThread function, including some that use the right parameters to exploit it. This is one of them (from winsrv.dll):
MOVS R3, #0xC
ADD R2, SP, #0x58
MOVS R1, #9
MOV R0, 0xFFFFFFFE
A CSRSS thread executes this code. Using a breakpoint, we can change the data structure pointed to by R2 before the NtUserSetInformationThread call happens to exploit the vulnerability. Sadly, this is very impractical because the exploit subtracts 1 from the specified address and we need to subtract 0x80000. This is because we can’t do an unaligned access on ARM (remember, our byte’s offset is 0x19FFA6), so we need to use 0x19FFA4.
We also need the linear address at which the kernel image resides. We can find this out by calling (on the device, this can be done from a store app which will run unsigned) NtQuerySystemInformation with information class 11. If you want to know how to use NtQuerySystemInformation from a store app, read . This gives us a list of all loaded drivers and their image bases, effectively bypassing ASLR in this case (although this is not what ASLR is for, it is annoying in these situations).
Using the remote debugger and MSFT’s armasm, I used a half-empty code page in winsrv.dll (0x10800 from the image base) to store this small payload:
mov r7, 0x80000
ldr r8, my_addr
movs r3, 0xC
add r2, sp, 0x68 ;0x58 org.
add r5, r2, 4
str r8, [r5]
movs r1, 9
mvn r0, 1
mov r12, 0x10E1
subs r7, r7, 1
cmp r7, 0
mov r0, r0
my_addr dcd 0x12345678 the kernel's base address + 0x18
We now set a breakpoint directly after the legitimate NtUserSetInformationThread call in TerminalServerRequestThread, pressing a volume button will trigger it. This is where it gets interesting.
Redirect the instruction pointer to the payload in memory and set a breakpoint at the mov r0, r0 instruction at the end. Press F5. Now set the instruction back to the first breakpoint and remove both. Press F5 again.
Congratulations, your Windows RT device is unlocked!
Windows RT is a clean port of Windows 8. They are the same thing and MSFT enforces Code Integrity to artificially separate these platforms. It does not stop pirates from modifying store apps (and their license checks) because store apps are the only things that can actually run unsigned. The fact that this method works on Windows 8 as well shows how similar the systems are. You can even enforce Code Integrity on Windows 8 to see what Windows RT feels like!
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!
- Sometimes this triggers a bugcheck because we can’t control the bytes at 0x19FFA4 and 0x19FFA5 from the kernel base and they sometimes are zero, causing a 0x18 bugcheck.
- This method is not practical for most users, especially because tablet buyers are less likely to know enough about computers to do this than PC users.
 j00ru//vx tech blog: Defeating Windows Driver Signature Enforcement #2: CSRSS and thread desktops
 Visual Studio 2012 Remote Tools
 Using the complete Windows API in store apps (mamaich at XDA-Developers)
also for further reading
[*] Discussion about this on XDA-Developers
6. Jan 2013: Added 0x18 offset in payload because it is very important and the article at  doesn’t mention it. Also added link to discussion on XDA-Developers for further reading.