Related
Obviously no one has a had a chance to try this yet, but will there be an effort to hack Windows RT to enable more desktop applications? I really don't care about the desktop, but there's one tiny utility that would be extremely useful. I use a program from Microsoft called "Mouse Without Borders" to control two computers with one keyboard and mouse. I'd love to do this on the Surface RT I'll be buying, but of course because it's a desktop application, I probably won't be able to.
revxx14 said:
Obviously no one has a had a chance to try this yet, but will there be an effort to hack Windows RT to enable more desktop applications? I really don't care about the desktop, but there's one tiny utility that would be extremely useful. I use a program from Microsoft called "Mouse Without Borders" to control two computers with one keyboard and mouse. I'd love to do this on the Surface RT I'll be buying, but of course because it's a desktop application, I probably won't be able to.
Click to expand...
Click to collapse
Compiling desktop apps for ARM using VS 2012 gives an error message, but it can be bypassed. Not sure if the results will run in Windows RT though.
Of course there's no way to find out until Windows RT devices are released to the public, because everyone who has access to one is under NDA. Have some patience.
for what you are suggesting, i believe it is technically either impossible or reliant on an emulator. since windows RT is for ARM processors and normal windows is for x86 processors, instructions would need to be converted from x86 to ARM in order to be used. this would be the job of an emulator, which would most likely not be able to be integrated deeply enough in the OS to do what you are talking about. even if it was, it would run slower than optimal.
now if microsoft releases the source code for their application (very unlikely), its an entirely different story. then the code can be recompiled for an ARM processor, making anything possible.
someone correct me if im wrong, but i believe im correct.
Pseudonym117 said:
for what you are suggesting, i believe it is technically either impossible or reliant on an emulator. since windows RT is for ARM processors and normal windows is for x86 processors, instructions would need to be converted from x86 to ARM in order to be used. this would be the job of an emulator, which would most likely not be able to be integrated deeply enough in the OS to do what you are talking about. even if it was, it would run slower than optimal.
now if microsoft releases the source code for their application (very unlikely), its an entirely different story. then the code can be recompiled for an ARM processor, making anything possible.
someone correct me if im wrong, but i believe im correct.
Click to expand...
Click to collapse
As someone who has one of these devices, I can't say much more other than it will not happen, I am sorry. You'll need to start barking at the developer to make a ARM Compatible App... Not likely it will happen as the API's are very different.
lseidman said:
As someone who has one of these devices, I can't say much more other than it will not happen, I am sorry. You'll need to start barking at the developer to make a ARM Compatible App... Not likely it will happen as the API's are very different.
Click to expand...
Click to collapse
You have an ARM device? If so, can you say 100% that there is no way to target win32/desktop using new code? It would be great to know for sure. I know it's possible to compile desktop code that targets ARM, producing a certain mystery executable. The only question is, will it actually run?
I have an arm device running WindowsRT. I compiled a HelloWorld for arm no problem in VS2012.
Unfortunately it will not run. Get 'Windows cannot verify the digital signature for this file'
If anyone knows a workaround to this we might be able to get it working
xanderkaiber said:
I have an arm device running WindowsRT. I compiled a HelloWorld for arm no problem in VS2012.
Unfortunately it will not run. Get 'Windows cannot verify the digital signature for this file'
If anyone knows a workaround to this we might be able to get it working
Click to expand...
Click to collapse
well the simple way would be to sign it. HOW to sign it is a completely different problem... there may be a group policy change or registry edit to turn off signature verification, but i am not familiar with windowsRT at all.
phailyoor said:
You have an ARM device? If so, can you say 100% that there is no way to target win32/desktop using new code? It would be great to know for sure. I know it's possible to compile desktop code that targets ARM, producing a certain mystery executable. The only question is, will it actually run?
Click to expand...
Click to collapse
How did you bypass the error message in VS2012? Can you share the exact steps you took to bypass the error as well as your mystery executable here so that folks who are under NDA and have early access to the ARM devices can try it out?
Since Office RT is a desktop app, one can only assume all of this is possible.
Windows RT is basically just Win8 recompiled for ARM, with one major exception: EXE files need to be signed by Microsoft before they will run. This means that MS can release desktop apps just fine - they have the signing keys, after all - but third-party software can't run by itself (as a desktop app) and will need to be bundled as an .APPX file (Metro-style app bundle).
If you want to try bypassing the signature check, there are a few things you could attempt. One would be to create your own signing certificate, install the public key in the OSes root code signing cert store (not the per-user store, though it qprobably wouldn't hurt to install it there too), and then sign your test apps with that cert. MS *probably* used certificate pinning - where a specific cert is used, rather than just any cert present in the OS of sufficient trust level - but they may not have, too. Alternatively, you could try looking for some legacy or debug functionality to disable the code-signing. Finally, you coul try using a built-in program, rundll, to invoke your applications.
I can't test any of this right now, because I don't have an RT device. There's a lot of research on them that I want to do, though.
Quote from one very old MS Windows 8 document, from those times when windows RT was called "woa" (2011). Everything could have changed from those days.
Description of the change:
WOA platforms will require that all desktop binary images be signed with a trusted Microsoft certificate. Any unsigned code will fail to load. This document describes the technical steps required to enable unsigned test, development, or manufacturing applications to run. This document does not cover Metro Style applications for which there is a separately documented signing requirement and developer licensing.
Action required
In order for any test binary or tool to run on WOA platforms you must do one of the following:
· Register the install location of your test binaries as an exclusion path, OR
· Attach a Kernel Debugger and disable checking by setting the appropriate registry value
...cut...
2. Scripts - Scripts will be allowed to run if the script host (e.g. cscript.exe, cmd.exe, etc.) is Microsoft signed or is run under an exclusion path.
...cut...
How to register your test binaries in an exclusion path
...cut...
Exclusion paths are listed in the following registry key in REG_MULTI_SZ format:
Key: HKLM\SYSTEM\CurrentControlSet\Control\CI\TRSData
Value: TestPath
Paths added to this key should be in one of two formats:
1. Path (recursive): \Program Files\TestAutomationPath
2. Binary (specific): \Program Files\TestAutomationPath\mybinary.exe
Note: Do not include the drive letter of the volume. Each path will be excluded across all volumes.
...cut...
The following paths are restricted and cannot be added as an exclusion:
1. \
2. \Windows
3. \Windows\System32
4. \Program Files
...cut...
How to disable signature verification with an attached Kernel Debugger
To disable signing verification when a Kernel Debugger is attached the “DebugFlags” value must be deleted from the “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CI” registry key and the system must be rebooted. After this Signing Verification will not take place.
This can be scripted by putting the following in a .cmd script and executing with admin privilege:
cmd /c reg delete "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CI" /v DebugFlags /f
shutdown -r -t 0
...cut...
Note: Enabling Kernel Debug will not be allowed by default on machines with Secure Boot enabled. Either Secure Boot will need to be disabled, or during boot the F8 menu selection to EnableDebugging must be chosen.
...cut...
At a later point, changes will be made to Windows 8 builds which will enforce that only machines configured as “Debug System” will support exclusion paths.
A “Debug System” is will initially be identified by the presence of the Microsoft Test Signing CA in the UEFI signature database (“db”).
...cut...
Note: If there is a need to run unsigned tools, the system can be configured as a “Debug System” during manufacturing but there must be a step in the production process that removes the Microsoft Test CA.
Production machines must not ship with the Microsoft Test CA in the db.
Click to expand...
Click to collapse
First we need to get hands on ARM device. I'd recommend Qualcomm-based, as chinese friends regularly leak their docs/sources. MS Surface is Tegra-based, so don't buy it
And one more thing:
This document “Enabling Debug Mode for Development, Manufacturing, and Support of Windows RT Devices” discusses placing a production device into ‘Debug Mode’ is accomplished by creating a per device Windows Debug Policy using tools provided by Microsoft.
Click to expand...
Click to collapse
Unfortunately I don't have “Enabling Debug Mode...” document, as I don't have access to connect.microsoft.com. Anyway it would not be helpful for us, end-users.
So to turn on a device to debug mode - you'll need a special "something" that is signed for your particular device. Sign is based on 2048-bit key, so you can't bruteforce it. But you can try to hack UEFI. UEFI is partially opensourced, so you can start to study its code now from edk2.sf.net
And one more way. Remember the test signing mode in Win7+. It is still present in Win8. Turn it on via bcdedit on your RT-device, use your own certificate to sign your driver or your program, ..., profit.
But be careful when hacking. There are known problems with BitLocker when test signing mode is on. The OS simply would not boot. Lets hope that we could disable BitLocker on our devices...
Just tried editing the registry to add a testing path. Didnt work
Still asks for certificate
xanderkaiber said:
Just tried editing the registry to add a testing path. Didnt work
Click to expand...
Click to collapse
According to MS document - this would work only on "debug mode"/"debug system" devices.
Can you turn on the test-signing mode:
Code:
In elevated CMD type:
bcdedit.exe /set {globalsettings} testsigning Yes
bcdedit.exe /set {bootmgr} testsigning Yes
bcdedit.exe /set {current} testsigning Yes
and try to sign your app with your own certificate I hope that test signing is still present on WinRT.
But first check that you are not using BitLocker (the "get-bitlockerVolume" command in admin's powershell). According to MS docs the retail device would not boot in this case (this info is taken from windows phone 8 "portico" docs, so may be unrelated to WinRT devices).
danchar4 said:
How did you bypass the error message in VS2012? Can you share the exact steps you took to bypass the error as well as your mystery executable here so that folks who are under NDA and have early access to the ARM devices can try it out?
Since Office RT is a desktop app, one can only assume all of this is possible.
Click to expand...
Click to collapse
Theres some info on the web somewhere for a config change to VS2012 that lets it build ARM desktop apps
Not that you can run them due to the signing issues
http://stackoverflow.com/questions/...op-programs-be-built-using-visual-studio-2012
I did it!
I managed to build and run a windows application for arm! Just turned on test signing and signed it with my own cert, then compiled for ARM in vs2012 and it ran
Definitely a good sign
xanderkaiber said:
I did it!
I managed to build and run a windows application for arm! Just turned on test signing and signed it with my own cert, then compiled for ARM in vs2012 and it ran
Definitely a good sign
Click to expand...
Click to collapse
Working on the surface?
Sent from my SCH-I535 using Tapatalk 2
eorsini said:
Working on the surface?
Sent from my SCH-I535 using Tapatalk 2
Click to expand...
Click to collapse
Not a surface, a Qualcomm engineering sample device. But I imagine it would definitely work on the surface also.
xanderkaiber said:
I managed to build and run a windows application for arm! Just turned on test signing and signed it with my own cert, then compiled for ARM in vs2012 and it ran
Click to expand...
Click to collapse
Great news
Seems that turning on the test-sign mode would soon be a must on ARM devices, at least for those of us who need programs like VLC player, DosBox, FAR manager and so on.
As far as I can see, you could port pretty much anything (as long as it's c++) if you can get the source code.
Might give VLC a try now
Doesn't seem like a very good solution to me though.
While it's nice that progress is made, I think that running unsigned apps should be the primary focus - Microsoft could revoke the keys at any time.
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 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.
Click to expand...
Click to collapse
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.
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?
Click to expand...
Click to collapse
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.
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.
Click to expand...
Click to collapse
I run office from windows.old but it doesnt work at all.
windowsrtc said:
I run office from windows.old but it doesnt work at all.
Click to expand...
Click to collapse
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.
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. >.<
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.
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.
Myriachan said:
Visual Studio 2012's remote debugger doesn't work anymore, either.
Click to expand...
Click to collapse
What about VS2013 - the preview version has just been released... ?
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.
Click to expand...
Click to collapse
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.
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.
Click to expand...
Click to collapse
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.
"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:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Looks like they locked down the debugger decently.
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.
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.
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.
Click to expand...
Click to collapse
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
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.
Click to expand...
Click to collapse
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.
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.
Click to expand...
Click to collapse
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
noloader said:
Since your exploit still works, can you locate ci.dll and patch it in-memory? Or is Microsoft performing runtime integrity checks?
Click to expand...
Click to collapse
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.
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.
Click to expand...
Click to collapse
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.
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.
Click to expand...
Click to collapse
I believe everything in this thread is our own research.
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.
please release your jailbreak so that other people can help you.
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.
why not change the variables back after you launch your unsigned exe?
windowsrtc said:
why not change the variables back after you launch your unsigned exe?
Click to expand...
Click to collapse
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?
Myriachan said:
However, this leaves one thing to be desired: executing ARM code.
Click to expand...
Click to collapse
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!
bfosterjr said:
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.
Click to expand...
Click to collapse
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.
...
...
Myriachan said:
That it's currently impossible to execute ARM code reliably on Windows RT is a major reason that Firefox hasn't been ported.
Click to expand...
Click to collapse
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.
bfosterjr said:
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.
Click to expand...
Click to collapse
The javascript JIT engine is to ARMv7 not THUMB_2 though.
SixSixSevenSeven said:
The javascript JIT engine is to ARMv7 not THUMB_2 though.
Click to expand...
Click to collapse
I gathered as much. I'm suggesting a re-write of that as part of the port.
Cheers!
Possible, but not easy. The result would likely be significantly less efficient... but better than no JIT at all. It substantially increases the effort required for porting, though.
As for PatchGuard... I don't know as much about it as I'd like, but the fact that it only checks periodically suggests something that we can anticipate and head off, assuming we can get our own drivers loaded... hmm. This is a pretty "out there" solution, but is there any chance that the version of PG from RT8.0 could be substituted in? That may assume a greater degree of encapsulation of PG functionality than is actually warranted, but it does seem to me that, if we can't modify it, we might be able to just replace (or possibly remove) it. Another option: rather than modifying the value itself, modify the code that checks it? I mean, if they were smart, that's under PG as well, but it *might* not be. Either bypassing the check for the values, or the signature check, or just spoofing the signature check, or taking it a level even further and replacing the whole loader function with a clone that lacks the check (which allows the original to remain intact, aside from however the shim is injected).
Any which way, a lot of binary RE... ick, but that's life.
A few ideas:
1) Put a memory read breakpoint on the memory addresses you wish to change, check the context reading it and change it to what it should be if it's PatchGuard, and what you want if it's not.
2) Hook BugCheck to make it just return if PatchGuard calls it (I seem to recall reading something about PG wiping the stack/any context before calling BugCheck, so this may not work)
3) Forcibly enable Debug mode VIA setting the required kernel flag/calling the proper function (kdStartDebugger? something like that; I had found it at one point) to enable the debugger. I have no idea if PG will sense this on pre-existing threads or not, but if it does then it should shut itself down.
4) Check if THIS approach works in 8.1 (I suspect not, since it was published for 8.0 previews)
5) (This would work for g_ciOptions, but not patching the interrupt handlers), hook the usermode function that queries the state of the signing, make it call a driver that changes the bit back, check, then call the driver to set it to default again. You would only get a BSoD if you were really unlucky and PatchGuard happened to run during the 30ms that the flag was changed.
I'd like to play with some of these ideas, but without access to the current prototype (hint hint), and not having a PC I want to upgrade to 8.1 right now, it's difficult.
netham45 said:
A few ideas:
1) Put a memory read breakpoint on the memory addresses you wish to change, check the context reading it and change it to what it should be if it's PatchGuard, and what you want if it's not.
2) Hook BugCheck to make it just return if PatchGuard calls it (I seem to recall reading something about PG wiping the stack/any context before calling BugCheck, so this may not work)
3) Forcibly enable Debug mode VIA setting the required kernel flag/calling the proper function (kdStartDebugger? something like that; I had found it at one point) to enable the debugger. I have no idea if PG will sense this on pre-existing threads or not, but if it does then it should shut itself down.
4) Check if THIS approach works in 8.1 (I suspect not, since it was published for 8.0 previews)
5) (This would work for g_ciOptions, but not patching the interrupt handlers), hook the usermode function that queries the state of the signing, make it call a driver that changes the bit back, check, then call the driver to set it to default again. You would only get a BSoD if you were really unlucky and PatchGuard happened to run during the 30ms that the flag was changed.
I'd like to play with some of these ideas, but without access to the current prototype (hint hint), and not having a PC I want to upgrade to 8.1 right now, it's difficult.
Click to expand...
Click to collapse
1. You can't set a read breakpoint because PatchGuard is also checking the contents of the interrupt vectors/registers. It would notice that someone is using the hardware breakpoints before it tried to read kernel memory.
2. Yes, PatchGuard overwrites KeBugCheckEx with a pristine copy among other tricks.
3. PatchGuard knows that the debugger was not enabled at boot, and will not allow it to be enabled. It will bugcheck if you try to enable it.
4. It's possible that the approach where you look for the self-decryption code at the beginning of the DPC handlers would work.
5. There is a better way, closely related to how I'm writing my installation program, to allow unsigned PEs to load. It would escape PatchGuard's notice. A user-mode hook would be required in order to neuter wldp.dll, though, since ntoskrnl.exe would still tell programs that the current policy was locked down.
I think I can do everything I need to do except execute ARM code reliably without harassing PatchGuard.
Melissa
As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.
sahack said:
As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.
Click to expand...
Click to collapse
There is a lot of software that we would like to port over that is written in arm assembly. We would have to rewrite it to THUMB-2 to use it on Windows RT, though. Porting software is (relatively) easy, rewriting it is difficult.
sahack said:
As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.
Click to expand...
Click to collapse
Common one that needs the ARM instruction set would be a javascript engine. V8 which is the javascript JIT used in chrome only has x86 and ARMv7 versions available, it doesn't have a THUMB_2 version. Although V8 itself can compile for THUMB2, that is only the JIT'er itself, it will only ever JIT to the full instruction set. So to port chrome we wouldnt be able to use V8, there might be a way to get it to compile using the windows javascript engine (which is slower than V8 but perfectly fine) or something but its still a significant obstacle.
The same applies to quite a few other softwares.
Then as netham says, we have software written in arm assembly which people have requested, thats great but it takes alot of effort to rewrite it in thumb2 assembly.
If you have software which can indeed compile for thumb2 and function on thumb2, yeah thats great. But there is some which doesnt.
netham45 said:
There is a lot of software that we would like to port over that is written in arm assembly. We would have to rewrite it to THUMB-2 to use it on Windows RT, though. Porting software is (relatively) easy, rewriting it is difficult.
Click to expand...
Click to collapse
Okay... I used to think that only JIT compilers and media decoders needed that...
But that gives another question.... Were we able to let the CPU stay in ARM mode in Windows RT 8.0?
(And if PatchGuard checks periodically, is it possible to just reset its timer once in a while?)
sahack said:
Okay... I used to think that only JIT compilers and media decoders needed that...
But that gives another question.... Were we able to let the CPU stay in ARM mode in Windows RT 8.0?
(And if PatchGuard checks periodically, is it possible to just reset its timer once in a while?)
Click to expand...
Click to collapse
First question, no.
Second question, thats what the thread is discussing although your suggestion is perhaps worth a look into (if myriachan hasnt already)
SixSixSevenSeven said:
First question, no.
Second question, thats what the thread is discussing although your suggestion is perhaps worth a look into (if myriachan hasnt already)
Click to expand...
Click to collapse
Sure, you could reset the timer on PatchGuard continuously, if you can find all its timers and perfectly distinguish them from those that were created by legitimate drivers. That's the harder part, unfortunately. =/
Hi,
I've buy from at lest one mont a surface rt, i've jailbreak it and install filezilla and notepad+++ so.... but i'd like anymore. Like many people i'd like to install a linux distribution on it but i dont really understand what is the problem...
I've know about:
Surface get a secure boot (EFI) and we can't disable the secure boot on surface RT caused windows need a valid key (?). I've read that linux got some distributions arm based (ubuntu, debian, fedora) and i think i've understand about ubuntu got a valid microsoft signature with a ssl provider that can bypass the useless verification... am i right?
So, if ubuntu (or another distro), got a valid sign for bypassing the limitation to due EFI why can't we normal install linux such like surface pro??
Best regards and sry for my bad english ^^'
----------------------------------------------
Some distros has keys to X86 UEFI. No one (other than Microsoft) has keys for ARM.
And (afair) due to some limitations of jailbreak we have no way to execute linux kernel.
This applies to any RT device.
kitor said:
And (afair) due to some limitations of jailbreak we have no way to execute linux kernel.
Click to expand...
Click to collapse
Is this true for sure? I figured especially since we have driver-level access we could possibly tear down the Windows kernel in reverse and start execution of arbitrary code. But I might have missed something.
The bigger issue about trying to port Linux to any device without official Linux support is usually in getting the kernel to boot and then making the hardware itself useful after that. This usually means you have to work "blind" and rely on some kind of low-level serial output to monitor the kernel boot to see where it panics. Only after getting a successful kernel boot can you even begin to think about drivers for the display, touch screen, etc.
So the prerequisites to even beginning to port to e.g. a Surface would be to find some way to kick out Windows and start arbitrary execution, enable some kind of low-level serial debugging for the would-be kernel, and then tediously poke and prod until it can successfully start. I'm not sure anyone knows of a dependable way to get serial debugging information.
Embedded devices on the whole are a lot more finicky and a lot less tolerant than normal PCs, generally due to their proprietary nature requiring a lot of hardware knowledge to initialize everything properly. About the only thing we'd have going for us is that it's a Tegra chipset, so if you can get the underpinnings working, you can probably at least get the basics like video and USB working without too much trouble.
I think the biggest thing about it is like the rest of RT ... there's just not enough interest in those with the skills to even attempt this because this is such an extreme minority platform. I imagine a Surface RT would make an excellent little Linux tablet, but I'm not holding my breath.
Well, If somebody would write something like WinKExec, or HaRET (haret allowed to analyse gpios and memory on WinCE/WM devices) then things may be possible. I own XPS10, so quite different device (as it has Snapdragon CPU), but I have some (small) experience on porting Linux on ARM devices - some time ago I was able to get Linux working on Bsquare Maui: http://pdasite.pl/kitor/maui_linux/ (including hardware reverse engineering - tracking gpios using multimeter - this way i found hidden usb host )
There's been talk of a WinKExec-like approach for months. Nobody has attempted it yet, though, or if they have they kept quiet about it.
One of the problems getting something like that working on RT is that it blocks kernel debugging, so you have to work pretty blindly. Then there's all the driver issues.
What about getting android to boot on it? There's drivers and such for tegra 3. I think its possible to build and deploy if we can get a kernel exploit. Am I wrong?
Android depends on Linux. If you can't get a Linux kernel booted, you won't be able to get Android to start up either.
skiman10 said:
What about getting android to boot on it? There's drivers and such for tegra 3. I think its possible to build and deploy if we can get a kernel exploit. Am I wrong?
Click to expand...
Click to collapse
The kernel by itself would be *relatively* easy (translation: still quite hard, but we could probably do it if people cared enough). However, getting all the other hardware (you know, things like the touchscreen, WiFi, and such) would likely be difficult, and without all that, it's pretty useless as a tablet. This is true for both Android and "desktop" Linux.
Where should I start to get a kernel to boot? I'm an android exploiter trying to dabble in Windows exploitation.
Sent from my HTC6500LVW using Tapatalk
Well, unless you think you can break Secure Boot, you should start by writing/porting a way to use the NT kernel to launch the Linux kernel. That probably means a lot of NT driver development stuff (done without the aid of a kernel debugger, just for extra fun).
There's a doc on internet from the blackhat usa 2013 seems to be interesting.
The man from the pdf get the exploit of injecting some code from the boot, so i think we can done this, no ?
If anyone tried and arrive he'll get amout of money from me
graphsys said:
There's a doc on internet from the blackhat usa 2013 seems to be interesting.
The man from the pdf get the exploit of injecting some code from the boot, so i think we can done this, no ?
If anyone tried and arrive he'll get amout of money from me
Click to expand...
Click to collapse
Can you PM me the article?
---------- Post added at 10:59 AM ---------- Previous post was at 10:57 AM ----------
GoodDayToDie said:
Well, unless you think you can break Secure Boot, you should start by writing/porting a way to use the NT kernel to launch the Linux kernel. That probably means a lot of NT driver development stuff (done without the aid of a kernel debugger, just for extra fun).
Click to expand...
Click to collapse
I think there is an exploit for Secure Boot, it just hasn't been shared yet...
If you mean the exploit I think you mean (discovered by an XDA member), it's a Windows bug, not actually a Secure Boot bug. It doesn't actually allow booting a different OS directly, just messing with Windows after bootup. We already have the jailbreak (for 8.0), which is pretty much equivalent.
GoodDayToDie said:
If you mean the exploit I think you mean (discovered by an XDA member), it's a Windows bug, not actually a Secure Boot bug. It doesn't actually allow booting a different OS directly, just messing with Windows after bootup. We already have the jailbreak (for 8.0), which is pretty much equivalent.
Click to expand...
Click to collapse
Im researching the doc i've found to provide you it.
Its not the jailbreak done by clockr ported by neman its another jailbreak who's available from the boot, but if remember they dont give sources... search in progress i'll post the link
There is one theoretical way to remove secureboot on a jailbroken device. It is rather easy: write a driver that reads/writes physical RAM. Find EFI_RUNTIME_SERVICES in memory and look for SetVariable function. Patch it so that it does not check for a valid signature. Than write your own certificates to UEFI with this patched function. Profit.
I've already done the first part - wrote a driver and found the table in memory (this is really an easy part). But my device died before I was able to successfully overwrite the certificates.
As far as I know similar method was once demonstrated for an x86 UEFI, just noone made it for ARM.
That... is a rather clever option too, although I'm tempted to avoid things which require modifying the firmware (too much option for future updates to break things). Still, a good option for those of us with gen1 devices who would like to be able to upgrade without losing the jailbreak, and also a good option for those who would like to install different OS images...
mamaich said:
There is one theoretical way to remove secureboot on a jailbroken device. It is rather easy: write a driver that reads/writes physical RAM. Find EFI_RUNTIME_SERVICES in memory and look for SetVariable function. Patch it so that it does not check for a valid signature. Than write your own certificates to UEFI with this patched function. Profit.
I've already done the first part - wrote a driver and found the table in memory (this is really an easy part). But my device died before I was able to successfully overwrite the certificates.
As far as I know similar method was once demonstrated for an x86 UEFI, just noone made it for ARM.
Click to expand...
Click to collapse
Can we get in contact? I'd love to get a more detailed plan that I can try. Gen 1 Surface RT on Windows 8 RT.
One demo about bypass: youtube.com/watch?v=i9ULYwRK1iU searching again the pdf mens
GoodDayToDie said:
Well, unless you think you can break Secure Boot, you should start by writing/porting a way to use the NT kernel to launch the Linux kernel. That probably means a lot of NT driver development stuff (done without the aid of a kernel debugger, just for extra fun).
Click to expand...
Click to collapse
About the only way you could possibly break secure boot is possibly by spoofing a key or potentially modify the UEFI to have secure boot disabled. While both are technically possible, you'd have to find an exploit to do it because I'm sure the UEFI probably can't be easily flashed
ThatGuy94 said:
About the only way you could possibly break secure boot is possibly by spoofing a key or potentially modify the UEFI to have secure boot disabled. While both are technically possible, you'd have to find an exploit to do it because I'm sure the UEFI probably can't be easily flashed
Click to expand...
Click to collapse
if you got a device with a jtag interface left open, that should be easy enough. The problem is that EPROM "fuses" are usually burned on the SOC. The secureboot check is hardcoded check that flag. You can't alter the bootloader without invalidating its signature, and it's practically impossible to unset an EPROM fuse.
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.
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.
LolitaPlus said:
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.
Click to expand...
Click to collapse
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?
yeah patchguard has been bypassed I think https://twitter.com/standa_t/status/437972336705159169
master.peterm said:
yeah patchguard has been bypassed I think https://twitter.com/standa_t/status/437972336705159169
Click to expand...
Click to collapse
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.
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.
GoodDayToDie said:
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.
Click to expand...
Click to collapse
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.
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.
... 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).
GoodDayToDie said:
... 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.
Click to expand...
Click to collapse
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.
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...
GoodDayToDie said:
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...
Click to expand...
Click to collapse
Well apparently when passing an int (29) as the ProcessInformationClass value that indicates a protected process, and it does work for enabling it and disabling it on other processes so far, process acts like csrss once enabled. We have to make sure to set the SeDebugPrivilege flag on the current process in order to make OpenProcess open a process with the flag PROCESS_ALL_ACCESS which is required for NtSetInformationProcess.
Looking into this, might be worth a shot.
Interesting. MSDN for NtQueryInformationProcess (http://msdn.microsoft.com/en-us/library/windows/desktop/ms684280(v=vs.85).aspx) says that value is ProcessBreakOnTermination and indicates a "critical" process, which I interpreted to mean one that cannot be safely exited (there are a few of these, and have been since XP or before, while protected processes were introduced in Vista and "lightweight protected processes" (the kind that CSRSS is, apparently) were introduced in 8.1. Still, worth a shot.
Administrator should have SeDebugPrivilege, and *probably* have it enabled by default. I'm still not sure you will be able to open the handle to CSRSS - it's explicitly not supposed to be possible to mess with it even if you *are* Administrator (or otherwise have debug privs) - but it's worth trying.
EDIT: There's a policy in Local Security Policy Editor (secpol.msc, yes it's present on RT at least 8.0, if not on 8.1 it's in the registry anyhow), under Local Policies -> User Rights Assignment. You can control what privileges (in the NT Se*Privilege sense) processes owned by given users have. For example, "Debug programs" (This user right determines which users can attach a debugger to any process or to the kernel. Developers who are debugging their own applications do not need to be assigned this user right. Developers who are debugging new system components will need this user right to be able to do so. This user right provides complete access to sensitive and critical operating system components.). You can add "ALL APPLICATION PACKAGES" to the assignees. In theory, this would mean that app packages now have SeDebug. They *might* not be able to use it anyhow (because of the lowbox restrictions) but if they are, that removes the need to use a debugger to inject code into a desktop process running as Admin; just write a native app that calls the relevant APIs.
Great find, i'm away from my dev box until later today but i will try this out. I'm not use to finding the exploit, how ever i'm perfectly capable of writing code for one once its found. But ill dig deeper maybe powershell could still be a possibility.
Edit: Found a spreadsheet that documents all of the security registry keys for 8.1! I found Debug Programs flag for User Rights Assignment in the document for 8.1 and it says minimum requirement is Windows XP! So its most likely on 8.1, my dev box and surface are both on 8.1 so I can verify later I also have the registry key.
Also found load and unload device drivers flag, not sure if thats of any use.
Second Edit: "User Rights security settings are not registry keys" there is no registry key to edit so we would have to either use secpol.msc or figure out where these values are stored.
Is there any way for us to figure out how csrss is being flagged as a protected process? Is that done in the kernel, with its createprocess params or is it done by the process itself?
Also has anyone checked if they modified Powershell's exe to prevent unsigned C# code from executing? And if so we also should check if we can use an 8.0 copy on 8.1 worth a shot as well but i'm almost positive it will not execute because of the "Windows cannot verify the digital signature of this application."
It would help if we could at least get cdb or WinDbg working on 8.1 even if we can't attach it to csrss.
I PMd netham45 about how he got cdb working on 8.1 but he has not replied yet. I've checked the WDK 8.1 release and everything is there even for arm except cdb.
Edit:
Also i'm working with Spazzarama over at EasyHook to see how he wrote his Patchguard disabler. If I can get unsigned code running even if it means we need to use a dev id just to start the jailbreak like the original version of nethams tool it would be worth it if it means we can disable patchguard. I have a few ideas on how to go about this, possibly creating a blank app and compile it. Then disassemble the exe with ildasm and replace the entry point with code that includes desktop code, then stitch it back up with ilasm (command line args allow arm code creation and toggling app containers, as long as the tools that create an app package don't test command line args it should work ok and be valid because it wont load any desktop dll's if they are not called i've tested this on normal environments. Then we might be able to get desktop code running that will allow us to disable patchguard, modify the value and then remove the app.
Lots of me rambling on about that, hopefully we get somewhere.
Toxickill said:
Is there any way for us to figure out how csrss is being flagged as a protected process? Is that done in the kernel, with its createprocess params or is it done by the process itself?
Also has anyone checked if they modified Powershell's exe to prevent unsigned C# code from executing? And if so we also should check if we can use an 8.0 copy on 8.1 worth a shot as well but i'm almost positive it will not execute because of the "Windows cannot verify the digital signature of this application."
It would help if we could at least get cdb or WinDbg working on 8.1 even if we can't attach it to csrss.
I PMd netham45 about how he got cdb working on 8.1 but he has not replied yet. I've checked the WDK 8.1 release and everything is there even for arm except cdb.
Edit:
Also i'm working with Spazzarama over at EasyHook to see how he wrote his Patchguard disabler. If I can get unsigned code running even if it means we need to use a dev id just to start the jailbreak like the original version of nethams tool it would be worth it if it means we can disable patchguard. I have a few ideas on how to go about this, possibly creating a blank app and compile it. Then disassemble the exe with ildasm and replace the entry point with code that includes desktop code, then stitch it back up with ilasm (command line args allow arm code creation and toggling app containers, as long as the tools that create an app package don't test command line args it should work ok and be valid because it wont load any desktop dll's if they are not called i've tested this on normal environments. Then we might be able to get desktop code running that will allow us to disable patchguard, modify the value and then remove the app.
Lots of me rambling on about that, hopefully we get somewhere.
Click to expand...
Click to collapse
Have you tried the latest WinDBG that came with SDK 8.1? I'm using RT 8.0 so I cannot verify it, however it should work on RT 8.1 since it came with the 8.1 SDK
C\Program Files (x86)\Windows Kits\8.1\Debuggers\Redist
cdb is part of WinDBG
It's a flag passed to CreateProcess (presumably therefore also in NtCreateProcess), CREATE_PROTECTED_PROCESS. Only usable on binaries with a special Microsoft signature. It blocks most access to the process, causing an OpenProcess specifying those permissions to fail. http://msdn.microsoft.com/en-us/library/windows/desktop/ms684880(v=vs.85).aspx
EDIT: Creating a sideloadable app with desktop code is easy; we managed that over a year ago. The fancy/complex way of doing involves scanning the system libraries that are loaded into memory (using an allowed API, such as GetSystemTime() as a starting point) for the entry point of LoadLibrary, then calling that using a function pointer. The simple and straightforward way is to either modify the header files (which #ifdef out the relevant prototypes when compiling for WinRT) or just copy-paste those prototypes and definitions into our own headers, and then link against the relevant libraries (it's easy to extract .LIB files from DLLs). The latter approach has more initial time investment, and is probably easier to detect, but is "cleaner" (the source code looks exactly the same as would normally be used, aside from removing some checks in the headers) and slightly more performant on startup.
@LolitaPlus: The public debug tool downloads don't include ARM debugger binaries, so they won't run on RT...
They can debug ARM programs, but that's not sufficient for this purpose. Microsoft (and OEMs) have debugging tools that run on the devices directly, and they have leaked in the past; that's what's needed.
GoodDayToDie said:
It's a flag passed to CreateProcess (presumably therefore also in NtCreateProcess), CREATE_PROTECTED_PROCESS. Only usable on binaries with a special Microsoft signature. It blocks most access to the process, causing an OpenProcess specifying those permissions to fail. http://msdn.microsoft.com/en-us/library/windows/desktop/ms684880(v=vs.85).aspx
EDIT: Creating a sideloadable app with desktop code is easy; we managed that over a year ago. The fancy/complex way of doing involves scanning the system libraries that are loaded into memory (using an allowed API, such as GetSystemTime() as a starting point) for the entry point of LoadLibrary, then calling that using a function pointer. The simple and straightforward way is to either modify the header files (which #ifdef out the relevant prototypes when compiling for WinRT) or just copy-paste those prototypes and definitions into our own headers, and then link against the relevant libraries (it's easy to extract .LIB files from DLLs). The latter approach has more initial time investment, and is probably easier to detect, but is "cleaner" (the source code looks exactly the same as would normally be used, aside from removing some checks in the headers) and slightly more performant on startup.
Click to expand...
Click to collapse
Thats what i figured, for csrss, with the sideloadable app I was just wondering if it would be easier to do il modifications. But we are trying to get unsigned code anyway. Im home now and ill look into secpol.msc on my 8.1 tablet. It IS on my dev pc 8.1.
Edit:
Ok secpol.msc is available on my surface, and Debug programs is set to Administrators, what should I try modifying it to?
GoodDayToDie said:
@LolitaPlus: The public debug tool downloads don't include ARM debugger binaries, so they won't run on RT...
They can debug ARM programs, but that's not sufficient for this purpose. Microsoft (and OEMs) have debugging tools that run on the devices directly, and they have leaked in the past; that's what's needed.
Click to expand...
Click to collapse
I'm not talking about VS remote tools. I'm talking about WinDBG (version 6.3.xxxx, not the 6.2.xxxx) and it is on my Surface RT now.
Please correct me if you are not talking about this(WinDBG). If indeed that is what you want, give this link a try (I just uploaded it):
https://mega.co.nz/#!Rthz1aCC!chur33IsRLASnysWQOgNY9LJaeyv8oIsPaHDnwbuWCE