return context;

여기서 가장 흥미로운 부분은 `LoadedApk.checkAndUpdateApkPaths()` 호출입니다. 이는 정적 메서드이며 일부 전역 상태를 수정할 것입니다 [(코드 스니펫 소스)](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/app/LoadedApk.java;l=2275-2302;drc=5916ee589c4880e2d8a1a9ad6dc852108e4c44c1)```java
public static void checkAndUpdateApkPaths(ApplicationInfo expectedAppInfo) {
    // Get the LoadedApk from the cache
    ActivityThread activityThread = ActivityThread.currentActivityThread();
    if (activityThread == null) {
        Log.e(TAG, "Cannot find activity thread");
        return;
    }
    checkAndUpdateApkPaths(activityThread, expectedAppInfo, /* cacheWithCode */ true);
    checkAndUpdateApkPaths(activityThread, expectedAppInfo, /* cacheWithCode */ false);
}

private static void checkAndUpdateApkPaths(ActivityThread activityThread,
        ApplicationInfo expectedAppInfo, boolean cacheWithCode) {
    String expectedCodePath = expectedAppInfo.getCodePath();
    LoadedApk loadedApk = activityThread.peekPackageInfo(
            expectedAppInfo.packageName, /* includeCode= */ cacheWithCode);
    // If there is load apk cached, or if the cache is valid, don't do anything.
    if (loadedApk == null || loadedApk.getApplicationInfo() == null
            || loadedApk.getApplicationInfo().getCodePath().equals(expectedCodePath)) {
        return;
    }
    // Duplicate framework logic
    List<String> oldPaths = new ArrayList<>();
    LoadedApk.makePaths(activityThread, expectedAppInfo, oldPaths);

    // Force update the LoadedApk instance, which should update the reference in the cache
    loadedApk.updateApplicationInfo(expectedAppInfo, oldPaths);
}

`setApplicationInfo()` [(스니펫 소스)](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/app/LoadedApk.java;l=392-422;drc=5916ee589c4880e2d8a1a9ad6dc852108e4c44c1)를 살펴보겠습니다.```java
private boolean setApplicationInfo(ApplicationInfo aInfo) {
    if (mApplicationInfo != null && mApplicationInfo.createTimestamp > aInfo.createTimestamp) {
        Slog.w(TAG, "New application info for package " + aInfo.packageName
                + " is out of date with TS " + aInfo.createTimestamp + " < the current TS "
                + mApplicationInfo.createTimestamp);
        return false;
    }
    // Snip: assign fields such as mAppDir and mResDir on this object from aInfo
    return true;
}

`addedPaths` 목록이 생성됩니다: 새 분할(split) 설치 시 `oldPaths`에는 새 분할 설치 전에 사용된 경로 목록이 포함되고, `addedPaths`에는 기존 `ClassLoader`에 추가해야 하는 `.apk` 파일 목록이 포함됩니다. 그러나 `checkAndUpdateApkPaths()`의 경우 `oldPaths`는 정확히 동일한 `ApplicationInfo` 객체에서 생성되므로 `addedPaths`는 비어 있게 되고, 공격자는 여기서 기존 `ClassLoader`에 새 경로를 추가할 수 없습니다.

`createOrUpdateClassLoaderLocked()`는 긴 메서드이지만, 여기서 흥미로운 부분은 몇 가지만 있습니다:

* [`mIncludeCode`가 `false`인 경우, `apk`/`dex` 파일을 참조하지 않고 `ClassLoader`를 생성하는 것만 수행됩니다](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/app/LoadedApk.java;l=968-990;drc=5916ee589c4880e2d8a1a9ad6dc852108e4c44c1)
* 가장 위험한 부분은 공격자가 제어하는 `ApplicationInfo`로 방금 설정된 경로를 사용하여 새 `ClassLoader`를 생성하는 것이지만, 이는 [`mDefaultClassLoader`가 `null`인 경우에만 발생합니다](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/app/LoadedApk.java;l=1005;drc=5916ee589c4880e2d8a1a9ad6dc852108e4c44c1). 즉, 해당 `LoadedApk` 인스턴스에서 첫 번째 `createOrUpdateClassLoaderLocked()` 호출임을 의미합니다 (`mDefaultClassLoader` 필드는 [`AppComponentFactory.instantiateClassLoader()`](https://developer.android.com/reference/android/app/AppComponentFactory#instantiateClassLoader(java.lang.ClassLoader,%20android.content.pm.ApplicationInfo)) 적용 전에 사용된 `ClassLoader` 인스턴스를 참조합니다)
* 또한 해당 `ClassLoader`의 네이티브 라이브러리 검색 경로에 새 경로를 추가하는 부분도 있습니다](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/app/LoadedApk.java;l=1050-1058;drc=5916ee589c4880e2d8a1a9ad6dc852108e4c44c1). 그러나 이를 악용하려면 피해 앱이 일반적으로 존재하지 않는 `System.loadLibrary()`를 호출해야 합니다
* 그리고 [`addedPaths` 인수의 `apk`/`dex` 경로를 기존 `ClassLoader`에 추가하는 부분도 있습니다](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/app/LoadedApk.java;l=1060-1065;drc=5916ee589c4880e2d8a1a9ad6dc852108e4c44c1). 그러나 `RemoteViews`의 코드 경로에서는 `addedPaths`가 비어 있게 됩니다

다시 `updateApplicationInfo()`로 돌아가면, 이 메서드가 수행하는 또 하나의 관련 작업이 있습니다. 바로 [`LoadedApk.mResources`를 새 `mResDir` 값을 사용하는 인스턴스로 교체하는 것](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/app/LoadedApk.java;l=382;drc=5916ee589c4880e2d8a1a9ad6dc852108e4c44c1)입니다. 이는 새 인스턴스이며, 이미 존재하는 인스턴스를 업데이트하는 것이 아니라는 점에 유의해야 합니다. 새로 생성된 `Context`는 이 새 `Resources` 인스턴스를 반환/사용하지만, 이미 생성된 `Context`는 계속 이전 `Resources`를 사용합니다.

# 영향 요약

위 섹션들을 요약하면, 피해 프로세스가 `RemoteViews`를 적용할 때마다 이 취약점을 통해 다음이 가능합니다:

* 해당 프로세스 내에서 새로 생성된 Activity의 [`Resources`(현지화 문자열, 레이아웃 등)](https://developer.android.com/guide/topics/resources/providing-resources)를 교체
* `System.loadLibrary()`에서 사용하는 네이티브 라이브러리 검색 경로에 추가. 단, 이를 악용하려면 피해자가 일반적으로 존재하지 않는 라이브러리 이름을 전달하여 `System.loadLibrary()`를 호출해야 하므로 가능성은 낮습니다
* 피해 프로세스가 `createPackageContext(CONTEXT_INCLUDE_CODE)`를 사용했지만 해당 `Context`에서 [`getClassLoader()`를 호출하지 않은 경우](https://developer.android.com/reference/android/content/Context#getClassLoader()) 임의 Java 코드를 로드. 그러나 코드 로딩이 `CONTEXT_INCLUDE_CODE` 플래그를 사용하는 이유이므로, 이 역시 자연스럽게 발생할 가능성은 낮습니다

이 경우 Java 코드를 로드할 가능성은 자연스럽게 발생하기 어렵지만, 저는 이를 트리거할 수 있었습니다.

# `WebView` 로딩

최신 Android 버전에서 `WebView`는 시스템의 일부가 아니라 [시스템 구성](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/res/res/xml/config_webview_packages.xml)에 정의된 일반 `apk`에서 로드되며, [시스템 앱이거나 시스템 내 정의된 서명과 일치하는 서명을 가집니다](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/services/core/java/com/android/server/webkit/WebViewUpdateServiceImpl2.java;l=688-705;drc=f8f9e9ab11e65322aaaeb7373efd77cf1d671928)

해당 `apk`의 로딩은 [새 `Context`를 생성하고 `Context.CONTEXT_INCLUDE_CODE | Context.CONTEXT_IGNORE_SECURITY` 플래그를 전달하여 수행됩니다](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/webkit/WebViewFactory.java;l=521;drc=f8f9e9ab11e65322aaaeb7373efd77cf1d671928)

이제 해당 메서드의 호출자를 살펴보겠습니다 [(스니펫 소스)](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/webkit/WebViewFactory.java;l=541-563;drc=f8f9e9ab11e65322aaaeb7373efd77cf1d671928)```java
// Overall snip: try/catch/finally, Trace, logging and timing measurement
webViewContext = getWebViewContextAndSetProvider();
if (android.content.res.Flags.registerResourcePaths()) {
    Resources.registerResourcePaths(webViewContext.getPackageName(),
            webViewContext.getApplicationInfo());
} else {
    // Snip: old resource update path, won't be used on latest Android builds
}
ClassLoader clazzLoader = webViewContext.getClassLoader();