• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

Windows RT 8.1 anti-jailbreak differences

Search This thread

Myriachan

Senior Member
Feb 11, 2013
117
174
It looks like they locked out the jailbreak from 8.1 by invalidating all old signatures. Windows RT 8.1's ci.dll does not trust the "1.3.6.1.4.1.311.10.3.6" OID in certificates anymore, only a new "1.3.6.1.4.1.311.10.3.21" OID. Both are required now. How it works is, if a certain configuration bit is not set in the call to CipMinCryptToSigningLevel, attempting to load an executable with a *10.3.6 OID on the certificate but not a *10.3.21, CipMinCryptToSigningLevel will explicitly fail with STATUS_INVALID_IMAGE_HASH--it won't even bother to consider it a 0 signing level.

I bet that this time, they will not give device manufacturers anything but executables that require booting Windows in test mode, something only Microsoft and device manufacturers can accomplish due to Secure Boot.

Microsoft Office's executables are signed with both the 2010 and 2011 keys, presumably so that it can run on both 8.0 and 8.1.

Visual Studio 2012's remote debugger doesn't work anymore, either. I bet that they're working on further locking down the remote debugger to avoid letting us use it to jailbreak.

The only good news I see is that NtUserSetInformationThread sub 7--the kernel exploit--has not been fixed.
 

netham45

Inactive Recognized Developer
Jun 24, 2009
886
568
Denver
It looks like they locked out the jailbreak from 8.1 by invalidating all old signatures. Windows RT 8.1's ci.dll does not trust the "1.3.6.1.4.1.311.10.3.6" OID in certificates anymore, only a new "1.3.6.1.4.1.311.10.3.21" OID. Both are required now. How it works is, if a certain configuration bit is not set in the call to CipMinCryptToSigningLevel, attempting to load an executable with a *10.3.6 OID on the certificate but not a *10.3.21, CipMinCryptToSigningLevel will explicitly fail with STATUS_INVALID_IMAGE_HASH--it won't even bother to consider it a 0 signing level.

I bet that this time, they will not give device manufacturers anything but executables that require booting Windows in test mode, something only Microsoft and device manufacturers can accomplish due to Secure Boot.

Microsoft Office's executables are signed with both the 2010 and 2011 keys, presumably so that it can run on both 8.0 and 8.1.

Visual Studio 2012's remote debugger doesn't work anymore, either. I bet that they're working on further locking down the remote debugger to avoid letting us use it to jailbreak.

The only good news I see is that NtUserSetInformationThread sub 7--the kernel exploit--has not been fixed.

Do you know if they blocked downgrading (through updating the EFI certs), or if we can just throw the old CI.dll in there or not?

Edit: Nevermind, they state that a recovery drive can return to RT.
 
Last edited:

Myriachan

Senior Member
Feb 11, 2013
117
174
Do you know if they blocked downgrading (through updating the EFI certs), or if we can just throw the old CI.dll in there or not?

I can boot the 8.0 recovery image from USB just fine. In fact, if I choose Command Prompt, I can then go run WinDbg if it's on the hard drive. =)

Windows 8.1 knows the name of the new OIDs. The previous OID 1.3.6.1.4.1.311.10.3.6 is "Windows System Component Verification"; the new OID 1.3.6.1.4.1.311.10.3.21 is specifically named "Windows RT Verification".

Replacing ci.dll with the old version causes it to fail to boot. Looking into this more.
 
  • Like
Reactions: Medjay

windowsrtc

Senior Member
Nov 21, 2012
94
34
It looks like they locked out the jailbreak from 8.1 by invalidating all old signatures. Windows RT 8.1's ci.dll does not trust the "1.3.6.1.4.1.311.10.3.6" OID in certificates anymore, only a new "1.3.6.1.4.1.311.10.3.21" OID. Both are required now. How it works is, if a certain configuration bit is not set in the call to CipMinCryptToSigningLevel, attempting to load an executable with a *10.3.6 OID on the certificate but not a *10.3.21, CipMinCryptToSigningLevel will explicitly fail with STATUS_INVALID_IMAGE_HASH--it won't even bother to consider it a 0 signing level.

I bet that this time, they will not give device manufacturers anything but executables that require booting Windows in test mode, something only Microsoft and device manufacturers can accomplish due to Secure Boot.

Microsoft Office's executables are signed with both the 2010 and 2011 keys, presumably so that it can run on both 8.0 and 8.1.

Visual Studio 2012's remote debugger doesn't work anymore, either. I bet that they're working on further locking down the remote debugger to avoid letting us use it to jailbreak.

The only good news I see is that NtUserSetInformationThread sub 7--the kernel exploit--has not been fixed.
I run office from windows.old but it doesnt work at all.
 
  • Like
Reactions: Woolabot

Myriachan

Senior Member
Feb 11, 2013
117
174
Trying to use the old ci.dll fails, but using the old boot loader does not. In fact, the old 8.0 boot loader can actually boot the 8.1 kernel just fine, not even noticing a difference.

The 8.1 bootmgr.efi is signed with the *10.3.21 OID. This means that they could reflash the firmware to only accept *10.3.21 signatures during the final build 8.1 upgrade process if they wanted to be mean to people in the way that Apple is. In other words, I fully expect that Microsoft will do this. Even worse, they could force the 8.1 install on most people via Windows Update if it's free to RT users.

We need another way in. >.<
 

southbird

Senior Member
Feb 12, 2010
249
100
I dunno, I think this should reinvigorate those with the know-how to figure out how to get Linux on the thing so we could keep control of our own devices. It's come up a couple times in a couple threads, and I'm sure a kernel driver is the easiest way to go about it for now.
 

GoodDayToDie

Inactive Recognized Developer
Jan 20, 2011
6,066
2,931
Seattle
The Linux boot ideas have all been about cross-booting from RT into Linux. If 8.1 locks out our ability to run unsigned code (including kernel drivers), then it would no longer be possible to load Linux either. New devices, or older ones that got the upgrade, would be stranded.

Don't get me wrong, I thing that getting Linux working is an admirable goal. Just don't expect it will fix the 8.1 "now with moar lockdown!" problem.
 

southbird

Senior Member
Feb 12, 2010
249
100
The Linux boot ideas have all been about cross-booting from RT into Linux. If 8.1 locks out our ability to run unsigned code (including kernel drivers), then it would no longer be possible to load Linux either. New devices, or older ones that got the upgrade, would be stranded.

Don't get me wrong, I thing that getting Linux working is an admirable goal. Just don't expect it will fix the 8.1 "now with moar lockdown!" problem.

Well, I meant, get out ahead of it and don't ever bother upgrading to 8.1. Leave it jailbroken at 8.0 and give up on Microsoft thereafter.
 

Myriachan

Senior Member
Feb 11, 2013
117
174
The Linux boot ideas have all been about cross-booting from RT into Linux. If 8.1 locks out our ability to run unsigned code (including kernel drivers), then it would no longer be possible to load Linux either. New devices, or older ones that got the upgrade, would be stranded.

Don't get me wrong, I thing that getting Linux working is an admirable goal. Just don't expect it will fix the 8.1 "now with moar lockdown!" problem.

It all depends on whether upon 8.1's final release Microsoft will do a firmware update that disallows bootarm.efi files that were signed with the original keys.
 

netham45

Inactive Recognized Developer
Jun 24, 2009
886
568
Denver
"The following error occurred: The Remote Debugger cannot be started as an Administrator on Microsoft Windows RT. Restart the remote debugger with normal user permissions."

I'm rather disappointed in MS for /still/ not unlocking RT.

Edit:
20130627231203275.png


Looks like they locked down the debugger decently.
 
Last edited:

windowsrtc

Senior Member
Nov 21, 2012
94
34
I think the best way is to find a way to flash uefi by uart.so we can hack uefi directly.
BTW,windows 8.1 WDK contains arm files and may be they can be used on vs2012.
 

netham45

Inactive Recognized Developer
Jun 24, 2009
886
568
Denver
I came up with a copy of windbg/cdb that works, but it looks like they blocked attaching to csrss by marking it as a protected image.
 
Last edited:
  • Like
Reactions: mattifestation

Myriachan

Senior Member
Feb 11, 2013
117
174
I came up with a copy of windbg/cdb that works, but it looks like they blocked attaching to csrss by marking it as a protected image.

I PM'd you about discussing ways into 8.1. I sent a PM because I would rather not discuss certain things visibly prior to 8.1 release when Microsoft still has an easy chance to defeat what we come up with before launch.
 
... Windows 8.1 knows the name of the new OIDs. The previous OID 1.3.6.1.4.1.311.10.3.6 is "Windows System Component Verification"; the new OID 1.3.6.1.4.1.311.10.3.21 is specifically named "Windows RT Verification".

Replacing ci.dll with the old version causes it to fail to boot. Looking into this more.
Since your exploit still works, can you locate ci.dll and patch it in-memory? Or is Microsoft performing runtime integrity checks?

As far as I {knew|know}, Microsoft was only doing on-disk checks before mapping the image into memory. See Alan Meese's Windows Phone: Security Deep Dive, http://channel9.msdn.com/Events/TechEd/Europe/2012/WPH304. (I know its a different platform, but I would expect it to be very similar).

Jeff
 
Last edited:

Myriachan

Senior Member
Feb 11, 2013
117
174
Since your exploit still works, can you locate ci.dll and patch it in-memory? Or is Microsoft performing runtime integrity checks?

Yes, which is what the 8.0 exploit does. Finding ci.dll is simple: EnumDeviceDrivers or whatever the NT API equivalent is. The hard part is writing to kernel memory.

Two exploits are required in order to jailbreak. The first is to execute arbitrary assembly code at user level. The second is to attack kernel mode with an exploit. Both of these are difficult problems to solve. In 8.0, the code execution exploit was to use a Microsoft-signed debugger executable to modify an existing program's code. The kernel exploit was the kernel not properly validating parameters from csrss.exe, a trusted process.

Microsoft didn't release a security fix for the csrss.exe exploit probably under the idea of being on the other side of the airtight hatchway, using Raymond Chen terminology: attacking csrss.exe requires Administrator access, so from a security perspective, an attacker would already have won. The only time that that philosophy doesn't apply is with DRM protections--and guess what, the 8.1 fix is to mark csrss.exe as a DRM process, which it clearly is not.

The other big thing Microsoft did in 8.1 was to invalidate all the signed debugger executables from 8.0, and make the new 8.1 debuggers require a special secure boot mode that only device manufacturers and Microsoft can enable.
 
It looks like they locked out the jailbreak from 8.1 by invalidating all old signatures. Windows RT 8.1's ci.dll does not trust the "1.3.6.1.4.1.311.10.3.6" OID in certificates anymore, only a new "1.3.6.1.4.1.311.10.3.21" OID. Both are required now. How it works is, if a certain configuration bit is not set in the call to CipMinCryptToSigningLevel, attempting to load an executable with a *10.3.6 OID on the certificate but not a *10.3.21, CipMinCryptToSigningLevel will explicitly fail with STATUS_INVALID_IMAGE_HASH--it won't even bother to consider it a 0 signing level.

I bet that this time, they will not give device manufacturers anything but executables that require booting Windows in test mode, something only Microsoft and device manufacturers can accomplish due to Secure Boot.

Microsoft Office's executables are signed with both the 2010 and 2011 keys, presumably so that it can run on both 8.0 and 8.1.

Visual Studio 2012's remote debugger doesn't work anymore, either. I bet that they're working on further locking down the remote debugger to avoid letting us use it to jailbreak.

The only good news I see is that NtUserSetInformationThread sub 7--the kernel exploit--has not been fixed.
Myriachan - do you have a reference for those changes? A friend is writing a paper and would like to verify the source and cite you. Google is turning up lots of spurious noise.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 11
    It looks like they locked out the jailbreak from 8.1 by invalidating all old signatures. Windows RT 8.1's ci.dll does not trust the "1.3.6.1.4.1.311.10.3.6" OID in certificates anymore, only a new "1.3.6.1.4.1.311.10.3.21" OID. Both are required now. How it works is, if a certain configuration bit is not set in the call to CipMinCryptToSigningLevel, attempting to load an executable with a *10.3.6 OID on the certificate but not a *10.3.21, CipMinCryptToSigningLevel will explicitly fail with STATUS_INVALID_IMAGE_HASH--it won't even bother to consider it a 0 signing level.

    I bet that this time, they will not give device manufacturers anything but executables that require booting Windows in test mode, something only Microsoft and device manufacturers can accomplish due to Secure Boot.

    Microsoft Office's executables are signed with both the 2010 and 2011 keys, presumably so that it can run on both 8.0 and 8.1.

    Visual Studio 2012's remote debugger doesn't work anymore, either. I bet that they're working on further locking down the remote debugger to avoid letting us use it to jailbreak.

    The only good news I see is that NtUserSetInformationThread sub 7--the kernel exploit--has not been fixed.
    7
    Some good news:
    g5cr.png


    There is a method of booting with any unsigned EFI file (for example Linux GRUB) on Asus VivoTab devices with the recent firmware.
    This also allows loading a "cracked" bootmgfw.efi that does not check for signatures of Windows kernel modules, and after patching the ci.dll - you'll be able to run any app or load any unsigned driver (even the boot-mode driver, unlike the 8.0 jailbreak).

    The limitations of my method:
    - It works only on Asus VivoTab RT tablets. Surface is not supported due to differences in UEFI firmware modules.
    - Bitlocker should be disabled (manage-bde.exe -protectors -disable c: )
    - There would be a line stating that secureboot is incorrectly set up, you can see it in the lower-right corner of the screenshot.
    - The most inconvenient thing: it requires a FAT32-formatted USB stick with a "hack" file to be inserted on boot.
    And, obviously, the "hole" could be closed by Asus in one of the next firmware updates. So Windows Update should be switched to manual mode (8.1 allows to select this from GUI).

    So this should be considered as a temporary method until something universal would be found. But it can be used to start developing Linux (or android) for Tegra3.
    I'll publish the instructions after 8.1 would be released.
    3
    Is anyone else working on this?
    I dimly remember some other devs working on this before abandoning their efforts due to OP claiming to come out with a fix "soon" ... this obviously was all just a load of BS, so I thought it might be a good idea to circle back to some of the other devs ...
    3
    I upgraded foolishly thinking that there would be a way to jailbreak. Luckily, I was able to downgrade back to RT 8.0. I use my Surface RT as a second screen to my laptop on the road so I NEED Synergy. I also use SumatraPDF as my default PDF reader because the Windows Store readers are terrible. Microsoft just doesn't get it. I understand it is a security hole and must be fixed but at least provide a "DEVELOPER OPTION" that allows you to run applications in desktop mode that are unsigned. If you enable "DEVELOPER OPTION" a warning box comes up with disclaimers, etc. Google figured this out with Android. Why does Microsoft have to be so dense.
    3
    I was reading through Sideload Windows Store Apps. Is it possible to install the 8.0 certificate on an 8.1 device and then side load the needed tools (for example, the debugger)?

    Sadly, no, for two reasons. The first is that Windows RT's enforcement of what is allowed to run is enforced by the same kernel driver that enforces what kernel drivers can run, ci.dll. ci.dll has a hard-coded list of certificates that it trusts and there is no way to add additional certificates.

    The second is that the certificates aren't really the problem - the object identifiers (OIDs) are. Windows 8.1 didn't invalidate the 8.0 certificates in the ordinary certificate revocation sense; rather, they changed ci.dll to require that a new OID be present in any signature for it to be trusted in 8.1. None of the 8.0 signatures have this OID.

    Windows Apps seem to use a different signature system overall. Unsigned Apps can be used if you have a developer certificate, and Apps installed by 8.0 are still valid in 8.1. Similarly, there is something special going on for sideloading. I don't personally know how any of that works, but I do know that sideloading isn't useful, because the privilege level of Apps is too low to be useful for much of anything.

    By the way, progress on breaking 8.1:

    https://twitter.com/Myriachan/statuses/365350790803619840