Is ARM (not Thumb) supported on WinPhone8 at all?

Question

I\'m facing a weird issue, somewhat similar to this. I have a Windows Phone 8 native DLL project, mostly C++ but with an ARM assembly source in it. The source is in ARM mode

Answer 1

I have firsthand knowledge of this; I was the reverse engineer who figured out the cause in Windows RT's kernel. Specifically, KeContextFromKframes in the Windows NT kernel (ntoskrnl.exe) is setting the T bit when freezing a thread's state for a task switch. This means that yes, upon resuming after an interrupt, you will crash.

This annoyed us jailbreakers for RT/WinPhone, because we couldn't directly port Chrome's JITter without breaking Microsoft's PatchGuard. We could load a kernel driver to patch this out of KeContextFromKframes, but then PatchGuard would later cause a crash.

Answer 2

A gentleman called Michael Schnell suggested elsewhere that the interrupt handler in Windows Phone 8 doesn't restore the Thumb flag, instead hard-codes it to 1. Testing seems to confirm that theory. The following snippet:

    THUMB
ASMTest
    mov r12, lr
    blx a
    mov lr, r12
    bx lr

    ALIGN 4
    ARM
a
    bx lr

consistently crashes under a debugger, but runs as expected when debuggerless (i. e. no interrupts while in ARM mode). When I inserted an empty loop with 0x10000 iterations in ARM mode, it ran on a few tries, then crashed.

Answer 3

you cant get an unaligned arm address when using BLX from thumb to arm. The lower two bits are anded by the second instruction. Read the arm docs, you basically have two instructions the first one is:

0xF01B

if H == 10 then
LR = PC + (SignExtend(offset_11) << 12)

basically the first instruction results in a modification of lr where pc is the address if this instruction plus 4 (two instructions ahead).

LR = PC + 0x1B000

The second is

0xEB0C

if H == 01 then
PC = (LR + (offset_11 << 1)) AND 0xFFFFFFFC
LR = (address of next instruction) | 1
CPSR T bit = 0

the end result is

PC = (address of next instruction + 0x1B000 + 0x318) AND 0xFFFFFFFC
PC = (address of next instruction + 0x1B318) AND 0xFFFFFFFC
LR = address of next instruction | 1
CPSR T bit = 0, arm mode.

I think your crash is somewhere else.

You should post the disassembly of the code in question, addresses of instructions and such.

as far as your BX attempt, you are walking a slippery slope...

ARM/Thumb state transfers
If Rm[1:0] == 0b10, the result is UNPREDICTABLE, as branches to non word-aligned
addresses are impossible in ARM state.

by anding with 1110 you are clearing the lsbit, but also potentially allowing an unaligned address. If you have not properly computed the destination address in r12 and if that is not arm code, then it wont work. Please post the disassembly of this as well as that will clearly show what is going on, also post the first instruction or few of the destination address.

It looks like your exception code is telling you that your exception is in thumb mode at a thumb address. Please post the disassembly for the code at/around that address.