FORUMS
Remove All Ads from XDA

[RT] Windows RT 8.1 Jailbreak Discussion

78 posts
Thanks Meter: 36
 
By Toxickill, Member on 27th February 2014, 01:51 PM
Post Reply Email Thread
If you have nothing to add to this discussion please do not post. Thanks

Im hoping that we can make a list of requirements for this jailbreak to happen. Please read along with us and if you have any ideas regarding any of the steps please help us out...

Thanks,

Toxickill.
 
 
27th February 2014, 05:30 PM |#2  
Member
Thanks Meter: 15
 
More
In JB 8.0 we change a byte which indicates the sign level from "Microsoft" to "Unsigned".
Now this is protected by PatchGuard: you will get BSOD if you change it.

I think this is probably the only change.
The Following 2 Users Say Thank You to LolitaPlus For This Useful Post: [ View ] Gift LolitaPlus Ad-Free
27th February 2014, 06:33 PM |#3  
OP Member
Thanks Meter: 36
 
More
Quote:
Originally Posted by LolitaPlus

In JB 8.0 we change a byte which indicates the sign level from "Microsoft" to "Unsigned".
Now this is protected by PatchGuard: you will get BSOD if you change it.

I think this is probably the only change.

Well can we bypass patchguard? Because people over at easy hook have written a c# patchguard 3 bypass driver maybe we can build off of that?
27th February 2014, 07:19 PM |#4  
master.peterm's Avatar
Senior Member
Thanks Meter: 75
 
More
yeah patchguard has been bypassed I think https://twitter.com/standa_t/status/437972336705159169
27th February 2014, 08:27 PM |#5  
OP Member
Thanks Meter: 36
 
More
Quote:
Originally Posted by master.peterm

yeah patchguard has been bypassed I think https://twitter.com/standa_t/status/437972336705159169

Ok so now that it can be done im going to fire up my surface and get working on a new jailbreak tool. If all succeeds then i will update accordingly. Hopefully bypassing patchguard is all that is needed to run old bypass methods. If patch guard stays bypassed then we can make the jailbreak persistent through sessions.
The Following User Says Thank You to Toxickill For This Useful Post: [ View ] Gift Toxickill Ad-Free
27th February 2014, 09:57 PM |#6  
Recognized Developer
Flag Seattle
Thanks Meter: 2,915
 
More
Well, the other problem is that you can't attach a debugger to CSRSS.EXE anymore. So you need a different way to change the relevant value (or a way to bypass the Protected Process restriction).

I think Myriachan already has a way to do that, though; she mentioned that she'd managed to jailbreak but Patchguard was causing the system to crash, so she was working on a way around that.
27th February 2014, 10:18 PM |#7  
OP Member
Thanks Meter: 36
 
More
Quote:
Originally Posted by GoodDayToDie

Well, the other problem is that you can't attach a debugger to CSRSS.EXE anymore. So you need a different way to change the relevant value (or a way to bypass the Protected Process restriction).

I think Myriachan already has a way to do that, though; she mentioned that she'd managed to jailbreak but Patchguard was causing the system to crash, so she was working on a way around that.

Would patchguard bsod if we removed the protected process on csrss?
Also, would shell code be able to call ntdll.dll methods? We might be able to code arm shell code and call a method to temporarily revoke its protected process flag.

Edit:
Could we attach the debugger to a none protected process, execute shell code that removes process protection? Only problem is writing shell code is not my thing and especially for arm where its not documented as well.
27th February 2014, 10:46 PM |#8  
OP Member
Thanks Meter: 36
 
More
Also could someone PM me with a cdb.exe thats signed for windows rt 8.1? the one provided with the old jailbreak is only signed for 8.
27th February 2014, 11:25 PM |#9  
Recognized Developer
Flag Seattle
Thanks Meter: 2,915
 
More
... You do realize the Protected Process flag is in the kernel, right? How do you plan to remove it when, in order to modify kernel memory, you would need to attach to a protected process? It's not like this is the RO flag on a file or something.

The whole point of Windows protected processes is to avoid letting somebody debug them even if they have full control over the machine (they were originally designed for DRM). In testsigning mode or with a kernel debugger, they usually won't launch at all (CSRSS will - it's critical for all Win32 processes, including stuff like Explorer - but the DRM ones won't). This isn't something Microsoft is going to just allow people to turn off. We could theoretically patch around the restriction with the aforementioned kernel debugger or with a testsigned kernel-mode driver, but if we could put RT into Testsigning or use a KD on it we wouldn't need anything else at all anyhow; either of those are sufficient for an easy jailbreak.

When thinking about breaking into the system, think about what you want to accomplish. Then identify attack vectors to get there. Then think about how those attack vectors might be blocked. Then think about how you might bypass those blocks. Etc... If you can't get at least as far as the fourth step, you won't accomplish much (certainly not against a target as hardened as Windows).
27th February 2014, 11:30 PM |#10  
OP Member
Thanks Meter: 36
 
More
Quote:
Originally Posted by GoodDayToDie

... You do realize the Protected Process flag is in the kernel, right? How do you plan to remove it when, in order to modify kernel memory, you would need to attach to a protected process? It's not like this is the RO flag on a file or something.

The whole point of Windows protected processes is to avoid letting somebody debug them even if they have full control over the machine (they were originally designed for DRM). In testsigning mode or with a kernel debugger, they usually won't launch at all (CSRSS will - it's critical for all Win32 processes, including stuff like Explorer - but the DRM ones won't). We could theoretically patch around this with the aforementioned kernel debugger or with a testsigned kernel-mode driver, but if we could put RT into Testsigning or use a KD on it we wouldn't need anything else at all anyhow; either of those are sufficient for an easy jailbreak.

So just to clarify we can not use this undocumented API call that works in Win8.1 x64 on RT:

Code:
[DllImport("ntdll.dll", SetLastError = true)]
        internal static extern int NtSetInformationProcess(IntPtr hProcess, int processInformationClass, ref int processInformation, int processInformationLength);
int enable = 0;
                NativeMethods.NtSetInformationProcess(CSRSS.exe HANDLE, 29, ref enable, sizeof(int));
C# code of course but you could easily code in any language.
28th February 2014, 01:10 AM |#11  
Recognized Developer
Flag Seattle
Thanks Meter: 2,915
 
More
I don't see any way you can set the Protected Process flag this way... ProcessBreakOnTermination is not, so far as I know, in any way related (although CSRSS should have that flag set anyhow, and should have had it since before protected processes were even added to NT at all). If you could *set* the ProcessBasicInformation you could in theory overwrite the PEB, but supposedly that one is query-only (according to undocumented.ntinternals.net, which may be wrong). Also, you may find that you can't call OpenProcess with PROCESS_SET_INFORMATION on CSRSS, at least on RT 8.1. Worth trying though, perhaps...
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