stalker: Fix recompile error in Stalker when processing the same real_address block with different insn multiple times.

[ZSA233]

Problem Resolution:

1. Due to incorrect snapshot comparison by memcpy in gum_exec_ctx_obtain_block_for, the instruction changes in the same real_address could not trigger a recompile, resulting in erroneous reuse of the first block when block->storage_block branch.
2. When performing recompile with scratch writes, if the original block cannot accommodate the space required by the instructions generated by the new transform(), the generated js_callback was not destroyed, leading to an issue.

Reproduction Scenario:

func alloc_mem_to_exec(void * start_addr, byte[] insnBytes) {
    void *mem = mmap(start_addr, page_size, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_ANON | MAP_PRIVATE, -1, 0);

    memcpy(mem, insnBytes, len(insnBytes));

    // flush cpu cached
    __asm__ volatile(
        "dsb sy\n"
        "isb sy\n"
    );

    // call func
    func_t func = reinterpret_cast<func_t>(mem);
    func();

    munmap(mem, page_size);

}

func main(){
    void *start_addr = nullptr; // make sure using the same area
    byte[] nopRet = [
            0x1F, 0x20, 0x03, 0xD5, // nop
            0xD6, 0x5F, 0x03, 0xC0, // ret
    ];
    byte[] ret = [
            0xD6, 0x5F, 0x03, 0xC0, // ret
    ];
    alloc_mem_to_exec(start_addr, nopRet);      // first block
    alloc_mem_to_exec(start_addr, ret);         // [√] recompile
    alloc_mem_to_exec(start_addr, nopRet);      // [x] no recompile
    alloc_mem_to_exec(start_addr, ret);         // [x] no recompile
}

Test

gumstalker-arm64 has been tested, and gumstalker-arm was fixed based on it but not tested.

[oleavr]

Thanks! Sorry it took me so long to get to this.

[oleavr]

This seems like it's dealing with a symptom instead of the root cause -- isn't the root cause that ctx->mappings should have been updated so it has the new block (storage_block)?

[ZSA233]

This seems like it's dealing with a symptom instead of the root cause -- isn't the root cause that ctx->mappings should have been updated so it has the new block (storage_block)?

Since my understanding of this project may not be very comprehensive, my previous commits made only minor modifications based on the original implementation approach — the fix works without updating ctx->mappings while maintaining the original design.

However, after hearing your explanation, I re-evaluated the code, and you are right. If we consider a more thorough modification, we could indeed try discarding the original block and updating ctx->mappings with the newly recompiled new_block, while also freeing the original block.

By doing so, ctx->scratch_slab and block->storage_block can be deprecated, making the recompilation logic clearer and more concise. Additionally, the following two cases in the original gum_exec_ctx_recompile_block implementation can be unified into a single approach (no need to use scratch to calculate and reuse block, generates a new block in any case):

1. When the size of the recompiled scratch_block fits within the space of the original block, the space in scratch_slab is used as a draft to overwrite the original block.
2. When the original block space is insufficient (the worst-case scenario requiring two compilations), a b jump is written into block->code_start to redirect execution to storage_block->code_start.

[oleavr]

(Sorry for the delay.) We cannot free/immediately re-cycle the original block, because other blocks may have been backpatched to jump directly to it. So that's why we leave it in place, but just overwrite its first instruction with a branch to the replacement block.

[oleavr]

This also seems like a symptom and not the correct fix. It seems the code generation is happening on the wrong block. Maybe it's just another symptom of failing to update the mappings?