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
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.
 
 
27th June 2013, 11:50 PM |#12  
Recognized Developer
Flag Denver
Thanks Meter: 563
 
Donate to Me
More
"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.
28th June 2013, 03:23 AM |#13  
Member
Thanks Meter: 34
 
More
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.
28th June 2013, 04:29 AM |#14  
Recognized Developer
Flag Denver
Thanks Meter: 563
 
Donate to Me
More
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.
The Following User Says Thank You to netham45 For This Useful Post: [ View ]
28th June 2013, 06:03 AM |#15  
Retired Recognized Developer
Thanks Meter: 221
 
Donate to Me
More
Quote:
Originally Posted by netham45

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
28th June 2013, 06:05 AM |#16  
Myriachan's Avatar
OP Senior Member
Thanks Meter: 174
 
More
Quote:
Originally Posted by netham45

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.
2nd July 2013, 05:54 AM |#17  
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 |#18  
Myriachan's Avatar
OP Senior Member
Thanks Meter: 174
 
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.
8th July 2013, 04:14 AM |#19  
Junior Member
Flag Baltimore, MD and New York, NY
Thanks Meter: 0
 
More
Question Re: Windows RT 8.1 anti-jailbreak differences
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.

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.
8th July 2013, 05:23 AM |#20  
Recognized Developer
Flag Denver
Thanks Meter: 563
 
Donate to Me
More
Quote:
Originally Posted by noloader

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.
8th July 2013, 07:36 AM |#21  
Myriachan's Avatar
OP Senior Member
Thanks Meter: 174
 
More
Quote:
Originally Posted by netham45

I believe everything in this thread is our own research.

Yes, confirming--almost everything, if not everything, in this thread is stuff we've figured out on our own through various means.
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