Closed elesbb closed 6 years ago
Are you sure com/android/server/ssrm/bx is exactly the class you are trying to work with? I would try to enumerate all declared methods of given class using getDeclaredMethods() and compare with your smali.
Maybe your class loader is wrong which means you are not hooking within a proper package/process.
Yeah. Its the right class I need. I also agree that the class loader might be wrong. However, the class is part of a framework.jar, so I use loadPackageParam.packageName.equals("android")
to filter the class loader. I'm going to surround it with a try/catch block to see if not filtering class loader will find the proper class. I find it hard to believe that another class has the same exact name from another package. Unless another package loads this class and only has access to specific methods? But getMethods
should return ALL methods, including private/protected ones.
getDeclaredMethods()
only returns AE
which is not even in the class attached. It has to be loading a different class than the one I am looking at in smali code. I did a pull of the system so I know I don't have my jar files messed up. Its also Samsung, so god knows what could be going on.
If i remember well the days i was playing with Samsung dvfs freqs, ssrm classes were loading in a different package.
So I tried this:
Class<?> BX = loadPackageParam.classLoader.loadClass("com.android.server.ssrm.bx");
Method m = BX.getMethod("run");
This was all in a try catch block and the only time it could find the class was when the loadPackageParam.packageName
equaled android. Every other time an exception was thrown. And this was without filtering packageName
. It never found the "run" method. So its like it doesn't exist.
So I have no idea which other package the class would be loaded in. Even still, it should have found it with the test I mentioned. I was getting multiple other errors with other classes too that had no real parent directory. They were like this in the decompiled directory "smali/g/i.smali" and it couldn't find those classes either.
I may just have to do the smali edits and remove the .odex file. I had a similar problem where the class was hooked but I couldn't locate the class smali file when coding my AOD Customizer module. Samsung can be really annoying but I need LifeProof cases lol.
@wanam, do you remember which package they were loading into?
I also wanna mention that the other methods and classes I can hook without any problem. There are just a few that I cannot.
I'm an idiot. Somehow I managed to look at an ssrm.odex that ISN'T on my device... Doing a pull of /system/framework I can now see that those methods and classes are not even part of the odex.. I am so sorry...
So I am trying to hook things. I can find the classes and methods inside the smali file that exists inside the ssrm.jar file. But xposed can't find them and I am doing everything correctly. Attached is the smali file and i have the logcat error included, along with code.
LOGCAT:
JAVA CODE SNIPPET:
bx.txt
If you look at the attached text file (smali) you'll see that the method is there.
Also, doing
getMethods
on the class shows that it doesn't exist so I don't think its necessarily xposed but what the heck is it then? The class is in a ssrm.jar framework file.