技術概念來源：[ 360開源插件框架，項目地址：https://github.com/DroidPluginTeam/DroidPlugin]

一、Binder機制回顧

在之前一篇文章中介紹了Android中的Binder機制和系統遠程服務調用機制，本文將繼續借助上一篇的內容來實現Hook系統服務攔截指定方法的邏輯，了解了上一篇文章之後，知道系統的服務其實都是一個遠程Binder對象，而這個對象都是由ServiceManager大管家管理的，用戶在使用系統服務的時候，會通過指定服務的Stub方法的asInterface把遠程的Binder對象轉化成本地化對象即可使用，而在這個過程中，我們也知道因為系統服務是在system_server進程中的，所以這個系統服務使用過程中屬於跨進程調用，那麼返回的對象其實就是Proxy代理對象。

 

二、系統中服務使用流程

本文主要就是借助這個知識點，通過Hook系統的服務來攔截服務方法，下面我們就通過系統剪切板服務案例作為分析

這裡看到了，使用系統服務的時候都是用了getSystemService方法，通過定義在Context中的服務描述符常量來獲取服務對象，而getSystemService方法定義在ComtextImpl.java類中：

這裡維護了一個ServiceFetcher的Map結構，看看這個結構在哪裡填充數據的：

在registerService方法中添加一個服務名稱和一個ServiceFetcher對象，而這個方法在靜態代碼塊中進行調用的：

我們找到了ClipboardManager這個服務：

這裡其實是一個ClipboardManager對象，其實這個對象是內部封裝了IClipboard.Stub功能，可以看看其他的服務：

比如這裡的聯網服務，直接調用了IConnectivityManager.Stub類的asInterface方法獲取Proxy對象。

 

下面就進去ClipboardManager.java中看看究竟：

看到這裡的設置剪切板內容的方法，其實內部是調用了getService方法獲取對象然後在調用指定方法，那麼可以大概知道了這個getService方法返回的應該就是IClipboard.Stub通過asInterface方法返回的Proxy對象：

好吧，果然是這樣，這裡通過ServiceManager獲取到Clipboard的遠端IBinder對象，然後通過asInterface方法返回一個Proxy對象即可。

 

到這裡我們就簡單的分析完了系統中的獲取剪切板的服務，其實系統中的服務都是這麼個邏輯，只是有的可能會在外面包裝一層罷了，下面總結一下流程：

現在只要記住一點：每次獲取系統服務的流程都是一樣的，先通過ServiceManager的getService方法獲取遠端服務的IBinder對象，然後在通過指定服務的Stub類的asInterface方法轉化成本地可使用對象，而這個對象其實就是一個Proxy對象，在這個過程中，Stub類繼承了Binder對象和實現了AIDL接口類型，Proxy對象實現了AIDL接口類型，而AIDL接口類型實現了IInterface接口類型。

 

三、Hook系統服務

上面分析完了Android中系統服務的使用流程以及原理解析，下面在來看一下Android中實現Hook機制的方法和原理解析，我們知道其實在很多系統中都存在這樣一個Hook技術，有的也叫作鉤子，但是不管任何系統，Hook技術的核心點都是一樣的，只有兩點即可完成Hook技術：

1、找到Hook點，即你想Hook哪個對象，那麼得先找到這個對象定義的地方，然後使用反射獲取到這個對象實例。所以這裡可以看到，一般Hook點都是一個類的單例方法或者是靜態變量，因為這樣的話Hook起來就非常方便，都是static類型，反射調用都比較方便無需具體的實例對象即可。而關於這個點也是整個Hook過程中最難的點，因為很難找到這個點。Android中主要是依靠分析系統源碼類來做到的。

2、構造一個Hook原始對象的代理類，關於這個代理其實在Java中有兩種方式，一種是靜態代理，一種是動態代理。

靜態代理：代理類中維護一個原始對象的成員變量，每個方法調用之前調用原始對象的方法即可。無需任何條件限制

動態代理：比靜態代理復雜點就是有一個規則：就是原始對象必須要實現接口才可以操作，原理是因為動態代理其實是自動生成一個代理類的字節碼，類名一般都是Proxy$0啥的，這個類會自動實現原始類實現的接口方法，然後在使用反射機制調用接口中的所有方法。

案例使用就很簡單了，下面我們通過源碼分析這個原理：

主要調用了getProxyClass0方法生成代理類的字節碼：

然後生成代理類：

看到這裡，其實這裡的生成字節碼不是很復雜的，我們可以借助asm等工具包就可以手動的生成一個字節碼，然後在使用類加載器加載即可，所以會發現需要傳遞類加載器。

當上面生成代理類之後，我們可以把這個類反編譯看一下，看一下方法的調用，在代理類中的靜態代碼塊：

會使用反射獲取到類的所有方法。

然後在指定方法中調用傳遞進來的InvocationHandler的回調接口的invoke方法，就是這麼實現的。

 

從源碼角度分析完動態代理之後，發現其實沒什麼復雜的，就是手動的生成一個代理類，然後用反射獲取類中所有的方法，在指定方法中用反射調用，同時回調InvocationHandler的invoke方法即可，所以這裡看到InvocationHandler中的invoke方法的第一個參數對象是代理類對象。

 

注意：

在JavaWeb開發中我們會用到Spring框架中的AOP編程，其實他就是利用了Java中動態代理技術，但是他依賴的是CGlib的功能，不是采用Java原生的這種自動產生代理類，從上面可以看到能夠做動態代理的類必須要實現一個接口，而這一個規則有時候要求非常高，很多類都沒有實現接口，導致無法實現代理功能，所以Spring采用了cglib，原理其實差不多，他采用asm工具包也是手動生成一個類，但是這個類是原始對象的子類，這樣也可以實現代理功能，但是這樣一來也有一個限制了，那就是代理對象不能是final類型，同時一些主要方法最好不能是final類型的，當然這個限制和上面的那個接口實現限制比起來還是好點的。

 

到此我們了解了Java中的Hook技術的核心知識點了，下面就用開始的剪切板服務來做實驗，我們Hook系統的剪切板服務功能，攔截其方法，上面也說道了，既然要Hook服務，首先得找到Hook點，通過開始對Android中系統服務的調用流程分析知道，其實這些服務都是一些保存在ServiceManager中的遠端IBinder對象，這其實是一個Hook點：

其實ServiceManager中每次在獲取服務的時候，其實是先從一個緩存池中查找，如果有就直接返回了：

而這個緩存池正好是全局的static類型，所以就可以很好的使用反射機制獲取到他了，然後進行操作了。

 

接下來，我們就需要構造一個剪切板的服務IBinder對象了，然後在把這個對象放到上面得到的池子中即可。那麼按照上面的動態代理的流程，

第一、原始對象必須實現一個接口，這裡也正好符合這個規則，每個遠程服務其實是實現了IBinder接口的。

第二、其次是要有原始對象，這個也可以，通過上面的緩存池即可獲取

有了這兩個條件那麼接下來就可以使用動態代理構造一個代理類了：

通過反射去獲取ServiceManager中的緩存池Binder對象就不多說了，完全反射機制即可，我們先獲取到緩存池，然後得到剪切板服務Binder對象，構造一個代理類，最後在設置回去即可。下面主要來看一下構造了代理類之後，如何攔截哪些方法？

這裡一定要注意了，有的同學可能想直接在這裡攔截setPrimaryClip這樣的剪切板方法不就可以了嗎？想想是肯定不可以的，為什麼呢？因為我們現在代理的是遠端服務的Binder對象，他還沒有轉化成本地對象呢？如何會有這些方法呢，而我們真正要攔截的方法是IClipboardManager，其實就是Proxy類，而這個對象也是Stub類的asInterface方法得到的，所以我們現在的思路是有了遠端服務的代理對象，攔截肯定是攔截這個代理對象Binder的一些方法，那麼這個遠端服務有哪些方法會在這個過程中被調用呢？我們再看看之前的一個簡單AIDL的例子：

在asInterface方法中可以看到，傳遞進來的就是一個遠端服務IBinder對象，這裡會先調用它的queryLocalInerface方法獲取本進程的本地化對象，那麼這個方法就是攔截的目標了。

然後在想，我們如果想攔截IClipboardManager的setPrimaryClip方法，其實就是要攔截ClipboardManager$Proxy的這些方法，那麼還需要做一次代理，代理ClipboardManager$Proxy類對象

第一、ClipboardManager$Proxy類實現了AIDL接口類型，符合規則。

第二、我們可以直接使用反射獲取到IClipboardManager$Stub類，然後反射調用它的asInterface方法就可以得到了IClipboardManager$Proxy對象了，符合規則。

到這裡，看來這個對象也符合了代理的條件，那麼就簡單了，繼續使用動態代理機制產生一個代理類即可：

這個代理類的InvocationHandler中，先需要通過反射獲取到Proxy原始對象：

最後才開始實現攔截操作。

 

下面來看一個實驗結果：

我們調用系統的剪切板服務，但是返回的結果卻是：

看到了，這裡的剪切板的內容已經被之前攔截，內容也被替換了。

 

上面就全部介紹了如何Hook系統的剪切板服務功能，流程如下：

1、我們的目的就是攔截系統的服務功能，那麼最開始的入口就是服務大管家ServiceManager對象，而在他內部也正好有一個遠端服務對象的IBinder緩存池，那麼這個變量就是我們操作的對象了，可以先使用反射機制去獲取到他，然後在獲取到指定的剪切板服務IBinder對象實例。

2、下一步肯定是Hook這個剪切板服務的Binder對象，這裡采用動態代理方式產生一個Binder對象代理類，符合兩個規則：

1》這個Binder對象實現了IBinder接口類型

2》我們已經得到了原始的Binder對象實例

構造完代理類之後，我們攔截的方法是queryLocalInterface方法，為什麼是這個方法呢？因為在整個服務使用過程中之後在Stub類中使用到了這個方法，很多同學會認為為什麼不在這裡直接攔截系統方法呢？這是一個誤區，要想清楚，這裡的代理對象是遠程服務的Binder，還不是本地化對象，不能會有哪些系統方法的，所以得再做一次Hook，去Hook住系統的本地化對象。

3、在攔截了Binder對象的queryLocalInterface方法之後，再一次做一下本地化服務對象的代理生成操作，而這個本地化對象一般都是IClipboard$Proxy，那麼動態代理的規則：

1》本地化服務對象都會實現AIDL接口類型(這裡才有哪些我們想攔截的系統方法)

2》通過反射調用IClipboard$Stub類的asInterface方法得到IClipboard$Proxy類對象實例

符合這兩個規則那麼就可以產生代理對象了，然後開始攔截服務的指定方法即可。

 

上面總結的這個流程是可以完全用於其他系統服務的Hook工作的，因為系統服務的機制都是一致的，所以這個流程一定要理解清楚，後面的工作才好進行。

 

四、補充說明

有的同學可能會好奇詢問，這個Hook系統服務貌似只對本應用有效吧？哈哈，的確是這樣的，上面的攔截只會對本應用有效，那有的同學會問，只對本應用有效意義就不是很大的，其實這個要看個人需求了，後面會介紹一些開發中遇到的問題，就需要借助這個技術去解決了，但是真正能夠攔截系統的服務對所有的應用有效，其實想想實現也不難，因為應用都會請求服務，而所有的服務都在system_server進程中，那麼就可以采用root之後，注入system_server進程，那時候在開始Hook工作即可完成真正意義上的攔截操作，這個用途就大了，比如我們可以修改系統的經緯度信息，偽造假的當前位置信息，篡改設備的IMEI值，讓有的游戲識別唯一設備無效等。但是這個就需要root了之後才可以操作了

五、總結

到這裡我們就介紹完了Android中Hook系統服務的流程，本文中主要介紹了Hook系統剪切板服務，攔截指定方法，其實後面還會繼續介紹攔截AMS和PMS服務，實現應用啟動的攔截操作，達到我們想要的效果。