插件開發之360 DroidPlugin源碼分析（四）Activity預注冊占坑

在了解系統的activity，service，broadcastReceiver的啟動過程後，今天將分析下360 DroidPlugin是如何預注冊占坑的？本篇文章主要分析Activity預注冊占坑，Activity占了坑後又是什麼時候開始瞞天過海欺騙AMS的？先看下Agenda：

AndroidMainfest.xml中概覽 Activity中關鍵方法被hook時機 startActivity被hook handelPerformActivity被hook Activity預注冊占坑整體流程圖 瞞天過海，冒充真實身份，欺騙AMS

AndroidMainfest.xml中概覽

我們知道所有能用的四大組件都要在Manifest中注冊聲明，第一步，先看AndroidManifest.xml，雖然在說hook機制時，也有提及過，但是畢竟沒細致分析，話不多說，看代碼上圖：

然後看下各個屬性的意思

表示一個activity1原來屬於task1，但是如果task2啟動起來的話，activity1可能不再屬於task1了，轉而投奔task2去了。

功能：啟動硬件加速
缺點：占用內存
特點：可以在Application、Activity、Window、View四個級別進行硬件加速控制<喎?/kf/ware/vc/" target="_blank" class="keylink">vcD4NCjxwPrTTQW5kcm9pZDMuMKOoQVBJIExldmVsIDExo6m/qsq8o6xBbmRyb2lkIDJE5NbIvrnctcDE3Lm7uPy6w7XE1qez1tOyvP6808vZoaPTsrz+vNPL2da00NC1xMv509C1xLvmzbyy2df3trzKx8q508NHUFXU2lZpZXe21M/ztcS7rbK8yc/AtL340NC1xKGj0vLOqsb008PTsrz+vNPL2bvh1Pa809fK1LS1xNDox/OjrNLytMvV4tH5tcTTptPDu+HVvNPDuPy24LXExNq05qGjPC9wPg0KPHA+xvTTw9OyvP6808vZtcTX7sjd0te1xLe9t6jKx7j41fu49tOm08OzzNDytry08r+qyKu+1tOyvP6808vZuabE3KGjyOe5+9Om08OzzNDy1rvKudPDserXvLXEVmlld7rNRHJhd2FibGWjrMTHw7S08r+qyKu+1tOyvP6808vZsru74bW81sLIzrrOtcSyu8G8tcS75tbG0Ke5+6GjtavKx6Os0vLOqtOyvP6808vZsqKyu9ans9bL+dPQtcQyRM280M675tbGstnX96Osy/nS1LbU09rEx9CpyrnTw7ao1sa1xFZpZXe6zbvm1sa199PDtcTTptPDs8zQ8sC0y7WjrLTyv6rIq77W07K8/rzTy9mjrL/J0tS74dOwz+y75tbG0Ke5+6GjzsrM4s2os6O74bP2z9bU2rbUxMfQqbK7v8m8+7XE1KrL2L340NDBy9Lss6O78rTtzvO1xM/xy9jk1si+oaPOqsHLsdzD4tXi1tbOyszio6xBbmRyb2lkzOG5qdLUz8K8trHwo6zS1LHjv8nRodTx0NS1xMb008O78r371rnTsrz+vNPL2aO6PC9wPg0KPHA+v9jWxtOyvP6808vZo6zE3Lm708PS1M/CvLax8MC0v9jWxtOyvP6808vZo7o8L3A+DQo8cD4xoaJBcHBsaWNhdGlvbry2sfA8L3A+DQo8cD7U2tOm08O1xEFuZHJvaWTH5bWlzsS8/tbQo6yw0c/CwdDK9NDUzO2807W91KrL2NbQo6zAtL+qxvTV+7j206bTw7PM0PK1xNOyvP6808vZoaM8L3A+DQo8cD4yoaJBY3Rpdml0eby2sfA8L3A+DQo8cD7I57n706bTw7PM0PKyu8TcubvV/ci3tcTKudPDsbu08r+qtcTIq77W07K8/rzTy9mjrMTHw7TSsr/J0tS21EFjdGl2aXR5t9ax8L340NC/2NbGoaPU2tSqy9jW0Mq508NhbmRyb2lkOmhhcmR3YXJlQWNjZWxlcmF0ZWTK9NDUo6zE3Lm7xvTTw7vyvfvWuUFjdGl2aXR5vLax8LXE07K8/rzTy9mho9LUz8LKvsD9xvTTw8irvta1xNOyvP6808vZo6y1q8i0vfvWucHL0ru49kFjdGl2aXR5tcTTsrz+vNPL2aGjPC9wPg0KPHA+M6GiV2luZG93vLax8DwvcD4NCjxwPsjnufvQ6NKquPzPuMGjtsi1xL/Y1sajrL7Nv8nS1Mq508PPwsHQtPrC68C01eu21Lj4tqi1xLSwv9rAtMb008PTsrz+vNPL2aO6PC9wPg0KPHA+16LS4qO6tbHHsLK7xNzU2ldpbmRvd7y2sfC9+9a507K8/rzTy9mhozwvcD4NCjxwPjxpbWcgYWx0PQ=="這裡寫圖片描述" src="/uploadfile/Collfiles/20160820/20160820092205592.png" title="\" />

4、View級別

能夠使用下列代碼在運行時針對一個獨立的View對象來禁止硬件加速：

注意：當前不能在View級別開啟硬件加速。View層除了禁止硬件加速以外，還有其他的功能，更多的相關信息請看本文的“View層”。

以上就是聲明屬性的含義說明，作為背景了解即可。重點看下面的分析

Manifest中注冊了8個進程，加上主進程共9個
然後第每個進程下面又有26個Activity注冊，一個service，一個contentprovider,那麼問題來了，搞這麼多注冊在manifest做什麼用？仔細分類：就兩類一類是Activity，一類是Dialog，我們知道Dialog是建立在Activity之上的，如果Activity被finish或destory後，就會報出異常：android.view.WindowManager$BadTokenException: Unable to add window — token android.os.BinderProxy@438e7108 is not valid; is your activity running?

附《插件占坑，四大組件動態注冊前奏（一） 系統Activity的啟動流程》（也可點擊鏈接過去看詳細過程）的activity的啟動時序列圖：

Activity中關鍵方法被hook時機

其中startActivity()和handleLanchActivity()是被DroidPlugin 要欺騙系統的兩個主要方法：

第一個方法是最被經常使用的startActivity()，hook機制見《插件開發之360 DroidPlugin源碼分析（二）Hook機制》中分析，主要是通過Java的反射機制替換掉IActivityManager全局對象，具體IActivityManagerHookHandle的onInstall()方法如下：

第二個方法是handleLaunchActivity()，這個方法屬於ActivityThread的一個叫做H的內部類，前面講Activity啟動時，已埋下伏筆，可以參考《插件占坑，四大組件動態注冊前奏（一） 系統Activity的啟動流程》，如果學過中間人攻擊協議的話，我們知道，現個通信雙方發出消息後，進行消息驗證，如果中間人攔截相關協議內容，通過一個代理進行轉發出去，從而達到欺騙的目的，這裡暫且理解handleLanchActivity被中間人攻擊了，當啟動handleLanchActivity時，被DroidPlugin hook後，那多人可能會想，你怎麼hook住hanleLanchActivity呢？別忘了，我們可是在Manifest占了一堆坑的。要是不好理解，可以參看《插件前奏-android黑科技 hook介紹 ：http://blog.csdn.net/hejjunlin/article/details/52091833》，可能更直觀些，哪在DroidPlugin中，如何在代碼中瞞天過海的呢？
我們可以看下：PluginCallbackHook.java，其中有一個onInstall()方法：

如上代碼也有注釋，可總結為：
1.DroidPlugin不是完全攻擊mH這個內部類，而是把mH的mCallback成員變量攻擊了，然後替換成了一個PluginCallback對象，進行消息分發，那麼就可以在在PluginCallback的handleMessage()裡任意攔截想要分發的消息，來欺騙AMS。經過中間人這麼一鬧騰，那就能達到控制這個區域的目的了。

最狠的看下面：
上面代碼中，有一個mH的mCallback,是被攔截攻擊了吧，既然被攔截後又要冒充一個擔當mH的mCallback職責相關，（這裡暫且誇張的說）那肯定得扒了它身上的某些特性放到冒充的mCallback吧，如身份驗證相關之類，所以那原來的mCallback丟了它的身份相關，不就是廢了，暫且理解為mCallback為null,實際上有mCallback在未賦值之前，初始化時，本身也是null。然後看下PluginCallback的handleMessage()方法：（ps: PluginCallback簡直就是仿照ActivityThread中的H內部類寫的，幾乎邏輯一樣，具體可看系統源碼證實）

這裡只攔截了一個消息類型為LAUNCH_ACTIVITY（ActivityThread中的H內部類中會有很多消息類型，也包含LAUNCH_ACTIVITY）。mCallback不為null，就是發一些偽裝的消息（因為我們剛攔截了mCallback），如果為null,返回false，這樣就會會再通過mH調用回真正ActivityThread的handleLaunchActivity()。（ps:系統發的消息沒什麼卵用時，我們就不去攔截，暫且理解為這樣）

以上就是兩個方法怎麼被hook相關分析，也可參考在Hook機制舉例為IPackageManager的驗證簽名被hook的過程，接下來就是要看hook中做了什麼事？附一張Activity預注冊占坑整體流程圖：

前面我們都是在說DroidPlugin怎麼用中間人攻擊方式，攔截了startActivity()方法和hanleLanchActivity()方法，接下來要看下攔截了後，怎麼把這種身份角色搞變化了（就是一個怎麼扮演冒充的角色過程）：
1.首先得找一個和真實的人像的角色，這時啟用的我們備用人員，也就是事先占的坑stub.ActivityStubxxx。
2.真實的角色身上有某些特定的特性，如愛抽煙，頭發亂糟糟的，像Activity中Intent作為一個extra傳到另一個Activity時，還有一些自己的lanchmode(啟動方式)，theme(主題)，這些都是Activity的一些特性，所以stub.ActivityStubxxx也得有這些，否則怎麼能達到冒充呢，這些我們在代碼中早就寫好了，所有的那些注冊的26個備用人員都是繼承ActivityStub，而ActivityStub是直接繼承Activity，那還說啥呢，不就是天然的冒充麼？說這麼多了，直接看代碼IActivityManagerHookHandle$startActvity：
這是一個靜態內部類，繼承ReplaceCallingPackageHookedMethodHandler，重寫了beforeInvoke方法，暫且理解為在冒充之前的一些准備工作，如下：

接著再看beforeStartActivity方法：

就是判斷了下Activity的啟動模式，接著都調入doFinshIt(mRunningXXXActivityList),繼續看此方法：

STUB_NO_ACTIVITY_MAX_NUM為4，上面方法總結為：runningActivityList（備用activity的list的總數）大於等於3時，就把最早進入activityRecord棧中的那個finish掉，因為坑就那麼多，要是都占著不干活，那要它干嘛？

瞞天過海，冒充真實身份，欺騙AMS

前面這些，還是小打小鬧，接下來看一個核心方法，就是beforeInvoke中的doReplaceIntentForStartActivityAPILow方法：

前面我們說了，欺騙了兩個方法，上面說的都是startActivity（），接下來看另個一個方法handleLanchActivity(), 這個方法在哪呢？我們前面說過有一個仿照ActivityThread中H內部類的class叫PluginCallBack,對，handleLaunchActivity就是在接到handleMessage中消息類型為LANCH_ACTIVITY時調用的：

以上就是Activity預注冊占坑，並欺騙AMS的過程，下篇分析Service預注冊占坑。