Android Activity Deeplink啟動來源獲取源碼分析
一、前言
目前有很多的業務模塊提供了Deeplink服務，Deeplink簡單來說就是對外部應用提供入口。
針對不同的跳入類型，app可能會選擇提供不一致的服務，這個時候就需要對外部跳入的應用進行區分。一般來講，我們會使用反射來調用Acticity中的mReferrer字段來獲取跳轉來源的包名。
具體代碼如下；
/**
* 通過反射獲取referrer
* @return
*/
private String reflectGetReferrer() {
try {
Field referrerField =
Activity.class.getDeclaredField("mReferrer");
referrerField.setAccessible(true);
return (String) referrerField.get(this);
} catch (NoSuchFieldException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
}
return "";
}
但是mReferrer有沒有被偽造的可能呢？
一旦mReferrer被偽造，輕則業務邏輯出錯，重則造成經濟損失，針對這種情況，有沒有辦法找到一種較為安全的來源獲取方法呢？
這就需要對mReferrer的來源進行一次分析。下面我們來進行一次mReferrer來源的另類源碼分析。之所以說另類，是因為這次會大量使用調試手段來逆向進行源碼分析。
二、mReferrer從哪裡來
2.1 搜索mReferrer，來源回溯
使用搜索功能來搜索Activity類中的mReferrer；使用 Find Usages 功能來查找mReferrer字段。
在Activity的Attach方法中對mReferrer做了賦值。
2.2 使用斷點調試跟蹤調用棧
我們在Attach方法上添加斷點，通過斷點來跟蹤Attach的調用；
紅框中就是Attach的調用路徑，該調用棧在主線程中執行；從調用棧中看出Attach是ActivityThread.performLaunchActivity調用的。
performLaunchActivity調用Attach時傳入的是r的referrer參數，r是一個ActivityClientRecord對象。
我們進一步找到ActivityClientRecord中對referrer賦值的地方，就是ActivityClientRecord的構造函數。
在構造函數中添加斷點，查看調用棧；
發現ActivityClientRecord在LaunchActivityItem的execute中被實例化，並且傳入的是LaunchActivityItem的mReferrer。
LaunchActivityItem的mReferrer是在setValues方法中賦值的，我們需要通過調試來看setValues是被誰調用的。當我們使用常規方式斷點查看setValues的調用方時，我們會發現這樣一種情況。
說明LaunchActivityItem在本地進程中，是一個被序列化後反序列化生成的對象。
在Activity中，序列化對象傳輸通常是使用binder來完成的，而binder的服務端是在System進程中。這裡實現了反序列化，那麼在遠端的binder服務中一定有序列化的過程。我們可以在System進程中調試這個斷點，應該就是序列化的過程。
2.3 斷點調試
對System進程調試的方式也比較簡單；
-
step1：下載安裝Android自帶的X86模擬器（注意一定要安裝google api版本，play版本不支持調試system進程）。
-
step2：在調試的時候選擇System進程。
通過調試，我們找到賦值堆棧（注意這裡堆棧顯示的進程已經是Binder進程了）。
我們根據這個堆棧的指示，一步一步的跟進，這裡需要注意一下，我們在查看調試堆棧的時候，只需要關注類名和方法名就可以了，不用刻意去關注堆棧中的行號，因為行號不一定準確。如果調試過程中發現差異太大，可以嘗試更換一個模擬器版本。
這裡跟進到ActivityStackSupervisor的realStartActivityLoacked方法。
在ActivityStackSupervisor中，我們發現這個參數是由r.LaunchedFromPackage的來的，這個r是ActivityRecord，查找LaunchedFromPackage的賦值的地方，最終找到ActivityRecord的初始化方法。
2.4 對象實例化過程
在初始化方法中添加斷點進行堆棧調試；
跟着堆棧一步一步的看，到了ActivityStarter的execute方法裏面，這裡可以看到package的來源是mRequest.callingPackage。
通過搜索Request的callingPackage對象對的Vaule write，mRequest.callingPackage的來源是ActivityStarter的setCallingPackage方法，一定是調用了setCallingPackage方法來實現了callingPackage內容的注入。
再看上一步驟中的堆棧，調用該方法的是ActivityTaskManagerService的startActivity方法；startActivity在構建時使用setCallingPackage傳入了package。與我們之前的猜測是一致的。
分析到這裡已經接近真相了。
2.5 遠程服務Binder調用的分析
我們都知道ActivityTaskManagerService是一個遠程服務，從它工作的進程就可以看出來，是一個binder進程。因為ActivityTaskManagerService extends IActivityTaskManager.Stub，那我們就要去找IActivityTaskManager.Stub被遠程調用的地方。
要想找他遠程調用的地方，我們就要先找到IActivityTaskManager.Stub是如何被調用方拿到的。
全局搜索IActivityTaskManager.Stub或者搜索IActivityTaskManager.Stub.asInterface，這裡為了方便使用了在線的Android源碼搜索平台。
我們在ActivityTaskManager中找到如下代碼；
@TestApi
@SystemService(Context.ACTIVITY_TASK_SERVICE)
public class ActivityTaskManager {
ActivityTaskManager(Context context, Handler handler) {
}
/** @hide */
public static IActivityTaskManager getService() {
return IActivityTaskManagerSingleton.get();
}
@UnsupportedAppUsage(trackingBug = 129726065)
private static final Singleton<IActivityTaskManager> IActivityTaskManagerSingleton =
new Singleton<IActivityTaskManager>() {
@Override
protected IActivityTaskManager create() {
final IBinder b = ServiceManager.getService(Context.ACTIVITY_TASK_SERVICE);
//這裡生成了遠程調用對象
return IActivityTaskManager.Stub.asInterface(b);
}
};
}
也就是說通過ActivityTaskManager.getService()方法可以拿到IActivityTaskManager.Stub的遠程調用句柄。
於是ActivityTaskManagerService的startActivity方法調用的寫法應該是ActivityTaskManager.getService().startActivity，下一步的計劃是找到這個方法調用的地方 。
2.6 萬能的搜索並不萬能
按照正常的思路，我們會再來使用搜索功能在這個在線源碼網站上搜索一下ActivityTaskManager.getService().startActivity。
搜索不到？這裡一定要注意，因為startActivity方法裏面有很多參數，很可能代碼被換行，一旦被換行，搜索ActivityTaskManager.getService().startActivity就不能搜到了。
搜索也不是萬能的，我們還是考慮加斷點試試。
那麼斷點應該加在哪裡呢？我們是否可以將斷點加在ActivityTaskManagerService的startActivity上呢？
答案是不行，如果你嘗試去在一個binder進程調用（遠程服務調用 ）的方法上面添加斷點。那麼你只會得到如下調用棧。
很顯然調用棧直接指向了 binder遠端，這不是我們想要的調用棧。我們知道，調用startActivity的源碼一定是ActivityTaskManager.getService().startActivity。
而這行代碼一定是在App的進程中調用的，屬於binder的客戶端調用，因此我們試着在getService()上面加一個斷點試試。這裡加了斷點之後也要注意一下，因為這個時候的startActivity應該是攻擊方調用的，也就是調起Deeplink的應用調用的。
所以。我們需要對Deeplink的發起方進行調試。我們可以寫一個Demo來進行調試。
點擊按鈕來發起Deeplink，然後進行斷點，這個時候就能找到如下堆棧。
點擊下一步斷點（Step Over）剛好就是ActivityTaskManager.getService().startActivity的方法調用。
於是我們得到如下調用棧；
ContextImpl.startActivty()
Instrumentation.execStartActivity()
ActivityTaskManager.getService()
.startActivity(whoThread, who.getBasePackageName(), intent,
intent.resolveTypeIfNeeded(who.getContentResolver()),
token, target != null ? target.mEmbeddedID : null,
requestCode, 0, null, options);
這邊就找到了 可以看到，callingPackage正是使用getBasePackageName方法來實現的。who就是context，也就是我們的Activity。
到這裡就可以確認 mReferrer其實就是使用context的getBasePackageName()來實現的。
三、如何避免包名被偽造
3.1 關注PID和Uid
如何來防止PackageName被偽造呢？
在我們調試ActivityRecord的時候，我們發現ActivityRecord的屬性中還有PID和Uid；
只要拿到這個Uid，我們就可以根據Uid調用packageManager的方法來獲取對應Uid的報名。
3.2 調研Uid是否有偽造的可能性
下面就是要驗證一下Uid是否有被偽造的可能了。調試查找Uid的來源，在ActivityRecord的初始化方法中斷點查看callingUid的來源。
我們發現 這個Uid其實是在ActivityStarter裏面使用Binder.getCallingUid得到的。Binder進程可不是應用層面可以干涉的了，我們可以放心大膽的使用這個Uid，不用擔心被偽造，剩下的就是如何使用Uid獲取PackageName了。
3.3 使用Uid置換PackageName
我們檢索代碼，發現ActivityTaskManagerService恰好提供了獲取Uid的方法。
所以我們需要拿到ActivityTaskManagerService引用，搜索IActivityTaskManager.Stub。
ActivityTaskManager是無法在app層引用的（是一個hide的類，但其實也是有辦法的，大家可以自己去探索一下）。
我們繼續查找；
最終發現ActivityManager提供了這麼一個方法來獲取ActivityTaskManagerService，但是很不幸，getTaskService是一個黑名單方法，被禁止調用。
最後我們發現ActivityTaskManagerService的getLaunchedFromUid方法其實是被ActivityManageService包裝了一下的。
public class ActivityManagerService extends IActivityManager.Stub
implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
@VisibleForTesting
public ActivityTaskManagerService mActivityTaskManager;
@Override
public boolean updateConfiguration(Configuration values) {
return mActivityTaskManager.updateConfiguration(values);
}
@Override
public int getLaunchedFromUid(IBinder activityToken) {
return mActivityTaskManager.getLaunchedFromUid(activityToken);
}
public String getLaunchedFromPackage(IBinder activityToken) {
return mActivityTaskManager.getLaunchedFromPackage(activityToken);
}
}
所以可以使用ActivityManageService來調用就可以了，代碼如下（注意不同的系統的版本可能代碼並不一樣）。
private String reRealPackage() {
try {
Method getServiceMethod = ActivityManager.class.getMethod("getService");
Object sIActivityManager = getServiceMethod.invoke(null);
Method sGetLaunchedFromUidMethod = sIActivityManager.getClass().getMethod("getLaunchedFromUid", IBinder.class);
Method sGetActivityTokenMethod = Activity.class.getMethod("getActivityToken");
IBinder binder = (IBinder) sGetActivityTokenMethod.invoke(this);
int uid = (int) sGetLaunchedFromUidMethod.invoke(sIActivityManager, binder);
return getPackageManager().getPackagesForUid(uid)[0];
} catch (Exception e) {
e.printStackTrace();
}
return "null";
}
使用Uid來置換PackageName是不是就萬無一失了呢？這裏面是否還有其他玄機？這裡先賣個關子，小夥伴們可以在評論區討論一下。
四、總結
mReferrer很容易通過重寫context的getBasePackageName()被偽造，在使用時一定要小心。通過ActivityManageService獲取的Uid是無法被偽造的，可以考慮使用Uid來轉換PackageName。
作者：vivo互聯網客戶端團隊-Chen Long
