Android系統通過Binder機制給應用程序提供了一系列的系統服務,諸如ActivityManagerService
,ClipboardManager
, AudioManager
等;這些廣泛存在系統服務給應用程序提供了諸如任務管理,音頻,視頻等異常強大的功能。
插件框架作爲各個插件的管理者,爲了使得插件能夠無縫地使用這些系統服務,自然會對這些系統服務做出一定的改造(Hook),使得插件的開發和使用更加方便,從而大大降低插件的開發和維護成本。比如,Hook住ActivityManagerService
可以讓插件無縫地使用startActivity
方法而不是使用特定的方式(比如that語法)來啓動插件或者主程序的任意界面。
我們把這種Hook系統服務的機制稱之爲Binder Hook,因爲本質上這些服務提供者都是存在於系統各個進程的Binder對象。因此,要理解接下來的內容必須瞭解Android的Binder機制,可以參考我之前的文章Binder學習指南
閱讀本文之前,可以先clone一份 understand-plugin-framework,參考此項目的binder-hook
模塊。另外,插件框架原理解析系列文章見索引。
系統服務的獲取過程
我們知道系統的各個遠程service對象都是以Binder的形式存在的,而這些Binder有一個管理者,那就是ServiceManager
;我們要Hook掉這些service,自然要從這個ServiceManager
下手,不然星羅棋佈的Binder廣泛存在於系統的各個角落,要一個個找出來還真是大海撈針。
回想一下我們使用系統服務的時候是怎麼幹的,想必這個大家一定再熟悉不過了:通過Context
對象的getSystemService
方法;比如要使用ActivityManager
:
1 |
ActivityManager am = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE); |
可是這個貌似跟ServiceManager
沒有什麼關係啊?我們再查看getSystemService
方法;(Context的實現在ContextImpl
裏面):
1 2 3 4 |
public Object getSystemService(String name) { ServiceFetcher fetcher = SYSTEM_SERVICE_MAP.get(name); return fetcher == null ? null : fetcher.getService(this); } |
很簡單,所有的service對象都保存在一張map
裏面,我們再看這個map是怎麼初始化的:
1 2 3 4 5 6 |
registerService(ACCOUNT_SERVICE, new ServiceFetcher() { public Object createService(ContextImpl ctx) { IBinder b = ServiceManager.getService(ACCOUNT_SERVICE); IAccountManager service = IAccountManager.Stub.asInterface(b); return new AccountManager(ctx, service); }}); |
在ContextImpl
的靜態初始化塊裏面,有的Service是像上面這樣初始化的;可以看到,確實使用了ServiceManager
;當然還有一些service並沒有直接使用ServiceManager
,而是做了一層包裝並返回了這個包裝對象,比如我們的ActivityManager
,它返回的是ActivityManager
這個包裝對象:
1 2 3 4 |
registerService(ACTIVITY_SERVICE, new ServiceFetcher() { public Object createService(ContextImpl ctx) { return new ActivityManager(ctx.getOuterContext(), ctx.mMainThread.getHandler()); }}); |
但是在ActivityManager
這個類內部,也使用了ServiceManager
;具體來說,因爲ActivityManager裏面所有的核心操作都是使用ActivityManagerNative.getDefault()
完成的。那麼這個語句幹了什麼呢?
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(b); return am; } }; |
因此,通過分析我們得知,系統Service的使用其實就分爲兩步:
1 2 |
IBinder b = ServiceManager.getService("service_name"); // 獲取原始的IBinder對象 IXXInterface in = IXXInterface.Stub.asInterface(b); // 轉換爲Service接口 |
尋找Hook點
在插件框架原理解析——Hook機制之動態代理裏面我們說過,Hook分爲三步,最關鍵的一步就是尋找Hook點。我們現在已經搞清楚了系統服務的使用過程,那麼就需要找出在這個過程中,在哪個環節是最合適hook的。
由於系統服務的使用者都是對第二步獲取到的IXXInterface
進行操作,因此如果我們要hook掉某個系統服務,只需要把第二步的asInterface
方法返回的對象修改爲爲我們Hook過的對象就可以了。
asInterface過程
接下來我們分析asInterface
方法,然後想辦法把這個方法的返回值修改爲我們Hook過的系統服務對象。這裏我們以系統剪切版服務爲例,源碼位置爲android.content.IClipboard
,IClipboard.Stub.asInterface
方法代碼如下:
1 2 3 4 5 6 7 8 9 10 |
public static android.content.IClipboard asInterface(android.os.IBinder obj) { if ((obj == null)) { return null; } android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR); // Hook點 if (((iin != null) && (iin instanceof android.content.IClipboard))) { return ((android.content.IClipboard) iin); } return new android.content.IClipboard.Stub.Proxy(obj); } |
這個方法的意思就是:先查看本進程是否存在這個Binder對象,如果有那麼直接就是本進程調用了;如果不存在那麼創建一個代理對象,讓代理對象委託驅動完成跨進程調用。
觀察這個方法,前面的那個if語句判空返回肯定動不了手腳;最後一句調用構造函數然後直接返回我們也是無從下手,要修改asInterface
方法的返回值,我們唯一能做的就是從這一句下手:
1 |
android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR); // Hook點 |
我們可以嘗試修改這個obj
對象的queryLocalInterface
方法的返回值,並保證這個返回值符合接下來的if
條件檢測,那麼就達到了修改asInterface
方法返回值的目的。
而這個obj
對象剛好是我們第一步返回的IBinder
對象,接下來我們嘗試對這個IBinder
對象的queryLocalInterface
方法進行hook。
getService過程
上文分析得知,我們想要修改IBinder
對象的queryLocalInterface
方法;獲取IBinder
對象的過程如下:
1 |
IBinder b = ServiceManager.getService("service_name"); |
因此,我們希望能修改這個getService
方法的返回值,讓這個方法返回一個我們僞造過的IBinder
對象;這樣,我們可以在自己僞造的IBinder
對象的queryLocalInterface
方法作處理,進而使得asInterface
方法返回在queryLocalInterface
方法裏面處理過的值,最終實現hook系統服務的目的。
在跟蹤這個getService
方法之前我們思考一下,由於系統服務是一系列的遠程Service,它們的本體,也就是Binder本地對象一般都存在於某個單獨的進程,在這個進程之外的其他進程存在的都是這些Binder本地對象的代理。因此在我們的進程裏面,存在的也只是這個Binder代理對象,我們也只能對這些Binder代理對象下手。(如果這一段看不懂,建議不要往下看了,先看Binder學習指南)
然後,這個getService
是一個靜態方法,如果此方法什麼都不做,拿到Binder代理對象之後直接返回;那麼我們就無能爲力了:我們沒有辦法攔截一個靜態方法,也沒有辦法獲取到這個靜態方法裏面的局部變量(即我們希望修改的那個Binder代理對象)。
接下來就可以看這個getService
的代碼了:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
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; } |
天無絕人之路!ServiceManager
爲了避免每次都進行跨進程通信,把這些Binder代理對象緩存在一張map
裏面。
我們可以替換這個map裏面的內容爲Hook過的IBinder
對象,由於系統在getService
的時候每次都會優先查找緩存,因此返回給使用者的都是被我們修改過的對象,從而達到瞞天過海的目的。
總結一下,要達到修改系統服務的目的,我們需要如下兩步:
- 首先肯定需要僞造一個系統服務對象,接下來就要想辦法讓
asInterface
能夠返回我們的這個僞造對象而不是原始的系統服務對象。 - 通過上文分析我們知道,只要讓
getService
返回IBinder
對象的queryLocalInterface
方法直接返回我們僞造過的系統服務對象就能達到目的。所以,我們需要僞造一個IBinder對象,主要是修改它的queryLocalInterface
方法,讓它返回我們僞造的系統服務對象;然後把這個僞造對象放置在ServiceManager
的緩存map
裏面即可。
我們通過Binder機制的優先查找本地Binder對象的這個特性達到了Hook掉系統服務對象的目的。因此queryLocalInterface
也失去了它原本的意義(只查找本地Binder對象,沒有本地對象返回null),這個方法只是一個傀儡,是我們實現hook系統對象的橋樑:我們通過這個“漏洞”讓asInterface
永遠都返回我們僞造過的對象。由於我們接管了asInterface
這個方法的全部,我們僞造過的這個系統服務對象不能是隻擁有本地Binder對象(原始queryLocalInterface
方法返回的對象)的能力,還要有Binder代理對象操縱驅動的能力。
接下來我們就以Hook系統的剪切版服務爲例,用實際代碼來說明,如何Hook掉系統服務。
Hook系統剪切版服務
僞造剪切版服務對象
首先我們用代理的方式僞造一個剪切版服務對象,關於如何使用代理的方式進行hook以及其中的原理,可以查看插件框架原理解析——Hook機制之動態代理。
具體代碼如下,我們用動態代理的方式Hook掉了hasPrimaryClip()
,getPrimaryClip()
這兩個方法:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
public class BinderHookHandler implements InvocationHandler { private static final String TAG = "BinderHookHandler"; // 原始的Service對象 (IInterface) Object base; public BinderHookHandler(IBinder base, Class<?> stubClass) { try { Method asInterfaceMethod = stubClass.getDeclaredMethod("asInterface", IBinder.class); // IClipboard.Stub.asInterface(base); this.base = asInterfaceMethod.invoke(null, base); } catch (Exception e) { throw new RuntimeException("hooked failed!"); } } @TargetApi(Build.VERSION_CODES.HONEYCOMB) @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // 把剪切版的內容替換爲 "you are hooked" if ("getPrimaryClip".equals(method.getName())) { Log.d(TAG, "hook getPrimaryClip"); return ClipData.newPlainText(null, "you are hooked"); } // 欺騙系統,使之認爲剪切版上一直有內容 if ("hasPrimaryClip".equals(method.getName())) { return true; } return method.invoke(base, args); } } |
注意,我們拿到原始的IBinder
對象之後,如果我們希望使用被Hook之前的系統服務,並不能直接使用這個IBinder
對象,而是需要使用asInterface
方法將它轉換爲IClipboard
接口;因爲getService
方法返回的IBinder
實際上是一個裸Binder代理對象,它只有與驅動打交道的能力,但是它並不能獨立工作,需要人指揮它;asInterface
方法返回的IClipboard.Stub.Proxy
類的對象通過操縱這個裸BinderProxy
對象從而實現了具體的IClipboard
接口定義的操作。
僞造IBinder
對象
在上一步中,我們已經僞造好了系統服務對象,現在要做的就是想辦法讓asInterface
方法返回我們僞造的對象了;我們僞造一個IBinder
對象:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 |
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); } } |
我們使用動態代理的方式僞造了一個跟原始IBinder
一模一樣的對象,然後在這個僞造的IBinder
對象的queryLocalInterface
方法裏面返回了我們第一步創建的僞造過的系統服務對象;注意看註釋,詳細解釋可以看代碼
替換ServiceManager的IBinder
對象
現在就是萬事具備,只欠東風了;我們使用反射的方式修改ServiceManager
類裏面緩存的Binder對象,使得getService
方法返回我們僞造的IBinder
對象,進而asInterface
方法使用僞造IBinder
對象的queryLocalInterface
方法返回了我們僞造的系統服務對象。代碼較簡單,如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
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); |
接下來,在app裏面使用剪切版,比如長按進行粘貼之後,剪切版的內容永遠都是you are hooked
了;這樣,我們Hook系統服務的目的宣告完成!詳細的代碼參見 github。
也許你會問,插件框架會這麼hook嗎?如果不是那麼插件框架hook這些幹什麼?插件框架當然不會做替換文本這麼無聊的事情,DroidPlugin插件框架管理插件使得插件就像是主程序一樣,因此插件需要使用主程序的剪切版,插件之間也會共用剪切版;其他的一些系統服務也類似,這樣就可以達到插件和宿主程序之間的天衣服縫,水乳交融!另外,ActivityManager
以及PackageManager
這兩個系統服務雖然也可以通過這種方式hook,但是由於它們的重要性和特殊性,DroidPlugin使用了另外一種方式,我們會單獨講解。
喜歡就點個贊吧~持續更新,請關注github項目 understand-plugin-framework 和我的 博客!