Android dynamic proxy and using dynamic proxy to implement ServiceHook

Java's dynamic proxy

The first thing we want to introduce is Java dynamic proxy. Java dynamic proxy involves two classes: InvocationHandler interface and Proxy class. We will focus on these two classes below, and analyze the correct usage with examples. Before that, let's briefly introduce the generation and loading process of class files in Java. After the Java compiler compiles the Java file, it will generate a .class file on the disk. This .class file is a binary file, and the content is machine code that only the JVM virtual machine can recognize. The JVM virtual machine reads the bytecode file, extracts the binary data, loads it into memory, parses the information in the .class file, and uses the corresponding ClassLoader class loader to generate the corresponding Class object:

The .class bytecode file is generated according to the bytecode organization rules specified in the JVM virtual machine specification. For a detailed introduction to the .class file format, please refer to the blog In-depth Understanding of Java Class File Format and Java Virtual Machine Specification.

From the above, we know that JVM loads classes through binary information of bytecode. If we follow the format and structure of .class files organized by the Java compiler system in the runtime system, generate corresponding binary data, and then convert this binary data into the corresponding class, we can dynamically generate a class we want during operation:

There are many frameworks in Java that can dynamically generate corresponding .class binary bytecodes according to JVM specifications at runtime, such as ASM and Javassist, etc. I will not introduce them in detail here. If you are interested, you can refer to relevant information. Here we take the dynamic proxy mode as an example to introduce the two very important classes we will use. Regarding the dynamic proxy mode, I have already introduced it in Java/Android Design Pattern Learning Notes (9) - Proxy Mode, but I did not analyze the InvocationHandler interface and Proxy class in detail at that time. Here I will introduce it in detail. In the blog on proxy mode, we mentioned that the proxy mode is divided into dynamic proxy and static proxy:

The above is the class diagram of the static proxy mode. When this proxy relationship is specified in the code stage, the ProxySubject class generates a .class bytecode file through the compiler. Before the system runs, this .class file already exists. The structure of the dynamic proxy mode is slightly different from the structure of the static proxy mode above. It introduces an InvocationHandler interface and a Proxy class. In the static proxy mode, the methods in the proxy class ProxySubject are all specifically called to the corresponding methods in a specific RealSubject. What ProxySubject does is nothing more than calling the corresponding method that triggers the RealSubject; the basic mode of dynamic proxy work is to hand over the implementation of its own method functions to the InvocationHandler role. The Proxy role will hand over the calls to each method in the Proxy role to the InvocationHandler for processing, and the InvocationHandler calls the method of RealSubject, as shown in the following figure:

InvocationHandler interface and Proxy class

Let's analyze the steps of generating ProxySubject in dynamic proxy mode:

1. Get a list of all interfaces on RealSubject;
2. Determine the class name of the proxy class to be generated. The default name generated by the system is: com.sun.proxy.$ProxyXXXX;
3. According to the interface information that needs to be implemented, dynamically create the bytecode of the ProxySubject class in the code;
4. Convert the corresponding bytecode into the corresponding Class object;
5. Create an instance object h of InvocationHandler to handle all method calls of the Proxy role;
6. Instantiate a Proxy role object with the created h object as a parameter.

The specific code is:

Subject.java

 public interface Subject {
 String operation();
 }

RealSubject.java

 public class RealSubject implements Subject{
 @Override
 public String operation() {
 return   "operation by subject" ;
 }
 }

ProxySubject.java

 public class ProxySubject implements InvocationHandler{
     protected Subject subject;
 public ProxySubject(Subject subject) {
        this.subject = subject;
 } 
 
 @Override
 public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
 //do something before
 return method.invoke(subject, args);
 }
 }

Test code

 Subject subject = new RealSubject();
 ProxySubject proxy = new ProxySubject(subject);
 Subject sub = (Subject) Proxy.newProxyInstance(subject.getClass().getClassLoader(),
        subject.getClass().getInterfaces(), proxy);
 sub.operation();

The above is the simplest implementation code of the dynamic proxy mode. JDK supports dynamic proxy by using the java.lang.reflect.Proxy package. Let's take a look at the description of this class:

 Proxy provides static methods for creating dynamic proxy classes and instances, and it is also the
 superclass of   all   dynamic proxy classes created by those methods.

Generally, we use the following

 public   static Object newProxyInstance(ClassLoader loader, Class<?>[]interfaces,InvocationHandler h) throws IllegalArgumentException {
 // Check if h is not empty, otherwise throw an exception
 if (h == null ) {
        throw new NullPointerException();
 } 
 
 // Get the proxy class type object associated with the specified class loader and a set of interfaces
    Class cl = getProxyClass(loader, interfaces); 
 
 // Get the constructor object through reflection and generate a proxy class instance
 try {
        Constructor cons = cl.getConstructor(constructorParams);
 return (Object) cons.newInstance(new Object[] { h });
    } catch (NoSuchMethodException e) { throw new InternalError(e.toString());
    } catch (IllegalAccessException e) { throw new InternalError(e.toString());
    } catch (InstantiationException e) { throw new InternalError(e.toString());
    } catch (InvocationTargetException e) { throw new InternalError(e.toString());
 }
 }

The getProxyClass method of the Proxy class calls the generatorProxyClass method of the ProxyGenerator to generate a dynamic class:

 public   static byte[] generateProxyClass(final String name , Class[] interfaces)

We will introduce this method below, so we will skip it here. After generating the bytecode of this dynamic class, we generate the object of this dynamic class through reflection. After generating a dynamic proxy object sub through this static function of the Proxy class, we call each method of the sub proxy object. Inside the code, we directly call the invoke method of InvocationHandler. The invoke method distinguishes what method it is based on the method parameter passed to it by the proxy class. Let's take a look at the introduction of the InvocationHandler class:

 InvocationHandler is the interface implemented by the invocation handler of a proxy instance. 
 
 Each proxy instance has an associated invocation handler. When a method is invoked on a proxy
 instance, the method invocation is encoded and dispatched to the invoke method of its invocation handler. 

Method parameters and return:

One point mentioned above that requires special attention is that if the return value of the method defined in the Subject class is one of the eight basic data types, then the corresponding basic type wrapper class must be returned in the ProxySubject class, that is, int corresponds to Integer, etc. It should also be noted that if null is returned at this time, a NullPointerException will be thrown. In other cases, the return value object must be consistent with the return value of the method defined in the Subject class, otherwise a ClassCastException will be thrown.

Generate source code analysis

So what does the class dynamically generated by the newProxyInstance method of the Proxy class look like? As we mentioned above, JDK provides us with a method ProxyGenerator.generateProxyClass(String proxyName,class[] interfaces) to generate the bytecode of the dynamic proxy class. This class is located in the sun.misc package and belongs to a special jar package. So the problem comes again. The android project created by Android studio cannot find the ProxyGenerator class. This class is in the jre directory. Even if I copy the .jar package related to this class into the project and reference it in gradle, although I can find this class in the end, there will be very strange problems during compilation. So, there is no way. Android studio cannot create ordinary java projects. I can only install an intellij idea myself or ask for help from relevant colleagues. After creating a java project, use the following code to export the generated class to the specified path:

 public   static void generateClassFile(Class clazz,String proxyName)
 {
 //Generate bytecode based on the class information and the provided proxy class name
    byte[] classFile = ProxyGenerator.generateProxyClass(proxyName, clazz.getInterfaces());
 String paths = "D:\\" ; // The path here is hard-coded as drive D, and can be modified according to actual needs
    System. out .println(paths);
    FileOutputStream out = null ; 
 
 try {
 //Save to hard disk
 out = new FileOutputStream(paths+proxyName+ ".class" );
 out .write(classFile);
 out .flush();
 } catch (Exception e) {
 e.printStackTrace();
 finally
 try {
 out . close ();
        } catch (IOException e) {
            e.printStackTrace();
 }
 }
 }

The way to call the code is:

 generateClassFile(ProxySubject.class, "ProxySubject" );

Finally, a ProxySubject.class file will be generated in the root directory of the D drive (if the path is not modified). You can open the file using jd-gui:

 import java.lang.reflect.InvocationHandler;
 import java.lang.reflect.Method;
 import java.lang.reflect.Proxy;
 import java.lang.reflect.UndeclaredThrowableException; 
 
 public final class ProxySubject
 extends Proxy
 implements Subject
 {
 private static Method m1;
 private static Method m3;
 private static Method m2;
 private static Method m0; 
 
 public ProxySubject(InvocationHandler paramInvocationHandler)
 {
    super(paramInvocationHandler);
 } 
 
 public final boolean equals(Object paramObject)
 {
 try
 {
 return ((Boolean)this.h.invoke(this, m1, new Object[] { paramObject })).booleanValue();
 }
    catch (Error|RuntimeException localError)
 {
 throw localError;
 }
    catch (Throwable localThrowable)
 {
      throw new UndeclaredThrowableException(localThrowable);
 }
 } 
 
 public final String operation()
 {
 try
 {
 return (String)this.h.invoke(this, m3, null );
 }
    catch (Error|RuntimeException localError)
 {
 throw localError;
 }
    catch (Throwable localThrowable)
 {
      throw new UndeclaredThrowableException(localThrowable);
 }
 } 
 
 public final String toString()
 {
 try
 {
 return (String)this.h.invoke(this, m2, null );
 }
    catch (Error|RuntimeException localError)
 {
 throw localError;
 }
    catch (Throwable localThrowable)
 {
      throw new UndeclaredThrowableException(localThrowable);
 }
 } 
 
 public final int hashCode()
 {
 try
 {
 return (( Integer )this.h.invoke(this, m0, null )).intValue();
 }
    catch (Error|RuntimeException localError)
 {
 throw localError;
 }
    catch (Throwable localThrowable)
 {
      throw new UndeclaredThrowableException(localThrowable);
 }
 } 
 
 static  
 {
 try
 {
      m1 = Class.forName( "java.lang.Object" ).getMethod( "equals" , new Class[] { Class.forName( "java.lang.Object" ) });
      m3 = Class.forName( "Subject" ).getMethod( "operation" , new Class[0]);
      m2 = Class.forName( "java.lang.Object" ).getMethod( "toString" , new Class[0]);
      m0 = Class.forName( "java.lang.Object" ).getMethod( "hashCode" , new Class[0]);
 return ;
 }
    catch (NoSuchMethodException localNoSuchMethodException)
 {
      throw new NoSuchMethodError(localNoSuchMethodException.getMessage());
 }
    catch (ClassNotFoundException localClassNotFoundException)
 {
      throw new NoClassDefFoundError(localClassNotFoundException.getMessage());
 }
 }
 }

It can be observed that this generated class inherits from java.lang.reflect.Proxy and implements the Subject interface. Let's take a look at the code for generating dynamic classes:

 Subject sub = (Subject) Proxy.newProxyInstance(subject.getClass().getClassLoader(),
        subject.getClass().getInterfaces(), proxy);

It can be seen that this dynamically generated class will implement all interfaces in subject.getClass().getInterfaces(), and another point is that all methods in the class are final, and the class is also final, so the class cannot be inherited. Finally, all methods will call the invoke() method of the InvocationHandler object h, which is why the invoke() method of the ProxySubject class is finally called. Draw their simple class diagram:

From this class diagram, we can clearly see that the dynamically generated class ProxySubject (same name, so Dynamic is added at the end) holds an object h of the ProxySubject class that implements the InvocationHandler interface. When the operation method of the proxy object is called, the invoke method of object h is called. The invoke method distinguishes the method based on the name of the method, and then calls the corresponding method of the specific object through the method.invoke() method.

Implementing ServiceHook using dynamic proxy in Android

Through the above introduction to InvocationHandler, we should have a general understanding of this interface, but what is the role of the proxy class dynamically generated at runtime? In fact, its role is to insert some additional operations before or after calling the real business:

So in short, the processing logic of the proxy class is very simple, which is to insert some additional services before and after calling a method. And our practical example in Android is to selectively do some special processing before and after actually calling a system service. This idea is also very important in the plug-in framework. So how do we specifically implement the hook system service and attach the services we need when actually calling the system service? This requires the introduction of the ServiceManager class.

Introduction to ServiceManager and hook steps

first step

The detailed introduction of ServiceManager has been introduced in my blog: android IPC communication (Part 2) - AIDL, so I will not repeat it here. I strongly recommend you to read that blog. Here we will focus on the getService(String name) method of ServiceManager:

 public final class ServiceManager {
    private static final String TAG = "ServiceManager" ; 
 
    private static IServiceManager sServiceManager;
    private static HashMap<String, IBinder> sCache = new HashMap<String, IBinder>(); 
 
    private static IServiceManager getIServiceManager() {
        if (sServiceManager != null ) {
 return sServiceManager;
 } 
 
        // Find the service manager
        sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());
 return sServiceManager;
 } 
 
 /**
     * Returns a reference to a service with the given name .
 *
 * @param name the name   of the service to get
     * @ return a reference to the service, or <code> null </code> if the service doesn't exist
 */
 public   static IBinder getService(String name ) {
 try {
            IBinder service = sCache.get( name );
            if (service != null ) {
 return service;
 } else {
 return getIServiceManager().getService( name );
 }
        } catch (RemoteException e) {
            Log.e(TAG, "error in getService" , e);
 }
 return   null ;
 } 
 
 public   static void addService(String name , IBinder service) {
 ...
 }
 ....
 }

We can see that the first step of the getService method is to get the IBinder object of the Service according to the name of the Service in the sCache map. If it is empty, the IBinder object of the Service will be obtained through ServiceManagerNative through cross-process communication. So we use the sCache map as the entry point, reflect the object, and then modify the object. Since the system's android.os.ServiceManager class is @hide, only reflection can be used. Based on this preliminary idea, write the code for the first step:

 Class c_ServiceManager = Class.forName( "android.os.ServiceManager" );
 if (c_ServiceManager == null ) {
 return ;
 } 
 
 if (sCacheService == null ) {
 try {
        Field sCache = c_ServiceManager.getDeclaredField( "sCache" );
        sCache.setAccessible( true );
        sCacheService = (Map<String, IBinder>) sCache.get( null );
 } catch (Exception e) {
 e.printStackTrace();
 }
 }
 sCacheService.remove(serviceName);
 sCacheService.put(serviceName, service);

Reflect the sCache variable, remove the system Service, and then put our own modified Service into it. In this way, when the getService(String name) method of ServiceManager is called, the modified Service is returned instead of the system's native Service.

Step 2

The first step is to know how to put the modified Service into the system's ServiceManager. The second step is to generate a hook Service. How to generate it? This requires the use of the InvocationHandler class we introduced above. We first obtain the native Service, then use the InvocationHandler to construct a hook Service, and finally put it into the sCache variable through the first step. The second step code:

 public class ServiceHook implements InvocationHandler {
    private static final String TAG = "ServiceHook" ; 
 
 private IBinder mBase;
 private Class<?> mStub;
    private Class<?> mInterface;
    private InvocationHandler mInvocationHandler; 
 
 public ServiceHook(IBinder mBase, String iInterfaceName, boolean isStub, InvocationHandler InvocationHandler) {
 this.mBase = mBase;
        this.mInvocationHandler = InvocationHandler; 
 
 try {
            this.mInterface = Class.forName(iInterfaceName);
            this.mStub = Class.forName(String.format( "%s%s" , iInterfaceName, isStub ? "$Stub" : "" ));
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
 }
 } 
 
    @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        if ( "queryLocalInterface" .equals(method.getName())) {
 return Proxy.newProxyInstance(proxy.getClass().getClassLoader(), new Class[] { mInterface },
                    new HookHandler(mBase, mStub, mInvocationHandler));
 } 
 
        Log.e(TAG, "ERROR!!!!! method:name = " + method.getName());
 return method.invoke(mBase, args);
 } 
 
    private static class HookHandler implements InvocationHandler {
 private Object mBase;
        private InvocationHandler mInvocationHandler; 
 
 public HookHandler(IBinder base, Class<?> stubClass,
                           InvocationHandler InvocationHandler) {
            mInvocationHandler = InvocationHandler; 
 
 try {
                Method asInterface = stubClass.getDeclaredMethod( "asInterface" , IBinder.class);
                this.mBase = asInterface.invoke( null , base);
            } catch (Exception e) {
                e.printStackTrace();
 }
 } 
 
        @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
            if (mInvocationHandler != null ) {
 return mInvocationHandler.invoke(mBase, method, args);
 }
 return method.invoke(mBase, args);
 }
 }
 }

Here we take the calling code of ClipboardService as an example:

 IBinder clipboardService = ServiceManager.getService(Context.CLIPBOARD_SERVICE);
 String IClipboard = "android.content.IClipboard" ; 
 
 if (clipboardService != null ) {
    IBinder hookClipboardService =
            (IBinder) Proxy.newProxyInstance(clipboardService.getClass().getClassLoader(),
                            clipboardService.getClass().getInterfaces(),
                    new ServiceHook(clipboardService, IClipboard, true , new ClipboardHookHandler()));
 //Call the first step method
    ServiceManager.setService(Context.CLIPBOARD_SERVICE, hookClipboardService);
 } else {
    Log.e(TAG, "ClipboardService hook failed!" );
 }

Let's analyze the above code. Before analyzing it, we need to look at the relevant class diagram of ClipboardService:

From this class diagram, we can clearly see the inheritance relationship of ClipboardService. The next step is to analyze the code:

• In the calling code, the second parameter of the Proxy.newProxyInstance function needs attention. Since ClipboardService inherits from three interfaces, all interfaces need to be passed in here. However, if the second parameter is changed to new Class[] { IBinder.class }, there is actually no problem (those who are interested can try it. The first parameter is changed to IBinder.class.getClassLoader(), and the second parameter is changed to new Class[]{IBinder.class}, which is also OK). In actual use, we only use the queryLocalInterface method of the IBinder class, and other methods are not used. Next, we will explain the role of the queryLocalInterface function;
• The third parameter of the Proxy.newProxyInstance function is the ServiceHook object, so when this Service is set into the sCache variable, all operations calling ClipboardService will be called into the invoke method in ServiceHook;
• Next, let's take a look at the invoke function of ServiceHook. It is very simple. When the function is the queryLocalInterface method, it returns a HookHandler object. In other cases, it directly calls the method.invoke native system ClipboardService function. Why only process the queryLocalInterface method? I have mentioned this in my blog: Java/Android Design Pattern Learning Notes (9) - Proxy Mode when analyzing AMS. The asInterface method will eventually call the queryLocalInterface method. The final return result of the queryLocalInterface method will be returned to the caller of the Service as the result of asInterface. Therefore, the object returned by the queryLocalInterface method will be directly called externally. This also explains why there is no problem with changing the second parameter in the calling code to new Class[] { IBinder.class }, because after the first call to the queryLocalInterface function, all subsequent calls go to the HookHandler object. The dynamically generated object only needs the queryLocalInterface method of IBinder, and does not need IClipboard. Other methods of the interface;
• Next is the HookHandler class. First, let's look at the constructor of this class. The first parameter is the system's ClipboardService, and the second parameter is

 Class.forName(String.format( "%s%s" , iInterfaceName, isStub ? "$Stub" : "" ))// "android.content.IClipboard"  

Let's compare this parameter with the class diagram above. This class is the parent class of ClipboardService. It has an asInterface method. By reflecting the asInterface method, the IBinder object is converted into an IInterface object. To learn why this is done, you can read my blog: Java/Android Design Pattern Learning Notes (9) - Final Summary of the Proxy Pattern. An IBinder object is obtained through the ServiceManager.getService method, but this IBinder object cannot be called directly. It must be converted into the corresponding IInterface object through the asInterface method before it can be used. Therefore, the mBase object is actually an IInterface object:

Finally, this result is confirmed. I don’t need to explain why it is a Proxy object;

• Finally, there is the invoke method of HookHandler, which calls the ClipboardHookHandler object. Let's take a look at the implementation of this class:

 public class ClipboardHook { 
 
    private static final String TAG = ClipboardHook.class.getSimpleName(); 
 
 public   static void hookService(Context context) {
        IBinder clipboardService = ServiceManager.getService(Context.CLIPBOARD_SERVICE);
        String IClipboard = "android.content.IClipboard" ; 
 
        if (clipboardService != null ) {
            IBinder hookClipboardService =
                    (IBinder) Proxy.newProxyInstance(IBinder.class.getClassLoader(),
                            new Class[]{IBinder.class},
                            new ServiceHook(clipboardService, IClipboard, true , new ClipboardHookHandler()));
            ServiceManager.setService(Context.CLIPBOARD_SERVICE, hookClipboardService);
 } else {
            Log.e(TAG, "ClipboardService hook failed!" );
 }
 } 
 
 public   static class ClipboardHookHandler implements InvocationHandler { 
 
 @Override
 public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
            String methodName = method.getName();
 int argsLength = args.length;
 //Every time you copy text from this app, add the source of the sharing
            if ( "setPrimaryClip" .equals(methodName)) {
                if (argsLength >= 2 && args[0] instanceof ClipData) {
                    ClipData data = (ClipData) args[0];
                    String text = data.getItemAt(0).getText().toString();
                    text += "this is shared from ServiceHook-----by Shawn_Dut" ;
                    args[0] = ClipData.newPlainText(data.getDescription().getLabel(), text);
 }
 }
 return method.invoke(proxy, args);
 }
 }
 }

Therefore, the invoke method of the ClipboardHookHandler class finally obtains the IInterface object of the Service to be hooked (that is, the IClipboard.Proxy object, and finally calls the system's ClipboardService through the Binder Driver), the Method object and the parameter list object of the calling function. After obtaining these, needless to say, you can do some additional operations as much as you want. Here I am imitating Zhihu's copying of text and adding a similar copyright statement at the end.

Discussion Questions

The above are the detailed steps of ServiceHook. To understand it, you must have a detailed understanding of InvocationHandler and look at the AOSP source code. For example, if you want to hook ClipboardService, you must first look at the source code of ClipboardService to see the name and function of each function in this class, the order and function of each parameter in the parameter list, and sometimes this is far from enough. We know that with the update of each version of Android, these classes may also be updated, modified or even deleted. It is very likely that the old hook method will no longer work for the new version. At this time, you must understand the latest source code, see the updated and modified places, and redefine the hook steps for the new version. This is a point that needs to be treated with caution.

step

Source code

This is the code of a great god in our company. It has been sorted and modified. I don't know if there are any copyright issues. Hahaha, thank you Zhou Jie, although he is no longer in the company, thank you very much~~

Source code download address: https://github.com/zhaozepeng/ServiceHook

Let's take a look at the effect of running:

Please indicate the source for reprinting: http://blog.csdn.net/self_study/article/details/55050627