yashsingh1/xdaforums huggingface dataset:
[Windows RT Development and Hacking] smx06:
Nice researches.

But did anyone tried to do official development apps for ARM steps?:

http://xdaforums.com/showthread.php?t=1466400&page=3

http://blogs.msdn.com/b/jasonz/arch...-about-developing-for-windows-on-arm-woa.aspx

There is a section of signing self app and this app can contain native code (if written on C++)

Maybe it is possible to modify sign procedures to sign self built arm legacy-desktop apps(MSVS 2012)

Or are the sign checks different for win8 apps (even containing native code) and desktop apps?

p.s. other interesting thing for me is to try to launch low level native app

built in VS2012 (for arm)

(SUBSYSTEM:native ; those that use just ntdll.dll and run even before login like chckdsk;

they started from

SYSTEM\\CurrentControlSet\\Control\\Session Manager

"BootExecute")
[Windows RT Development and Hacking] netham45:
I tried that yesterday, it informed me that my device did not support that feature, though I just tried it after doing a reinstall and it worked fine... Perhaps that was related to it thinking I was using Windows To Go, not sure.

And as far as modifying the low-level code, the only code we could modify that won't get checked is the UEFI code.

UEFI checks bootloader, bootloader checks winload.efi, winload.efi checks ntoskrnl, ntoskrnl checks everything else. We need to disable verification somewhere. The kernel options to disable it seem to be overridden by the secureboot option, and we have no means of getting into the BIOS and changing that, as far as I know.

Maybe there's some way we could fool the kernel into thinking the device isn't ACPI aware so it couldn't check secureboot status or something?

Edit: I was also able to get a remote debugger to attach to a command prompt on the system. Download (Signed, for ARM)

It should be possible to replace code with it, as the EXEs -should- only be checked upon load. I haven't done enough with VS to know how to do that, though. I was able to change the current instruction (PC) though, and it did have an effect on the process.

Also, just to note, booting off of USB like I laid out in the previous post even once will mark your install as a to-go install and break the store. Only way I've found so far to fix it is to reinstall windows.
[Windows RT Development and Hacking] clrokr:
The UEFI firmware is signed, so we can't flash our own. Maybe there exists a vulnerability in the certificate parsing code, in that case we could. Still digging.
[Windows RT Development and Hacking] netham45:
On the note of flashing, are there any easy to access jtag pins?

Edit: I'm playing with the drivers in the c:\windows\system32\drivers folder, you can append whatever you want to them and they still work, and they don't seem to contain any signatures internally. However, if you edit them, it gives a digital signature error. Anyone know where the signatures for them would be stored?

More edit: There's seemingly no way to disable DEP. /execute and /noexecute=AlwaysOff have no effect on the kernel (Querying WMI in powershell reports DEP is still on).
[Windows RT Development and Hacking] GoodDayToDie:
The debugger is a good step. Even without kernel debugging, that means we already have arbitrary code exeution (if very, very clunkily) on the desktop, potentially as Admin. That's huge.

I'll try and do some research next week, when I've got a bit of time off from work. I think I have a non-debugger way of running third-party desktop code on RT, although it will currently require being networked to another PC.
[Windows RT Development and Hacking] netham45:
How would you get arbitrary code with the debugger? I can change registers, but I can't see any way to change opcodes or data.

Edit: I also stepped through the process creation in commandprompt, it's all fine until it makes a call off to kernel-land, then the kernel returns with a failure error. I was hoping it was checking in userland (similar to how Software Restriction Policies work), but it's not.

On that note, a developer-signed app is signed with a temporary key (generated off of your developer license), but the resulting .exes are not runnable, except through metro. They give the certificate error, but they run as their own process through Metro.

Said exe seems to be completely unsigned, and is not challenged when I change strings inside it.

Also note that you should be able to use powershell to P/Invoke stuff.
[Windows RT Development and Hacking] smx06:
and what will go on if call desktop exe from metro app (createprocess or somth)?

did You create native code app? (c++) or .net one?
[Windows RT Development and Hacking] netham45:
I created a default project, it seems to be C++.

I also found out how to get it to stop thinking I'm on Windows To Go, set HKLM\System\CurrentControlSet\Control\PortableOperatingSystem to 0. I also managed to get msinfo32 to report secureboot as off (locked down the HKLM\System\CurrentControlSet\Control\SecureBoot key), but the kernel is still enforcing it.
[Windows RT Development and Hacking] smx06:
Thanks

Imho there are more chances playing with apps signing with developer license than finding a way to switch off the signing at all
[Windows RT Development and Hacking] GoodDayToDie:
The debugger allows you to override memory and modify memory protections within the process address space. This includes the code pages (normally read-only) and data pages (normally not executable). At least, you can do such things with WinDBG on x86 processes; I'd be quite surprised if it didn't work on ARM too (considering that the entire way that a debugger does breakpoints requires modifying the process code...)

It is, as I said, very clunky. However, you should be able to trap a program as soon as it is loaded (after the kernel checks and such, but before the program actually begins executing) and basically replace it wholesale with a different program.
[Windows RT Development and Hacking] netham45:
Yup, I was able to change some code in the command prompt. Just had to find where they hid the memory window in VS2012.

Edit:

Top being normal command prompt behavior, the bottom being after I flipped a few random opcodes in the function that's returned to right after the kernel tries to run the exe.

So yea, unsigned code, though however tedious, is running.

Now that we can do that, we need to find some way to get into kernel mode and disable the signing checks.

Edit 2: Or, if you want to elaborate a bit more on your idea, I can start trying to poke at it to see if I can get any results.
[Windows RT Development and Hacking] chris3ds:
App Certification Kit for Windows RT

Microsoft have released a version of their App Certification Kit, it's a desktop app that'll install and run on Windows RT and is designed for validating Metro-style apps for the Windows Store, however for whatever reason it's possible to select the option to validate a desktop app. Not sure if this could maybe be used as a method of loading unsigned desktop apps on Windows RT.

http://msdn.microsoft.com/en-US/windows/apps/jj572486
[Windows RT Development and Hacking] netham45:
Gave it a shot, it didn't run the app. It flickered some error after thinking for about 5 minutes, then said it didn't run.

https://code.google.com/p/chromium/issues/detail?id=146254 (Don't just click links on there, you may BSoD)

The OS that comes in recovery is vulnerable to that kernel exploit that should be able to give us code execution.
[Windows RT Development and Hacking] GoodDayToDie:
I was thinking of using that exploit, but it's already patched. You don't want to remain unpatched to something so easily remotely exploitable, anyhow. Now that we have arbitrary code execution in user space, however tediously, all we really need is an authenticated-user-to-kernel exploit. MS tends to assign these very low priority, which often leads to them being left unpatched...
[Windows RT Development and Hacking] superboom:
Is there a Remote Desktop App?

http://www.youtube.com/watch?v=tS4mJBzEkUw

Lol he runs Minecraft with remote desktop app on surface
[Windows RT Development and Hacking] GoodDayToDie:
There's actually two Remote Desktop apps. There's the built-in one common to all versions of Windows (mstsc.exe, called "Remote Desktop Conection" in the Start menu, runs on the desktop) and there's also a free Metro-style Remote Desktop app available from Microsoft. In one of the few cases of such a thing, I think the Store app may actually be better in some ways than the desktop app whose functionality it duplicates. Both work fine on Surface.
[Windows RT Development and Hacking] netham45:
I think the win32k.sys exploit is possibly the best-case scenario. It's in the recovery image, so MS can't blacklist the cert without completely breaking it, it's easy to use (double-click a TTF, done), and it's documented rather well for an exploit.

Yea, it'll leave a hole open, but no one is going to be targeting the ARM machines with it, so worst-case we get a BSoD here and there.

Also, IE isn't vulnerable to it. You have to download the .ttf to the desktop and open it in the preview app to get it to crash.

Edit:

Using the exploit from http://xdaforums.com/showthread.php?t=1944675
[Windows RT Development and Hacking] GoodDayToDie:
Oh, nice find!! Cool. That means we now can execute arbitrary desktop code... if we don't mind the fact that everything will be running in the AppContainer, which means low ACl privileges and low integrity level.

Is your test Exe completely unsigned, or do you have the signing cert for it installed on your tablet the way that sideloading Metro apps requires you to do?

Also, on more thought: the Windows Runtime API for opening a folder permanently gives access to the specified folder to that app. This makes it a lot easier to lift the restrictions of the sandbox, although you can of course also do it using the normal tools for editing permissions as well.
[Windows RT Development and Hacking] netham45:
It's completely unsigned. I've attached it. Also, lots of various API calls seem to fail, I'm currently trying to get runas to let me elevate to a different user to see if that'll let me run anything as admin.

Oh, also, I had to put the .exe in the system32 folder to get it to let me run it. I suspect it just has to be on the path, but I haven't tried.
[Windows RT Development and Hacking] GoodDayToDie:
It needs to be anywhere that the app can access. The System32 directory works fine, because of course the app needs to be able to load system binaries from there. Putting the executable into the app's AppData folder should also work, although since I believe a low-integrity folder (which makes it easier for the app to write to it), that *might* not work. I'm not sure.

Thanks for the download, although I have my own test code too. Mine was signed before, but I can easily test an unsigned version... :)
[Windows RT Development and Hacking] netham45:
I was unable to escalate privileges with CreateProcessWithLoginW, it gave me an access denied.

Oh, also, advapi32.lib does not expose the LogonUser and CreateProcessWithLogin functions, I had to use the code in the previously posted example to get them.

Edit: Something in kernel-space is verifying if the process can launch other processes or not, any idea what to look for?
[Windows RT Development and Hacking] GoodDayToDie:
Yeah, I don't believe Low integrity apps are allowed to call that API. The usual way you'd do it is to create a medium IL "broker process" that listens on an IPC channel of some sort for requests from the low IL process, verifies that they are safe, then carries them out on behalf of said process (this is how IE in Protected Mode is still able to save files to normal IL folders, for example).

Of course, in this case, we can't really write our own broker processes yet. AppContainer has brokers (used for the file/folder pickers, among other things) butI'm pretty sure none of them are going to let you call CreateProcess with medium IL but no signature checks...
[Windows RT Development and Hacking] netham45:
Is there any way to replace the security token with one of higher access in the debugger?
[Windows RT Development and Hacking] GoodDayToDie:
Typically that would require a kernel debugger. The security token is stored in, or at least referenced from, the PROCESS kernel object (technically a C struct). Under normal situations, a process doesn't even read its own PROCESS object, and it's not even possible for user-mode code to write to it, debugger or no debugger. Now, a local EoP from user to kernel could get around that...
[Windows RT Development and Hacking] netham45:
We'd better get to work on that, then. My vote is still for exploiting the TTF bug, though it's a bit outside my skill range right now.
[Windows RT Development and Hacking] smx06:
Maybe somth of this powershell cmds from neighbor thread:

2. Open powershell as an administrator

3. Execute the following commands in powershell

a) set-executionpolicy unrestricted

b) cd xyz\Pandora_0.0.3.3_AnyCPU_Test

c) .\Add-AppDevPackage.ps1

[Note: It might ask you to login to your Microsoft Account that is necessary to get the necessary certificates to sign the package]
[Windows RT Development and Hacking] netham45:
Unfortunately those only control signature verification for sideloading Metro apps, they have no effect on Desktop Mode.

Edit: Another idea, use the debugger to edit explorer.exe and disable where it lowers the security token before calling the Metro app.
[Windows RT Development and Hacking] clrokr:
It's very like enforced on kernel level, so if you want to start the process with normal rights it has to be signed. That's why an application with AppContainer integrity can start other unsigned apps.

EDIT: The vulnerability in win32k.sys is not exploitable. Yes, it triggers a crash on Windows RT. But the routine looks like this:

Int16 start=0x0000
Int16 end=0xFFFF

Int32 counter = (Int16)(end + 1 - start)

So counter is zero. The 16-bit value is even zero-extended to 32 bits. Now the crash:

do {
Int32 x = *someBuffer
*someBuffer = x

*someBuffer+=4
counter-=1
} while (counter != 0)

It crashes after more than 0x10000 iterations because after the first iteration the counter is 0xFFFFFFFF when it should be 0xFFFF. The problem is it crashes on read access and without a kernel debugger there is nothing we can do about that.

The function bComputeGlyphAttrBits could be exploited (it has the same counter problem), but we never get there.

I seriously hope I'm wrong about this, but I don't think so.
[Windows RT Development and Hacking] netham45:
Perhaps we could make IE plugins then?

Does it crash right at 0x10000 iterations, or somewhere farther down the line? Would it be possible to mak the TTF only have 0x10000 and bypass the crashing function?
[Windows RT Development and Hacking] GoodDayToDie:
Taking that TTF file and trying to tweak it (or just fuzzing the file, which is a brute-force but surprisingly effective option) may work, but - even though this is right up my alley, skill-wise - I'm going to pursue other approaches first. I don't like the idea of trying to use an already-patched exploit that could so easily be exploited by somebody else (just slip the TTF into any downloaded ZIP file or similar).
[Windows RT Development and Hacking] clrokr:
No, either it crashes or it parses perfectly fine. Both have the same bug/design problem.

However, looking at some of the code for font parsing, there have to be more vulnerabilities. I don't get why it is part of win32k either.

I also have another idea. RE the code of WinVerifyTrust to find out if we can change the "allowed" root certificate. I sincerely hope it isn't signed itself though.
[Windows RT Development and Hacking] netham45:
I believe the root certificate is passed to the OS by the bootloader, which is signed.

Something else I've found: If you hold vol+/vol- and hit power, it will boot to a blank screen, not unlike what my Iconia boots to in APX mode.
[Windows RT Development and Hacking] clrokr:
It doesn't seem to do anything with USB though. Maybe the i2c bus that connects the touch cover is working?
[Windows RT Development and Hacking] netham45:
If I boot like that with a direct USB cable linking the surface to my computer I get a new device in the device manager called 'APX'. I haven't been able to get anything in response from it, though.

C:\Users\Nathan\Downloads\NVFlash>nvflash.exe --sync
Nvflash started
rcm version 0X4
Command send failed (usb write failed)
[Windows RT Development and Hacking] clrokr:
Okay, that's a very good sign. It doesn't seem to work on mine, but I'll get another cable to be sure.

EDIT: Are you running it as admin? Please don't be offended, it happens to everyone and I don't know if nvflash can use UAC to get a new token.
[Windows RT Development and Hacking] netham45:
I can't recall if I was running it as admin or not, I'll be able to check in a few minutes. Also, the cable that I used was one that I made, I took two USB-A cables and wired them up wire for wire (Green<->Green,Red<->Red,White<->White,Black<->Black), plugged it all in with the tablet off, then booted into APX mode.
[Windows RT Development and Hacking] clrokr:
Thanks for the info on the cable, looking forward to poke this thing with libusb.

I can also confirm that the bootloader gives the kernel a "keyringaddress" boot argument.
[Windows RT Development and Hacking] netham45:
Is that the /FVEBOOT argument?
[Windows RT Development and Hacking] clrokr:
Good point. I'll try disabling BitLocker to see if it is still there.
[Windows RT Development and Hacking] netham45:
I was running as administrator, I also tried a number of different APX drivers.

Here are the HWIDs if you want them:
[Windows RT Development and Hacking] clrokr:
You could try patching this:

http://xdaforums.com/showthread.php?t=1426502

or using a pre-patched one from

http://androidroot.mobi/t3_nvflash/

I will do this later today, first i need to find a A->A cable with the right wires.
[Windows RT Development and Hacking] netham45:
Same result with the Transformer 700 APX interface driver.

Edit: I'm curious to see if it'll work from a Linux host. I'll try to get one set up in a few minutes.

Edit 2: No luck on Linux either, same error.

Edit 3: Found after some googling that 0x4 means that the bootloader is locked and that the SBK key is required to unlock it. As far as I know the SBK key has not been leaked for any Windows RT devices, and I have no idea how to come up with it.
[Windows RT Development and Hacking] apatcas:
I really wish microsoft would lose one of the unlocked keys.
[Windows RT Development and Hacking] netham45:
What about this exploit: http://j00ru.vexillium.org/?p=1272

Looks fairly secure to implement, and Windows RT -should- be vulnerable to it.

Edit: Herpderp, need to read closer. Win8 isn't vulnerable to it.
[Windows RT Development and Hacking] GoodDayToDie:
Yeah, that kind of exploit tends to get patched by MS. I'm still working on this but it's been a busy couple weeks, between travel and Thanksgiving (taking me away from my dev box) and work.
[Windows RT Development and Hacking] netham45:
Okay, well, I'm still actively looking, so if you have anything you want me to look at, feel free to let me know.
[Windows RT Development and Hacking] xsoliman3:
Adding link to this article on calling win32 apis as the technique works on RT

and is relevant to the discussions here

http://xdaforums.com/showthread.php?t=1944675

Update - the cmd prompt this starts can run unsigned side loaded RT desktop apps

Update2 - unsigned cmd line apps (not win32 gui apps) but they still run in a modern app container
[Windows RT Development and Hacking] netham45:
That's already been linked here (It shows some promise because you can run unsigned apps with those API calls, they're just heavily restricted), but thanks.
[Windows RT Development and Hacking] netham45:
I was playing with the bootloader again, here's what I found this time:

You can edit the options passed to the kernel with the loadoptions bcd element, or by hitting F10 at the classic bootloader.

The classic bootloader can be accessed with 'bcdedit /set {default} bootmenupolicy legacy' and by adding another boot option to the menu (copy or create). You'll need a USB keyboard to change options once you're at the legacy menu.

'Legacy OS Loader' and 'Real-mode Boot Sector' modes seem to still exist on ARM, but the only file I could get to give any result while booting was by calling bootmgr.efi. It throws an invalid file handle error accessing /BCD (I created BCD files on the root of all FS's, was unable to get a change)

If you have 'testsigning', 'debug', or 'disable_integrity_checks' anywhere inside the loadoptions or entered at the F10 screen it will go to a default config consisting of /NOEXECUTE=ALWAYSON /FVEBOOT=<number> /NOVGA

If you remove NOVGA from the options the kernel will panic stating 0x00000004, which means INVALID_DATA_ACCESS_TRAP.

FVEBOOT has to do with bitlocker(FVE == Full Volume Encryption). I changed it to all sorts of random numbers and was unable to get any results, though.

You can get into safemode by cloning the default entry and setting 'SOS' to 1 in the BCD entry for it
[Windows RT Development and Hacking] clrokr:
Yes, while disassembling bootarm.efi I found a list of elements (parameters in their hexadecimal form) that are not allowed. I don't think there is a way around that.

Our best hope is for a signed device driver with a bug. It is going to happen, just a matter of time.
[Windows RT Development and Hacking] netham45:
I was reading through THIS and I don't see any reason it shouldn't work on the tablets. We have the debugger, I can attach to CSRSS and change random opcodes in memory, and disabling the integrity checks might do exactly what we need to do.
[Windows RT Development and Hacking] clrokr:
I can see only one small problem with this method: It relies on the fact that

The ARM Windows is running with big endianness. Also, it is 32-bit, so addresses are not sign-extended after bit 47. That means the pointer stored before nt!g_CiEnabled (if it is even there) will not appear like in the example. Let's say memory at nt!g_CiEnabled-4 looks like this:

C0102A08 C780012C 00000001

Accessing nt!g_CiEnabled-1 will look like 2C000000.

What we need is the value after nt!g_CiEnabled so we can access nt!g_CiEnabled+1. Its highest-order byte must not be zero because in that case the object manager would probably attempt to free it after decrementing 256 times. Any other value will be fine. Also, the kernel can not rely on this value while the operation is running.

Another thing we will have to find out is whether Windows RT allows for unaligned access to memory like that. Let's hope it does.
[Windows RT Development and Hacking] netham45:
Does anyone know if I can get the symbols for Windows RT anywhere, so I can poke at this?

Edit: Nevermind, had an extra character in my symbol store path. Still not getting g_cienabled, though.
[Windows RT Development and Hacking] smx06:
Didn't someone try to explore the boundories of running desktop apps from native ones (described in the neighbor posts)? If cmd is successfully working and file restrictions can be bepassed with ACLs editing, it is already usefull.

Can anybody tell us what are other limitations running desktop apps from native app container?

Also from fact of possibility of running unsigned code there is an option to examine the checks (for app token?) that differ allowing and disallowing unsigned code running.

Guess this check is inside ntdll.dll (?) Can somebody attach this file from arm version (surface one) to explore?

thanks!
[Windows RT Development and Hacking] netham45:
The issue with running them inside the restricted app container is that it's permissions are so low that what would be just a recompiling job for most apps would turn into a tedious porting job.

The checks are inside kernel space. I briefly looked at them, but not enough to get anything conclusive. It errors out inside a kernel call in one of the CreateProcess functions inside advapi.dll.