[WIP] Compatibility with frida-server#376
Conversation
|
The in-memory value of |
Workaround: Using LSPosed and Frida Simultaneously1. The Problem: A Conflict of ControlBoth LSPosed and Frida are powerful frameworks that function by deeply modifying the Android Runtime (ART) and application processes. When used together on the same application, they compete for control over the same low-level structures, such as method entry points and internal runtime objects. Our analysis shows that Frida's instrumentation is often more invasive—it may replace core runtime pointers and data structures that LSPosed assumes will be stable. This leads to a fundamental conflict:
Therefore, the key to compatibility is ensuring the correct initialization order. 2. The Golden Rule: LSPosed First, Frida SecondThe core principle of this workaround is to ensure that LSPosed's hooks are applied when an application process is first created, and Frida only attaches to the process after it has been stabilized by LSPosed. An application process is instrumented by LSPosed at the moment of its creation (the "Zygote fork"). In contrast, This leads us to the practical workaround. 3. Step-by-Step InstructionsTo safely use both frameworks on a target application, you must manually control the initialization order. Let's assume the target application's package name is
By following these steps, you ensure the app starts in a "pure" LSPosed environment, which is stable enough to then accept Frida's instrumentation. 4. Important Scenarios and Warnings
While the long-term goal is to resolve this incompatibility at the source-code level, this workaround provides a stable and reliable method for using these two powerful tools together. |
|
This critical A detailed investigation into the crash revealed that the root cause is an incorrect base address resolution for
To solve this, the parsing logic has been fundamentally improved. The new implementation replaces the fragile "find-first" approach with a robust, structurally-aware heuristic. It first filters all memory segments belonging to the target library and then searches this list for the first |
Resolves a `SIGSEGV` crash that occurs when co-instrumenting with recent versions of Frida. The root cause was that the previous parsing logic would select the first memory mapping matching the library name. When Frida is active, it can temporarily create a transient, read-only mapping at a lower address than the real library. This would cause our parser to select the wrong base address. This commit refactors the `findModuleBase` function to be structurally aware. It now filters all mappings for the target library and specifically searches for the pattern of a read-only (`r--p`) segment immediately followed by an executable (`r-xp`) segment. This allows it to correctly identify the real library mapping and ignore transient artifacts from other instrumentation frameworks.
A running
frida-serverchanges a lot of Android runtime, and thus ruins the initialization of LSPosed and LSPlant.In this PR, we aim to solve this problem by avoid touching environment modified by Frida during the LSPosed initialization.