FORUMS
Remove All Ads from XDA

Windows RT 8.1 anti-jailbreak differences

117 posts
Thanks Meter: 174
 
By Myriachan, Senior Member on 27th June 2013, 09:04 AM
Post Reply Email Thread
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.
The Following 11 Users Say Thank You to Myriachan For This Useful Post: [ View ] Gift Myriachan Ad-Free
 
 
27th June 2013, 09:20 AM |#2  
Recognized Developer
Flag Denver
Thanks Meter: 563
 
Donate to Me
More
Quote:
Originally Posted by Myriachan

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.
27th June 2013, 09:43 AM |#3  
Myriachan's Avatar
OP Senior Member
Thanks Meter: 174
 
More
Quote:
Originally Posted by netham45

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.
The Following User Says Thank You to Myriachan For This Useful Post: [ View ] Gift Myriachan Ad-Free
27th June 2013, 09:44 AM |#4  
Member
Thanks Meter: 34
 
More
Quote:
Originally Posted by Myriachan

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.
The Following User Says Thank You to windowsrtc For This Useful Post: [ View ] Gift windowsrtc Ad-Free
27th June 2013, 09:45 AM |#5  
Myriachan's Avatar
OP Senior Member
Thanks Meter: 174
 
More
Quote:
Originally Posted by windowsrtc

I run office from windows.old but it doesnt work at all.

Windows RT 8.1 installs a new set of Office executables that are signed with the new signature. The old Office executables won't work, just like everything else won't work.
27th June 2013, 10:01 AM |#6  
Myriachan's Avatar
OP Senior Member
Thanks Meter: 174
 
More
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. >.<
27th June 2013, 03:10 PM |#7  
Senior Member
Thanks Meter: 102
 
More
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.
27th June 2013, 08:36 PM |#8  
Recognized Developer
Flag Seattle
Thanks Meter: 2,919
 
More
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.
27th June 2013, 09:19 PM |#9  
Member
Thanks Meter: 17
 
More
Quote:
Originally Posted by Myriachan

Visual Studio 2012's remote debugger doesn't work anymore, either.

What about VS2013 - the preview version has just been released... ?
27th June 2013, 09:21 PM |#10  
Senior Member
Thanks Meter: 102
 
More
Quote:
Originally Posted by GoodDayToDie

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.
27th June 2013, 10:40 PM |#11  
Myriachan's Avatar
OP Senior Member
Thanks Meter: 174
 
More
Quote:
Originally Posted by GoodDayToDie

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.
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes