Android Security AutoRepro

AutoRepro Gradle प्लगिन को Android Trade Federation टेस्ट हार्नेस के आधार पर बनाया गया है. इसका इस्तेमाल, Android Security Bulletin में मौजूद कमियों के ख़िलाफ़ सुरक्षा पैच की जांच करने के लिए, सभी Android डिवाइसों पर किया जाता है. ये टेस्ट सिर्फ़ उन सुधारों के लिए हैं जो सामान्य जोखिम की आशंका और एक्सपोज़र (सीवीई) से जुड़े हैं या जुड़ेंगे.

इस प्लगिन की मदद से, Android Studio या स्टैंडर्ड Android SDK का इस्तेमाल करके, Android सोर्स ट्री के बाहर Tradefed टेस्ट डेवलप किए जा सकते हैं. इसमें Tradefed टेस्ट को बनाने और चलाने के लिए ज़रूरी सभी यूटिलिटी शामिल हैं.

इसका इस्तेमाल मुख्य रूप से, Android Vulnerability Rewards Program के लिए, अपने-आप दोहराए जा सकने वाले कॉन्सेप्ट के सबूत सबमिट करने के लिए किया जाता है.

Direct Download AutoRepro Example download

ऑटोरेप्रो के उदाहरण और टेंप्लेट ब्राउज़ करें open_in_new

ज़रूरी शर्तें

यहां 64-बिट Linux पीसी के लिए निर्देश दिए गए हैं.

• Android Studio Ladybug या नया वर्शन - इसे डिस्ट्रो के पैकेज मैनेजर से भी इंस्टॉल किया जा सकता है.
• Android SDK प्लैटफ़ॉर्म टूल (adb, fastboot) - इन्हें इंस्टॉल करना होगा और ये आपके $PATH में होने चाहिए. इसका मतलब है कि आपको कमांड लाइन से adb को चलाने की अनुमति होनी चाहिए. प्लैटफ़ॉर्म टूल इंस्टॉल करने का सबसे आसान तरीका है, अपने डिस्ट्रो के पैकेज मैनेजर का इस्तेमाल करना.
  • अगर स्टैंडअलोन प्लैटफ़ॉर्म टूल के बजाय Android Studio के एसडीके मैनेजर का इस्तेमाल किया जा रहा है, तो कमांड-लाइन डेवलपमेंट के लिए, एसडीके की platform-tools डायरेक्ट्री को अपनी $PATH में जोड़ना न भूलें.
• AAPT2. - इसे डिस्ट्रो के पैकेज मैनेजर का इस्तेमाल करके भी इंस्टॉल किया जा सकता है.
• Java JDK 21 या इसके बाद का वर्शन - Android SDK और Gradle के साथ काम करता है.

Android Studio का इस्तेमाल शुरू करना

उदाहरण या टेंप्लेट को निकालने के बाद, डायरेक्ट्री को Android Studio में मौजूदा प्रोजेक्ट के तौर पर खोलें. इसके बाद, Gradle सिंक होने का इंतज़ार करें. Android Studio में, पहले से कॉन्फ़िगर किए गए कई रन कॉन्फ़िगरेशन होते हैं.

Gradle टास्क:

• assembleSubmissionSources - सबमिट करने के लिए, सोर्स फ़ाइलों को zip फ़ाइल में इकट्ठा करें.
• assembleSubmissionZip - अपलोड करने के लिए, सबमिशन की ज़िप फ़ाइल बनाएं.
• copyInvocationResultsToSubmission - समीक्षा की प्रोसेस में मदद करने के लिए, पिछले Tradefed invocations के नतीजों को AutoRepro submission sources डायरेक्ट्री में कॉपी करें. ध्यान दें कि इसमें होस्ट और डिवाइस, दोनों के लॉग शामिल होते हैं. इसलिए, इसे चलाने से पहले या बाद में, इसके कॉन्टेंट की समीक्षा करें.

Android Studio के रन कॉन्फ़िगरेशन में AutoRepro को इस तरह से शुरू किया जा सकता है:

• autorepro_nonroot_arm64
• autorepro_nonroot_x86_64
• autorepro_root_arm64
• autorepro_root_x86_64

लॉन्चर कॉन्फ़िगरेशन, autorepro_{device_root}_{device_arch} के फ़ॉर्म में होते हैं. आम तौर पर, नॉनरूट का इस्तेमाल करना बेहतर होता है, क्योंकि रूट की ज़रूरत वाली कमज़ोरियां कम गंभीर होती हैं. हालांकि, सेटअप या क्लीनअप करने के लिए रूट का इस्तेमाल किया जा सकता है. इसके लिए, यह ज़रूरी है कि इसे साफ़ तौर पर दस्तावेज़ में शामिल किया गया हो और इसे आम तौर पर मान्य नॉनरूट स्टेट के तौर पर स्वीकार किया जाता हो. उदाहरण के लिए, डिवाइस पर नकली मैसेज भेजने के लिए रूट का इस्तेमाल किया जा सकता है. इससे दूसरे डिवाइस और कई सिम कार्ड की ज़रूरत नहीं पड़ती.

इनसे आपकी जांच के लिए Tradefed लॉन्च हो जाएगा. Tradefed, कनेक्ट किए जाने के लिए किसी मान्य डिवाइस का इंतज़ार करता है. इसलिए, पक्का करें कि कोई डिवाइस कनेक्ट हो और ADB डीबग करने की अनुमति मिली हो.

कोडिंग एजेंट के साथ इंटिग्रेशन

उदाहरण और टेंप्लेट में, AGENTS.md कॉन्टेक्स्ट फ़ाइल दी गई है. यह Android Studio में Gemini, Gemini CLI, और अन्य कोडिंग एजेंट के साथ काम करती है. इसमें सबमिट किए गए कॉन्टेंट को स्ट्रक्चर करने के बारे में राय दी गई है. साथ ही, AutoRepro का इस्तेमाल करने के निर्देश दिए गए हैं. इसका इस्तेमाल इन कामों के लिए किया जा सकता है:

• अपने डिवाइस के लिए, AutoRepro को अपने-आप चलने की अनुमति देना
• मौजूदा सबमिशन की कोड समीक्षा करें, ताकि ऐसे बदलाव किए जा सकें जिनसे आपकी रिपोर्ट को तेज़ी से स्वीकार किया जा सके
• कमज़ोरी के बारे में दी गई जानकारी के आधार पर, नया PoC बनाने में मदद करो

AutoRepro टेस्ट लिखना

AutoRepro टेस्ट के तीन हिस्से होते हैं. साथ ही, इनसे जुड़े तीन Gradle प्लगिन होते हैं:

1. Gradle प्लगिन id("com.android.security.autorepro.javahosttest") यह एक ऐसा Tradefed टेस्ट है जो होस्ट-साइड पर होता है. यह ADB के ज़रिए डिवाइस से इंटरैक्ट करता है. इस उदाहरण में, इसका इस्तेमाल submission/hostTest/ डायरेक्ट्री में किया गया है.
2. Gradle प्लगिन id("com.android.security.autorepro.apptest") यह एक ऐप्लिकेशन या सेवा का APK होता है. इसे adb install के ज़रिए डिवाइस पर इंस्टॉल किया जाता है. साथ ही, इसे होस्ट-साइड टेस्ट लॉन्च करता है. ऐप्लिकेशन या सेवा में, JUnit के अपने दावे भी शामिल हो सकते हैं. इनकी जानकारी होस्ट-साइड रनर को दी जाती है. इस उदाहरण में, इसका इस्तेमाल submission/appTest/ और डायरेक्ट्री में किया गया है.
3. Gradle प्लगिन id("com.android.security.autorepro.ndktest") यह एक वैकल्पिक एनडीके-आधारित कॉन्सेप्ट का सबूत देने वाला हमला है. इसे adb push के ज़रिए डिवाइस पर पुश किया जाता है और होस्ट-साइड टेस्ट के ज़रिए लागू किया जाता है. उदाहरण में, इसका इस्तेमाल submission/ndkTest/ डायरेक्ट्री में किया गया है.

आम तौर पर, AutoRepro टेस्ट फ़्लो में इनमें से कोई एक पैटर्न होता है:

• इंस्ट्रुमेंट किया गया टेस्ट ऐप्लिकेशन:

  1. होस्ट-साइड टेस्ट, डिवाइस पर इंस्ट्रुमेंट किए गए ऐप्लिकेशन या सेवा वाला APK पुश करता है.
  2. होस्ट-साइड टेस्ट, डिवाइस-साइड JUnit टेस्ट शुरू करता है. यह टेस्ट, runDeviceTest() के ज़रिए APK के साथ बंडल किया जाता है.
  3. डिवाइस पर JUnit टेस्ट, बटन टैप करते हैं और UIAutomator का इस्तेमाल करके ऐप्लिकेशन देखते हैं. इसके अलावा, वे Android API को ऐसे तरीकों से ऐक्सेस करते हैं जिनसे सुरक्षा से जुड़ी कमज़ोरियों का पता चलता है.
  4. डिवाइस-साइड JUnit टेस्ट के पास या फ़ेल होने की जानकारी, होस्ट-साइड टेस्ट को भेजी जाती है. इसका इस्तेमाल यह तय करने के लिए किया जा सकता है कि टेस्ट पास हुआ या नहीं. गड़बड़ी के मैसेज में इस बारे में पूरी जानकारी होनी चाहिए कि पुष्टि क्यों नहीं हो सकी. साथ ही, इसमें किसी खास ऑब्जेक्ट, वैल्यू, अपवाद, स्टैकट्रेस या अन्य आर्टफ़ैक्ट के बारे में भी जानकारी होनी चाहिए, ताकि यह साबित किया जा सके कि गड़बड़ी हुई है.

• एनडीके का कॉन्सेप्ट टेस्ट:

  1. होस्ट-साइड टेस्ट, डिवाइस पर Linux एक्ज़ीक्यूटेबल को पुश और लॉन्च करता है.
  2. नेटिव प्रोग्राम क्रैश हो जाता है या कोई खास एक्ज़िट कोड दिखाता है.
  3. होस्ट-साइड टेस्ट, क्रैश की जांच करता है. साथ ही, logcat बैकट्रैक की जांच करता है या किसी खास एक्ज़िट कोड की जांच करता है, ताकि यह पता लगाया जा सके कि हमला सफल हुआ है या नहीं. गड़बड़ी के मैसेज में इस बारे में पूरी जानकारी होनी चाहिए कि पुष्टि क्यों नहीं हो सकी. साथ ही, इसमें किसी खास स्ट्रक्चर, वैल्यू, स्टैकट्रेस या अन्य आर्टफ़ैक्ट को शामिल किया जाना चाहिए, ताकि यह साबित किया जा सके कि गड़बड़ी की वजह से सुरक्षा से जुड़ी समस्या हुई है.

दोनों पैटर्न को मिलाकर भी इस्तेमाल किया जा सकता है. उदाहरण के लिए, डिवाइस-साइड टेस्ट के साथ-साथ नेटिव प्रोग्राम को भी चलाया जा सकता है. frida-inject जैसे कुछ अन्य इंस्ट्रूमेंटेशन फ़्रेमवर्क भी उपलब्ध हैं. ज़्यादा जानकारी के लिए, Security Test Suite के रेफ़रंस दस्तावेज़ और Tradefed के रेफ़रंस दस्तावेज़ देखें.

प्रूफ़-ऑफ़-कॉन्सेप्ट की पुष्टि करने के लिए स्ट्रक्चर बनाना

अच्छी क्वालिटी वाले PoC में, सिर्फ़ बग को ट्रिगर करने के अलावा और भी चीज़ें होनी चाहिए. इसमें यह पुष्टि करने वाला सबूत होना चाहिए कि सुरक्षा सीमा का उल्लंघन हुआ है. ऐसा करने के लिए, PoC इन तीन चरणों वाले "पहले फ़ेल होना, फिर सफल होना" पैटर्न का पालन कर सकते हैं:

1. सेटअप: ज़रूरी ऐप्लिकेशन इंस्टॉल करके, फ़ाइलें पुश करके, और यह पक्का करके डिवाइस को तैयार करें कि डिवाइस, एक्सप्लॉइट से ठीक पहले ज़रूरी स्थिति में हो. (अगर रूट का इस्तेमाल करना ज़रूरी हो और यह असली उपयोगकर्ता की स्थिति को दिखाता हो, तो कॉन्फ़िगरेशन के लिए रूट का इस्तेमाल करने की अनुमति है).
2. सीमा साबित करें: जोखिम को ट्रिगर करने से पहले, टारगेट की गई कार्रवाई करें और पुष्टि करें कि वह कार्रवाई पूरी नहीं हुई. उदाहरण के लिए, अगर किसी एक्सप्लॉइट से सुरक्षित फ़ाइल को पढ़ा जा सकता है, तो आपको पहले उसे पढ़ने की कोशिश करनी चाहिए. साथ ही, यह पुष्टि करनी चाहिए कि आपको "अनुमति नहीं है" गड़बड़ी का मैसेज मिला हो.
3. ट्रिगर और पुष्टि करें: जोखिम को ट्रिगर करें. इसके बाद, दूसरे चरण में की गई कार्रवाई को तुरंत दोहराएं. अब इस कार्रवाई को, सुरक्षा से जुड़ी समस्या वाले डिवाइस पर पूरा किया जा सकता है. इसकी पुष्टि करने के लिए, आपको ऐसे दावे का इस्तेमाल करना होगा जो सुरक्षा से जुड़ी कमियों वाले डिवाइस पर काम नहीं करता. साथ ही, इस दावे का मैसेज AUTOREPRO_VULNERABILITY_PROVEN: प्रीफ़िक्स से शुरू होना चाहिए. इस मैसेज में, सुरक्षा से जुड़ी समस्या के बारे में कम शब्दों में जानकारी दी जानी चाहिए. साथ ही, कैप्चर किए गए किसी भी आर्टफ़ैक्ट (जैसे कि लीक हुआ डेटा या अनचाही स्थितियां) के बारे में जानकारी दी जानी चाहिए, ताकि यह साबित किया जा सके कि समस्या का फ़ायदा उठाया गया है.

उदाहरण:

@Test
public void testPoc() throws Exception {
    // 1. Setup: Prepare the device.
    setup();

    // 2. Prove the Boundary: Assert the resource is protected BEFORE the exploit.
    // This passes on all devices (safe or vulnerable) before the trigger runs.
    assertDeviceIsSecure();

    // 3. Trigger & Verify: Execute the exploit logic, then immediately repeat
    // the action from Step 2. On a vulnerable device, this action should now
    // succeed, causing assertDeviceIsSecure() to fail with an
    // AUTOREPRO_VULNERABILITY_PROVEN message.
    triggerExploit();
    assertDeviceIsSecure();
}

private void assertDeviceIsSecure() {
    try {
        String content = readProtectedFile();

        // Where possible, put the content in the assertion message.
        // Start the assertion message with "AUTOREPRO_VULNERABILITY_PROVEN:".
        Assert.fail("AUTOREPRO_VULNERABILITY_PROVEN: Successfully read protected file. Content: '" + content + "'");
    } catch (ThisVulnSpecificException e) {
        Log.i(TAG, "protected against reading protected file", e);
    }
}

मेरे कॉन्सेप्ट की पुष्टि करने वाले हमले के लिए, टेस्ट ऐप्लिकेशन या नेटिव एक्ज़ीक्यूटेबल की ज़रूरत नहीं है

ज़्यादातर टेस्ट के लिए, डिवाइस-साइड ऐप्लिकेशन और नेटिव एक्ज़ीक्यूटेबल, दोनों की ज़रूरत नहीं होगी.

अगर आपके टेस्ट में किसी सुविधा का इस्तेमाल नहीं किया जा रहा है, तो गैर-ज़रूरी gradle सबप्रोजेक्ट डायरेक्ट्री मिटाएं.

मेरे कॉन्सेप्ट के सबूत के तौर पर किए गए हमले में, किसी दूसरे ऐप्लिकेशन या सेवा का इस्तेमाल किया गया है

AutoRepro प्लगिन की मदद से, जितने चाहें उतने Gradle सबप्रोजेक्ट जोड़ें.

AutoRepro टेस्ट सबमिट करना

अपने डिवाइस से टेस्ट के नतीजों को सबमिट किए गए डेटा में शामिल करने के लिए:

• ज़रूरी नहीं: पुराने टेस्ट रन मिटाने के लिए, Gradle clean टास्क चलाएं.
• अपने टेस्ट के लिए Tradefed को शुरू करने के लिए, AutoRepro का सही रन कॉन्फ़िगरेशन चलाएं. साथ ही, लॉग और नतीजे इकट्ठा करें.
• लॉग और नतीजों को सबमिशन सोर्स डायरेक्ट्री में कॉपी करने के लिए, copyInvocationResultsToSubmission टास्क चलाएं.

submission/build/autorepro-submission.zip फ़ाइल बनाने के लिए, assembleSubmissionZip चलाएं. इस फ़ाइल को Android Vulnerability Reward Program में सबमिट की गई अपनी रिपोर्ट के साथ अपलोड करें. पक्का करें कि अटैचमेंट, *autorepro-submission*.zip पैटर्न से मेल खाता हो और इसे शुरुआती रिपोर्ट के साथ अपलोड किया गया हो. समय पर सबमिट न करने से, आपकी रिपोर्ट की सही तरीके से समीक्षा करने की हमारी क्षमता पर असर पड़ेगा.