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.
http://surfsec.wordpress.com/2013/01/06/circumventing-windows-rts-code-integrity-mechanism/
Circumventing Windows RT’s Code Integrity Mechanism
January 6, 201355
clrokr (@clrokr) – 6. Jan 2013
It’s taken longer than expected but it has finally happened: unsigned desktop applications run on Windows RT. Ironically, a vulnerability in the Windows kernel that has existed for some time and got ported to ARM just like the rest of Windows made this possible. MSFT’s artificial incompatibility does not work because Windows RT is not in any way reduced in functionality. It’s a clean port, and a good one. But deep in the kernel, in a hashed and signed data section protected by UEFI’s Secure Boot, lies a byte that represents the minimum signing level.
Finding the right spot
The minimum signing level determines how good an executable’s signature is on a scale like this: Unsigned(0), Authenticode(4), Microsoft(8), Windows(12). The default value on x86 machines is of course 0 because you can run anything you like on your computer. On ARM machines, it defaults to 8.
That means that even if you sign your apps using your Authenticode certificate, the Surface or any other Windows RT device (at this moment) will not run them. This is not a user setting, but a hardcoded global value in the kernel itself. It cannot be changed permanently on devices with UEFI’s Secure Boot enabled. It can, however, be changed in memory.
Finding this byte in the kernel takes a while, there is no exported symbol for it and not even in the symbol database at MSFT. I found it using WinDbg and a machine running Windows 8 Pro, creating processes and watching how the system behaves when the signature checks happen all the way through CI.dll and back. Because Windows 8 and Windows RT are so similar, locating it in the ARM kernel was not hard:
SeGetImageRequiredSigningLevel+0x18
LDR R3, =0x59FFA6 This is our byte, 0x19FFA6 at 0x400000 image base
LDRB R3, [R3]
CMP R3, #4
BHI loc_HighSigReq
B.W loc_LowSigReq
There are many more places where you can find this byte accessed, but none of them have an exported symbol.
Prerequisites
A while ago I read an article about how the Windows kernel assumes that data passed by certain processes is always well-formed [1]. This vulnerability exists in Windows RT, but exploitation is a bit harder than on Windows 8 because unsigned binaries can’t be run in the first place (and store apps don’t have the security context you need to attach to other processes). But Microsoft decided to provide something very important [2] that made this whole endeavour a lot easier. This remote debugger, when run as Administrator, can attach to the user’s CSRSS process and manipulate its memory.
CSRSS contains a lot of calls to the vulnerable NtUserSetInformationThread function, including some that use the right parameters to exploit it. This is one of them (from winsrv.dll):
TerminalServerRequestThread+0x230
MOVS R3, #0xC
ADD R2, SP, #0x58
MOVS R1, #9
MOV R0, 0xFFFFFFFE
BL NtUserSetInformationThread
A CSRSS thread executes this code. Using a breakpoint, we can change the data structure pointed to by R2 before the NtUserSetInformationThread call happens to exploit the vulnerability. Sadly, this is very impractical because the exploit subtracts 1 from the specified address and we need to subtract 0×80000. This is because we can’t do an unaligned access on ARM (remember, our byte’s offset is 0x19FFA6), so we need to use 0x19FFA4.
We also need the linear address at which the kernel image resides. We can find this out by calling (on the device, this can be done from a store app which will run unsigned) NtQuerySystemInformation with information class 11. If you want to know how to use NtQuerySystemInformation from a store app, read [3]. This gives us a list of all loaded drivers and their image bases, effectively bypassing ASLR in this case (although this is not what ASLR is for, it is annoying in these situations).
Exploitation
Using the remote debugger and MSFT’s armasm, I used a half-empty code page in winsrv.dll (0×10800 from the image base) to store this small payload:
push {r5-r8}
mov r7, 0x80000
ldr r8, my_addr
loc_loop_begin:
movs r3, 0xC
add r2, sp, 0x68 ;0x58 org.
add r5, r2, 4
str r8, [r5]
movs r1, 9
mvn r0, 1
mov r12, 0x10E1
svc 1
subs r7, r7, 1
cmp r7, 0
bne loc_loop_begin
pop {r5-r8}
mov r0, r0
my_addr dcd 0x12345678 the kernel's base address + 0x18
We now set a breakpoint directly after the legitimate NtUserSetInformationThread call in TerminalServerRequestThread, pressing a volume button will trigger it. This is where it gets interesting.
Redirect the instruction pointer to the payload in memory and set a breakpoint at the mov r0, r0 instruction at the end. Press F5. Now set the instruction back to the first breakpoint and remove both. Press F5 again.
Congratulations, your Windows RT device is unlocked!
Conclusion
Windows RT is a clean port of Windows 8. They are the same thing and MSFT enforces Code Integrity to artificially separate these platforms. It does not stop pirates from modifying store apps (and their license checks) because store apps are the only things that can actually run unsigned. The fact that this method works on Windows 8 as well shows how similar the systems are. You can even enforce Code Integrity on Windows 8 to see what Windows RT feels like!
The decision to ban traditional desktop applications was not a technical one, but a bad marketing decision. Windows RT needs the Win32 ecosystem to strengthen its position as a productivity tool. There are enough “consumption” tablets already.
Microsoft, please consider making code signing optional and thereby increasing the value of your Windows RT devices!
Drawbacks
Sometimes this triggers a bugcheck because we can’t control the bytes at 0x19FFA4 and 0x19FFA5 from the kernel base and they sometimes are zero, causing a 0×18 bugcheck.
This method is not practical for most users, especially because tablet buyers are less likely to know enough about computers to do this than PC users.
Interesting... he doesn't give any examples of code he's managed to run, though.
How do we go about building desktop software for RT since Visual Studio only targets Metro?
elyl said:
Interesting... he doesn't give any examples of code he's managed to run, though.
How do we go about building desktop software for RT since Visual Studio only targets Metro?
Click to expand...
Click to collapse
Someone has already run Putty on WinRT in the other thread in the Win8 forum.
http://forum.xda-developers.com/showthread.php?goto=newpost&t=1885399
Not sure what else has been successful
goofball2k said:
Someone has already run Putty on WinRT in the other thread in the Win8 forum.
http://forum.xda-developers.com/showthread.php?goto=newpost&t=1885399
Not sure what else has been successful
Click to expand...
Click to collapse
Hmm, in that case almost all desktop apps could potentially be rebuilt for ARM in VS2012.
Think we just need someone to have the EFI secure boot so the hack can be done permanently, since it's a little impractical to do this every boot.
goofball2k said:
Someone has already run Putty on WinRT in the other thread in the Win8 forum.
http://forum.xda-developers.com/showthread.php?goto=newpost&t=1885399
Not sure what else has been successful
Click to expand...
Click to collapse
Thanks for the heads up. Haven't followed that thread for a while.
Cant wait until this is ready for the masses to try out. Would there be a chance of bricking the device by doing this - I assume so.
I've recompiled Bochs, TightVNC (Server and Viewer), and PuTTY personally, 7zip was recompiled and posted by Cotulla, and the tablet will just run any pure .net 4.5 apps.
Very exciting stuff. Certainly looking forward to a perm unlock though.
Has anyone tried to run cisco anyconnect or is that to reliant on x86? This is great news though
There are other hacks being worked on to achieve this, or something like it, on a permanent basis (or at least without requiring an external PC). Follow the threads, we'll keep the community informed.
One request though, please: unless you have something to actually contribute, PLEASE DO NOT post on that thread! It got a bit spammed when the news broke, which is annoying to people who are using it to communicate and coordinate hacking efforts.
lumpaywk said:
Has anyone tried to run cisco anyconnect or is that to reliant on x86? This is great news though
Click to expand...
Click to collapse
if u wanna recompile for ARM you can try it. Don't misunderstand that you will be able to run x86 apps, you will not.
lumpaywk said:
Has anyone tried to run cisco anyconnect or is that to reliant on x86? This is great news though
Click to expand...
Click to collapse
I doubt this would work since it AnyConnect also installs a network driver which shows up in Device Manager.
The problem is just being able to recompile it. Windows RT can actually install third-party drivers, though they need to be signed (as on x64 versions of Windows... and testsigning mode is blocked, so it has to be a trusted signature). However, if something you want isn't open-source, you're going to have a hard time getting an ARM copy of it at all, and without that you can't run in on Surface RT or any other Windows RT (ARM) device.
I posted this in the Desktop Apps Ported To... thread and it was recommended that I take this topic to its own discussion.
I stumbled across this the other day and found it quite interesting.
WinKexec
https://www.jstump.com/projects/kexec/wiki
Basically a Windows Kexec port wrapped up in a driver. I'm waaay out of my league here, but it would seem like it should be possible to port this driver to RT and install it since we now have kernel mode access in the most recent Jailbreak.
The idea of kexec in RT was tossed around earlier in some threads but never really go off the ground. Perhaps porting an existing Windows driver would be easier.
Thoughts?
I have not looked into sources, but I really think that the process is too x86-specific. I don't think that ARM HAL uses HalReturnToFirmware function as we have UEFI, not BIOS, and so on.
The same can be done for RT too, and even much easier. Just make a driver that would flush the disk cache, and then run the Haret code that was used to turn off MMU and boot Linux on Windows Mobile devices. Probably the code should be modified for newest ARM CPUs (at least to shut down the second and other cores), but this should not be too difficult.
mamaich said:
I have not looked into sources, but I really think that the process is too x86-specific. I don't think that ARM HAL uses HalReturnToFirmware function as we have UEFI, not BIOS, and so on.
The same can be done for RT too, and even much easier. Just make a driver that would flush the disk cache, and then run the Haret code that was used to turn off MMU and boot Linux on Windows Mobile devices. Probably the code should be modified for newest ARM CPUs (at least to shut down the second and other cores), but this should not be too difficult.
Click to expand...
Click to collapse
Reading the implementation doc, probably some of the steps are still the right idea, if they have Windows RT equivalents. It's using the kernel to halt the other CPU cores (definitely a good idea) and then finally executing the boot. I imagine having a kernel driver via our jailbreak is the right way to go in any case (whether or not it's "this" kernel driver) because we pretty much need to do the basic concept of halting everything Windows is doing and overwriting it (in memory) with a new bootloader binary.
Why would RT not use HalReturnToFirmware? First of all, a lot of x86 Windows installs are on UEFI these days. It's almost impossible to find a new motherboard with BIOS, in fact (though many will emulate it on top of UEFI). Second, what do you think the "F" in UEFI stands for? RT certainly does have HAL as well.
In any case, there is *some* function that implements the "OK, kernel is done, turn everything off at the hardware level now" functionality. It might not be called HalReturnToFirmware on RT (though it probably is), but I guarantee you it exists.
GoodDayToDie said:
Why would RT not use HalReturnToFirmware?
Click to expand...
Click to collapse
There just may be no sense in it. As RT does not need to implement lots of legacy BIOS interactions and directly call UEFI interfaces when needed, like HalEfiResetSystem. But this is just my guess, I have not looked into the HAL disasm for a long time.
Anyway I've already wrote how loading Linux could be done from a driver without patching the HAL in RAM by reusing the old Haret code. You are in kernel mode in your driver - so you can really do anyting.
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. =/
I tried to post this in the development forum, but I am not allowed.
I am tinkering with ARM architecture and Android device development and low level OS stuff. I am currently using QT C++ for Android for app development. This works great for all of my standard Android app development, but now I am digging deeper. I am doing an experiment where I have a small binary blob (64k) of ARM code that I want to load into memory at run time using mmap(). In order for this code to work, it needs to be loaded at address 0x22000000. In my C++ code i call mmap(0x22000000, ...) which would map the binary file to that address only if it were not in use already, which it is on a couple different android devices that I have tried, so it maps to another address, as it should by design. I tried using MAP_FIXED as a flag to mmap() and the application crashes, as expected, since mmap() overwrites memory that is already in use.
In order for mmap() to map the binary file to the address I want, I believe that I can do some sort of advanced Android / Kotlin / gradle level compile time linking modifications in order to make sure that the area of memory (the whole page at least I imagine) that I want to mmap() to is unused when execution reaches my C++ code that calls mmap(). I don't know the android build system very well though, so I hope some Android experts can help me. I am not trying to access real physical RAM though, only address 0x22000000 in the processes virtual address space. Because of this, I believe that with some custom hackery can be done during linking to modify the areas of RAM that are assigned for program/stack/etc use. I believe I am looking for the equivalent of LD script customization for standard GCC C/C++ compiled software, and possibly some direction on how to manipulate.
I have successfully done this on a raspberry pi running raspbian via a command line C++ application, as well as an x86_64 Fedora system using an x86_64 binary blob. In both cases I got lucky that the area of memory was not in use, so mmap() succeeded and I was able to execute the code as desired.