插件框架原理解析——Hook機制之Binder Hook

public class BinderProxyHookHandler implements InvocationHandler {

    private static final String TAG = "BinderProxyHookHandler";

    // 絕大部分情況下,這是一個BinderProxy對象
    // 只有當Service和我們在同一個進程的時候才是Binder本地對象
    // 這個基本不可能
    IBinder base;

    Class<?> stub;

    Class<?> iinterface;

    public BinderProxyHookHandler(IBinder base) {
        this.base = base;
        try {
            this.stub = Class.forName("android.content.IClipboard$Stub");
            this.iinterface = Class.forName("android.content.IClipboard");
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

        if ("queryLocalInterface".equals(method.getName())) {

            Log.d(TAG, "hook queryLocalInterface");

            // 這里直接返回真正被Hook掉的Service接口
            // 這里的 queryLocalInterface 就不是原本的意思了
            // 我們肯定不會真的返回一個本地接口, 因為我們接管了 asInterface方法的作用
            // 因此必須是一個完整的 asInterface 過的 IInterface對象, 既要處理本地對象,也要處理代理對象
            // 這只是一個Hook點而已, 它原始的含義已經被我們重定義了; 因為我們會永遠確保這個方法不返回null
            // 讓 IClipboard.Stub.asInterface 永遠走到if語句的else分支里面
            return Proxy.newProxyInstance(proxy.getClass().getClassLoader(),

                    // asInterface 的時候會檢測是否是特定類型的接口然后進行強制轉換
                    // 因此這里的動態代理生成的類型信息的類型必須是正確的
                    new Class[] { IBinder.class, IInterface.class, this.iinterface },
                    new BinderHookHandler(base, stub));
        }

        Log.d(TAG, "method:" + method.getName());
        return method.invoke(base, args);
    }
}

final String CLIPBOARD_SERVICE = "clipboard";

// 下面這一段的意思實際就是: ServiceManager.getService("clipboard");
// 只不過 ServiceManager這個類是@hide的
Class<?> serviceManager = Class.forName("android.os.ServiceManager");
Method getService = serviceManager.getDeclaredMethod("getService", String.class);
// ServiceManager里面管理的原始的Clipboard Binder對象
// 一般來說這是一個Binder代理對象
IBinder rawBinder = (IBinder) getService.invoke(null, CLIPBOARD_SERVICE);

// Hook 掉這個Binder代理對象的 queryLocalInterface 方法
// 然后在 queryLocalInterface 返回一個IInterface對象, hook掉我們感興趣的方法即可.
IBinder hookedBinder = (IBinder) Proxy.newProxyInstance(serviceManager.getClassLoader(),
        new Class<?>[] { IBinder.class },
        new BinderProxyHookHandler(rawBinder));

// 把這個hook過的Binder代理對象放進ServiceManager的cache里面
// 以后查詢的時候 會優先查詢緩存里面的Binder, 這樣就會使用被我們修改過的Binder了
Field cacheField = serviceManager.getDeclaredField("sCache");
cacheField.setAccessible(true);
Map<String, IBinder> cache = (Map) cacheField.get(null);
cache.put(CLIPBOARD_SERVICE, hookedBinder);

</div>

接下來，在app里面使用剪切版，比如長按進行粘貼之后，剪切版的內容永遠都是 you are hooked 了；這樣，我們Hook系統服務的目的宣告完成！詳細的代碼參見 github 。

也許你會問，插件框架會這么hook嗎？如果不是那么插件框架hook這些干什么？插件框架當然不會做替換文本這么無聊的事情，DroidPlugin插件框架管理插件使得插件就像是主程序一樣，因此插件需要使用主程序的剪切版，插件之間也會共用剪切版；其他的一些系統服務也類似，這樣就可以達到插件和宿主程序之間的天衣服縫，水乳交融！另外， ActivityManager 以及 PackageManager 這兩個系統服務雖然也可以通過這種方式hook，但是由于它們的重要性和特殊性，DroidPlugin使用了另外一種方式，我們會單獨講解。

喜歡就點個贊吧～持續更新，請關注github項目 understand-plugin-framework 和我的博客!