search

rovo89 / XposedBridge

The Java part of the Xposed framework.
3.91k stars 1.1k forks source link

I found the hook for package can be disabled by app itself #67

Closed liudongmiao closed 7 years ago

liudongmiao commented 9 years ago

So, what's the principle for xposed?

Currently, the hook for package is running in the same process with the running package, and can be disabled by the app. So how do you think about this?

For the app developers, it's not safe for xposed to hook some method, specially for billing app. But I don't think the hook should be disabled absolutely by the app too.

rovo89 commented 9 years ago

the hook for package is running in the same process with the running package

This sentence doesn't make sense to me. A hook isn't something that can "run" - it's basically just code injection into the app, so it has to run in the same process. Can you explain in more detail please?

rovo89 commented 9 years ago

That's one of probably many ways. Any suggestions how you would prevent this?

pylerSM commented 9 years ago

Class.forName - if argv[0] is XposedBridge, throw Class not found exception?

pylerSM commented 9 years ago

I wrote really simple module which does what I said above and it works. Maybe it could be part of framework?

rovo89 commented 9 years ago

I strongly recommend not to hook such central classes/functionality because it might interfere with Xposed's internals and might lead to performance issues (e.g. Class.forName() is used a lot for every single layout that is inflated). Besides that, this closes just one possible access vector, while it might have unforeseeable side-effects. So no, this is nothing for the framework, and I wouldn't even want this to be done by any module.