-
Notifications
You must be signed in to change notification settings - Fork 647
Better Hidden & Module Scope #634
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
CI is not compatible with my PR. So I created my own GitHub action in my fork: https://github.com/yujincheng08/EdXposed/actions. You can try out the artifacts. DO AT YOUR OWN RISK. Updates:
For module scope, plz use this manger instead (need core patch): https://github.com/NekoInverter/EdXposedManagerR/releases/tag/v4.5.8 |
|
Since edxposed version 0.5, cannot hook isolated processes at initZygote's.Please help me |
Intended behavior. |
Yes, intended behavior. But some app can detect edxposed install. |
|
@loveedxposed never ever hook isolated process. it will lead to crashing (like chromium) |
Yes, i'm know, but version edxposed 0.4 can hook function in isolated process and bypass it. |
|
I think that's because Magisk hide doesn't work on isolated processes and is none of EdXposed's business. |
Thanks you, have a nice day |
Motivation
Many apps now detect Xposed's classes for security issues. EdXposed now provides an app list function to prevent hooking undesired apps. However, the classloader persists even if the app is blacklisted. The reason is that EdXposed load its java bridge and do some preliminary hooks in the zygote process and all subprocesses inherit them! Since both YAHFA and SandHook do not support unhooking, all the java bridge will be preserved in the process memory even if we remove all global references (SandHook and YAHFA hold some handling global references). Apps, therefore, can detect Xposed by checking the classloaders and the Xposed Bridge. To prevent such detection, one way is to load the Java bridge in the target process instead of the zygote process if the app is whitelisted.
Implementation
To finish this mission, we should do as least things as possible in the zygote process, and do most of the jobs after forking. In the zygote process, we should not load any Java codes and do things purely in c++. Things that must be done in the zygote process are those that require special permission: reading the java bridge from the filesystem and loading configs. I, therefore, initialize the config manager in the zygote function and load dex files into byte arrays (but not loading them in ART).
After forking, if the target process is not blacklisted, load the dex files into ART by using
InMemoryDexClassloaderand load all the modules from the preloaded list by absolute Apk paths. Otherwise, release all the memories in the c++ part inherit from the zygote process.Side effect
InitZygote's are called on every process. This behavior exists in EdXposed but is not desired by the original Xposed.Testing
Tested YAHFA in Mi10 AndroidQ MIUI and in x86 AndoirdR emulator. Tested and passed Xposed Detector. Some apps detecting Xposed like Deemo, China Mobile, and BOCHK are working.
More tests are requried.