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` में उन paths की सूची होगी जो नए split की स्थापना से पहले उपयोग में थे और `addedPaths` में उन `.apk` फाइलों की सूची होगी जिन्हें मौजूदा `ClassLoader` में जोड़ा जाना है, हालाँकि `checkAndUpdateApkPaths()` के मामले में `oldPaths` बिल्कुल उसी `ApplicationInfo` ऑब्जेक्ट से बनाया जाएगा और इसलिए `addedPaths` खाली होगा और हमलावर यहाँ मौजूदा `ClassLoader` में नए paths नहीं जोड़ पाएगा

`createOrUpdateClassLoaderLocked()` एक लंबी विधि है, लेकिन यहाँ केवल कुछ चीज़ें दिलचस्प हैं:

* [यदि `mIncludeCode` `false` है, तो केवल `ClassLoader` बनाना है बिना किसी `apk`/`dex` फाइल का संदर्भ दिए](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/app/LoadedApk.java;l=968-990;drc=5916ee589c4880e2d8a1a9ad6dc852108e4c44c1)
* सबसे खतरनाक चीज़ उन paths का उपयोग करके नया `ClassLoader` बनाना है जो अभी-अभी हमलावर-नियंत्रित `ApplicationInfo` का उपयोग करके सेट किए गए थे, हालाँकि ऐसा केवल तभी होगा जब [`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` के native library search path में नए paths जोड़ना भी है [](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` तर्क से मौजूदा `ClassLoader` में `apk`/`dex` paths जोड़ना भी है [](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()` पर फिर से लौटते हुए, अभी भी एक प्रासंगिक चीज़ है जो यह विधि करती है, [नए `mResDir` मान का उपयोग करने वाले इंस्टेंस के साथ `LoadedApk.mResources` को बदलना](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/app/LoadedApk.java;l=382;drc=5916ee589c4880e2d8a1a9ad6dc852108e4c44c1)। यह ध्यान दिया जाना चाहिए कि यह नया इंस्टेंस है, पहले से मौजूद इंस्टेंस को अपडेट नहीं करता। नवनिर्मित `Context`s इस नए `Resources` इंस्टेंस को लौटाएंगे/उपयोग करेंगे, हालाँकि पहले से बनाए गए कोई भी `Context`s पुराने `Resources` का उपयोग करते रहेंगे

# प्रभाव सारांश

उपरोक्त अनुभागों को सारांशित करने के लिए, जब भी पीड़ित प्रक्रिया `RemoteViews` लागू करती है, यह भेद्यता अनुमति देती है:

* उस प्रक्रिया के भीतर नवनिर्मित Activities के [`Resources` (स्थानीयकरण स्ट्रिंग्स, लेआउट, आदि)](https://developer.android.com/guide/topics/resources/providing-resources) को बदलना
* `System.loadLibrary()` द्वारा उपयोग किए जाने वाले native library search path में जोड़ना, हालाँकि उसका शोषण करने के लिए पीड़ित को `System.loadLibrary()` को उस लाइब्रेरी का नाम पास करके कॉल करना होगा जो सामान्यतः अनुपस्थित है, जो संभावना नहीं है
* मनमाना Java कोड लोड करना यदि पीड़ित प्रक्रिया ने `createPackageContext(CONTEXT_INCLUDE_CODE)` का उपयोग किया है, लेकिन उस `Context` पर [`getClassLoader()`](https://developer.android.com/reference/android/content/Context#getClassLoader()) को कॉल नहीं किया है, हालाँकि चूँकि कोड लोड करना `CONTEXT_INCLUDE_CODE` फ्लैग का उपयोग करने का कारण है, यह भी स्वाभाविक रूप से होने की संभावना नहीं है

अब, जबकि इस मामले में Java कोड लोड करने का मौका स्वाभाविक रूप से होने की संभावना नहीं है, मैं इसे ट्रिगर करने में सक्षम था

# `WebView` लोड करना

आधुनिक Android संस्करणों पर, `WebView` सिस्टम का हिस्सा नहीं है, बल्कि सामान्य `apk` से लोड किया जाता है जो [सिस्टम कॉन्फ़िगरेशन](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/res/res/xml/config_webview_packages.xml) में परिभाषित है और [या तो सिस्टम ऐप है या सिस्टम के भीतर परिभाषित हस्ताक्षर से मेल खाने वाला हस्ताक्षर है](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();