Fix code swap region permissions

[kaftejiman]

I/O error began appearing after installing the latest ART update (version 351110190) on my Pixel 6 Android 12. The bootstrapper code was written into a non-writable region, causing the ptrace pokedata call to fail with an I/O error. My understanding of Frida internals is limited, so the breakdown below might be incomplete or off-target

At the start of the injection flow a comparison occurs between the remote and local libc here. Libc is delivered as part of the runtime APEX; since apexd can mount the APEX packages multiple times—each with a separate loop device—both system_server and Frida obtain their APEX mount through separate activation or bind-mount operations. This results in different loop devices (with distinct minor numbers), making the identity comparison (based on dev major+minor and inode) between local and remote libc fail.

As a consequence, the injection flow falls back to the code swap route here, where Frida tries to load the bootstrapper into an RX-mapped region. Prior to ART version 351110190, this route worked because Frida correctly matched the boot image segment loaded as RWX. After the update, the runtime behavior changed: the RWX region no longer exists, and the enumeration now selects the memfd:jit-zygote-cache region, which is not writable. Consequently, the ptrace call here fails with an I/O error.

This PR refines both the libc comparison and the permissions matching for the code swap region.

Debugged on:

• Pixel 6
• Android 12
• Frida: 16.6.3
• ART version: 351110190

[oleavr]

Thanks a lot! 🙌

• I made some minor style tweaks to your libc matching patch, mainly introducing variables to avoid the need for comments.
• The suggested change to the code swap logic would require every such target to have at least one RWX region, which could be a bit much to ask and result in a regression. So I changed the logic there to skip memfd regions. For plain regions we don't need the W bit set, as ptrace() will help us out, but it appears it won't do that for memfd regions. Hopefully we won't have to add too many additional exceptions to this heuristic :)