Run QBDI on another stack for android application

[nsurbay]

When running Frida/QBDI on android, Frida and QBDI hijack the "genuine" stack of the current thread. An other stack is allocated and use by the instrumented program. However, It's seems that android runtime performs dynamic check on the stack pointer (see #242 (comment) and #235) and generate StackOverflowError exception when the stack pointer is lower that the expected stack limit.

Three solutions exists to solve this problem:

• Allocate a stack with a greater address than the "genuine" stack
• Fix the android runtime
• Implement a stack switch in QBDI

For the first solution, the user can perform it by itself. It will need to check the current allocated region in the current process, find a suitable range with a greater address that the current SP, and allocated with mmap (with a fixed address). However, this need extra code, and we not sure that a suitable range exists.

For the second solution, it's more an hack than an actual solution. The user can patch the android source code and recompile it, or, for a given version of android, reverse the current runtime to find the address where the stack limit is stored, and dynamically patch this address.

The third solution is to add a new API inside QBDI to move the engine (QBDI) stack to another location during the instrumentation. When performing this stack switch, the "genuine" stack is no longer use by the engine and can be use by the instrumented code. However, this solution has some limitation that the used must know :

• While the genuine stack will be used by the instrumented code, we cannot remove / override the part use by Frida/QBDI before the stack switch. As it, the instrumented code will only use the remaining genuine stack after the stack switch.
• When the execution of the instrumented code returns, QBDI will erase his custom stack and returns to the genuine one. As it, the user cannot access to the instrumented stack after end of the instrumented execution.
• Callback will be executed on the new allocated stack. If the user or the Frida / JS engine calls android runtime method, the same exception can occurs. To handle this case, we may want callbacks to execute on the genuine stack (below the current stack pointer and potential red-zone).