À partir de 2026, pour nous aligner sur notre modèle de développement stable et garantir la stabilité de la plate-forme pour l'écosystème, nous publierons le code source sur AOSP au deuxième et au quatrième trimestre. Pour créer et contribuer à AOSP, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main. La branche de fichier manifeste android-latest-release fera toujours référence à la version la plus récente envoyée à AOSP. Pour en savoir plus, consultez Modifications apportées à AOSP.

Android Security AutoRepro

Le plug-in Gradle AutoRepro est basé sur le harnais de test Android Trade Federation pour tester tous les appareils Android en matière de correctifs de sécurité contre les failles du Bulletin de sécurité Android. Ces tests sont exclusivement réservés aux correctifs associés ou qui seront associés à une faille CVE (Common Vulnerabilities and Exposures).

Ce plug-in permet de développer des tests Tradefed en dehors de l'arborescence source Android à l'aide d'Android Studio ou du SDK Android standard. Il inclut tous les utilitaires nécessaires pour créer et exécuter un test Tradefed.

Il est principalement utilisé pour envoyer des démonstrations de faisabilité reproductibles automatiquement pour le Programme de récompenses pour les failles de sécurité Android.

Exemple de reproduction automatique avec téléchargement direct

Parcourir les exemples et les modèles AutoRepro

Prérequis

Les instructions sont fournies pour un PC Linux 64 bits.

Android Studio Ladybug ou version ultérieure : peut également être installé à partir du gestionnaire de packages de votre distribution.
Outils de plate-forme du SDK Android (adb, fastboot) : ils doivent être installés et se trouver dans votre $PATH (c'est-à-dire que vous devez pouvoir exécuter adb à partir de la ligne de commande). Le moyen le plus simple d'installer les outils de plate-forme consiste à utiliser le gestionnaire de packages de votre distribution.
- Si vous utilisez le SDK Manager d'Android Studio au lieu des outils de plate-forme autonomes, n'oubliez pas d'ajouter le répertoire platform-tools du SDK à votre $PATH pour le développement en ligne de commande.
AAPT2. - Peut également être installé à l'aide du gestionnaire de packages de votre distribution.
Java JDK 21 ou version ultérieure : compatible avec le SDK Android et Gradle.

Premiers pas avec Android Studio

Après avoir extrait l'exemple ou le modèle, ouvrez le répertoire dans Android Studio en tant que projet existant et attendez que la synchronisation Gradle soit terminée. Plusieurs configurations d'exécution Android Studio sont préconfigurées.

Tâches Gradle :

assembleSubmissionSources : assemblez les fichiers sources pour le fichier zip à envoyer.
assembleSubmissionZip : assemblez le fichier ZIP à importer.
copyInvocationResultsToSubmission : copiez les résultats des précédentes invocations Tradefed dans le répertoire des sources de l'envoi AutoRepro pour faciliter le processus d'examen. Notez que cela contient des journaux de l'hôte et de l'appareil. Examinez le contenu avant ou après l'exécution.

Configurations d'exécution Android Studio pour l'appel AutoRepro :

autorepro_nonroot_arm64
autorepro_nonroot_x86_64
autorepro_root_arm64
autorepro_root_x86_64

Les configurations du lanceur sont au format autorepro_{device_root}_{device_arch}. Il est généralement préférable d'utiliser nonroot, car les failles nécessitant la racine sont moins graves. Toutefois, l'utilisation de la racine pour effectuer la configuration ou le nettoyage peut être acceptable à condition qu'elle soit clairement documentée et généralement acceptée comme un état non root valide. Par exemple, il est acceptable d'utiliser le root pour simuler l'envoi de messages texte à l'appareil afin d'éviter d'avoir besoin d'un deuxième appareil et de plusieurs cartes SIM.

Ces commandes lanceront Tradefed pour votre test. Tradefed attend qu'un appareil valide soit connecté. Assurez-vous donc qu'un appareil est connecté et que le débogage ADB est autorisé.

Intégration avec les agents de codage

L'exemple et les modèles fournissent un fichier de contexte AGENTS.md compatible avec Gemini dans Android Studio, la CLI Gemini et d'autres agents de codage. Il contient des opinions sur la structuration des envois et des instructions sur l'utilisation d'AutoRepro. Vous pouvez l'utiliser pour :

Exécuter automatiquement AutoRepro pour votre appareil
Examiner le code d'une demande existante pour identifier les modifications qui peuvent aider à ce que votre rapport soit accepté plus rapidement
Aide à structurer une nouvelle preuve de concept à partir d'informations sur la faille

Écrire un test AutoRepro

Un test AutoRepro comporte trois parties et trois plug-ins Gradle correspondants :

Plug-in Gradle id("com.android.security.autorepro.javahosttest") : test Tradefed côté hôte unique qui interagit avec l'appareil via ADB. L'exemple l'utilise dans le répertoire submission/hostTest/.
Plug-in Gradle id("com.android.security.autorepro.apptest") : APK d'application ou de service installé sur l'appareil via adb install et lancé par le test côté hôte. L'application ou le service peuvent également contenir leur propre ensemble d'assertions JUnit qui sont signalées au lanceur côté hôte. L'exemple l'utilise dans le répertoire submission/appTest/.
Plug-in Gradle id("com.android.security.autorepro.ndktest") : preuve de concept d'attaque basée sur le NDK, facultative, qui est transférée sur l'appareil via adb push et exécutée par le test côté hôte. L'exemple l'utilise dans le répertoire submission/ndkTest/.

Un flux de test AutoRepro type suit généralement l'un des deux schémas suivants :

Application de test instrumentée :
1. Le test côté hôte envoie un APK constitué d'une application ou d'un service instrumenté sur l'appareil.
2. Le test côté hôte démarre les tests JUnit côté appareil qui sont fournis avec l'APK via runDeviceTest().
3. Les tests JUnit côté appareil appuient sur les boutons et surveillent l'application à l'aide d'UIAutomator, ou accèdent aux API Android d'une manière qui révèle des failles de sécurité.
4. La réussite ou l'échec des tests JUnit côté appareil est renvoyée au test côté hôte, qui peut être utilisé pour déterminer si le test a réussi ou non. Le message d'échec doit contenir des informations détaillées sur la raison de l'échec de l'assertion, ainsi que des objets, des valeurs, des exceptions, des traces de pile ou d'autres artefacts spécifiques comme preuve de la vulnérabilité.
Démonstration de faisabilité du NDK :
1. Le test côté hôte envoie et lance un exécutable Linux sur l'appareil.
2. Le programme natif plante ou renvoie un code de sortie spécifique.
3. Le test côté hôte vérifie les plantages, examine la trace de pile logcat ou recherche le code de sortie spécifique pour déterminer si l'attaque a réussi. Le message d'échec doit contenir des informations détaillées sur la raison de l'échec de l'assertion, ainsi que des structs, des valeurs, des traces de pile ou d'autres artefacts spécifiques comme preuve de la faille.

Il est également possible de combiner les deux modèles (par exemple, en exécutant un programme natif en même temps que des tests côté appareil). D'autres frameworks d'instrumentation, tels que frida-inject, sont également disponibles. Pour en savoir plus, consultez la documentation de référence sur la suite de tests de sécurité et la documentation de référence sur Tradefed.

Structuration de la démontrabilité des démonstrations de faisabilité

Une PoC de haute qualité doit faire plus que déclencher un bug. Elle doit fournir une preuve vérifiable qu'une limite de sécurité a été franchie. Pour ce faire, les PoC peuvent suivre un schéma spécifique en trois étapes : "échec, puis réussite".

Configuration : préparez l'appareil en installant les applications nécessaires, en transférant des fichiers et en vous assurant qu'il se trouve dans l'état spécifique requis juste avant l'exploitation. (L'utilisation de la racine est autorisée pour la configuration si elle est justifiée et représentative d'un état réaliste de l'utilisateur final.)
Prouvez la limite : avant de déclencher la faille, tentez l'action cible et affirmez qu'elle échoue. Par exemple, si l'exploit permet de lire un fichier protégé, vous devez d'abord essayer de le lire et confirmer que vous recevez une erreur "Autorisation refusée".
Déclenchez et vérifiez : déclenchez la faille, puis répétez immédiatement l'action de l'étape 2. Sur un appareil vulnérable, cette action devrait maintenant réussir. Pour vérifier cela, vous devez utiliser une assertion qui échoue sur un appareil vulnérable avec un message commençant par le préfixe exact AUTOREPRO_VULNERABILITY_PROVEN:. Ce message doit inclure une description concise de la faille et de tous les artefacts capturés (tels que les données divulguées ou les états inattendus) pour prouver de manière définitive que l'exploitation a réussi.

Exemple :

@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);
    }
}

Mon attaque de démonstration de faisabilité n'a pas besoin d'application de test ni d'exécutable natif

La plupart des tests n'ont pas besoin à la fois d'une application côté appareil et d'un exécutable natif.

Si votre test n'implique pas l'utilisation d'une fonctionnalité, supprimez les répertoires de sous-projets Gradle inutiles.

Mon attaque de validation du concept implique une deuxième application ou un deuxième service

Ajoutez autant de sous-projets Gradle avec des plug-ins AutoRepro que vous le souhaitez.

Envoyer le test AutoRepro

Pour inclure les résultats des tests de votre appareil dans l'envoi :

Vous pouvez également exécuter la tâche Gradle clean pour supprimer les anciennes exécutions de test.
Exécutez la configuration d'exécution AutoRepro appropriée pour appeler Tradefed pour votre test et collecter les journaux et les résultats.
Exécutez la tâche copyInvocationResultsToSubmission pour copier les journaux et les résultats dans le répertoire des sources de l'envoi.

Exécutez assembleSubmissionZip pour créer le fichier submission/build/autorepro-submission.zip. Importez ce fichier avec votre demande dans le programme de récompenses pour la détection de failles d'Android. Assurez-vous que la pièce jointe correspond au modèle *autorepro-submission*.zip et qu'elle est importée avec le rapport initial. Si vous envoyez vos documents en retard, nous ne pourrons pas examiner correctement votre rapport.