FORUMS
Remove All Ads from XDA

Bypassing PatchGuard...?

117 posts
Thanks Meter: 177
 
By Myriachan, Senior Member on 18th October 2013, 07:38 AM
Post Reply Email Thread
So I know pretty much how my jailbreak is going to work from end to end, except with regard to PatchGuard. I don't need to burn my "Holy Grail" exploit in order to release a jailbreak, but it means that I have to deal with PatchGuard.

In Windows 8.1, Microsoft modified the kernel and ci.dll so that PatchGuard protects the signing enforcement mode variables. This means that if you modify the variables that were modified by 8.0's jailbreak, some random time in the next hour from that point, your system will bugcheck (bluescreen) because PatchGuard detected something tampering with the kernel. It is very obvious that the addition of these variables to PatchGuard's protected list was a deliberate attack against the RT jailbreak, because there is little other reason to care about enforcing these variables' integrity after startup.

I need to get around PatchGuard somehow. PatchGuard itself is designed to be an obfuscated mess, deliberately difficult to modify in a stable manner. It does a lot of nasty tricks, things that you would typically find in copy protection systems. Obviously, disabling it would be nice, but quite difficult. So is stopping it from bugchecking.

I can load kernel drivers, so I know of a way in which I can hook parts of the system that would not anger PatchGuard such that arbitrary unsigned DLLs and drivers could be loaded without hassle. For things like the lockdown in WinDbg, VBScript and PowerShell, I can hook NtQuerySystemInformation in the user-mode ntdll.dll and intercept the request to check the lockdown setting. Even though the system lockdown state would still be active, as long as user mode programs don't know about it, it won't be enforced. (The kernel doesn't care at all.)

However, this leaves one thing to be desired: executing ARM code. I already know how we can patch the kernel so that ARM code can execute without the CPU being switched back to Thumb2 all the time. However, patching the kernel definitely will get PatchGuard's attention, so there's no way to pull that off without defeating PatchGuard.

The optimal solution is definitely to defeat PatchGuard, but I don't know how. I'm not an expert in the field of low-level NT kernel stuff.
The Following 10 Users Say Thank You to Myriachan For This Useful Post: [ View ] Gift Myriachan Ad-Free
 
 
18th October 2013, 11:07 AM |#2  
Member
Thanks Meter: 34
 
More
please release your jailbreak so that other people can help you.
18th October 2013, 11:24 AM |#3  
kitor's Avatar
Senior Member
Flag Wieluń
Thanks Meter: 28
 
More
If i got it correctly, it will BSOD in a hour of running, so releasing it to public is not a good idea. Maybe via PM to other devs, but that depends on OP.
18th October 2013, 11:30 AM |#4  
Member
Thanks Meter: 34
 
More
why not change the variables back after you launch your unsigned exe?
18th October 2013, 12:04 PM |#5  
Senior Member
Thanks Meter: 19
 
More
Quote:
Originally Posted by windowsrtc

why not change the variables back after you launch your unsigned exe?

I think about doing this too. Can we discard hacked? If it can done. Will it have problem with running unsigned exe? And did we know exactly when did PatchGuard notice about hack?
18th October 2013, 10:14 PM |#6  
Senior Member
Thanks Meter: 187
 
Donate to Me
More
Quote:
Originally Posted by Myriachan

However, this leaves one thing to be desired: executing ARM code.

Perhaps I'm missing something, ... why do you want to do this? The reason I ask is because this seems to be your motivation for wanting to "defeat" patch guard.

WRT simply running native applications/driver - If you can successfully load a driver, even once, then there are a few easy ways to support this without a patch guard defeat.

Cheers!
19th October 2013, 07:06 AM |#7  
Myriachan's Avatar
OP Senior Member
Thanks Meter: 177
 
More
Quote:
Originally Posted by bfosterjr

Perhaps I'm missing something, ... why do you want to do this? The reason I ask is because this seems to be your motivation for wanting to "defeat" patch guard.

WRT simply running native applications/driver - If you can successfully load a driver, even once, then there are a few easy ways to support this without a patch guard defeat.

That it's currently impossible to execute ARM code reliably on Windows RT is a major reason that Firefox hasn't been ported. Fixing that would require patching two context-switch routines in ntoskrnl.exe.

You're right that there are various ways of loading unsigned executables and drivers once the initial driver is bootstrapped. ci.dll and ntoskrnl.exe have so many variables that aren't protected by PatchGuard that this is pretty much inevitable. Ironically, removing the lockdown from WinDbg, PowerShell and VBScript is actually harder than running unsigned code when using this attack.

Defeating PatchGuard would be the optimal experience for users.
19th October 2013, 04:03 PM |#8  
Jeff's Avatar
Senior Member
Brussels, Belgium
Thanks Meter: 27
 
More
...
...
20th October 2013, 02:01 AM |#9  
Senior Member
Thanks Meter: 187
 
Donate to Me
More
Quote:
Originally Posted by Myriachan

That it's currently impossible to execute ARM code reliably on Windows RT is a major reason that Firefox hasn't been ported.

Actually, I don't agree. There is no hard requirement for ARM code that I can see. The major reason for a lack of FF port is that the native RT community is too small to get behind the port to sort out re-writing parts of the code base. There is also the large build system/process that needs to be shifted to VS. Throw in the lack of a public RT 8.1 JB.. and there is little motivation for this community to invest the time/effort in making FF work.

Don't get me wrong, FF will likely come to RT (even 8.1) eventually.. but I don't see the lack of ARM code being the roadblock. Its time and effort along with a new JB.
20th October 2013, 11:50 AM |#10  
Senior Member
Thanks Meter: 326
 
More
Quote:
Originally Posted by bfosterjr

Actually, I don't agree. There is no hard requirement for ARM code that I can see. The major reason for a lack of FF port is that the native RT community is too small to get behind the port to sort out re-writing parts of the code base. There is also the large build system/process that needs to be shifted to VS. Throw in the lack of a public RT 8.1 JB.. and there is little motivation for this community to invest the time/effort in making FF work.

Don't get me wrong, FF will likely come to RT (even 8.1) eventually.. but I don't see the lack of ARM code being the roadblock. Its time and effort along with a new JB.

The javascript JIT engine is to ARMv7 not THUMB_2 though.
21st October 2013, 08:28 AM |#11  
Senior Member
Thanks Meter: 187
 
Donate to Me
More
Quote:
Originally Posted by SixSixSevenSeven

The javascript JIT engine is to ARMv7 not THUMB_2 though.

I gathered as much. I'm suggesting a re-write of that as part of the port.

Cheers!
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