ميزة AutoRepro لأمان Android

تم إنشاء المكوّن الإضافي AutoRepro Gradle استنادًا إلى مفعِّل اختبار Android Trade Federation لاختبار جميع أجهزة Android بحثًا عن اختبارات رمز تصحيح الأمان ضد الثغرات الأمنية في نشرة أمان Android. تُجرى هذه الاختبارات حصريًا للإصلاحات المرتبطة أو التي سيتم ربطها بـ "الثغرات الأمنية الشائعة والتعرّض لها" (CVE).

يسمح المكوّن الإضافي بتطوير اختبارات Tradefed خارج شجرة مصدر Android باستخدام "استوديو Android" أو حزمة Android SDK العادية. ويتضمّن جميع الأدوات المساعدة اللازمة لإنشاء اختبار Tradefed وتشغيله.

يُستخدم هذا المكوّن الإضافي في المقام الأول لإرسال إثباتات جدوى قابلة للتكرار تلقائيًا لـ برنامج مكافآت Android للمبلّغين عن الثغرات الأمنية.

Direct Download AutoRepro Example download

Browse AutoRepro Example and Templates open_in_new

المتطلبات الأساسية

يتم تقديم التعليمات لجهاز كمبيوتر Linux بنظام 64 بت.

• "استوديو Android" إصدار Ladybug أو إصدار أحدث - يمكن أيضًا تثبيته من مدير الحِزم في التوزيعة.
• أدوات منصة Android SDK (adb وfastboot) - يجب تثبيتها وإضافتها إلى $PATH (أي يجب أن تتمكّن من تشغيل adb من سطر الأوامر). أسهل طريقة لتثبيت أدوات المنصة هي استخدام مدير الحِزم في التوزيعة.
  • إذا كنت تستخدم مدير حزمة SDK في "استوديو Android" بدلاً من أدوات المنصة المستقلة ، تذكَّر إضافة دليل platform-tools لحزمة SDK إلى $PATH لتطوير سطر الأوامر.
• AAPT2. - يمكن أيضًا تثبيته باستخدام مدير الحِزم في التوزيعة
• Java JDK 21 أو إصدار أحدث - متوافق مع Android SDK وGradle

بدء استخدام "استوديو Android"

بعد استخراج المثال أو النموذج، افتح الدليل في "استوديو Android" كمشروع حالي وانتظر اكتمال مزامنة Gradle. تتوفّر عدة إعدادات تشغيل تم ضبطها مسبقًا في "استوديو Android".

مهام Gradle:

• assembleSubmissionSources - تجميع ملفات المصدر لملف ZIP الذي سيتم إرساله
• assembleSubmissionZip - تجميع ملف ZIP الذي سيتم إرساله لتحميله
• copyInvocationResultsToSubmission - نسخ النتائج من عمليات استدعاء Tradefed السابقة إلى دليل مصادر الإرسال في AutoRepro للمساعدة في عملية المراجعة يُرجى العِلم أنّ هذا الدليل يحتوي على سجلّات من كلٍّ من المضيف والجهاز، لذا راجِع المحتويات قبل تشغيل هذا الأمر أو بعده.

إعدادات تشغيل "استوديو Android" لاستدعاء AutoRepro:

• autorepro_nonroot_arm64
• autorepro_nonroot_x86_64
• autorepro_root_arm64
• autorepro_root_x86_64

تكون إعدادات مشغّل التطبيقات على شكل autorepro_{device_root}_{device_arch}. من الأفضل عمومًا استخدام nonroot لأنّ الثغرات الأمنية التي تتطلّب الوصول إلى الجذر تكون أقل خطورة. ومع ذلك، يمكن أن يكون استخدام الجذر لإجراء عملية الإعداد أو التنظيف مقبولاً طالما تم توثيقه بوضوح وكان مقبولاً عمومًا كحالة nonroot صالحة. على سبيل المثال، من المقبول استخدام الجذر لإرسال رسائل نصية مزيّفة إلى الجهاز لتجنُّب الحاجة إلى جهاز ثانٍ وشرائح SIM متعددة.

سيؤدي ذلك إلى تشغيل Tradefed لاختبارك. ينتظر Tradefed توصيل جهاز صالح، لذا تأكَّد من توصيل جهاز ومنح الإذن بتصحيح أخطاء ADB.

التكامل مع وكلاء الترميز

يوفّر المثال والنماذج ملف سياق AGENTS.md متوافقًا مع Gemini في "استوديو Android" وGemini CLI ووكلاء الترميز الآخرين. ويتضمّن هذا الملف محتوى يتضمّن آراء حول تنظيم ملف الإرسال وتعليمات حول استخدام AutoRepro. يمكنك استخدام هذا الملف لإجراء ما يلي:

• تشغيل AutoRepro تلقائيًا لجهازك
• مراجعة رمز ملف إرسال حالي بحثًا عن التغييرات التي يمكن أن تساعد في قبول تقريرك بشكل أسرع
• المساعدة في تنظيم إثبات جدوى جديد استنادًا إلى معلومات حول الثغرة الأمنية

كتابة اختبار 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") هو هجوم اختياري لإثبات الجدوى يستند إلى NDK ويتم نقله إلى الجهاز من خلال adb push ويتم تنفيذه بواسطة الاختبار من جانب المضيف. يستخدمه المثال في الدليل submission/ndkTest/.

يتّبع سير اختبار AutoRepro النموذجي عادةً أحد النمطَين التاليَين:

• تطبيق الاختبار الذي تم تتبّعه:

  1. ينقل الاختبار من جانب المضيف حزمة APK تتألف من تطبيق أو خدمة تم تتبّعهما إلى الجهاز.
  2. يبدأ الاختبار من جانب المضيف اختبارات JUnit من جانب الجهاز المضمّنة في حزمة APK من خلال runDeviceTest().
  3. تنقر اختبارات JUnit من جانب الجهاز على الأزرار وتراقب التطبيق باستخدام UIAutomator، أو تصل بطريقة أخرى إلى واجهات برمجة تطبيقات Android بطرق تكشف عن الثغرات الأمنية.
  4. يتم إرجاع نجاح اختبارات JUnit من جانب الجهاز أو فشلها إلى الاختبار من جانب المضيف، ويمكن استخدام ذلك لتحديد ما إذا كان الاختبار قد اجتاز أم لا. يجب أن تحتوي رسالة الخطأ على معلومات مفصّلة حول سبب فشل التأكيد وأي كائنات أو قيم أو استثناءات أو عمليات تتبُّع مكدس أو بيانات أخرى محدّدة كدليل على الثغرة الأمنية.

• إثبات الجدوى المستند إلى NDK:

  1. ينقل الاختبار من جانب المضيف برنامجًا قابلاً للتنفيذ على Linux ويشغّله على الجهاز.
  2. يتعطّل البرنامج الأصلي أو يعرض رمز خروج معيّنًا.
  3. يبحث الاختبار من جانب المضيف عن الأعطال أو يطّلع على عملية تتبُّع logcat أو يبحث عن رمز الخروج المحدّد لتحديد ما إذا نجح الهجوم. يجب أن تحتوي رسالة الخطأ على معلومات مفصّلة حول سبب فشل التأكيد وأي هياكل أو قيم أو عمليات تتبُّع مكدس أو بيانات أخرى محدّدة كدليل على الثغرة الأمنية.

يمكن أيضًا استخدام مزيج من النمطَين (على سبيل المثال، تشغيل برنامج أصلي بالتزامن مع الاختبارات من جانب الجهاز). تتوفّر أيضًا بعض أُطر عمل التتبُّع الأخرى، مثل frida-inject. لمعرفة التفاصيل، يُرجى الاطّلاع على مستندات مرجع مجموعة أدوات اختبار الأمان ومستندات مرجع Tradefed.

تنظيم إثبات الجدوى

يجب أن يفعل إثبات الجدوى عالي الجودة أكثر من مجرد تشغيل خطأ، بل يجب أن يقدّم دليلاً قابلاً للتحقّق منه على تجاوز حد أمان. لتحقيق ذلك، يمكن أن تتّبع إثباتات الجدوى نمطًا معيّنًا من ثلاث خطوات "الفشل ثم النجاح":

1. الإعداد: يمكنك إعداد الجهاز من خلال تثبيت التطبيقات الضرورية ونقل الملفات والتأكّد من أنّ الجهاز في الحالة المحدّدة المطلوبة مباشرةً قبل عملية الاستغلال. (يُسمح باستخدام الجذر في عملية الإعداد إذا كان ذلك مبرّرًا ويمثّل حالة واقعية للمستخدم النهائي).
2. إثبات تجاوز الحد: قبل تشغيل الثغرة الأمنية، حاوِل تنفيذ الإجراء المستهدَف وأكِّد أنّه يفشل. على سبيل المثال، إذا كان الاستغلال يسمح بقراءة ملف محمي، عليك أولاً محاولة قراءته والتأكّد من تلقّي الخطأ "تم رفض الإذن".
3. التشغيل والتحقّق: شغِّل الثغرة الأمنية، ثم كرِّر على الفور الإجراء من الخطوة 2. على جهاز عرضة للخطر، يجب أن ينجح هذا الإجراء الآن. للتحقّق من ذلك، عليك استخدام تأكيد يفشل على جهاز عرضة للخطر مع رسالة تبدأ بالبادئة الدقيقة 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.

يتضمّن الهجوم الذي أثبتُ فيه جدوى الفكرة تطبيقًا أو خدمة ثانية

يمكنك إضافة أي عدد تريده من المشاريع الفرعية في Gradle باستخدام مكوّنات AutoRepro الإضافية.

إرسال اختبار AutoRepro

لتضمين نتائج الاختبار من جهازك كجزء من عيّنة تم إرسالها:

• يمكنك اختياريًا تشغيل مهمة clean في Gradle لحذف أي عمليات تشغيل اختبار قديمة.
• شغِّل إعداد تشغيل AutoRepro المناسب لاستدعاء Tradefed لاختبارك وجمع السجلّات والنتائج.
• شغِّل مهمة copyInvocationResultsToSubmission لنسخ السجلّات والنتائج إلى دليل مصادر الإرسال.

شغِّل assembleSubmissionZip لإنشاء الملف submission/build/autorepro-submission.zip. حمِّل هذا الملف مع ملف الإرسال إلى برنامج مكافآت Android للمبلّغين عن الثغرات الأمنية. تأكَّد من أنّ الـ مرفق يتطابق مع النمط *autorepro-submission*.zip وأنّه يتم تحميله مع التقرير الأولي. سيؤثر تحميل ملفات الإرسال في وقت متأخر في قدرتنا على مراجعة تقريرك بشكل صحيح.