Windows RT 8.1 anti-jailbreak differences

Myriachan · Jun 27, 2013

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 · Jun 27, 2013

Myriachan said:
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.

Myriachan · Jun 27, 2013

netham45 said:
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.

windowsrtc · Jun 27, 2013

Myriachan said:
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.

Myriachan · Jun 27, 2013

windowsrtc said:
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.

Myriachan · Jun 27, 2013

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 · Jun 27, 2013

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 · Jun 27, 2013

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.

DarkoLord · Jun 27, 2013

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

What about VS2013 - the preview version has just been released... ?

southbird · Jun 27, 2013

GoodDayToDie said:
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 · Jun 27, 2013

GoodDayToDie said:
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 · Jun 27, 2013

"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:

Looks like they locked down the debugger decently.

windowsrtc · Jun 28, 2013

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 · Jun 28, 2013

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.

mamaich · Jun 28, 2013

netham45 said:
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.

This may make things harder, but you can try to run WinDBG as a service and run your script. Start from here: http://support.microsoft.com/kb/824344

Myriachan · Jun 28, 2013

netham45 said:
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.

noloader · Jul 2, 2013

Myriachan said:
... 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

Myriachan · Jul 2, 2013

noloader said:
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.

noloader · Jul 8, 2013

Myriachan said:
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.

netham45 · Jul 8, 2013

noloader said:
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.

I believe everything in this thread is our own research.

Windows RT 8.1 anti-jailbreak differences

Senior Member

Inactive Recognized Developer

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Inactive Recognized Developer

Member

Senior Member

Senior Member

Inactive Recognized Developer

Senior Member

Inactive Recognized Developer

Retired Recognized Developer

Senior Member

Member

Senior Member

Member

Inactive Recognized Developer

Similar threads

Top Liked Posts