# 一、前言

目前有很多的業務模組提供了Deeplink服務，Deeplink簡單來說就是對外部應用提供入口。

針對不同的跳入型別，app可能會選擇提供不一致的服務，這個時候就需要對外部跳入的應用進行區分。一般來講，我們會使用反射來呼叫Acticity中的mReferrer欄位來獲取跳轉來源的包名。

具體程式碼如下；

```java
/**
 * 透過反射獲取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欄位。

![](https://static001.geekbang.org/infoq/c0/c09342d65b033f6358b6c266403e21a1.png)

在Activity的Attach方法中對mReferrer做了賦值。

## 2.2 使用斷點除錯跟蹤呼叫棧

我們在Attach方法上新增斷點，透過斷點來跟蹤Attach的呼叫；

![](https://static001.geekbang.org/infoq/36/3670522168dfd8637eaf5ca4cb83fb13.png)

紅框中就是Attach的呼叫路徑，該呼叫棧在主執行緒中執行；從呼叫棧中看出Attach是ActivityThread.performLaunchActivity呼叫的。

![](https://static001.geekbang.org/infoq/fe/fe428fd59c1242a8f4389d316c244355.png)

performLaunchActivity呼叫Attach時傳入的是r的referrer引數，r是一個ActivityClientRecord物件。

我們進一步找到ActivityClientRecord中對referrer賦值的地方，就是ActivityClientRecord的建構函式。

![](https://static001.geekbang.org/infoq/55/551a654d02a1c34ad6a486709822c971.png)

在建構函式中新增斷點，檢視呼叫棧；

![](https://static001.geekbang.org/infoq/ba/ba606026a7deda4f717ac94951de9ef2.png)

發現ActivityClientRecord在LaunchActivityItem的execute中被例項化，並且傳入的是LaunchActivityItem的mReferrer。

LaunchActivityItem的mReferrer是在setValues方法中賦值的，我們需要透過除錯來看setValues是被誰呼叫的。當我們使用常規方式斷點檢視setValues的呼叫方時，我們會發現這樣一種情況。

![](https://static001.geekbang.org/infoq/9d/9de4ba54c13fe253145f58f2240e7ede.png)

說明LaunchActivityItem在本地程式中，是一個被序列化後反序列化生成的物件。

在Activity中，序列化物件傳輸通常是使用binder來完成的，而binder的服務端是在System程式中。這裡實現了反序列化，那麼在遠端的binder服務中一定有序列化的過程。我們可以在System程式中除錯這個斷點，應該就是序列化的過程。

## 2.3 斷點除錯

對System程式除錯的方式也比較簡單；

-   step1：下載安裝Android自帶的X86模擬器（注意一定要安裝google api版本，play版本不支援除錯system程式）。
    
-   step2：在除錯的時候選擇System程式。

![](https://static001.geekbang.org/infoq/72/72e1c1ff45200555b8e07211b0cb5400.png)

透過除錯，我們找到賦值堆疊（注意這裡堆疊顯示的程式已經是Binder程式了）。

![](https://static001.geekbang.org/infoq/24/24bb3848c57cea013248d73f639b8370.png)

我們根據這個堆疊的指示，一步一步的跟進，這裡需要注意一下，我們在檢視除錯堆疊的時候，只需要關注類名和方法名就可以了，不用刻意去關注堆疊中的行號，因為行號不一定準確。如果除錯過程中發現差異太大，可以嘗試更換一個模擬器版本。

這裡跟進到ActivityStackSupervisor的realStartActivityLoacked方法。

![](https://static001.geekbang.org/infoq/2e/2eac489a89b8670bac2477aa9b8849ac.png)

在ActivityStackSupervisor中，我們發現這個引數是由r.LaunchedFromPackage的來的，這個r是ActivityRecord，查詢LaunchedFromPackage的賦值的地方，最終找到ActivityRecord的初始化方法。

## 2.4 物件例項化過程

在初始化方法中新增斷點進行堆疊除錯；

![](https://static001.geekbang.org/infoq/14/1478e0712794e6ad10b217b9b1658ff8.png)

跟著堆疊一步一步的看，到了ActivityStarter的execute方法裡面，這裡可以看到package的來源是mRequest.callingPackage。

![](https://static001.geekbang.org/infoq/e0/e04de8ec3ec18ac7f21fee3f4a0511e0.png)

透過搜尋Request的callingPackage物件對的Vaule write，mRequest.callingPackage的來源是ActivityStarter的setCallingPackage方法，一定是呼叫了setCallingPackage方法來實現了callingPackage內容的注入。

![](https://static001.geekbang.org/infoq/3c/3c3854ef66b9dc9a39ac03527b0adec0.png)

再看上一步驟中的堆疊，呼叫該方法的是ActivityTaskManagerService的startActivity方法；startActivity在構建時使用setCallingPackage傳入了package。與我們之前的猜測是一致的。

![](https://static001.geekbang.org/infoq/03/03a8e29513a1588a05a236a263662deb.png)

分析到這裡已經接近真相了。

## 2.5 遠端服務Binder呼叫的分析

我們都知道ActivityTaskManagerService是一個遠端服務，從它工作的程式就可以看出來，是一個binder程式。因為ActivityTaskManagerService extends IActivityTaskManager.Stub，那我們就要去找IActivityTaskManager.Stub被遠端呼叫的地方。

要想找他遠端呼叫的地方，我們就要先找到IActivityTaskManager.Stub是如何被呼叫方拿到的。

全域性搜尋IActivityTaskManager.Stub或者搜尋IActivityTaskManager.Stub.asInterface，這裡為了方便使用了線上的Android原始碼搜尋平臺。

![](https://static001.geekbang.org/infoq/ee/ee54bce2c052c10d76b2489f5bf8ca47.png)

我們在ActivityTaskManager中找到如下程式碼；

```java
@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程式呼叫（遠端服務呼叫 ）的方法上面新增斷點。那麼你只會得到如下呼叫棧。

![](https://static001.geekbang.org/infoq/99/99d91e8d72f6ac36b7461b158d4f22e7.png)

很顯然呼叫棧直接指向了 binder遠端，這不是我們想要的呼叫棧。我們知道，呼叫startActivity的原始碼一定是ActivityTaskManager.getService().startActivity。

而這行程式碼一定是在App的程式中呼叫的，屬於binder的客戶端呼叫，因此我們試著在getService()上面加一個斷點試試。這裡加了斷點之後也要注意一下，因為這個時候的startActivity應該是攻擊方呼叫的，也就是調起Deeplink的應用呼叫的。

所以。我們需要對Deeplink的發起方進行除錯。我們可以寫一個Demo來進行除錯。

![](https://static001.geekbang.org/infoq/80/80ff03269e973731ac2b0f185b646485.png)

點選按鈕來發起Deeplink，然後進行斷點，這個時候就能找到如下堆疊。

![](https://static001.geekbang.org/infoq/3f/3f604a306d2560e3f23fa26351e0adce.png)

點選下一步斷點（Step Over）剛好就是ActivityTaskManager.getService().startActivity的方法呼叫。

![](https://static001.geekbang.org/infoq/85/85b701688fc1ed8674b2463f8e669984.png)

於是我們得到如下呼叫棧；

```java
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；

![](https://static001.geekbang.org/infoq/e6/e6c1958b2e5e7f2336dd684c36779a9f.png)

只要拿到這個Uid，我們就可以根據Uid呼叫packageManager的方法來獲取對應Uid的報名。

## 3.2 調研Uid是否有偽造的可能性

下面就是要驗證一下Uid是否有被偽造的可能了。除錯查詢Uid的來源，在ActivityRecord的初始化方法中斷點檢視callingUid的來源。

![](https://static001.geekbang.org/infoq/7f/7fd6981c21dade350f3cfd3b9178e410.png)

我們發現 這個Uid其實是在ActivityStarter裡面使用Binder.getCallingUid得到的。Binder程式可不是應用層面可以干涉的了，我們可以放心大膽的使用這個Uid，不用擔心被偽造，剩下的就是如何使用Uid獲取PackageName了。

## 3.3 使用Uid置換PackageName

我們檢索程式碼，發現ActivityTaskManagerService恰好提供了獲取Uid的方法。

![](https://static001.geekbang.org/infoq/81/8197c202977d5091817c53074b00e0aa.png)

所以我們需要拿到ActivityTaskManagerService引用，搜尋IActivityTaskManager.Stub。

![](https://static001.geekbang.org/infoq/3e/3e701d5d000dc36b435caa351f38ff16.png)

ActivityTaskManager是無法在app層引用的（是一個hide的類，但其實也是有辦法的，大家可以自己去探索一下）。

我們繼續查詢；

![](https://static001.geekbang.org/infoq/5c/5cee41783ec1ae8f7331b8f7e926e9b9.png)

最終發現ActivityManager提供了這麼一個方法來獲取ActivityTaskManagerService，但是很不幸，getTaskService是一個黑名單方法，被禁止呼叫。

最後我們發現ActivityTaskManagerService的getLaunchedFromUid方法其實是被ActivityManageService包裝了一下的。

```java
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來呼叫就可以了，程式碼如下（注意不同的系統的版本可能程式碼並不一樣）。

```java
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</iactivitytaskmanager></iactivitytaskmanager>

Android Activity Deeplink啟動來源獲取原始碼分析

相關文章