ऐतिहासिक रूप से ये सादे टेक्स्ट XML फ़ाइलें होती थीं जिनमें इंडेंटेशन होता था, जिससे डेवलपर्स इन्हें आसानी से पढ़ पाते थे, हालाँकि [Android 12 में उस प्रारूप का नया बाइनरी संस्करण पेश किया गया, जिसमें कहा गया कि `system_server` द्वारा बिताए गए कुल समय का 1.5% इन XML ऑपरेशनों पर खर्च होता है](https://android.googlesource.com/platform/frameworks/base/+/4ccea8796991d678ead4399130ec31edf63ff4fa%5E%21/)

गौरतलब है कि यह प्रारूप केवल सिस्टम द्वारा आंतरिक रूप से उपयोग किया जाता है और इसमें मैजिक वैल्यू `"ABX\x00"` वाली फ़ाइलें होती हैं। यह [APK के अंदर उपयोग किए जाने वाले प्रारूप](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/libs/androidfw/ResourceTypes.cpp;l=1770;drc=d4e49e63519397789d284a03aea5fafc119cb1b0) से भिन्न है, जो `AndroidManifest.xml`, `res/xml/*.xml`, `res/layout/*.xml` आदि के लिए होता है और जिसमें कोई स्पष्ट "मैजिक वैल्यू" नहीं होती, हालाँकि यह आमतौर पर `0300 0800` से शुरू होता है (जो [हेडर](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/libs/androidfw/include/androidfw/ResourceTypes.h;l=608;drc=d4e49e63519397789d284a03aea5fafc119cb1b0) है जिसमें `type=RES_XML_TYPE` और `headerSize=8` होता है)

जब भी सिस्टम इन आंतरिक स्टेट XML फ़ाइलों में से किसी को पढ़ता है, तो वह [Binary XML फ़ाइल के लिए पार्सर या नियमित XML पार्सर चुनने के लिए फ़ाइल में `"ABX\0"` मैजिक वैल्यू का उपयोग करता है](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/util/Xml.java;l=188-192;drc=97a370a95275e79c69e79d7ead11aa38934a5575)। जब भी इन फ़ाइलों को Binary XML के रूप में सहेजा जाता है, यह [सिस्टम प्रॉपर्टी द्वारा नियंत्रित](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/util/Xml.java;drc=97a370a95275e79c69e79d7ead11aa38934a5575;l=74?q=Xml.java) होता है और डिफ़ॉल्ट रूप से सक्षम होता है

जब Binary XML फ़ाइलें उपयोग में होती हैं, तो आप उनकी सामग्री पढ़ सकते हैं, उदाहरण के लिए `adb shell su 0 abx2xml /data/system/packages.xml -` के माध्यम से

इस बाइनरी प्रारूप की एक खासियत यह है कि यह टाइप किए गए एक्सेसर्स प्रदान करता है, इसलिए सीरियलाइज़र `attributeInt(String namespace, String name, int value)` विधि प्रदान करता है, जो मान को बाइनरी इंटीजर के रूप में लिखता है, जिससे String के माध्यम से राउंड-ट्रिप से बचा जा सकता है जो नया आवंटन और उसके बाद गारबेज कलेक्शन के लिए ऑब्जेक्ट होता

एक अन्य प्रकार जिसे सीधे सीरियलाइज़ किया जा सकता है वह बाइट ऐरे है```java
@Override
public XmlSerializer attributeBytesBase64(String namespace, String name, byte[] value)
        throws IOException {
    if (namespace != null && !namespace.isEmpty()) throw illegalNamespace();
    mOut.writeByte(ATTRIBUTE | TYPE_BYTES_BASE64);
    mOut.writeInternedUTF(name);
    mOut.writeShort(value.length);
    mOut.write(value);
    return this;
}

<package name="com.android.settings" codePath="/system_ext/priv-app/Settings" ... sharedUserId="1000" ...>
  <sigs count="1" schemeVersion="3">
    <cert index="3" key="308204..." />
  </sigs>
  <proper-signing-keyset identifier="2" />
</package>
```
क्या हम `/data/app` में कहीं नया APK लिख सकते हैं (किसी अन्य `PackageInstallerSession` का उपयोग करके) और `packages.xml` में नया `<package>` तत्व जोड़ सकते हैं और इसे उस तरह इंस्टॉल करवा सकते हैं?

हाँ, हालाँकि हमें `<cert>` में अपने नए इंस्टॉल किए गए APK के मान्य हस्ताक्षर प्रदान करने होंगे और सिस्टम बूट के दौरान इसे APK फ़ाइल के विरुद्ध जाँचेगा

क्या हम `userId` विशेषता को अपनी इच्छित मान पर सेट कर सकते हैं (`sharedUserId` के बजाय, जो `AndroidManifest.xml` में `<manifest android:sharedUserId>` विशेषता के बिना APK को इंगित करता है)?

हाँ, हालाँकि हमें ऐसा मान उपयोग नहीं करना चाहिए जो पहले से किसी अन्य पैकेज या `sharedUserId` द्वारा उपयोग किया गया हो

क्या हम अपने ऐप के लिए `sharedUserId="1000"` सेट कर सकते हैं?

यदि हम ऐसा करते हैं, तो बूट के दौरान सिस्टम उस सेटिंग को [`canJoinSharedUserId()`](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/services/core/java/com/android/server/pm/PackageManagerServiceUtils.java;l=658-750;drc=7ec13b04c3bbaeac99cbbc4db9f9f80492c508fe) के माध्यम से मान्य करेगा

विशेष रूप से वह विधि [`checkCapability()`](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/content/pm/SigningDetails.java;l=613-637;drc=97a370a95275e79c69e79d7ead11aa38934a5575) का उपयोग यह जाँचने के लिए करेगी कि हस्ताक्षर या तो बिल्कुल मेल खाते हैं या एक तरफ का हस्ताक्षर दूसरी तरफ के पिछले हस्ताक्षरों में से किसी एक से मेल खाता है

ये "पिछले हस्ताक्षर" `packages.xml` से आते हैं, विशेष रूप से जब हमारे पास `<cert>` के साथ `<sigs>` तत्व होता है, तो हम [`SigningDetails.mPastSigningCertificates`](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/content/pm/SigningDetails.java;l=74-87;drc=97a370a95275e79c69e79d7ead11aa38934a5575) में नई प्रविष्टियाँ जोड़ने के लिए `<sigs>` के अंतर्गत `<pastSigs>` तत्व जोड़ सकते हैं

अंत में, हमारा छेड़छाड़ किया गया `<shared-user>` तत्व इस तरह दिखता है:```xml
<shared-user name="android.uid.system" userId="1000">
  <sigs count="1" schemeVersion="3">
    <cert index="3" />
    <pastSigs count="2" schemeVersion="3">
      <cert index="19" flags="2" />
      <cert index="19" flags="2" />
    </pastSigs>
  </sigs>
</shared-user>
```
`<cert>` तत्व को `<pastSigs>` के अंतर्गत दो बार डाला जाता है क्योंकि [अंतिम पिछला हस्ताक्षर वर्तमान माना जाता है और इसलिए उस पर विचार नहीं किया जाता](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/content/pm/SigningDetails.java;l=698-700;drc=97a370a95275e79c69e79d7ead11aa38934a5575)

[`flags="2"` का अर्थ है कि प्रमाणपत्र `sharedUserId` के लिए अनुमत है](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/content/pm/SigningDetails.java;l=102-103;drc=97a370a95275e79c69e79d7ead11aa38934a5575)

इसके अलावा, `<package sharedUserId="1000">` पंजीकरण उस ऐप पर लागू किया जाना चाहिए जो manifest में `android:sharedUserId="android.uid.system"` घोषित करता है, इसलिए यह उस APK से अलग होना चाहिए जो शोषण करता है

# नया इंस्टॉल किया गया system-uid ऐप शुरू होने में विफल रहता है

हालाँकि मैं `android:sharedUserId="android.uid.system"` के लिए विश्वसनीय नया प्रमाणपत्र पंजीकृत करने में सक्षम था, सामान्यतः उस प्रमाणपत्र के साथ हस्ताक्षरित और manifest में केवल `sharedUserId` घोषित करने वाला ऐप शुरू नहीं हो पाएगा। इसे लॉन्च करने पर हमें `logcat` में निम्न संदेश दिखाई देगा:```
signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
Abort message: 'JNI FatalError called: (com.example.abxoverflow.droppedapk) frameworks/base/core/jni/com_android_internal_os_Zygote.cpp:1976: selinux_android_setcontext(1000, 0, "default:privapp:targetSdkVersion=33:complete", "com.example.abxoverflow.droppedapk") failed'
```
ऐसा इसलिए है क्योंकि [`seapp_contexts` फ़ाइल](https://cs.android.com/android/platform/superproject/main/+/main:system/sepolicy/private/seapp_contexts) में कोई भी परिभाषा मेल नहीं खाई है

उस फ़ाइल में `user=` नियम [`uid` से मैप किया गया है](https://cs.android.com/android/platform/superproject/main/+/main:external/selinux/libselinux/src/android/android_seapp.c;l=819-833;drc=530165a996d8ca5ab5959c33bc040c78951bcb59) (`selinux_android_setcontext()` का पहला तर्क), हमारे मामले में यह `user=system` होगा, सामान्य ऐप्स के लिए यह `user=_app` है

मेल खाने वाली दूसरी चीज़ `seinfo=` नियम है, जो `selinux_android_setcontext()` के तीसरे तर्क से पहले कोलन तक लिया जाता है। मूल रूप से यह मान लॉन्च किए गए ऐप के हस्ताक्षर की तुलना `/system/etc/selinux/plat_mac_permissions.xml` में परिभाषित हस्ताक्षरों से करने पर प्राप्त होता है

अंत में हमारा ऐप `user=system seinfo=default` मिलाने का प्रयास करता है और `seapp_contexts` में ऐसा कोई नियम मौजूद नहीं है

हालाँकि, हमारे नए `android:sharedUserId="android.uid.system"` ऐप के लिए प्रोसेस शुरू नहीं किया जा सकता, फिर भी ऐप को मौजूदा प्रोसेस में लोड किया जा सकता है यदि इसे [`android:process` विशेषता](https://developer.android.com/guide/topics/manifest/application-element#proc) के माध्यम से निर्दिष्ट किया जाए। विशेष रूप से, `android.uid.system` के अंतर्गत चलने वाले ऐप `android:process="system"` निर्दिष्ट कर सकते हैं ताकि वे `system_server` में लोड हो सकें

# सिस्टम को क्रैश करना

सामान्य तौर पर [`system_server` का क्रैश ट्रिगर करने वाले ऐप को नगण्य सुरक्षा प्रभाव वाला बग माना जाता है](https://bughunters.google.com/learn/invalid-reports/android-platform/5148417640366080/bugs-with-negligible-security-impact#triggering-a-local-temporary-denial-of-service) और यहाँ यह केवल इसलिए उल्लेखनीय है क्योंकि यह एक्सप्लॉइट श्रृंखला का हिस्सा है जिसमें दो `system_server` रीस्टार्ट की आवश्यकता होती है

वैसे भी, हमारे पास `Parcelable` श्रृंखला है:

* [`IAlarmManager.set()` AIDL विधि `AlarmManager.AlarmClockInfo` स्वीकार करती है](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/apex/jobscheduler/framework/java/android/app/IAlarmManager.aidl;l=32-35;drc=ca41ed611ac9c6584c6d5c38ae8428b8e4f3b135)
* [`AlarmClockInfo` बिना प्रकार तर्क के deprecated `readParcelable()` को कॉल करता है](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/apex/jobscheduler/framework/java/android/app/AlarmManager.java;l=1598;drc=04bf84e220ade9d7ad8ef0b2f7e6ce6ec72841c8) (क्योंकि यह apex मॉड्यूल में है और इन्हें नई विधियों में स्विच नहीं किया गया था)
* मैं [`android.content.pm.PackageParser$Activity`](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/content/pm/PackageParser.java;l=8240;drc=7d3ffbae618e9e728644a96647ed709bf39ae759) को `Parcelable` क्लास के रूप में निर्दिष्ट करता हूँ
* उसे पढ़ने से [किसी भी सार्वजनिक कंस्ट्रक्टर का आह्वान होता है जो एकल `Parcel` तर्क स्वीकार करता है](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/content/pm/PackageParser.java;l=7789-7795;drc=7d3ffbae618e9e728644a96647ed709bf39ae759)
* मैं [`android.os.PooledStringWriter`, जो दिए गए `Parcel` पर `writeInt(0)` कॉल करता है](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/os/PooledStringWriter.java;l=55;drc=782d49826862cbdc9d020fc9d85f8a6f64675dcb) निर्दिष्ट करता हूँ
* वह `writeInt()` कॉल `Parcel` पर किया गया था जो [`onTransact()`](https://developer.android.com/reference/android/os/Binder#onTransact(int,%20android.os.Parcel,%20android.os.Parcel,%20int)) के `data` तर्क के रूप में प्राप्त हुआ था, जो `/dev/binder` से `mmap`-ed रीड-ओनली मेमोरी द्वारा समर्थित है। उस पर लिखने से `SIGSEGV` उत्पन्न होता है

उल्लेखनीय रूप से, [मैंने पिछली रिपोर्टों के हिस्से के रूप में `PackageParser`+`PooledStringWriter` संयोजन का उपयोग किया है, उदाहरण के लिए CVE-2023-21098 के लिए](https://github.com/michalbednarski/TheLastBundleMismatch)

# संपूर्ण प्रवाह

ऐप के भीतर "Do everything" बटन दबाते ही यही होता है

1. `RebootBackgroundRunner` एक अलग प्रोसेस के रूप में शुरू किया जाता है, जो अब केवल [`setsid()`](https://man7.org/linux/man-pages/man2/setsid.2.html) का उपयोग करके यूज़रस्पेस रीबूट से बचेगा और उसके बाद बैकग्राउंड में प्रतीक्षा करेगा
2. नया `PackageInstaller.Session` आवंटित किया जाता है और उसमें नया `Checksum` ऑब्जेक्ट जोड़ा जाता है। उस `Checksum` ऑब्जेक्ट में बाइट ऐरे होता है जिसका आकार सीरियलाइज़ेशन के दौरान इंटीजर ओवरफ्लो का कारण बनेगा और एक बार उसका डेटा वापस डी-सीरियलाइज़ हो जाने पर सिस्टम को ऐसे `PackageInstaller.Session`-s दिखेंगे जिनका डेटा पहले `Checksum` पेलोड था। विशेष रूप से, दो सत्र इंजेक्ट किए गए हैं
    * एक जिसमें `sessionStageDir="/data/system"` और `prepared="true"` है (अर्थात स्टेज निर्देशिका पहले से तैयार है और उसे बनाने की आवश्यकता नहीं है)
    * एक जिसमें `sessionStageDir="/data/app/dropped_apk"` और `prepared="false"` है (अर्थात यह निर्देशिका पहले `Session.openWrite()` पर बनाई जाएगी)
3. नया `PackageInstaller.Session` आवंटित किया जाता है और फिर तुरंत नष्ट कर दिया जाता है। यह सिस्टम को `install_sessions.xml` में अद्यतन सामग्री लिखने के लिए प्रेरित करता है
4. थोड़ी देरी के बाद, एक `system_server` क्रैश ट्रिगर किया जाता है
5. अगले `system_server` प्रारंभ के दौरान, `install_sessions.xml` फ़ाइल पढ़ी जाती है और अब हमारे द्वारा इंजेक्ट किए गए `PackageInstaller.Session`-s का उपयोग किया जा सकता है
6. `RebootBackgroundRunner` यूज़रस्पेस रीबूट के दौरान बैकग्राउंड में प्रतीक्षा कर रहा होता है और जैसे ही उसे पता चलता है कि सिस्टम वापस चालू और तैयार है, यह अगले चरण करता है
7. एक `PackageInstaller.Session` का उपयोग करके, नया APK assets से निकाला जाता है और `/data/app/dropped_apk/base.apk` में लिखा जाता है
8. दूसरे सत्र का उपयोग `/data/system/packages.xml` पढ़ने के लिए किया जाता है, उस फ़ाइल को पैच किया जाता है ताकि यह घोषित किया जा सके कि नया ड्रॉप किया गया APK पहले ही इंस्टॉल हो चुका है और इसके लिए उपयोग किया गया प्रमाणपत्र पहले `android:sharedUserId="android.uid.system"` के लिए उपयोग किया गया था और अभी भी उस उद्देश्य के लिए विश्वसनीय है। परिवर्तित फ़ाइल को `/data/system/packages-backup.xml` के रूप में लिखा जाता है
9. एक और `system_server` क्रैश ट्रिगर किया जाता है
10. जब स्टार्टअप के दौरान `system_server` `packages-backup.xml` देखता है, तो यह मूल `packages.xml` को दूषित मानता है और इसके बजाय बैकअप का उपयोग करता है
11. चूँकि सिस्टम ने संशोधित `packages.xml` पढ़ लिया है, अभी-अभी ड्रॉप किया गया ऐप मौजूद है और [`ACTION_BOOT_COMPLETED`](https://developer.android.com/reference/android/content/Intent#ACTION_BOOT_COMPLETED) से स्वयं को लॉन्च करता है। वह नया ऐप `system_server` के भीतर चलता है क्योंकि `AndroidManifest.xml` में `<manifest android:sharedUserId="android.uid.system">` और `<application android:process="system">` है

# `utils/` में स्क्रिप्ट्स

PoC ऐप के साथ `utils` निर्देशिका भी है जिसमें कुछ स्क्रिप्ट्स हैं

* `moveapk.sh` संकलित APK को ड्रॉपर के `assets` में डालने के लिए ले जाता है, इसे `gradle :droppedapk:assembleRelease` के बाद चलाया जाना है
* `peeksessions.sh` `install_sessions.xml` की वर्तमान सामग्री देखने की अनुमति देता है (Android के `eng`/`userdebug` बिल्ड की आवश्यकता है)
* `wipesessions.sh` मौजूद किसी भी `PackageInstaller.Session`-s को हटाता है और सिस्टम को पुनरारंभ करता है (Android के `eng`/`userdebug` बिल्ड की आवश्यकता है)

# ट्रिविया

निश्चित नहीं है कि यह संबंधित है, लेकिन संभावित ABX-संबंधित बगों के इतिहास (`cd frameworks/base ; git log -S ABX`) को देखते हुए मुझे ["Stop processing on IOException" कमिट](https://android.googlesource.com/platform/frameworks/base/+/5112cfef2a2023a2629a426154547444593e9f9b%5E!/) मिला, जिसमें **ट्रंकेटेड ABX फ़ाइल के साथ यूनिट टेस्ट का जोड़ शामिल है**। वह कमिट ["Ignore malformed shortcuts"](https://android.googlesource.com/platform/frameworks/base/+/d5122bfaf18f1503e73c1a3a177a56d0f604a008%5E%21/) का अनुवर्ती था, जिसे [बुलेटिन में DoS के रूप में वर्णित किया गया था](https://source.android.com/docs/security/bulletin/2022-12-01#framework)