ثم يتم إرسال `Parcel` إلى عملية أخرى [عبر `Binder`](https://developer.android.com/reference/android/os/IBinder#transact(int,%20android.os.Parcel,%20android.os.Parcel,%20int)). بدلاً من ذلك، ولأغراض الاختبار، يمكن استدعاء [`p.setDataPosition(0)`](https://developer.android.com/reference/android/os/Parcel#setDataPosition(int)) لإعادة توجيه الـ parcel إلى موضعه الأولي والبدء في القراءة:```java
int a = p.readInt(); // a = 1
String b = p.readString(); // b = "Hello"

private WindowContainerTransaction(Parcel in) {
    in.readMap(mChanges, null /* loader */);
    in.readList(mHierarchyOps, null /* loader */);
}

@Override
public void writeToParcel(@NonNull Parcel dest, int flags) {
    dest.writeMap(mChanges);
    dest.writeList(mHierarchyOps);
}

@NonNull
public static final Creator<WindowContainerTransaction> CREATOR =
        new Creator<WindowContainerTransaction>() {
            @Override
            public WindowContainerTransaction createFromParcel(Parcel in) {
                return new WindowContainerTransaction(in);
            }
        };

كما يتضح أعلاه، يتم استخدام طريقة `writeToParcel()` أثناء الكتابة. ثم أثناء القراءة يتم استدعاء طريقة المصنع `CREATOR.createFromParcel()`. تقع مسؤولية تنفيذ `Parcelable` في ضمان أن `createFromParcel` يقرأ نفس كمية البيانات التي كتبها `writeToParcel`، وإلا فإن جميع القراءات اللاحقة من ذلك `Parcel` ستقرأ البيانات من إزاحة خاطئة

يمكن كتابة/قراءة مثل هذه الفئة من/إلى `Parcel` من خلال:

* استدعاء `obj.writeToParcel(parcel, 0)` / `obj = WindowContainerTransaction.CREATOR.createFromParcel()` مباشرة، وهذا يُستخدم غالبًا عندما يكون نوع الفئة معروفًا، على سبيل المثال عندما يحتوي `Parcelable` على حقل بنوع `Parcelable` مختلف أو في الكود المُولّد بواسطة AIDL عندما تحتوي طريقة RPC المعرّفة على `Parcelable` كوسيط
* من خلال `Parcel.writeParcelable`/`readParcelable`. [`writeParcelable`](https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/os/Parcel.java;l=1909;drc=58787794eb5c879f6e39ee58c0071b36e337f8e3) يكتب أولاً اسم الفئة ثم يستدعي طريقة `writeToParcel` من واجهة `Parcelable`. [`readParcelable`](https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/os/Parcel.java;l=3282;drc=58787794eb5c879f6e39ee58c0071b36e337f8e3) يقرأ اسم الفئة المكتوب، ويجد الفئة بهذا الاسم في `ClassLoader` المقدم أو في `BOOTCLASSPATH` إذا تم توفير قيمة فارغة. بمجرد العثور على الفئة، يتم استخدام حقلها الثابت `CREATOR` للحصول على مثيل [`Parcelable.Creator`](https://developer.android.com/reference/android/os/Parcelable.Creator) وهو المصنع المستخدم لقراءة تلك الفئة. من المهم ملاحظة أنه عند استخدام طريقة `readParcelable` يمكنها قراءة أي `Parcelable` متاح في مسار الفئات حيث يتم قراءة اسم الكائن المراد إنشاؤه من نفس `Parcel`
* يتم استخدام `readParcelable` بواسطة العديد من طرق `Parcel` الأخرى، على سبيل المثال `readList` الذي شوهد في المثال أعلاه يقرأ العناصر من خلال `readValue`، وهي الطريقة الأكثر عمومية لنقل الكائنات في `Parcel` وإحدى الطرق التي تستخدمها هي من خلال `readParcelable`. أيضًا في المثال أعلاه، بسبب محو النوع في جافا (Type Erasure)، يمكن لحقل `ArrayList<HierarchyOp> mHierarchyOps` أن يحتوي فعليًا على أي كائنات يدعمها Parcel، وليس فقط تلك المتوافقة مع النوع المحدد في تعريف النوع العام

# عدم تطابق `writeToParcel`/`createFromParcel`

كما ذُكر أعلاه، تقع مسؤولية تنفيذ واجهة `Parcelable` في ضمان أن `createFromParcel` يقرأ نفس كمية البيانات من `Parcel` التي كتبها `writeToParcel` المطابق سابقًا. كلما وُجد في `BOOTCLASSPATH` عنصر `Parcelable` يمكنه انتهاك هذا العقد، فإنه يُنشئ ثغرة أمنية لأنه يسمح بالسيناريو التالي:

1. يرسل تطبيق خبيث إلى `system_server` حزمة `Bundle` أو عنصر `Parcelable` يحتوي على مثيل `Parcelable` معيب إلى جانب بيانات مُنشأة خصيصًا سيتم قراءتها فعليًا في الخطوة 3 ولكن يتم تمريرها حرفيًا خلال الخطوة 2
2. يتحقق `system_server` من أن `Bundle` آمن ثم يعيد توجيهه، أو يمرر `system_server` عنصر `Parcelable` المقدم إلى طريقة AIDL التي تحتوي أيضًا على بيانات حرجة مرسلة في المعامل التالي (إذا كان من الممكن تعديل البيانات المستلمة في ذلك المعامل فسيؤدي ذلك إلى مشكلة أمنية)
3. يستقبل تطبيق آخر البيانات من `system_server` ويثق بها، ومع ذلك بسبب التسلسل المعيب فإن البيانات التي يراها فعليًا تختلف عن البيانات التي قصد `system_server` إرسالها

استخدمت "أو" في الخطوات أعلاه لأن هذه الخطوات تصف كلاً من [نوع استغلال قديم يؤدي إلى تشغيل نشاط عشوائي والذي نشرته في 2017](https://github.com/michalbednarski/ReparcelBug) (على الجانب الأيسر من "أو") ونوع جديد سأصفه هنا في القسم التالي

# كيفية تنفيذ `BroadcastReceiver` في التطبيق

من وجهة نظر مطور التطبيق الذي يستخدم واجهات برمجة التطبيقات المتاحة في Android SDK، فإن طريقة عمل [`BroadcastReceiver`](https://developer.android.com/guide/components/broadcasts) هي أن أحد التطبيقات يستدعي [`sendBroadcast`](https://developer.android.com/reference/android/content/Context#sendBroadcast(android.content.Intent)) (على الرغم من أن التطبيقات غالبًا ما تريد استقبال البث من النظام، وليس من تطبيق آخر) ثم يتم مطابقة `Intent` المُبث مع `<receiver>` المعرّف في `AndroidManifest.xml`، وعند حدوث ذلك يبدأ النظام عملية التطبيق المستلم، ويُنشئ مثيلًا من فئة فرعية لـ `BroadcastReceiver` كما هو معرّف في سمة `<receiver android:name>` ثم يستدعي طريقة [`onReceive`](https://developer.android.com/reference/android/content/BroadcastReceiver#onReceive(android.content.Context,%20android.content.Intent))

دعنا نلقي نظرة على التواصل مع `system_server` الذي يحدث في عملية استقبال البث:

* عندما تبدأ عملية التطبيق في البداية، فإنها [تستدعي `IActivityManager.attachApplication()`](https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/app/ActivityThread.java;l=7340;drc=f53e23b917aa0f6a6310e46a233a29b6d6226b2c)، وبذلك تمرر مقبض [`IApplicationThread`](https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/app/IApplicationThread.aidl) الذي يستخدمه النظام لإخبار عملية التطبيق بما يجب فعله
* عندما يريد النظام تنفيذ `BroadcastReceiver` المسجل في البيان داخل عملية التطبيق، فإنه يستدعي طريقة [`scheduleReceiver`](https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/app/ActivityThread.java;l=950;drc=f53e23b917aa0f6a6310e46a233a29b6d6226b2c) باستخدام `IApplicationThread` الموصوف في النقطة السابقة. تحتوي هذه الطريقة على عدة وسائط ولكن أهمها هنا هما الأولان:
  1. `Intent intent`، والذي تم تمريره سابقًا إلى النظام عند استدعاء `sendBroadcast()`
  2. `ActivityInfo info`، والذي يحتوي على معلومات حول المكوّن الذي يجب تنفيذه. يتم أخذ قيمة هذا المعامل من قبل النظام من خدمة مدير الحزم (Package Manager Service). والأهم من ذلك أن البيانات المرسلة في هذا المعامل تتضمن المسار إلى الملف الذي سيتم تحميل فئة جافا المسؤولة عن معالجة البث المستلم منه

في هذه المرحلة ربما يمكنك تخمين مسار الاستغلال الجديد هذا: استدعاء `sendBroadcast()` مع تمرير `Intent` سيؤدي إلى أنه عندما يحاول النظام استدعاء `scheduleReceiver` سيتسبب في أن التطبيق الذي يُستدعى فيه `scheduleReceiver` سيرى `ActivityInfo` معدّلًا

تجدر الإشارة إلى أن مسار الاستغلال الجديد هذا أصبح ممكنًا في Android 12 حيث لم تكن هناك طريقة سابقًا لوضع عناصر `Parcelable` عشوائية في `Intent` ([إضافات Intent](https://developer.android.com/reference/android/content/Intent#putExtra(java.lang.String,%20android.os.Parcelable)) لا تُحتسب لأنها توضع في `Bundle` الذي يُكتب طوله بالكامل في Parcel ويتم [قراءته ككتلة واحدة](https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/os/BaseBundle.java;l=1671-1681;drc=5d123b67756dffcfdebdb936ab2de2b29c799321)، لذا لا يمكن للإضافات أن تسبب سوء تفسير لكائن `Intent` الذي يحتويها)

# تفعيل عدم تطابق `writeToParcel`/`createFromParcel`

في معظم الأحيان، تكون حالات عدم تطابق `writeToParcel`/`createFromParcel` هي حالات يُنسى فيها أحد الحقول أو يُكتب مرتين في إحدى هاتين الطريقتين، وفي هذه الحالة سيتسبب إرسال مثل هذا الكائن دائمًا في عدم تطابق. (يحدث ذلك غالبًا عندما يكون الكائن على الرغم من كونه `Parcelable`، لا يُستخدم فعليًا عبر العمليات، وإلا لكان ذلك قد لُوحظ بسرعة أثناء الاستخدام العادي)

لكن هذه المرة لم يكن الأمر كذلك، وتفعيل عدم التطابق ليس واضحًا

دعنا نلقي نظرة على الفئة المعرضة للخطر ([الأصل كان هنا](https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/hardware/camera2/params/OutputConfiguration.java;drc=46c390a1c695e2dc458cb889e40559f259f60aed)، الأسطر المميزة بـ `// New in Android 12` أُضيفت يدويًا لأنها لم تكن موجودة في AOSP وقت الكتابة) ([إليك الالتزام الذي أدخل الثغرة في الأصل](https://android.googlesource.com/platform/frameworks/base/+/a69b1bc58b0838e06deefb190e226774a34671e6%5E%21/#F10)، ومع ذلك تم نشره بعد إصدار Android 12)```java
package android.hardware.camera2.params;

public final class OutputConfiguration implements Parcelable {
    private OutputConfiguration(@NonNull Parcel source) {
        int rotation = source.readInt();
        int surfaceSetId = source.readInt();
        int surfaceType = source.readInt();
        int width = source.readInt();
        int height = source.readInt();
        boolean isDeferred = source.readInt() == 1;
        boolean isShared = source.readInt() == 1;
        ArrayList<Surface> surfaces = new ArrayList<Surface>();
        source.readTypedList(surfaces, Surface.CREATOR);
        String physicalCameraId = source.readString();
        boolean isMultiResolution = source.readInt() == 1; // New in Android 12
        ArrayList<Integer> sensorPixelModesUsed = new ArrayList<Integer>(); // New in Android 12
        source.readList(sensorPixelModesUsed, Integer.class.getClassLoader()); // New in Android 12

		// SNIP: copy values from variables set above to fields of this class
    }

    public static final @android.annotation.NonNull Parcelable.Creator<OutputConfiguration> CREATOR =
            new Parcelable.Creator<OutputConfiguration>() {
        @Override
        public OutputConfiguration createFromParcel(Parcel source) {
            try {
                OutputConfiguration outputConfiguration = new OutputConfiguration(source);
                return outputConfiguration;
            } catch (Exception e) {
                Log.e(TAG, "Exception creating OutputConfiguration from parcel", e);
                return null;
            }
        }

        @Override
        public OutputConfiguration[] newArray(int size) {
            return new OutputConfiguration[size];
        }
    };

    @Override
    public void writeToParcel(Parcel dest, int flags) {
        if (dest == null) {
            throw new IllegalArgumentException("dest must not be null");
        }
        dest.writeInt(mRotation);
        dest.writeInt(mSurfaceGroupId);
        dest.writeInt(mSurfaceType);
        dest.writeInt(mConfiguredSize.getWidth());
        dest.writeInt(mConfiguredSize.getHeight());
        dest.writeInt(mIsDeferredConfig ? 1 : 0);
        dest.writeInt(mIsShared ? 1 : 0);
        dest.writeTypedList(mSurfaces);
        dest.writeString(mPhysicalCameraId);
        dest.writeInt(mIsMultiResolution ? 1 : 0); // New in Android 12
        dest.writeList(mSensorPixelModesUsed); // New in Android 12
    }

    private ArrayList<Surface> mSurfaces;
    private final int mRotation;
    private final int mSurfaceGroupId;
    private final int mSurfaceType;
    private final Size mConfiguredSize;
    private final int mConfiguredFormat;
    private final int mConfiguredDataspace;
    private final int mConfiguredGenerationId;
    private final boolean mIsDeferredConfig;
    private boolean mIsShared;
    private String mPhysicalCameraId;
    private boolean mIsMultiResolution; // New in Android 12
    private ArrayList<Integer> mSensorPixelModesUsed; // New in Android 12
}