FORUMS
Remove All Ads from XDA
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  
Inactive Recognized Developer
Flag Denver
Thanks Meter: 564
 
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: 176
 
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
2nd July 2013, 05:54 AM |#4  
Junior Member
Flag Baltimore, MD and New York, NY
Thanks Meter: 0
 
More
Question
Quote:
Originally Posted by Myriachan

... 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/Tech...pe/2012/WPH304. (I know its a different platform, but I would expect it to be very similar).

Jeff
2nd July 2013, 06:21 AM |#5  
Myriachan's Avatar
OP Senior Member
Thanks Meter: 176
 
More
Quote:
Originally Posted by noloader

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.
27th June 2013, 09:44 AM |#6  
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 |#7  
Myriachan's Avatar
OP Senior Member
Thanks Meter: 176
 
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 |#8  
Myriachan's Avatar
OP Senior Member
Thanks Meter: 176
 
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 |#9  
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 |#10  
Inactive Recognized Developer
Flag Seattle
Thanks Meter: 2,940
 
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.
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