À 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
Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Le plug-in Gradle AutoRepro est basé sur le banc d'essais de la Android Trade Federation pour tester tous les appareils Android afin de vérifier que les correctifs de sécurité corrigent les failles du bulletin de sécurité Android. Ces tests sont réservés aux correctifs associés ou qui seront associés à une faille CVE (Common Vulnerabilities and Exposures).

Le plug-in permet de développer des tests Tradefed en dehors de l'arborescence de sources Android à l'aide d'Android Studio ou du SDK Android standard. Il comprend tous les utilitaires nécessaires à la création et à l'exécution d'un test Tradefed.

Il est principalement utilisé pour envoyer des preuves de concept 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 paquets de votre distribution.
Outils de plate-forme du SDK Android (adb, fastboot) : 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 la plate-forme consiste à utiliser le gestionnaire de paquets de votre distribution.
- Si vous utilisez le SDK Manager d'Android Studio au lieu d'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 paquets 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 préconfigurées sont disponibles.

Tâches Gradle:

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

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

autorepro_nonroot_arm64
autorepro_nonroot_x86_64
autorepro_root_arm64
autorepro_root_x86_64

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

Ils lanceront Tradefed pour votre test. Tradefed attend qu'un appareil valide soit connecté. Assurez-vous-en et autorisez le débogage ADB.

É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 peut également contenir son propre ensemble d'assertions JUnit qui sont signalées au programme d'exécution 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 preuve de concept facultative basée sur le NDK, qui est transmise à 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 typique suit généralement l'un des deux modèles suivants:

Application de test instrumentée:
1. Le test côté hôte transfère un APK composé 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 associés à 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 de manière à révéler des failles de sécurité.
4. Le succès 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, valeurs, exceptions, traces de pile ou autres artefacts spécifiques comme preuve de la vulnérabilité.
Démonstration de faisabilité du NDK:
1. Le test côté hôte transfère 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 recherche les plantages, examine la rétrocontamination 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 pour laquelle l'assertion a échoué, ainsi que des structures, des valeurs, des traces de pile ou d'autres artefacts spécifiques comme preuve de la vulnérabilité.

Une combinaison des deux modèles (par exemple, l'exécution d'un programme natif en conjonction avec des tests côté appareil) est également possible. 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 Security Test Suite et la documentation de référence de Tradefed.

Mon attaque de preuve de concept ne nécessite pas d'application de test ni d'exécutable natif

La plupart des tests n'exigent pas à la fois une application côté appareil et 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 preuve 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 votre demande:

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 collectez 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 d'envoi.

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