AndroidHook機制——插件化之AMS&PMS

在前面的文章中我們介紹了DroidPlugin的Hook機制,也就是代理方式Binder Hook;插件框架通過AOP實現了插件使用和開發的透明性。在講述DroidPlugin如何實現四大組件的插件化之前,有必要說明一下它對ActivityManagerServiche以及PackageManagerService的Hook方式(以下簡稱AMS,PMS)。

ActivityManagerService對於FrameWork層的重要性不言而喻,Android的四大組件無一不與它打交道:

  1. startActivity最終調用了AMS的startActivity系列方法,實現了Activity的啓動;Activity的生命週期回調,也在AMS中完成;
  2. startService,bindService最終調用到AMS的startService和bindService方法;
  3. 動態廣播的註冊和接收在AMS中完成(靜態廣播在PMS中完成)
  4. getContentResolver最終從AMSgetContentProvider獲取到ContentProvider

PMS則完成了諸如權限校撿(checkPermission,checkUidPermission),Apk meta信息獲取(getApplicationInfo等),四大組件信息獲取(query系列方法)等重要功能。

在上文Android插件化原理解析——Hook機制之Binder Hook中講述了DroidPlugin的Binder Hook機制;我們知道AMSPMS就是以Binder方式提供給應用程序使用的系統服務,理論上我們也可以採用這種方式Hook掉它們。但是由於這兩者使用得如此頻繁,Framework給他們了一些“特別優待”,這也給了我們相對於Binder Hook更加穩定可靠的hook方式。

閱讀本文之前,可以先clone一份 understand-plugin-framework,參考此項目的ams-pms-hook模塊。另外,插件框架原理解析系列文章見索引

AMS獲取過程

前文提到Android的四大組件無一不與AMS相關,也許讀者還有些許疑惑;這裏我就挑一個例子,依據Android源碼來說明,一個簡單的startActivity是如何調用AMS最終通過IPC到system_server的。

不論讀者是否知道,我們使用startActivity有兩種形式:

  1. 直接調用Context類的startActivity方法;這種方式啓動的Activity沒有Activity棧,因此不能以standard方式啓動,必須加上FLAG_ACTIVITY_NEW_TASK這個Flag。
  2. 調用被Activity類重載過的startActivity方法,通常在我們的Activity中直接調用這個方法就是這種形式;

Context.startActivity

我們查看Context類的startActivity方法,發現這竟然是一個抽象類;查看Context的類繼承關係圖如下:

我們看到諸如ActivityService等並沒有直接繼承Context,而是繼承了ContextWrapper;繼續查看ContextWrapper的實現:

1
2
3
4
@Override
public void startActivity(Intent intent) {
    mBase.startActivity(intent);
}

WTF!! 果然人如其名,只是一個wrapper而已;這個mBase是什麼呢?這裏我先直接告訴你,它的真正實現是ContextImpl類;至於爲什麼,有一條思路:mBase是在ContextWrapper構造的時候傳遞進來的,那麼在ContextWrapper構造的時候可以找到答案
什麼時候會構造ContextWrapper呢?它的子類ApplicationService等被創建的時候。

可以在App的主線程AcitivityThreadperformLaunchActivit方法裏面找到答案;更詳細的解析可以參考老羅的 Android應用程序啓動過程源代碼分析

好了,我們姑且當作已經知道Context.startActivity最終使用了ContextImpl裏面的方法,代碼如下:

1
2
3
4
5
6
7
8
9
10
11
12
public void startActivity(Intent intent, Bundle options) {
    warnIfCallingFromSystemProcess();
    if ((intent.getFlags()&Intent.FLAG_ACTIVITY_NEW_TASK) == 0) {
        throw new AndroidRuntimeException(
                "Calling startActivity() from outside of an Activity "
                + " context requires the FLAG_ACTIVITY_NEW_TASK flag."
                + " Is this really what you want?");
    }
    mMainThread.getInstrumentation().execStartActivity(
        getOuterContext(), mMainThread.getApplicationThread(), null,
        (Activity)null, intent, -1, options);
}

代碼相當簡單;我們知道了兩件事:

  1. 其一,我們知道了在Service等非Activity的Context裏面啓動Activity爲什麼需要添加FLAG_ACTIVITY_NEW_TASK
  2. 其二,真正的startActivity使用了Instrumentation類的execStartActivity方法;繼續跟蹤:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public ActivityResult execStartActivity(
        Context who, IBinder contextThread, IBinder token, Activity target,
        Intent intent, int requestCode, Bundle options) {
	// ... 省略無關代碼
    try {
        intent.migrateExtraStreamToClipData();
        intent.prepareToLeaveProcess();
        // ----------------look here!!!!!!!!!!!!!!!!!!!
        int result = ActivityManagerNative.getDefault()
            .startActivity(whoThread, who.getBasePackageName(), intent,
                    intent.resolveTypeIfNeeded(who.getContentResolver()),
                    token, target != null ? target.mEmbeddedID : null,
                    requestCode, 0, null, null, options);
        checkStartActivityResult(result, intent);
    } catch (RemoteException e) {
    }
    return null;
}

到這裏我們發現真正調用的是ActivityManagerNativestartActivity方法;如果你不清楚ActivityManagerActivityManagerService以及ActivityManagerNative之間的關係;建議先仔細閱讀我之前關於Binder的文章 Binder學習指南

Activity.startActivity

Activity類的startActivity方法相比Context而言直觀了很多;這個startActivity通過若干次調用輾轉到達startActivityForResult這個方法,在這個方法內部有如下代碼:

1
2
3
4
Instrumentation.ActivityResult ar =
    mInstrumentation.execStartActivity(
        this, mMainThread.getApplicationThread(), mToken, this,
        intent, requestCode, options);

可以看到,其實通過Activity和ContextImpl類啓動Activity並無本質不同,他們都通過Instrumentation這個輔助類調用到了ActivityManagerNative的方法。

Hook AMS

OK,我們到現在知道;其實startActivity最終通過ActivityManagerNative這個方法遠程調用了AMSstartActivity方法。那麼這個ActivityManagerNative是什麼呢?

ActivityManagerNative實際上就是ActivityManagerService這個遠程對象的Binder代理對象;每次需要與AMS打交道的時候,需要藉助這個代理對象通過驅動進而完成IPC調用。

我們繼續看ActivityManagerNativegetDefault()方法做了什麼:

1
2
3
static public IActivityManager getDefault() {
    return gDefault.get();
}

gDefault這個靜態變量的定義如下:

1
2
3
4
5
6
7
private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
    protected IActivityManager create() {
        IBinder b = ServiceManager.getService("activity
        IActivityManager am = asInterface(
        return am;
    }
};

由於整個Framework與AMS打交道是如此頻繁,framework使用了一個單例把這個AMS的代理對象保存了起來;這樣只要需要與AMS進行IPC調用,獲取這個單例即可。這是AMS這個系統服務與其他普通服務的不同之處,也是我們不通過Binder Hook的原因——我們只需要簡單地Hook掉這個單例即可。

這裏還有一點小麻煩:Android不同版本之間對於如何保存這個單例的代理對象是不同的;Android 2.x系統直接使用了一個簡單的靜態變量存儲,Android 4.x以上抽象出了一個Singleton類;具體的差異可以使用grepcode進行比較:差異

我們以4.x以上的代碼爲例說明如何Hook掉AMS;方法使用的動態代理,如果有不理解的,可以參考之前的系列文章Android插件化原理解析——Hook機制之動態代理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Class<?> activityManagerNativeClass = Class.forName("android.app.ActivityManagerNative");

// 獲取 gDefault 這個字段, 想辦法替換它
Field gDefaultField = activityManagerNativeClass.getDeclaredField("gDefault");
gDefaultField.setAccessible(true);
Object gDefault = gDefaultField.get(null);

// 4.x以上的gDefault是一個 android.util.Singleton對象; 我們取出這個單例裏面的字段
Class<?> singleton = Class.forName("android.util.Singleton");
Field mInstanceField = singleton.getDeclaredField("mInstance");
mInstanceField.setAccessible(true);

// ActivityManagerNative 的gDefault對象裏面原始的 IActivityManager對象
Object rawIActivityManager = mInstanceField.get(gDefault);

// 創建一個這個對象的代理對象, 然後替換這個字段, 讓我們的代理對象幫忙幹活
Class<?> iActivityManagerInterface = Class.forName("android.app.IActivityManager");
Object proxy = Proxy.newProxyInstance(Thread.currentThread().getContextClassLoader(),
        new Class<?>[] { iActivityManagerInterface }, new IActivityManagerHandler(rawIActivityManager));
mInstanceField.set(gDefault, proxy);

好了,我們hook成功之後啓動Activity看看會發生什麼:

1
2
3
4
5
6
7
8
D/HookHelper﹕ hey, baby; you are hook!!
D/HookHelper﹕ method:activityResumed called with args:[android.os.BinderProxy@9bc71b2]
D/HookHelper﹕ hey, baby; you are hook!!
D/HookHelper﹕ method:activityIdle called with args:[android.os.BinderProxy@9bc71b2, null, false]
D/HookHelper﹕ hey, baby; you are hook!!
D/HookHelper﹕ method:startActivity called with args:[android.app.ActivityThread$ApplicationThread@17e750c, com.weishu.upf.ams_pms_hook.app, Intent { act=android.intent.action.VIEW dat=http://wwww.baidu.com/... }, null, android.os.BinderProxy@9bc71b2, null, -1, 0, null, null]
D/HookHelper﹕ hey, baby; you are hook!!
D/HookHelper﹕ method:activityPaused called with args:[android.os.BinderProxy@9bc71b2]

可以看到,簡單的幾行代碼,AMS已經被我們完全劫持了!! 至於劫持了能幹什麼,自己發揮想象吧~

DroidPlugin關於AMS的Hook,可以查看IActivityManagerHook這個類,它處理了我上述所說的兼容性問題,其他原理相同。另外,也許有童鞋有疑問了,你用startActivity爲例怎麼能確保Hook掉這個靜態變量之後就能保證所有使用AMS的入口都被Hook了呢?

答曰:無他,唯手熟爾。

Android Framewrok層對於四大組件的處理,調用AMS服務的時候,全部都是通過使用這種方式;若有疑問可以自行查看源碼。你可以從Context類的startActivity, startService,bindService, registerBroadcastReceiver, getContentResolver 等等入口進行跟蹤,最終都會發現它們都會使用ActivityManagerNative的這個AMS代理對象來完成對遠程AMS的訪問。

PMS獲取過程

PMS的獲取也是通過Context完成的,具體就是getPackageManager這個方法;我們姑且當作已經知道了Context的實現在ContextImpl類裏面,直奔ContextImpl類的getPackageManager方法:

1
2
3
4
5
6
7
8
9
10
11
12
public PackageManager getPackageManager() {
    if (mPackageManager != null) {
        return mPackageManager;
    }

    IPackageManager pm = ActivityThread.getPackageManager();
    if (pm != null) {
        // Doesn't matter if we make more than one instance.
        return (mPackageManager = new ApplicationPackageManager(this, pm));
    }
    return null;
}

可以看到,這裏幹了兩件事:

  1. 真正的PMS的代理對象在ActivityThread類裏面
  2. ContextImpl通過ApplicationPackageManager對它還進行了一層包裝

我們繼續查看ActivityThread類的getPackageManager方法,源碼如下:

1
2
3
4
5
6
7
8
public static IPackageManager getPackageManager() {
    if (sPackageManager != null) {
        return sPackageManager;
    }
    IBinder b = ServiceManager.getService("package");
    sPackageManager = IPackageManager.Stub.asInterface(b);
    return sPackageManager;
}

可以看到,和AMS一樣,PMS的Binder代理對象也是一個全局變量存放在一個靜態字段中;我們可以如法炮製,Hook掉PMS。

現在我們的目的很明切,如果需要Hook PMS有兩個地方需要Hook掉:

  1. ActivityThread的靜態字段sPackageManager
  2. 通過Context類的getPackageManager方法獲取到的ApplicationPackageManager對象裏面的mPM字段。

Hook PMS

現在使用代理Hook應該是輕車熟路了吧,通過上面的分析,我們Hook兩個地方;代碼信手拈來:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// 獲取全局的ActivityThread對象
Class<?> activityThreadClass = Class.forName("android.app.ActivityThread");
Method currentActivityThreadMethod = activityThreadClass.getDeclaredMethod("currentActivityThread");
Object currentActivityThread = currentActivityThreadMethod.invoke(null);

// 獲取ActivityThread裏面原始的 sPackageManager
Field sPackageManagerField = activityThreadClass.getDeclaredField("sPackageManager");
sPackageManagerField.setAccessible(true);
Object sPackageManager = sPackageManagerField.get(currentActivityThread);

// 準備好代理對象, 用來替換原始的對象
Class<?> iPackageManagerInterface = Class.forName("android.content.pm.IPackageManager");
Object proxy = Proxy.newProxyInstance(iPackageManagerInterface.getClassLoader(),
        new Class<?>[] { iPackageManagerInterface },
        new HookHandler(sPackageManager));

// 1. 替換掉ActivityThread裏面的 sPackageManager 字段
sPackageManagerField.set(currentActivityThread, proxy);

// 2. 替換 ApplicationPackageManager裏面的 mPM對象
PackageManager pm = context.getPackageManager();
Field mPmField = pm.getClass().getDeclaredField("mPM");
mPmField.setAccessible(true);
mPmField.set(pm, proxy);

好了,Hook完畢我們驗證以下結論;調用一下PMSgetInstalledApplications方法,打印日誌如下:

1
2
03-07 15:07:27.187    8306-8306/com.weishu.upf.ams_pms_hook.app D/IActivityManagerHandler﹕ hey, baby; you are hook!!
03-07 15:07:27.187    8306-8306/com.weishu.upf.ams_pms_hook.app D/IActivityManagerHandler﹕ method:getInstalledApplications called with args:[0, 0]

OK,我們又成功劫持了PackageManager!!DroidPlugin 處理PMS的代碼可以在IPackageManagerHook查看。

在結束講解PackageManager的Hook之前,我們需要說明一點;那就是Context的實現類裏面沒有使用靜態全局變量來保存PMS的代理對象,而是每擁有一個Context的實例就持有了一個PMS代理對象的引用;所以這裏有個很蛋疼的事情,那就是我們如果想要完全Hook住PMS,需要精確控制整個進程內部創建的Context對象;所幸,插件框架中,插件的Activity,Service,ContentProvider,Broadcast等所有使用到Context的地方,都是由框架控制創建的;因此我們要小心翼翼地替換掉所有這些對象持有的PMS代理對象。

我前面也提到過,靜態變量和單例都是良好的Hook點,這裏很好地反證了這句話:想要Hook掉一個實例變量該是多麼麻煩!

小結

寫到這裏,關於DroidPlugin的Hook技術的講解已經完結了;我相信讀者或多或少地認識到,其實Hook並不是一項神祕的技術;一個乾淨,透明的框架少不了AOP,而AOP也少不了Hook。

我所講解的Hook僅僅使用反射和動態代理技術,更加強大的Hook機制可以進行字節碼編織,比如J2EE廣泛使用了cglib和asm進行AOP編程;而Android上現有的插件框架還是加載編譯時代碼,採用動態生成類的技術理論上也是可行的;之前有一篇文章Android動態加載黑科技 動態創建Activity模式,就講述了這種方式;現在全球的互聯網公司不排除有用這種技術實現插件框架的可能 ;我相信不遠的未來,這種技術也會在Android上大放異彩。

瞭解完Hook技術之後,接下來的系列文章會講述DroidPlugin對Android四大組件在插件系統上的處理,插件框架對於這一部分的實現是DroidPlugin的精髓,Hook只不過是工具而已。學習這部分內容需要對於Activity,Service,Broadcast以及ContentProvider的工作機制有一定的瞭解,因此我也會在必要的時候穿插講解一些Android Framework的知識;我相信這一定會對讀者大有裨益。

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章