TransitionPlayer

تم إصلاح هذه المشكلة لنظام Android 14+ في [نشرة أمان Android لشهر يونيو 2026](https://source.android.com/docs/security/bulletin/2026/2026-06-01). [اضغط هنا لرؤية التصحيح](https://android.googlesource.com/platform/frameworks/base/+/40c30bb5613ee94403723b37d0d6c58197d3d1b4)

## شرح
~~TODO~~

~~سأكمل الشرح عندما أحصل على القليل من وقت الفراغ~~

~~ولكن قبل ذلك، يجب أن أحارب الأعمال المدرسية والامتحانات~~

قررت إكمال القسم قبل انتهاء الامتحانات

حظاً موفقاً لي 😇

### مقدمة إلى IApplicationThread
[`IApplicationThread`](https://cs.android.com/android/platform/superproject/+/android-16.0.0_r1:frameworks/base/core/java/android/app/IApplicationThread.aidl) هو رد اتصال خاص يُقدم من التطبيقات للنظام، بحيث يمكن للنظام استخدامه لإرسال الأوامر (تحميل تطبيق معين، إخطار بتغييرات دورة حياة المكون، إلخ) إلى التطبيق

من المفترض أن يكون قابلاً للاستخدام فقط من قبل النظام، [لذلك لا توجد فحوصات أذونات](https://cs.android.com/android/platform/superproject/+/android-16.0.0_r1:frameworks/base/core/java/android/app/ActivityThread.java;l=1143)، ويتم ضمان الأمان فقط من خلال حقيقة أن الكائن لا يتم الحصول عليه بواسطة عملية ضارة. هذا يشبه إلى حد ما مفهوم "الكوكيز" أو "الرموز" في الويب. يسمى نموذج التحكم في الوصول هذا [الأمان القائم على الإمكانيات](https://en.wikipedia.org/wiki/Capability-based_security)

إذا تمكن شخص آخر من الحصول على `IApplicationThread` من عمليات أخرى، فيمكنه إرسال أوامر عشوائية وسيقوم التطبيق الضحية بمعالجتها كما لو كانت صادرة عن النظام. في [استغلال سابق لـ CVE-2022-20452](https://github.com/michalbednarski/LeakValue) تم استخدام الحيلة لتنفيذ تعليمات برمجية عشوائية

### RemoteTransition
بينما يجب تمرير `IApplicationThread` فقط إلى عملية النظام، يمكن إرساله بشكل غير متوقع خارج `system_server`

لن يقوم أحد بتنفيذ واجهة برمجة تطبيقات `getIApplicationThreadForApp(String packageName)` معروضة لأي شخص، فهذا انتهاك أمني واضح

ولكن إذا تم تغليف `IApplicationThread` داخل كائن آخر وتم إرسال كائن الغلاف الخارجي، فهذا سيناريو أكثر احتمالية

[`RemoteTransition`](https://cs.android.com/android/platform/superproject/+/android-16.0.0_r1:frameworks/base/core/java/android/window/RemoteTransition.java;l=36;bpv=0) هو مثل هذا الغلاف الذي يحتوي على `IApplicationThread` من أجل رفع أولوية التطبيق الذي يقوم بتشغيل رسم متحرك

أحد مستخدمي هذه الواجهة هو Launcher3، تطبيق الشاشة الرئيسية الافتراضي على AOSP وأجهزة Pixel، والذي [ينشئ `ActivityOptions` باستخدام `RemoteTransition`](https://cs.android.com/android/platform/superproject/+/android-16.0.0_r1:packages/apps/Launcher3/quickstep/src/com/android/launcher3/QuickstepTransitionManager.java;l=358) ثم يمرره إلى `startActivity()`

بينما لا يعرض Launcher3 نفسه الكائن لعوامل غير موثوقة، فإن `system_server` يفعل ذلك أحيانًا

حدث [CVE-2022-20419](https://android.googlesource.com/platform/frameworks/base/+/e5dd8be748c76c11615050c610dfc1fae73ad4a4) لأن `system_server` أعاد توجيه `ActivityOptions` التي مررها المتصل إلى التطبيق الذي تم إطلاقه لكنه نسي إزالة `RemoteTransition`، مما سمح للتطبيق الذي تم إطلاقه باستلامه وتحميل تعليمات برمجية عشوائية داخل عملية المشغل

### TransitionPlayer
أثناء الرسوم المتحركة لانتقال العناصر المشتركة، يجب القيام بالكثير من العمل ويجب أن تحدث اتصالات بين `WMCore` و`WMShell`، حيث يعني `WM` مدير النوافذ

يمكنك قراءة [هذه المقالة](https://cs.android.com/android/platform/superproject/+/android-16.0.0_r1:frameworks/base/libs/WindowManager/Shell/src/com/android/wm/shell/docs/overview.md) لفهم `WMShell`

نظرًا لأن `WMCore` و`WMShell` يعملان في عمليات مختلفة (`WMCore` يعمل في `system_server` و`WMShell` يعمل في SystemUI)، فإنهما يستخدمان آلية Binder للتواصل مع بعضهما البعض

كشف `WMCore` عن [واجهة برمجة تطبيقات Binder `registerTransitionPlayer`](https://cs.android.com/android/platform/superproject/+/android-16.0.0_r1:frameworks/base/core/java/android/window/IWindowOrganizerController.aidl;l=88) و[يستخدمها `WMShell` لتسجيل Binder الخاص به](https://cs.android.com/android/platform/superproject/+/android-16.0.0_r1:frameworks/base/libs/WindowManager/Shell/src/com/android/wm/shell/transition/Transitions.java;l=396)

عند بدء الرسم المتحرك، يستدعي `WMCore` `requestStartTransition` و[يتم تمرير `TransitionRequestInfo`](https://cs.android.com/android/platform/superproject/+/android-16.0.0_r1:frameworks/base/core/java/android/window/TransitionRequestInfo.java;l=53;bpv=0) إلى البعيد، [والذي يتضمن `RemoteTransition` الأولي](https://cs.android.com/android/platform/superproject/+/android-16.0.0_r1:frameworks/base/services/core/java/com/android/server/wm/TransitionController.java;l=853)

لذا إذا تمكنا من استبدال مشغل الانتقال، سنتمكن من استرداد `IApplicationThread` الخاص بـ Launcher وتحقيق تنفيذ تعليمات برمجية عشوائية داخل عملية متميزة

ومع ذلك، [فإن `registerTransitionPlayer` محمي بإذن `MANAGE_ACTIVITY_TASKS`](https://cs.android.com/android/platform/superproject/+/android-16.0.0_r1:frameworks/base/services/core/java/com/android/server/wm/WindowOrganizerController.java;l=2343) الذي لا يمكن لتطبيق طرف ثالث الحصول عليه

ولكن يمكن لـ `adb shell` أيضًا تشغيل كود مستخدم غير موثوق، و[يتم منح shell إذن `MANAGE_ACTIVITY_TASKS`](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/base/packages/Shell/AndroidManifest.xml;l=287)، لذا لحسن الحظ يمكننا شن هجوم من adb shell

### التأثير
إنه سؤال مضحك حول ما يمكن للمهاجمين فعله من خلال هذه الثغرة

نظرًا لأن معظم الأذونات الممنوحة لـ Launcher يمتلكها أيضًا adb shell، فإن المهاجمين الذين يمكنهم بالفعل تنفيذ تعليمات برمجية تحت هوية shell لا يحتاجون إلى استغلال هذه الثغرة لاختراق الجهاز

هذا更像 مثال تعليمي لتعلم `IApplicationThread` بدلاً من استغلال يمكن استخدامه بواسطة تطبيق ضار

ومع ذلك، قد يظل شخص ما مهتمًا بهذا

على سبيل المثال، يمكن استخدام هذا لاستخراج الملفات الخاصة لـ Launcher، والتي يمكن أن تكون مفيدة في التحليل الجنائي لتطبيقات Launcher الضارة دون تجذير الجهاز. سابقًا [تم تحقيق ذلك عن طريق استغلال CVE-2024-31317](https://mp.weixin.qq.com/s/LWKjGgrtMNo9JwKV_kt17Q)، ويكشف اكتشافي طريقة أخرى بعد إصلاح الطريقة السابقة

يسمح هذا أيضًا للمستخدمين باستخدام [تراكب موارد وقت التشغيل المُصنّع (FRRO)](https://developer.android.com/reference/kotlin/android/content/om/FabricatedOverlay) دون تجذير أجهزتهم أولاً، لذا [تعود السمات المخصصة بدون جذر](https://www.xda-developers.com/android-12s-fabricated-overlay-api-brings-back-rootless-themes/) بعد إصلاح [CVE-2021-39630](https://android.googlesource.com/platform/frameworks/base/+/b2dc041a4e84986e3a6932b127d3a18ef02b6d0a). أثبت استغلالي ذلك عن طريق [تعيين `android:integer/config_multiuserMaximumUsers` إلى 100](https://github.com/canyie/TransitionPlayer/blob/main/app/src/main/java/top/canyie/transitionplayer/ShellCodeReceiver.java#L68)

بالإضافة إلى ذلك، [يستضيف Launcher أيضًا مكون شاشة الأخيرة بشكل افتراضي](https://cs.android.com/android/platform/superproject/+/android-16.0.0_r1:frameworks/base/core/res/res/values/config.xml;l=3748-3754) وبالتالي فهو مدرج في القائمة البيضاء لبعض الإجراءات المميزة. أعتقد أن Launcher [مسموح له ببدء أي نشاط في مهمة موجودة بغض النظر عن إعدادات التصدير/الأذونات للأنشطة التي تم إطلاقها](https://cs.android.com/android/platform/superproject/+/android-16.0.0_r1:frameworks/base/services/core/java/com/android/server/wm/ActivityTaskSupervisor.java;l=1172-1180) والتي قد تكون مرغوبة [من قبل بعض تطبيقات أدوات إدارة الأجهزة](https://github.com/MuntashirAkon/AppManager/commit/bcbd6b2e1dd7360df3127084a9f5056aeabc2dcf)، على الرغم من أنني لم أختبرها بنفسي

## اختبار
قم ببناء المشروع، وقم بتثبيت ملف apk المُنشأ (إذا كنت تستخدم زر التشغيل داخل Android Studio، فقم بتشغيل "Always install with package manager")

قم بتشغيل الأمر التالي على الكمبيوتر
```shell
adb shell app_process '-Djava.class.path=$(pm path top.canyie.transitionplayer | cut -c9-) /system/bin top.canyie.transitionplayer.Main'
```
ثم قم بتشغيل أي تطبيق عن طريق النقر على أيقونته من المشغل

يجب إرسال إشعار من تطبيق المشغل، وإذا كنت على Android 14+، فسيتم حقن تراكب مصنّع في النظام، لذا يجب أن يعيد `adb shell cmd overlay lookup android android:integer/config_multiuserMaximumUsers` القيمة 100

## الإصلاحات
- [تم إعادة هيكلة آلية تفويض الرسوم المتحركة ولم يعد يتم إرسال مقبض IApplicationThread خارج WindowManagerService](https://android.googlesource.com/platform/frameworks/base/+/40c30bb5613ee94403723b37d0d6c58197d3d1b4)
- بدءًا من Android 17، [سيتم رفض الاستدعاء إلى IApplicationThread إذا كان من غير النظام](https://cs.android.com/android/_/android/platform/frameworks/base/+/3a9b1c451a0d4a2e5cea997364ecba98912f85fb). لا أعتقد أنها طريقة فعالة للتخفيف من مثل هذه الاستغلالات لأنني أعتقد أن المهاجمين يمكنهم خداع ActivityManagerService لإجراء استدعاءات بمسار apk يتحكم فيه المهاجم إلى العملية المستهدفة (على الرغم من أنني لم أختبرها بنفسي)، لكنها إشارة إلى أن فريق أمان Android بدأ في اتخاذ إجراءات