À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.

Cette page a été traduite par l'API Cloud Translation.

Android Security AutoRepro

Le plug-in Gradle AutoRepro est basé sur le framework 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 la détection de failles d'Android.

Télécharger l'exemple 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 d'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 root 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é.

É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") : attaque de validation du concept 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é 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 faille.
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 stacktraces 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 de la suite de tests de sécurité et la documentation de référence de Tradefed.

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 de concept implique une deuxième application/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 tests.
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 contribution au 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.