[Release] RT Jailbreak Tool

Can use ARM code, but interrupt handlers will (incorrectly) throw the
CPU back into THUMB mode upon return, therefore ARM code is highly
unstable

Netham45,
That would explain the issue that I'm having. Do you have anymore info? Does that mean that I should completely forget about 32-bit ARM, or it's still possible to use it? Is that OS bug?

"ARMNT" is the PE image type of ARMv7-Thumb2. Visual C++ uses the #define _M_ARM_NT, though _M_ARM is also #defined by the compiler. Windows RT never leaves Thumb2 mode. In fact, the context switch routines in the kernel set the Thumb bit of CPSR when saving the CPU context of a frozen task, meaning that any interrupt will cause an ARM program to crash when control returns.

I know how to fix this - it's a matter of flipping a total of two bits in the kernel - the Thumb bit in a bitmask in an opcode in two functions. The problem is that PatchGuard doesn't like kernel hacks very much, and PatchGuard is a huge pain to work around.

I assume you got your answer in your other thread:

Basically you should "completely forget about 32-bit ARM" if you don't want to wait on the efforts of others to fix this issue.

Now, is it an OS bug? Well, I guess that depends on how you look at it...

or intended "feature" with primary intention to defeat rival browsers to get their products ported to arm-WinRT on time or make them crippled so that end-users stop liking these sluggish browsers and had a second look at old good explorer .

There is a certain amount of opcode interpretation done by the NT kernel. As an example from the x86 world, the NT kernel distinguishes between exception codes STATUS_INTEGER_DIVIDE_BY_ZERO and STATUS_INTEGER_OVERFLOW. The latter means integer divide overflow, which can easily occur in assembly language or intrinsics, but in straight C can only occur if you divide 0x80000000 by -1 as signed division.

The problem is that the x86 processor exception is the same for both divide by zero and divide overflow - interrupt 0. In order to distinguish the two cases, the NT kernel actually has to decode the faulting CPU instruction to see whether its parameter was zero.

On ARM, you see this with the invalid opcode handler. The UND (intentionally-undefined) opcode handler assigns special meaning to the low byte.

If the kernel allowed user mode to use ARM code, it would mean that the kernel would have to be able to decode opcodes in ARM mode, as well. I guess that they didn't want to have to do that.

This kinda complicates things , no? Are there any other interrupt/exception handlers that work like this?

Yes. It looks like the page fault handler also uses this mechanism to know where the page fault was. I guess ARM doesn't have anything like the x86's CR2 register =/